staging: vc04_services: vchiq-mmal: harden MMAL message handling against firmware bugs#7296
Open
Sebasteuo wants to merge 687 commits intoraspberrypi:rpi-6.18.yfrom
Open
staging: vc04_services: vchiq-mmal: harden MMAL message handling against firmware bugs#7296Sebasteuo wants to merge 687 commits intoraspberrypi:rpi-6.18.yfrom
Sebasteuo wants to merge 687 commits intoraspberrypi:rpi-6.18.yfrom
Conversation
The initialisation sequence differs slightly from the documentation in that the clocks are meant to be running before resets and similar. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
vc4_dsi_bridge_disable wasn't resetting things during shutdown, so add that in. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The block must be enabled for the FIFO resets to be actioned, so ensure this is the case. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The pixel to byte FIFO appears to not always reset correctly, which can lead to colour errors and/or horizontal shifts. Reset on every vblank to work around the issue. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The TC358762 bridge and panel decodes the mode differently on DSI0 to DSI1 for no obvious reason, and results in a shift off the screen. Whilst it would be possible to change the compatible used for the panel, that then messes up Pi5. As it appears to be restricted to vc4 DSI0, fix up the mode in vc4_dsi. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Some DSI peripheral drivers wish to send commands in the post_disable or panel unprepare callback. These are called after the DSI host's disable call, but before the host's post_disable if pre_enable_prev_first is set. Don't reset the block until post_disable to allow these commands to be sent. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The DSI block appears to be able to come up stuck in a condition where it leaves the lanes in HS mode or just jabbering. This stops LP transfers from completing as there is no LP time available. This is signalled via the LP1 contention error. Enabling video briefly clears that condition, so if we detect the error condition, enable video mode and then retry. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Similar to the ch7006 and nouveau drivers, introduce a "tv_mode" module parameter that allow setting the TV norm by specifying vc4.tv_norm= on the kernel command line. If that is not specified, try inferring one of the most popular norms (PAL or NTSC) from the video mode specified on the command line. On Raspberry Pis, this causes the most common cases of the sdtv_mode setting in config.txt to be respected. Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> drm/vc4: Do not reset tv mode as this is already handled by framework In vc4_vec_connector_reset, the tv mode is already reset to the property default by drm_atomic_helper_connector_tv_reset, so there is no need for a local fixup to potentially some other default. Fixes: 96922af ("drm/vc4: Allow setting the TV norm via module parameter") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
With the command line parser now providing the information about the tv mode, use that as the preferred choice for initialising the default of the tv_mode property. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
If you disable HDR metadata, then the hardware should stop sending the infoframe, and that is implemented by the clear_infoframe hook which wasn't implemented. Add it. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
See: https://forum.libreelec.tv/thread/24783-tv-avr-turns-back-on-right-after-turning-them-off While the kernel provides a :D flag for assuming device is connected, it doesn't stop this function from being called and generating a cec_phys_addr_invalidate message when hotplug is deasserted. That message provokes a flurry of CEC messages which for many users results in the TV switching back on again and it's very hard to get it to stay switched off. It seems to only occur with an AVR and TV connected but has been observed across a number of manufacturers. The issue started with raspberrypi#4371 and this provides an optional way of getting back the old behaviour Signed-off-by: Dom Cobley <popcornmix@gmail.com>
The intention of the vc4.force_hotplug setting is to ignore hotplug completely. It can be used when a display toggles hotplug when switching AV inputs, going into standby or changing a KVM switch, and some side effect of that is unwanted. It turns out while vc4.force_hotplug currently makes hotplug always read as asserted, that isn't enough to stop drm doing lots of stuff, including re-reading the edid. An example of what drm does with a hotplug deasert/assert and vc4.force_hotplug=1 currently is: https://paste.debian.net/hidden/dc07434b/ That is unwanted. Lets ignore the hotplug interrupt completely so drm is blissfully unaware of the hotplug change. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
There appears to be a requirement for some devices (I'm testing with a 8K VRROOM 40Gbps HDMI switch) for a measable delay between removing the hdmi phy output from the old mode, to enabling the hdmi phy output for the new mode. Without the delay, a mode switch has a small change of getting a permanent 'no signal', which requires a subsequent mode switch or a unplug/replug to redetect. Switching between 4kp24/25/30 modes fails about 5% of time in my testing. Add a delay to make it impossible to switch faster than this. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
The body of this function was missing so we don't reset the phy when disabling it. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
The current reset code doesn't actually stop the hdmi output. That makes it difficult for displays to handle a mode set. Powering down the PLL does actually remove the hdmi signal and makes mode sets more reliable Signed-off-by: Dom Cobley <popcornmix@gmail.com>
There are no MEDIA_BUS_FMT_* defines for GRB or BRG, and adding them is a pain. Add a DT override to allow setting the order. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Seeing as the HVS can be configured with regard the scaling filter, and DRM now supports selecting scaling filters at a per CRTC or per plane level, we can implement it. Default remains as the Mitchell/Netravali filter, but nearest neighbour is now also implemented. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The documentation says that the TPZ filter can not upscale, and requesting a scaling factor > 1:1 will output the original image in the top left, and repeat the right/bottom most pixels thereafter. That fits perfectly with upscaling a 1x1 image which is done a fair amount by some compositors to give solid colour, and it saves a large amount of LBM (TPZ is based on src size, whilst PPF is based on dest size). Select TPZ filter for images with source rectangle <=1. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The register to enable/disable background fill was being set from atomic flush, however that will be applied immediately and can be a while before the vblank. If it was required for the current frame but not for the next one, that can result in corruption for part of the current frame. Store the state in vc4_hvs, and update it on vblank. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The HVS can accept an arbitrary number of planes, provided that the overall pixel read load is within limits, and the display list can fit into the dlist memory. Now that DRM will support 64 planes per device, increase the number of overlay planes from 16 to 48 so that the dlist complexity can be increased (eg 4x4 video wall on each of 3 displays). Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Instead of having 48 generic overlay planes, assign 32 to the writeback connector so that there is no ambiguity in wlroots when trying to find a plane for composition using the writeback connector vs display. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The transposer/writeback connector should be running with a lower priority, so shouldn't be factored into the load calculations. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
As the writeback connector doesn't have the same realtime constraints of a live display, drop the panic priority for it. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The txp block can implement transpose as it writes out the image data, so expose that through the new connector rotation property. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm: vc4: txp: Do not allow 24bpp formats when transposing The hardware doesn't support transposing to 24bpp (RGB888/BGR888) formats. There's no way to advertise this through DRM, so block it from atomic_check instead. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Currently, booting with no hdmi connected has: pi@pi4:~ $ vcgencmd measure_clock hdmi pixel frequency(9)=120010256 frequency(29)=74988280 After connecting hdmi we get: pi@pi4:~ $ vcgencmd measure_clock hdmi pixel frequency(9)=300005856 frequency(29)=149989744 and that persists after disconnecting hdmi I can measure this on a power supply as 10mA@5.2V (52mW). We should always remove clk_set_min_rate requests when we no longer need them. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Whilst BCM2712 does fix using odd horizontal timings, it doesn't work with interlaced modes. Drop the workaround for interlaced modes and revert to the same behaviour as BCM2711. raspberrypi#6281 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
This is a squash of all firmware-kms related patches from previous branches, up to and including "drm/vc4: Set the possible crtcs mask correctly for planes with FKMS" plus a couple of minor fixups for the 5.9 branch. Please refer to earlier branches for full history. This patch includes work by Eric Anholt, James Hughes, Phil Elwell, Dave Stevenson, Dom Cobley, and Jonathon Bell. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: Fixup firmware-kms after "drm/atomic: Pass the full state to CRTC atomic enable/disable" Prototype for those calls changed, so amend fkms (which isn't upstream) to match. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: Fixup fkms for API change Atomic flush and check changed API, so fix up the downstream-only FKMS driver. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: Make normalize_zpos conditional on using fkms Eric's view was that there was no point in having zpos support on vc4 as all the planes had the same functionality. Can be later squashed into (and fixes): drm/vc4: Add firmware-kms mode Signed-off-by: Dom Cobley <popcornmix@gmail.com> drm/vc4: FKMS: Change of Broadcast RGB mode needs a mode change The Broadcast RGB (aka HDMI limited/full range) property is only notified to the firmware on mode change, so this needs to be signalled when set. raspberrypi/firmware#1580 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> vc4/drv: Only notify firmware of display done with kms fkms driver still wants firmware display to be active Signed-off-by: Dom Cobley <popcornmix@gmail.com> ydrm/vc4: fkms: Fix margin calculations for the right/bottom edges The calculations clipped the right/bottom edge of the clipped range based on the left/top margins. raspberrypi#4447 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: fkms: Use new devm_rpi_firmware_get api drm/kms: Add allow_fb_modifiers Signed-off-by: Dom Cobley <popcornmix@gmail.com> drm/vc4: Add async update support for cursor planes Now that cursors are implemented as regular planes, all cursor movements result in atomic updates. As the firmware-kms driver doesn't support asynchronous updates, these are synchronous, which limits the update rate to the screen refresh rate. Xorg seems unaware of this (or at least of the effect of this), because if the mouse is configured with a higher update rate than the screen then continuous mouse movement results in an increasing backlog of mouse events - cue extreme lag. Add minimal support for asynchronous updates - limited to cursor planes - to eliminate the lag. See: raspberrypi#4971 raspberrypi#4988 Signed-off-by: Phil Elwell <phil@raspberrypi.com> drivers/gpu/drm/vc4: Add missing 32-bit RGB formats The missing 32-bit per pixel ABGR and various "RGB with an X value" formats are added. Change sent by Dave Stevenson. Signed-off-by: David Plowman <david.plowman@raspberrypi.com> drm: vc4: Fixup duplicated macro definition in vc4_firmware_kms Both vc4_drv.h and vc4_firmware_kms.c had definitions for to_vc4_crtc. Rename the fkms one to make it unique, and drop the magic define vc4_crtc vc4_kms_crtc define to_vc4_crtc to_vc4_kms_crtc that renamed half the variable and function names in a slightly unexpected way. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: Fix FKMS for when the YUV chroma planes are different buffers The code was assuming that it was a single buffer with offsets, when kmstest uses separate buffers and 0 offsets for each plane. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: fkms: Rename plane related functions The name collide with the Full KMS functions that are going to be made public. Signed-off-by: Maxime Ripard <maxime@cerno.tech> drm/vc4_fkms: Fix up interrupt handler for both 2835/2711 and 2712 2712 has switched from using the SMI peripheral to another interrupt source for the vsync interrupt, so handle both sources cleanly. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: fkms: No SMI abuse needed on BCM2712 Since we don't use the (absent) SMI block to create interrupts on BCM2712, there's no need to map any registers. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Testing whether the VideoCore generation we want to mock is vc5 or vc4 worked so far, but will be difficult to extend to support BCM2712 (VC6). Convert to a switch. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The DRM device pointer and the DRM encoder pointer are redundant, since the latter is attached to the former and we can just follow the drm_encoder->dev pointer. Let's remove the drm_device pointer argument. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Move all resource allocation operations before actually enabling the clock, as those operations don't require the GPU to be powered on. This is a preparation for runtime PM support. The next commit will move all code related to powering on and initiating the GPU into the runtime PM resume callback and all resource allocation will happen before resume(). Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
Commit 90a64ad ("drm/v3d: Get rid of pm code") removed the last bits of power management code that V3D had, which were actually never hooked. Therefore, currently, the GPU clock is enabled during probe and only disabled when removing the driver. Implement proper power management using the kernel's Runtime PM framework. Signed-off-by: Maíra Canal <mcanal@igalia.com>
commit 237577e upstream The GEM MAC provides four read-only, clear-on-read LPI statistics registers at offsets 0x270-0x27c: GEM_RXLPI (0x270): RX LPI transition count (16-bit) GEM_RXLPITIME (0x274): cumulative RX LPI time (24-bit) GEM_TXLPI (0x278): TX LPI transition count (16-bit) GEM_TXLPITIME (0x27c): cumulative TX LPI time (24-bit) Add register offset definitions, extend struct gem_stats with corresponding u64 software accumulators, and register the four counters in gem_statistics[] so they appear in ethtool -S output. Because the hardware counters clear on read, the existing macb_update_stats() path accumulates them into the u64 fields on every stats poll, preventing loss between userspace reads. These registers are present on SAMA5D2, SAME70, PIC32CZ, and RP1 variants of the Cadence GEM IP and have been confirmed on RP1 via devmem reads. Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com> Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
commit 0cc425f upstream The GEM MAC has hardware LPI registers (NCR bit 19: TXLPIEN) but no built-in idle timer, so asserting TXLPIEN blocks all TX immediately with no automatic wake. A software idle timer is required, as noted in Microchip documentation (section 40.6.19): "It is best to use firmware to control LPI." Implement phylink managed EEE using the mac_enable_tx_lpi and mac_disable_tx_lpi callbacks: - macb_tx_lpi_set(): sets or clears TXLPIEN; requires bp->lock to be held by the caller (asserted with lockdep_assert_held). Returns bool indicating whether the register actually changed, avoiding redundant writes and unnecessary udelay on the xmit fast path. - macb_tx_lpi_work_fn(): delayed_work handler that enters LPI if all TX queues are idle and EEE is still active. Takes bp->lock with irqsave before calling macb_tx_lpi_set(). - macb_tx_lpi_schedule(): arms the work timer using the LPI timer value provided by phylink (default 250 ms). Called from macb_tx_complete() after each TX drain so the idle countdown restarts whenever the ring goes quiet. - macb_tx_lpi_wake(): called from macb_start_xmit() under bp->lock, immediately before TSTART. Returns early if eee_active is false to avoid a register read on the common path when EEE is disabled. Clears TXLPIEN and applies a 50 us udelay for PHY wake (IEEE 802.3az Tw_sys_tx is 16.5 us for 1000BASE-T / 30 us for 100BASE-TX; GEM has no hardware enforcement). Only delays when TXLPIEN was actually set. The delay is placed after tx_head is advanced so the work_fn's queue-idle check sees a non-empty ring and cannot race back into LPI before the frame is transmitted. - mac_enable_tx_lpi: stores the timer and sets eee_active under bp->lock, then defers the first LPI entry by 1 second per IEEE 802.3az section 22.7a. - mac_disable_tx_lpi: cancels the work (sync, without the lock to avoid deadlock with the work_fn), then takes bp->lock to clear eee_active and deassert TXLPIEN. Populate phylink_config lpi_interfaces (MII, GMII, RGMII variants) and lpi_capabilities (MAC_100FD | MAC_1000FD) so phylink can negotiate EEE with the PHY and call the callbacks appropriately. Set lpi_timer_default to 250000 us and eee_enabled_default to true. Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com> Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
commit 61332b7 upstream Implement get_eee and set_eee ethtool ops for GEM as simple passthroughs to phylink_ethtool_get_eee() and phylink_ethtool_set_eee(). No MACB_CAPS_EEE guard is needed: phylink returns -EOPNOTSUPP from both ops when mac_supports_eee is false, which is the case when lpi_capabilities and lpi_interfaces are not populated. Those fields are only set when MACB_CAPS_EEE is present (previous patch), so phylink already handles the unsupported case correctly. Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com> Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
commit 92ba330 upstream Set MACB_CAPS_EEE for the Raspberry Pi 5 RP1 southbridge (Cadence GEM_GXL rev 0x00070109 paired with BCM54213PE PHY). EEE has been verified on RP1 hardware: the LPI counter registers at 0x270-0x27c return valid data, the TXLPIEN bit in NCR (bit 19) controls LPI transmission correctly, and ethtool --show-eee reports the negotiated state after link-up. Other GEM variants that share the same LPI register layout (SAMA5D2, SAME70, PIC32CZ) can be enabled by adding MACB_CAPS_EEE to their respective config entries once tested. Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com> Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
BCM54213PE (PHY_ID = 0x600d84a2) and BCM54210E share the same model ID when masked by PHY_ID_MATCH_MODEL_MASK (0xfffffff0): both reduce to 0x600d84a0. The dispatch switch in bcm54xx_config_init() switches on phydev->drv->phy_id & PHY_ID_MATCH_MODEL_MASK, so the separate case PHY_ID_BCM54213PE: could never match — the expression always evaluated to 0x600d84a0, not 0x600d84a2. bcm54213pe_config_init() was silently never called; BCM54213PE instead fell through to the BCM54210E path. Replace the dead case label with an exact driver ID check inside the BCM54210E case, which already handles the same model ID family. Fixes: 1001c6f ("phy: broadcom: Add bcm54213pe configuration") Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
BCM54xx PHYs default to AutogrEEEn mode (MII_BUF_CNTL_0 bit 0), which manages EEE Low Power Idle autonomously without forwarding LPI signaling to the MAC over the RGMII interface. This prevents the MAC from tracking LPI activity and controlling TX LPI entry/exit. Unconditionally clear the AutogrEEEn enable bit during config_init to switch all BCM54xx PHYs to Native EEE mode. In Native EEE mode the MAC controls TX LPI and the PHY forwards received LPI on the RGMII interface, allowing MACs with IEEE 802.3az support to observe RX LPI transitions. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Reverts 85b196f ("dts: cm5/pi5: Disable EEE on rp1"). Now that the macb driver supports EEE via the phylink managed EEE API, the BCM54213PE PHY can advertise EEE correctly and the MAC will handle TX LPI entry/exit properly. Remove the eee-broken-1000t and eee-broken-100tx properties that were added as a workaround when the macb driver lacked EEE support. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Add an eee dtparam to allow users to disable EEE on the BCM54213PE PHY without recompiling the device tree. Setting dtparam=eee=off adds the eee-broken-1000t and eee-broken-100tx properties to the PHY node which prevents EEE advertisement and negotiation. EEE is enabled by default (dtparam=eee=on). Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Reverts 42b77dd ("net: bcmgenet: Add 'eee' module parameter") for the DTS side. The downstream driver patch can be dropped as the same functionality is now handled entirely in device tree, removing one downstream-only driver change from the tree. Move the eee dtparam from the shared bcm2711-rpi-ds.dtsi into the individual Pi4 and CM4 device trees (where phy1 is defined), using eee-broken-1000t and eee-broken-100tx properties on the PHY node. This prevents EEE advertisement at the PHY level without requiring driver modifications. CM4S is excluded as it has no onboard Ethernet. Setting dtparam=eee=off adds the eee-broken properties to the PHY node which prevents EEE negotiation entirely. EEE is enabled by default (dtparam=eee=on). Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Some Goodix controllers report the buffer isn't ready continuously when there are no touch points to report. That triggers the retry mechanism within the driver required as supposedly the data can be 10ms after the interrupt occurs. Seeing as we don't have an interrupt there is little point in retrying, and we can wait for the next poll event. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The [AX]RGB8888 and [AX]BGR8888 formats were all in the translation list, but RGB[AX]8888 and BGR[AX]8888 weren't. Seeing as the writeback connector had them in the list of supported formats, that meant it could generate content that couldn't be input. Add the relevant translations. Whilst T-Format support should be possible, it has not been added at this stage. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
BCM2711 fixes PLLC, so there's no need to avoid it. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
This reverts commit 44d0986.
This reverts commit 627b64f.
Retain the original compatible strings as fallbacks. See: raspberrypi#7023 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
On pi this was getting set to 0 which was hanging the firmware Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Commit de9e2b3d88af upstream. Currently DIV_ROUND_CLOSEST() is only available for the kernel via include/linux/math.h. Expose it to userland as well by adding __KERNEL_DIV_ROUND_CLOSEST() as a common definition in uapi. Additionally, ensure it allows building ISO C applications by switching from the 'typeof' GNU extension to the ISO-friendly __typeof__. Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Diederik de Haas <diederik@cknow-tech.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260303-rk3588-bgcolor-v8-1-fee377037ad1@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
Commit 4c684596cde4 upstream. Some display controllers can be hardware programmed to show non-black colors for pixels that are either not covered by any plane or are exposed through transparent regions of higher planes. This feature can help reduce memory bandwidth usage, e.g. in compositors managing a UI with a solid background color while using smaller planes to render the remaining content. To support this capability, introduce the BACKGROUND_COLOR standard DRM mode property, which can be attached to a CRTC through the drm_crtc_attach_background_color_property() helper function. Additionally, define a 64-bit ARGB format value to be built with the help of a couple of dedicated DRM_ARGB64_PREP*() helpers. Individual color components can be extracted with desired precision using the corresponding DRM_ARGB64_GET*() macros. Co-developed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Diederik de Haas <diederik@cknow-tech.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260303-rk3588-bgcolor-v8-2-fee377037ad1@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
When adding the register definitions for the GEN_6D hardware, 6 defines managed to get added twice. Remove that duplication. Fixes: 3ca2940 ("drm/vc4: hvs: Add in support for 2712 D-step.") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Since a previous patch introduced the BACKGROUND_COLOR CRTC property, which defaults to solid black, take it into account when programming the hardware. The exact registers used varies between the hardware generations, but is supported by all of them. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The downstream implementation of power management for v3d used a 100ms delay and it has been tested for many years with success. Use the same delay with the runtime PM implementation. Although the shorter 50ms delay is not problematic in RPi 5, it can cause occasional GPU resets on RPi 4 during intensive workloads, due to the overhead of negotiating with the ASB bridge during frequent power domain transitions. Signed-off-by: Maíra Canal <mcanal@igalia.com>
The PHY supports swapping the pairs within a lane, so expose this. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The driver uses a couple of crypto_shash_* functions, which are not always available, potentially leading to build errors: arm-linux-ld: drivers/spi/spi-rp2040-gpio-bridge.o: in function `rp2040_gbdg_block_hash': spi-rp2040-gpio-bridge.c:(.text+0x274): undefined reference to `crypto_shash_update' spi-rp2040-gpio-bridge.c:(.text+0x2c4): undefined reference to `crypto_shash_update' spi-rp2040-gpio-bridge.c:(.text+0x2e4): undefined reference to `crypto_shash_final' spi-rp2040-gpio-bridge.c:(.text+0x2ec): undefined reference to `crypto_shash_digest' spi-rp2040-gpio-bridge.c:(.text+0x2fc): undefined reference to `crypto_shash_update' arm-linux-ld: drivers/spi/spi-rp2040-gpio-bridge.o: in function `rp2040_gbdg_probe': spi-rp2040-gpio-bridge.c:(.text+0x510): undefined reference to `crypto_alloc_shash' Fixes: fe24eda ("spi: Add a driver for the RPI RP2040 GPIO bridge") Signed-off-by: Corubba Smith <corubba@gmx.de>
…_to_host_cb() event_to_host_cb() uses msg->u.event_to_host.client_component as an index into the instance->component[] array (size VCHIQ_MMAL_MAX_COMPONENTS = 64) without bounds validation. While the kernel generally trusts the hardware it is bound to, a bounds check here hardens the driver against potential firmware bugs that could otherwise cause an uncontrolled out-of-bounds array access and kernel crash. Add a bounds check on comp_idx before using it as an array index and move the component pointer assignment after the validation. Use pr_err_ratelimited() to avoid log flooding. Note: this file does not currently have access to a struct device, so dev_err() is not available. Cc: stable@vger.kernel.org Fixes: b18ee53 ("staging: bcm2835: Break MMAL support out from camera") Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
…eceive() inline_receive() copies payload data from a VCHIQ message into a destination buffer using payload_in_message as the copy length, but never validates that this length fits within the destination buffer (msg_context->u.bulk.buffer->buffer_size). While the caller validates payload_in_message <= MMAL_VC_SHORT_DATA (128) to prevent overreading the source, the destination buffer may be smaller than 128 bytes. This is inconsistent with bulk_receive() which does check buffer_size before copying. Add a bounds check against buffer_size and truncate the copy length if it exceeds the destination capacity, matching the defensive pattern used in bulk_receive(). Use pr_warn_ratelimited() for the truncation warning. Cc: stable@vger.kernel.org Fixes: b18ee53 ("staging: bcm2835: Break MMAL support out from camera") Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
…rameter_set() port_parameter_set() copies value_size bytes from the caller-supplied value buffer into the stack-allocated struct mmal_msg's port_parameter_set.value field, which is u32[96] (384 bytes). There is no bounds check on value_size before the memcpy. While current in-tree callers pass small fixed-size structures, the function is exported via EXPORT_SYMBOL_GPL and accessible to any GPL kernel module. A caller passing value_size > 384 would overflow the stack-allocated mmal_msg structure. Add a bounds check rejecting value_size larger than the value field. Cc: stable@vger.kernel.org Fixes: b18ee53 ("staging: bcm2835: Break MMAL support out from camera") Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
…ameter_get() port_parameter_get() subtracts 2 * sizeof(u32) from the VideoCore firmware's reply size field to compute the parameter value size. If the firmware returns a size smaller than 8, the subtraction wraps around to a large value due to unsigned integer underflow. The underflowed size is then used in a comparison that selects the wrong copy path and stored back to the caller via *value_size, propagating a bogus size to subsequent operations. Add a minimum size check before the subtraction and return -EPROTO if the reply is malformed. Cc: stable@vger.kernel.org Fixes: b18ee53 ("staging: bcm2835: Break MMAL support out from camera") Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This series adds defensive bounds checks to the MMAL VCHIQ driver
to harden against potential firmware bugs or malformed responses
from the VideoCore GPU.
Patch 1/4: Validate client_component index in event_to_host_cb()
before using it as an array index into the 64-element component[]
array. A firmware bug returning an out-of-range value would cause
an OOB array access.
Patch 2/4: Add buffer size check in inline_receive() before
memcpy. The payload_in_message field (up to 128 bytes) is used
as the copy size without checking the destination buffer_size.
Patch 3/4: Prevent stack overflow in port_parameter_set() by
validating value_size against the 384-byte destination before
memcpy.
Patch 4/4: Fix integer underflow in port_parameter_get() where
a firmware reply size field is subtracted without minimum check,
potentially wrapping to ~4GB.
All checks use pr_err_ratelimited() and the patches are framed
as hardening rather than security fixes per Greg KH's guidance.
Found through manual source code auditing.
Reported-by: Sebastián Alba Vives sebasjosue84@gmail.com
Signed-off-by: Sebastián Alba Vives sebasjosue84@gmail.com