Skip to content

Fixes for https://github.com/raspberrypi/linux/issues/7301#7302

Open
by wants to merge 625 commits intoraspberrypi:rpi-7.0.yfrom
by:rpi-7.0.y
Open

Fixes for https://github.com/raspberrypi/linux/issues/7301#7302
by wants to merge 625 commits intoraspberrypi:rpi-7.0.yfrom
by:rpi-7.0.y

Conversation

@by
Copy link
Copy Markdown

@by by commented Apr 3, 2026

These are the two fixes I successfully tested to mitigate #7301

6by9 and others added 30 commits March 30, 2026 12:34
Pass the DRM connector name to any configured backlight
device so that userspace can associate the two items.

Ideally this should be in drm_panel, but it is bridge/panel
that creates the drm_connector and therefore knows the name.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

drm/bridge: panel: Ensure backlight is reachable

Ensure that the various options of modules vs builtin results
in being able to call into the backlight code.

raspberrypi#6198

Fixes: 573f8fd ("drm/bridge: panel: Name an associated backlight device")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Offset the backend dev-nodes starting at /dev/video20
onwards to maintain backward compatibility with the
pre-upstreamed kernel driver.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Add YAML device tree bindings for the Raspberry Pi RP2040 GPIO Bridge.

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>
The Raspberry Pi RP2040 GPIO bridge is an I2C-attached device exposing
both a Tx-only SPI controller, and a GPIO controller.

Due to the relative difference in transfer rates between standard-mode
I2C and SPI, the GPIO bridge makes use of 12 MiB of non-volatile storage
to cache repeated transfers. This cache is arranged in ~8 KiB blocks and
is addressed by the MD5 digest of the data contained therein.

Optionally, this driver is able to take advantage of Raspberry Pi RP1
GPIOs to achieve faster than I2C data transfer rates.

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>

spi: rp2040-gpio-bridge: Add debugfs progress indicator

Useful for tracking upload progress via userspace.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

spi: rp2040-gpio-bridge: add missing MD5 dependency

rp2040-gpio-bridge relies on the md5 crypto driver. This dependency
cannot be determined automatically as rp2040-gpio-bridge does not
use any of md5's symbols directly.

Declare a soft 'pre' dependency on md5 to ensure that it is included and
loaded before rp2040-gpio-bridge.

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>

spi: rp2040-gpio-bridge: fix gpiod error handling

In some circumstances, devm_gpiod_get_array_optional() can return
PTR_ERR rather than NULL to indicate failure. Handle these cases.

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>

spi: rp2040-gpio-bridge: probe: Cfg fast_xfer clk

Fast transfer mode requires that the first bit of data is clocked with a
rising edge. This can cause extra bits of data to be clocked on hardware
where the clock signal uses a pull-up. This change ensures that clk is
driven low before fast data transfer mode is entered.

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>

spi: rp2040-gpio-bridge: Grow MAX_TRANSFER_SIZE

Increase the maximum SPI transfer size from an arbitrary 1 MiB to ~4 MiB
(the amount of data that can be referenced by a single manifest).

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>
The snps,block-size DT property declares the maximum block size for each
channel of the dw-axi-dmac. However, the driver ignores these when
setting max_seg_size and uses MAX_BLOCK_SIZE (4096) instead.

To take advantage of the efficiencies of larger blocks, calculate the
minimum block size across all channels and use that instead.

See: raspberrypi#6256

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The firmware advertises its features as a string of words separated by
spaces. Ensure that feature names are only matched in their entirety.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The Cypress firmwares use "extsae" to indicate wpa_supplicant-hosted
SAE/WPA3.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
support sae executed in wpa_supplicant and offload 4-way handshake offload.

Signed-off-by: Chien-Chia Chen <carella.chen@infineon.com>

JIRA: SWWLAN-142424
TMOD_TO is the transmit-only mode that doesn't put data into the receive
FIFO. Using TMOD_TO when the user doesn't want the received data saves
CPU time and memory bandwidth.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
TMOD_RO is the receive-only mode that doesn't require data in the
transmit FIFO in order to generate clock cycles. Using TMOD_RO when the
device doesn't care about the data sent to it saves CPU time and memory
bandwidth.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Disabling the peripheral resets controller state which has a dangerous
side-effect of disabling the DMA handshake interface while it is active.
This can cause DMA channels to hang.

