p71924506
/
linux_old1
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

A bunch of fixes to avoid null pointer dereference in fbcon, fix a return 

in xen, some DT bindings fixes, a vc4 issue with 1920x1200 mode validation,
 and a conflicting framebuffer in vboxvideo.
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXohMogAKCRDj7w1vZxhR
 xd7kAQCCO8qphr1Quf7SeyCW5hVLiikpeQKoxnYX2jO7M/+SKQD/XEtxDX5qZ6Jx
 pVBu2N8Qr+fKSnxG6VNF/eg6XAO6igg=
 =NZMp
 -----END PGP SIGNATURE-----

Merge tag 'drm-misc-next-fixes-2020-04-04' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

A bunch of fixes to avoid null pointer dereference in fbcon, fix a return
in xen, some DT bindings fixes, a vc4 issue with 1920x1200 mode validation,
and a conflicting framebuffer in vboxvideo.

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200404090057.a3m7uw6tavwtcyon@gilmour.lan
This commit is contained in:
Dave Airlie 2020-04-08 09:14:21 +10:00
parent 0a1a6793d0 d8a26d8fc3
commit 3208a24f2b
11 changed files with 37 additions and 44 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
View File

@ -21,15 +21,6 @@ properties:
- {}
- const: panel-dpi
data-mapping:
enum:
- rgb24
- rgb565
- bgr666
description: |
Describes the media format, how the display panel is connected
to the display interface.
backlight: true
enable-gpios: true
height-mm: true
@ -52,7 +43,6 @@ examples:
compatible = "osddisplays,osd057T0559-34ts", "panel-dpi";
label = "osddisplay";
power-supply = <&vcc_supply>;
data-mapping = "rgb565";
backlight = <&backlight>;
port {

4
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
View File

@ -65,7 +65,7 @@ properties:
ports:
type: object
description:
Ports as described in Documentation/devictree/bindings/graph.txt
Ports as described in Documentation/devicetree/bindings/graph.txt
properties:
"#address-cells":
const: 1
@ -121,7 +121,7 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/soc/ti,sci_pm_domain.h>
dss: dss@04a00000 {
dss: dss@4a00000 {
compatible = "ti,am65x-dss";
reg = <0x0 0x04a00000 0x0 0x1000>, /* common */
<0x0 0x04a02000 0x0 0x1000>, /* vidl1 */

4
Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
View File

@ -98,7 +98,7 @@ properties:
ports:
type: object
description:
Ports as described in Documentation/devictree/bindings/graph.txt
Ports as described in Documentation/devicetree/bindings/graph.txt
properties:
"#address-cells":
const: 1
@ -154,7 +154,7 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/soc/ti,sci_pm_domain.h>
dss: dss@04a00000 {
dss: dss@4a00000 {
compatible = "ti,j721e-dss";
reg = <0x00 0x04a00000 0x00 0x10000>, /* common_m */
<0x00 0x04a10000 0x00 0x10000>, /* common_s0*/

4
Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
View File

@ -56,7 +56,7 @@ properties:
port:
type: object
description:
Port as described in Documentation/devictree/bindings/graph.txt.
Port as described in Documentation/devicetree/bindings/graph.txt.
The DSS DPI output port node
max-memory-bandwidth:
@ -81,7 +81,7 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
dss: dss@02540000 {
dss: dss@2540000 {
compatible = "ti,k2g-dss";
reg = <0x02540000 0x400>,
<0x02550000 0x1000>,

11
drivers/dma-buf/Kconfig
View File

@ -43,11 +43,12 @@ config DMABUF_MOVE_NOTIFY
bool "Move notify between drivers (EXPERIMENTAL)"
default n
help
Don''t pin buffers if the dynamic DMA-buf interface is available on both the
exporter as well as the importer. This fixes a security problem where
userspace is able to pin unrestricted amounts of memory through DMA-buf.
But marked experimental because we don''t jet have a consistent execution
context and memory management between drivers.
Don't pin buffers if the dynamic DMA-buf interface is available on
both the exporter as well as the importer. This fixes a security
problem where userspace is able to pin unrestricted amounts of memory
through DMA-buf.
This is marked experimental because we don't yet have a consistent
execution context and memory management between drivers.
config DMABUF_SELFTESTS
tristate "Selftests for the dma-buf interfaces"

8
drivers/gpu/drm/drm_mm.c
View File

@ -45,7 +45,6 @@
#include <linux/export.h>
#include <linux/interval_tree_generic.h>
#include <linux/seq_file.h>
#include <linux/sched/signal.h>
#include <linux/slab.h>
#include <linux/stacktrace.h>
@ -367,11 +366,6 @@ next_hole(struct drm_mm *mm,
struct drm_mm_node *node,
enum drm_mm_insert_mode mode)
{
/* Searching is slow; check if we ran out of time/patience */
cond_resched();
if (fatal_signal_pending(current))
return NULL;
switch (mode) {
default:
case DRM_MM_INSERT_BEST:
@ -563,7 +557,7 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
return 0;
}
return signal_pending(current) ? -ERESTARTSYS : -ENOSPC;
return -ENOSPC;
}
EXPORT_SYMBOL(drm_mm_insert_node_in_range);

11
drivers/gpu/drm/panel/panel-simple.c
View File

@ -361,7 +361,6 @@ static int panel_dpi_probe(struct device *dev,
struct panel_desc *desc;
unsigned int bus_flags;
struct videomode vm;
const char *mapping;
int ret;
np = dev->of_node;
@ -386,16 +385,6 @@ static int panel_dpi_probe(struct device *dev,
of_property_read_u32(np, "width-mm", &desc->size.width);
of_property_read_u32(np, "height-mm", &desc->size.height);
of_property_read_string(np, "data-mapping", &mapping);
if (!strcmp(mapping, "rgb24"))
desc->bus_format = MEDIA_BUS_FMT_RGB888_1X24;
else if (!strcmp(mapping, "rgb565"))
desc->bus_format = MEDIA_BUS_FMT_RGB565_1X16;
else if (!strcmp(mapping, "bgr666"))
desc->bus_format = MEDIA_BUS_FMT_RGB666_1X18;
else if (!strcmp(mapping, "lvds666"))
desc->bus_format = MEDIA_BUS_FMT_RGB666_1X24_CPADHI;
/* Extract bus_flags from display_timing */
bus_flags = 0;
vm.flags = timing->flags;

4
drivers/gpu/drm/vboxvideo/vbox_drv.c
View File

@ -41,6 +41,10 @@ static int vbox_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (!vbox_check_supported(VBE_DISPI_ID_HGSMI))
return -ENODEV;
ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, "vboxvideodrmfb");
if (ret)
return ret;
vbox = kzalloc(sizeof(*vbox), GFP_KERNEL);
if (!vbox)
return -ENOMEM;

20
drivers/gpu/drm/vc4/vc4_hdmi.c
View File

@ -681,11 +681,23 @@ static enum drm_mode_status
vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
const struct drm_display_mode *mode)
{
/* HSM clock must be 108% of the pixel clock. Additionally,
* the AXI clock needs to be at least 25% of pixel clock, but
* HSM ends up being the limiting factor.
/*
* As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
* be faster than pixel clock, infinitesimally faster, tested in
* simulation. Otherwise, exact value is unimportant for HDMI
* operation." This conflicts with bcm2835's vc4 documentation, which
* states HSM's clock has to be at least 108% of the pixel clock.
*
* Real life tests reveal that vc4's firmware statement holds up, and
* users are able to use pixel clocks closer to HSM's, namely for
* 1920x1200@60Hz. So it was decided to have leave a 1% margin between
* both clocks. Which, for RPi0-3 implies a maximum pixel clock of
* 162MHz.
*
* Additionally, the AXI clock needs to be at least 25% of
* pixel clock, but HSM ends up being the limiting factor.
*/
if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100))
if (mode->clock > HSM_CLOCK_FREQ / (1000 * 101 / 100))
return MODE_CLOCK_HIGH;
return MODE_OK;

2
drivers/gpu/drm/xen/xen_drm_front.c
View File

@ -401,7 +401,7 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
obj = xen_drm_front_gem_create(dev, args->size);
if (IS_ERR_OR_NULL(obj)) {
ret = PTR_ERR(obj);
ret = PTR_ERR_OR_ZERO(obj);
goto fail;
}

3
drivers/video/fbdev/core/fbcon.c
View File

@ -1282,6 +1282,9 @@ static void fbcon_deinit(struct vc_data *vc)
if (!con_is_bound(&fb_con))
fbcon_exit();
if (vc->vc_num == logo_shown)
logo_shown = FBCON_LOGO_CANSHOW;
return;
}