Fixes for https://github.com/raspberrypi/linux/issues/7301#7302
Fixes for https://github.com/raspberrypi/linux/issues/7301#7302by wants to merge 625 commits intoraspberrypi:rpi-7.0.yfrom
Conversation
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>
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>
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.
|
Any fixes to code that is unchanged in our downstream (rpi-7.0.y) kernel will need to be submitted upstream. |
|
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. |
|
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. |
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. |
|
Thank you all! – I reduced to just the two patches re. RP1 here, moved the other (independent!) stuff to upstream discussions. |
These are the two fixes I successfully tested to mitigate #7301