The error recovery pathway will wait for DMA to stop and reset the chip
anyway, so mask further FIFO interrupts and let the transfer finish
gracefully.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
There's no real need to constrain MEM access widths to 32-bit (or
narrower), as the DMAC is intelligent enough to size memory accesses
appropriately. Wider accesses are more efficient.

Similarly, MEM burst lengths don't need to be a function of DEV burst
lengths - the DMAC packs/unpacks data into/from its internal channel
FIFOs appropriately. Longer accesses are more efficient.

However, the DMAC doesn't have complete support for unaligned accesses,
and blocks are always defined in integer multiples of SRC_WIDTH, so odd
source lengths or buffer alignments will prevent wide accesses being
used, as before.

There is an implicit requirement to limit requested DEV read burst
lengths to less than the hardware's maximum configured MSIZE - otherwise
RX data will be left over at the end of a block. There is no config
register that reports this value, so the AXI burst length parameter is
used to produce a facsimile of it. Warn if such a request arrives that
doesn't respect this.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Do an end-run around ASoC in lieu of not being able to easily find the
associated DMA controller capabilities.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Ensure the transmit FIFO has emptied before ending the transfer by
dropping the TX threshold to 0 when the last byte has been pushed into
the FIFO. Include a similar fix for the non-IRQ paths.

See: raspberrypi#6285
Fixes: 6014649 ("spi: dw: Save bandwidth with the TMOD_TO feature")
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The DW SPI interface has a 16-bit clock divider, where the bottom bit
of the divisor must be 0. Limit how low the clock speed can go to
prevent the clock divider from being truncated, as that could lead to
a much higher clock rate than requested.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
In the same way that other subsystems support the setting of device
id numbers from Device Tree aliases, allow gpiochip numbers to be
derived from "gpiochip<n>" aliases.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Although later functions can handle a NULL fwnode, fwnode can't handle
being passed a NULL pointer.

See: raspberrypi#6305

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The check if the oscillator stop bit is set was reading from Control_1
register instead of the Seconds register.
This caused the Seconds register to be incorrectly changed if bit 7 of
Control_1 happens to be set.

Signed-off-by: Axel Hammarberg <axel.hammarberg@gmail.com>
Add YAML device tree binding for the Sony IMX500 CMOS image sensor /
CNN inference engine.  Also, add a MAINTAINERS entry.

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>
The Sony IMX500 is a stacked 1/2.3-inch CMOS digital image sensor and
inbuilt AI processor with an active array CNN (Convolutional Neural
Network) inference engine.  The native sensor size is 4056H x 3040V, and
the module also contains an in-built ISP for the CNN. The module is
programmable through an I2C interface with firmware and neural network
uploads being made over SPI. This driver supports imaging only.

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>

media: i2c: imx500: Inbuilt AI processor support

Add support for the IMX500's inbuilt AI processor. The IMX500 program
loader, AI processor firmware, DNN weights are accessed via the kernel's
firmware interface on 'open' and are transferred to the IMX500 over SPI.

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>

media: i2c: imx500: Enable LED during SPI transfers

The Raspberry Pi 'AI Camera' is equipped with an LED. Enable this LED
during SPI transfers to indicate to the end-user that progress is being
made during large tramsfers.

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>

drivers: media: imx500: Fixes for vblank control

Reduce the default/max framerate of the 2x2 binned mode to 30fps.
The current limit of 50fps can cause the sensor to produce corrupt
frames and cause missing framing events.

Also fixup the vblank control min/max/default/step paramters when
setting up.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

drivers: media: imx500: Simplify the vblank control init

Set the VBLANK control minimum and default values to IMX500_VBLANK_MIN
unconditionally everywhere.

Remove the mode specific framerate_default parameter, it is now unused.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

drivers: media: imx500: Enable LS correction

This correction is calibrated to approx 5000K.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

imx500: Fix for long exposure setup

The IMX500 (unlike the IMX477/IMX708) requires two regsiters to be set
for the exposure shift value to work correctly. The additional register
write (which was missing) is for the integration time shift.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

drivers: media: imx500: Enable sensor temperature monitoring

The register needs to be disabled before loading any firmware, otherwise
the upload fails for unknown reasons. Re-enable before starting the
sensor streaming.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

drivers: media: imx500: Add device id readback control

Add a new custom control V4L2_CID_USER_GET_IMX500_DEVICE_ID to allow
userland to query the device id from the IMX500 sensor eeprom.

Note that this device id can only be accessed when a network firmware
has been upoloaded to the device, so cannot be cached on probe.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

media: i2c: imx500: pm_runtime error paths

This change amends various error-paths in imx500_start_streaming() to
ensure that pm_runtime refcounts do not remain erroneously incremented
on failure.

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>

media: i2c: imx500: GPIO acquire/release semantics

When the imx500 driver is used as part of the 'AI Camera', the poweroff
state is never reached as the camera and gpio driver share a regulator.
By releasing the GPIOs when they are not in use, 'AI Camera' is able to
achieve a powered-down state.

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>

media: i2c: imx500: input tensor injection

Input tensor injection is a debug feature that allows a user-controlled
input to be passed directly to IMX500's inference engine (bypassing the
in-built ISP).

Three new custom controls are added to ENABLE_INJECTION before streaming
begins, to provide appropriate input tensors via an INPUT_TENSOR_FD, and
to provide notification of DNN results in the sensor output via
INJECTION_CMP_FRM.

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>

media: i2c: imx500: Allow larger SPI transfers

Remove the arbitrary 1 MiB transfer limit from imx500_spi_write() as
the 1 MiB chunk limitation for firmware / network transfers is already
upheld by imx500_state_transition(). This allows for larger input
tensors to be injected via imx500_inject_input_tensor() (where there is
no 1 MiB chunk limitation).

Increase the number of poll attempts whilst waiting for the injection
handshake register to be TRANS_COMP to allow more time for the checksum
of larger input tensors to be calculated.

Alter error messages in imx500_inject_input_tensor() so that
imx500_spi_write() and imx500_injection_wait_transfer_complete() errors
may be more easily differentiated.

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>
Add EXPORT_SYMBOL_GPL() for find_cpio_data() so that loadable modules
may also parse uncompressed cpio.

Signed-off-by: Richard Oliver <richard.oliver@raspberrypi.com>
The i.MX8MP makes calls on it's source device to determine
the link-frequency that should be configured on the CSI2 receiver.

When the source is behind a video mux, we need to pass this call through
to the connected device.

Map the control handler of the source device to the video-mux,
essentially proxying all controls on the mux to the device which has
it's link enabled.

Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
system_heap.max_order=<uint>

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Add numa_policy kernel argument to allow overriding the kernel's default
NUMA policy at boot time.

Syntax identical to what tmpfs accepts as it's mpol argument is accepted.

Some examples:

 numa_policy=interleave
 numa_policy=interleave=skip-interleave
 numa_policy=bind:0-3,5,7,9-15
 numa_policy=bind=static:1-2

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>

mm/mempolicy: Remove CONFIG_TMPFS from mpol_parse_str in headers

Commit 24993d7 ("mm/numa: Allow override of kernel's default NUMA policy")
removed the #ifdef CONFIG_TMPFS guard from the function definition
for mpol_parse_str, but not for the prototype. This lead to build errors/
warnings should CONFIG_TMPFS be disabled.

Fixes: 24993d7 ("mm/numa: Allow override of kernel's default NUMA policy")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
... Make sure CMA zones do not straddle the emulated NUMA nodes ...

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
…ed allocations

Add iommu_dma_numa_policy= kernel parameter which can be used to modify
the NUMA allocation policy of remapped buffer allocations.

Policy is only used for devices which are not associated with a NUMA node.

Syntax identical to what tmpfs accepts as it's mpol argument is accepted.

Some examples:

 iommu_dma_numa_policy=interleave
 iommu_dma_numa_policy=interleave=skip-interleave
 iommu_dma_numa_policy=bind:0-3,5,7,9-15
 iommu_dma_numa_policy=bind=static:1-2

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
To help work around certain memory controller limitations or similar, a
random NUMA allocation memory policy is added.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Some apps like linpack use numa_setpolicy to disable numa,
but that tends to have a significant performance hit for us.

If you have a cmdline.txt setting of numa_policy (to something other
than default), then lets ignore runtime changes and stick with
the cmdline.txt setting.

Not specifying numa_setpolicy in cmdline, or setting
numa_setpolicy=default(*) will allow runtime settings to work.

(*) easier to do when numa_setpolicy=interleave is set in DT.

Ignore logging for the first 40 seconds as there are some
expected switches during boot.

Signed-off-by: Dom Cobley <popcornmix@gmail.com>

Show process name in set_mempolicy() ignored message

Signed-off-by: Trevor Man <tman_github@trejan.com>
As a workaround (and possibly a fix) for CPU spins observed on BCM2837,
use ptep_clear_flush_young instead of ptep_test_and_clear_young inside
lru_gen_look_around in order to expose PTE changes to the MMU. Note that
on architectures that don't require an explicit flush,
ptep_clear_flush_young just calls ptep_test_and_clear_young.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
A user has reported that a card of this model from late 2021 doesn't
work, so extend the date range and make it match on all card sizes.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
nbuchwitz and others added 21 commits March 30, 2026 12:34
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>
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>
fs/btrfs/discard.c:591:60: error: ‘discard_state’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
  591 |                 if (discard_state == BTRFS_DISCARD_BITMAPS ||
      |                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
  592 |                     discard_state == BTRFS_DISCARD_FULLY_REMAPPED) {
      |                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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>
Enhance IRQ affinity setting with effective update.
Refactor irq_set_affinity handling to update effective affinity on success.
@popcornmix
Copy link
Copy Markdown
Collaborator

Any fixes to code that is unchanged in our downstream (rpi-7.0.y) kernel will need to be submitted upstream.
See here.

@by
Copy link
Copy Markdown
Author

by commented Apr 4, 2026

Thanks, and I'm trying to get this done, but it is not trivial for a non-kernel developer, as it appears; have reached out via email to check.

The two regarding RP1 (6b29188 and 0504cd9) are independent of the others, only for Pis with the RP1 and not related to upstream linux, if I'm not mistaken? I should have created two pull requests, my mistake, I'm sorry.

@popcornmix
Copy link
Copy Markdown
Collaborator

Yes, I think the RP1 commits affect downstream code, so belong here.

The PPS commits looked to be editing files we haven't changed downstream, so belong upstream.
We can pick them up once they are accepted upstream, but the (upstream) code devs are in a better position to judge the changes to be correct (and advise if not).

@by by marked this pull request as draft April 4, 2026 15:41
@nbuchwitz
Copy link
Copy Markdown
Contributor

Thanks, and I'm trying to get this done, but it is not trivial for a non-kernel developer, as it appears; have reached out via email to check.

The two regarding RP1 (6b29188 and 0504cd9) are independent of the others, only for Pis with the RP1 and not related to upstream linux, if I'm not mistaken? I should have created two pull requests, my mistake, I'm sorry.

Regarding the non-rp1 commits:

The pps-gpio threaded IRQ split is clean and nearly ready for upstream as-is. I'd lead the series with that one.

The raw_spinlock conversion needs some rework though. pps_event() calls wake_up_interruptible_all(), kill_fasync(), and the echo callback all under the lock - those can sleep on RT and must not be held under raw_spinlock. You'd need to move those out of the critical section first, then do the conversion. That makes it a 2-3 patch mini-series on its own.

If this is your first touchpoint with the upstream process and you'd like help getting this posted to the mailing list, feel free to reach out - happy to guide you through the process.

@by by marked this pull request as ready for review April 6, 2026 21:08
@by
Copy link
Copy Markdown
Author

by commented Apr 6, 2026

Thank you all! – I reduced to just the two patches re. RP1 here, moved the other (independent!) stuff to upstream discussions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.