summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-05-19spi: sh-msiof: Move register definitions to <linux/spi/sh_msiof.h>Geert Uytterhoeven
Move the MSIOF register and register bit definitions from the MSIOF SPI driver to the existing header file <linux/spi/sh_msiof.h>, so they can be shared with the MSIOF I2S driver. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/066d1086973eb309006258484e9fe8138807e565.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Document frame start sync pulse modeGeert Uytterhoeven
Unused, but nice to have it documented. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/3d3acaab4a4125106a0655d28c09c050341c5eeb.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Double maximum DMA transfer size using two groupsGeert Uytterhoeven
The maximum DMA transfer size is limited by the maximum values that can be written to the word count fields (WDLENx) in the Transmit and Control Data Registers (SITDR2/SIRDR2). As all MSIOF variants support transferring data of multiple (two or four) groups, the maximum size can be doubled by using two groups instead of one, thus reducing setup overhead for very large SPI transfers. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/bad522c76b8d225c195433977b22f95015cf2612.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Simplify BRG's Division RatioGeert Uytterhoeven
As FIELD_PREP() masks the value to be stored in the field, the Baud Rate Generator's Division Ratio handling can be simplified from a look-up table to a single subtraction. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/e736221942b0381fb53dc64109a1389f7ec5f44a.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Increase TX FIFO size for R-Car V4H/V4MGeert Uytterhoeven
The MSIOF transmit FIFOs on R-Car V4H and V4M have 256 stages. Add a new family-specific match entry to handle this. Add quirk match entries for older R-Car Gen4 Socs (R-Car V3U and S4-8) that have transmit FIFOs with only 64 stages, just like on R-Car Gen3. Update the (unused) definition of SIFCTR_TFUA for consistency. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/69cb5fc48f034d37484fa127b9864a1971a83417.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Correct RX FIFO size for R-Car Gen3Geert Uytterhoeven
According to the R-Car Gen3 Hardware Manual Errata for Rev 0.55 of September 28, 2017, the MSIOF receive FIFOs on R-Car Gen3 SoCs have room for 256 words of 32 bits. Note that this change has no actual impact on the behavior of the driver, as SPI_CONTROLLER_MUST_TX is set, and transfer size is currenty limited to the minimum of the transmit and receive FIFO sizes. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/6f74508ea4681aa0b7c6bf6810eab026725e75a3.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Correct RX FIFO size for R-Car Gen2Geert Uytterhoeven
According to Renesas Technical Updates TN-RCS-S068A/E, the MSIOF receive FIFOs on R-Car Gen2 SoCs have room for 128 words of 32 bits. Note that this change has no actual impact on the behavior of the driver, as SPI_CONTROLLER_MUST_TX is set, and transfer size is currenty limited to the minimum of the transmit and receive FIFO sizes. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/fd11933f932df81d84f417a21e2179bd4fdcfdc1.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Add core support for dual-group transfersGeert Uytterhoeven
All MSIOF variants support transferring data of multiple (2 or 4) groups. Add definitions for the register bits related to multiple groups, and enhance sh_msiof_spi_set_mode_regs() to accept a second group size. For now the second group is unused. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/be75e20cfcd2a6c0d73ab09e0126f902911adc69.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Correct SIMDR2_GRPMASKGeert Uytterhoeven
The Group Output Mask is not a single bit, but a bit field, containing one bit for each of the four possible groups. Correct the definition. Note that this change has no direct impact, as the driver only uses the first group. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/ad268d67807cb7e544eddaf7a056793482a965d4.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: SIFCTR bitfield conversionGeert Uytterhoeven
Convert MSIOF FIFO Control Register field accesses to use the FIELD_PREP() bitfield access macro. This gets rid of explicit shifts and custom field preparation macros. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/0bf4c366381a8999c9755285272897300852bc18.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: SICTR bitfield conversionGeert Uytterhoeven
Convert MSIOF Control Register field accesses to use the FIELD_PREP() bitfield access macro. This gets rid of explicit shifts. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/4511c678c8fce5969eb50ffa7372d53396ff80ff.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: SITSCR/SIRSCR bitfield conversionGeert Uytterhoeven
Convert MSIOF Transmit and Receive Clock Select Register field accesses to use the FIELD_PREP() bitfield access macro. This gets rid of explicit shifts and custom field preparation macros. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/f2462c99b6ea2e45b995ab4509c2f039043da032.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: SITMDR2 and SIRMDR2 bitfield conversionGeert Uytterhoeven
Convert MSIOF Transmit and Receive Mode Register 2 field accesses to use the FIELD_PREP() bitfield access macro. This gets rid of explicit shifts and custom field preparation macros. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/135b92d010a71e2c224feab3a5792724b4e60ff1.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: SITMDR1/SIRMDR1 bitfield conversionGeert Uytterhoeven
Convert MSIOF Transmit and Receive Mode Register 1 field accesses to use the FIELD_PREP() bitfield access macro. This gets rid of explicit shifts. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/9685c54e752b8ef4256c9b281e9d8292e71d222e.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Make words/fs unsigned in FIFO helpersGeert Uytterhoeven
Make the words and fs parameters of the various FIFO filler and emptier functions unsigned, as they can never be negative. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/a7b13ecb1811148227ec8c883079085ed1ea6eac.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Make words/bits unsigned in sh_msiof_spi_txrx_once()Geert Uytterhoeven
Make the words and bits parameters of sh_msiof_spi_txrx_once() unsigned, as that matches what is passed by the caller. This allows us to replace min_t() by the safer min(). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/30eff1052642a4bcb0f1bc4bed7aae25d355a7dc.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Use bool for boolean flagsGeert Uytterhoeven
Use bools instead of integers for boolean flags, which allows us to remove the "!!" idiom from several expressions. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/35cd51bdfb3c810911a5be757e0ce5bb29dcc755.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Complete using dev in sh_msiof_spi_probe()Geert Uytterhoeven
Commit c4887bd4b35b225f ("spi: sh-msiof: use dev in sh_msiof_spi_probe()") forgot to convert one instance. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/88d271b2d16c6ad7f174858894573f91cec1bc90.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Fix maximum DMA transfer sizeGeert Uytterhoeven
The maximum amount of data to transfer in a single DMA request is calculated from the FIFO sizes (which is technically not 100% correct, but a simplification, as it is limited by the maximum word count values in the Transmit and Control Data Registers). However, in case there is both data to transmit and to receive, the transmit limit is overwritten by the receive limit. Fix this by using the minimum applicable FIFO size instead. Move the calculation outside the loop, so it is not repeated for each individual DMA transfer. As currently tx_fifo_size is always equal to rx_fifo_size, this bug had no real impact. Fixes: fe78d0b7691c0274 ("spi: sh-msiof: Fix FIFO size to 64 word from 256 word") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/d9961767a97758b2614f2ee8afe1bd56dc900a60.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Remove unneeded compatible valuesGeert Uytterhoeven
The Clock-Synchronized Serial Interfaces with FIFO (MSIOF) driver matches against both SoC-specific and family-specific compatible values to maintain backwards-compatibility with old DTBs predating the introduction of the family-specific compatible values. For RZ/G1, the SoC-specific compatible match entry can be removed from the driver: their DT always had the family-specific compatible values, and thus there was never a need to add the SoC-specific compatible values to the driver. For R-Car Gen2 and M3-W, the SoC-specific compatible match entries can be removed, too, as there are a few points in time where DT backwards-compatibility was broken for other reasons: - Legacy DT clock support is no longer supported since commit 58256143cff7c2e0 ("clk: renesas: Remove R-Car Gen2 legacy DT clock support") in v5.5, and the addition of "renesas,rcar-gen2-msiof" to DTS in v4.11 predates the completion of the clock conversion in v4.15, - Legacy DT LVDS support is no longer supported since commit 841281fe52a769fe ("drm: rcar-du: Drop LVDS device tree backward compatibility") in v5.18, and the addition of "renesas,rcar-gen3-msiof" in commit 8b51f97138ca22b6 ("arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for msiof nodes") in v4.11 predates the LVDS conversion in commit 58e8ed2ee9abe718 ("arm64: dts: renesas: Convert to new LVDS DT bindings") in v4.20. For R-Car H3, the SoC-specific compatible match entry cannot be removed, as its purpose is to handle an SoC-specific quirk. Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/d33393ac7536bc3f0f624b079f70d80dd19843db.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-19spi: sh-msiof: Drop comma after OF match table sentinelGeert Uytterhoeven
It does not make sense to have a comma after a sentinel, as any new elements must be added before the sentinel. Add a comment to clarify the purpose of the empty element. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/2ab5745407339ba54b63c3e6410082c7c566bf95.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-15spi: dt-bindings: tegra: Document IOMMU property for Tegra234 QSPIVishwaroop A
Add the 'iommus' property to the Tegra QSPI device tree binding. The property is needed for Tegra234 when using the internal DMA controller, and is not supported on other Tegra chips, as DMA is handled by an external controller. Signed-off-by: Vishwaroop A <va@nvidia.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20250513200043.608292-1-va@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-15spi: tegra210-quad: Add support for internal DMAVishwaroop A
Add support for internal DMA in Tegra234 devices. Tegra234 has an internal DMA controller, while Tegra241 continues to use an external DMA controller (GPCDMA). This patch adds support for both internal and external DMA controllers. Signed-off-by: Vishwaroop A <va@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20250513200043.608292-2-va@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-14spi: spi-qpic-snand: validate user/chip specific ECC propertiesGabor Juhos
The driver only supports 512 bytes ECC step size and 4 bit ECC strength at the moment, however it does not reject unsupported step/strength configurations. Due to this, whenever the driver is used with a flash chip which needs stronger ECC protection, the following warning is shown in the kernel log: [ 0.574648] spi-nand spi0.0: GigaDevice SPI NAND was found. [ 0.635748] spi-nand spi0.0: 256 MiB, block size: 128 KiB, page size: 2048, OOB size: 128 [ 0.649079] nand: WARNING: (null): the ECC used on your system is too weak compared to the one required by the NAND chip Although the message indicates that something is wrong, but it often gets unnoticed, which can cause serious problems. For example when the user writes something into the flash chip despite the warning, the written data may won't be readable by the bootloader or by the boot ROM. In the worst case, when the attached SPI NAND chip is the boot device, the board may not be able to boot anymore. Also, it is not even possible to create a backup of the flash, because reading its content results in bogus data. For example, dumping the first page of the flash gives this: # hexdump -C -n 2048 /dev/mtd0 00000000 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000040 0f 0f 0f 0f 0f 0f 0f 0d 0f 0f 0f 0f 0f 0f 0f 0f |................| 00000050 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 000001c0 0f 0f 0f 0f ff 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| 000001d0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000200 0f 0f 0f 0f f5 5b ff ff 0f 0f 0f 0f 0f 0f 0f 0f |.....[..........| 00000210 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 000002f0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 1f 0f 0f |................| 00000300 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 000003c0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f ff 0f 0f 0f |................| 000003d0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000400 0f 0f 0f 0f 0f 0f 0f 0f e9 74 c9 06 f5 5b ff ff |.........t...[..| 00000410 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 000005d0 0f 0f 0f 0f ff 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| 000005e0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000600 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f c6 be 0f c3 |................| 00000610 e9 74 c9 06 f5 5b ff ff 0f 0f 0f 0f 0f 0f 0f 0f |.t...[..........| 00000620 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000770 0f 0f 0f 0f 8f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| 00000780 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000800 # Doing the same by using the downstream kernel results in different output: # hexdump -C -n 2048 /dev/mtd0 00000000 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000800 # This patch adds some sanity checks to the code to prevent using the driver with unsupported ECC step/strength configurations. After the change, probing of the driver fails in such cases: [ 0.655038] spi-nand spi0.0: GigaDevice SPI NAND was found. [ 0.659159] spi-nand spi0.0: 256 MiB, block size: 128 KiB, page size: 2048, OOB size: 128 [ 0.669138] qcom_snand 79b0000.spi: only 4 bits ECC strength is supported [ 0.677476] nand: No suitable ECC configuration [ 0.689909] spi-nand spi0.0: probe with driver spi-nand failed with error -95 This helps to avoid the aforementioned hassles until support for 8 bit ECC strength gets implemented. Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Link: https://patch.msgid.link/20250501-qpic-snand-validate-ecc-v1-1-532776581a66@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-12Add more devm_ functions to fix PM imbalance inMark Brown
Merge series from Bence Csókás <csokas.bence@prolan.hu>: The probe() function of the atmel-quadspi driver got quite convoluted, especially since the addition of SAMA7G5 support, that was forward-ported from an older vendor kernel. During the port, a bug was introduced, where the PM get() and put() calls were imbalanced. To alleivate this - and similar problems in the future - an effort was made to migrate as many functions as possible, to their devm_ managed counterparts. The few functions, which did not yet have a devm_ variant, are added in patch 1 of this series. Patch 2 then uses these APIs to fix the probe() function.
2025-05-11spi: atmel-quadspi: Fix unbalanced pm_runtime by using devm_ APIBence Csókás
Fix unbalanced PM in error path of `atmel_qspi_probe()` by using `devm_pm_runtime_*()` functions. Reported-by: Alexander Dahl <ada@thorsis.com> Closes: https://lore.kernel.org/linux-spi/20250110-paycheck-irregular-bcddab1276c7@thorsis.com/ Fixes: 5af42209a4d2 ("spi: atmel-quadspi: Add support for sama7g5 QSPI") Signed-off-by: Bence Csókás <csokas.bence@prolan.hu> Link: https://patch.msgid.link/20250327195928.680771-4-csokas.bence@prolan.hu Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-10spi: dt-bindings: nuvoton,wpcm450-fiu: Drop unrelated nodes from DTS exampleKrzysztof Kozlowski
Binding example should not contain other nodes, including other providers like syscon, because this is redundant and only adds unnecessary bloat. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250509112130.123462-4-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-10spi: dt-bindings: fsl,dspi: Fix example indentationKrzysztof Kozlowski
DTS example in the bindings should be indented with 2- or 4-spaces, so correct a mixture of different styles to keep consistent 4-spaces. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20250509112130.123462-3-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-09Add RZ/G3E xSPI supportMark Brown
Merge series from Biju Das <biju.das.jz@bp.renesas.com>: The xSPI IP found on RZ/G3E SoC similar to RPC-IF interface, but it can support writes on memory-mapped area. Even though the registers are different, the rpcif driver code can be reused for xSPI by adding wrapper functions.
2025-05-08spi: rpc-if: Add write support for memory-mapped areaBiju Das
Add write support for memory-mapped area as xSPI interface require it. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20250424090000.136804-8-biju.das.jz@bp.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-08memory: renesas-rpc-if: Add missing static keywordBiju Das
Fix the below sparse warnings: symbol 'rpcif_impl' was not declared. Should it be static? symbol 'xspi_impl' was not declared. Should it be static? Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505072013.1EqwjtaR-lkp@intel.com/ Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20250507162146.140494-1-biju.das.jz@bp.renesas.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-05-07This patch set did some clean up and add runtime pmMark Brown
Merge series from Haibo Chen <haibo.chen@nxp.com>: PATCH1/3/4 to clean up the code, make the code more readable PATCH2 add the runtime pm support PATCH5 use devm_add_action_or_reset() to replace remove() callback, this can avoid oops when do bind/unbind test
2025-05-06spi: nxp-fspi: use devm instead of remove for driver detachHan Xu
fspi driver use devm APIs to manage clk/irq/resources and register the spi controller, but the legacy remove function will be called first during device detach and trigger kernel panic. Drop the remove function and use devm_add_action_or_reset() for driver cleanup to ensure the release sequence. Signed-off-by: Han Xu <han.xu@nxp.com> Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Link: https://patch.msgid.link/20250428-flexspipatch-v3-5-61d5e8f591bc@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-06spi: spi-nxp-fspi: remove the unchecked return value for ↵Haibo Chen
nxp_fspi_clk_disable_unprep For nxp_fspi_clk_disable_unprep(), no caller check the return value, so remove the unchecked return value. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Link: https://patch.msgid.link/20250428-flexspipatch-v3-4-61d5e8f591bc@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-06spi: spi-nxp-fspi: use guard(mutex) to simplify the codeHaibo Chen
Use guard(mutex) to simplify the code logic. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Link: https://patch.msgid.link/20250428-flexspipatch-v3-3-61d5e8f591bc@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-06spi: spi-nxp-fspi: enable runtime pm for fspiHaibo Chen
Enable the runtime PM in fspi driver. Also for system PM, On some board like i.MX8ULP-EVK board, after system suspend, IOMUX module will lost power, so all the pinctrl setting will lost when system resume back, need driver to save/restore the pinctrl setting. Signed-off-by: Han Xu <han.xu@nxp.com> Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Link: https://patch.msgid.link/20250428-flexspipatch-v3-2-61d5e8f591bc@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-06spi: spi-nxp-fspi: remove the goto in probeHaibo Chen
Remove all the goto in probe to simplify the driver. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Link: https://patch.msgid.link/20250428-flexspipatch-v3-1-61d5e8f591bc@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-05spi: cadence-quadspi: Assume device could match via platformKrzysztof Kozlowski
Driver has only of_device_id table, however it also has MODULE_ALIAS() for platform name, thus assume there is a configuration where this can be loaded outside of OF system. In such case of_device_get_match_data() will return NULL, which is already checked in one place of probe() function but not in the other, leading to Smatch warning: drivers/spi/spi-cadence-quadspi.c:1942 cqspi_probe() error: we previously assumed 'ddata' could be null (see line 1885) Driver should be consistent, so assume device can be matched via platform bus and of_device_get_match_data() can indeed return NULL. This is also possible with malformed DTS on OF-platform: no unit address and device node name matching driver name. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250501-n-smatch-fixes-v2-3-d2ad9c1f2e67@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-05spi: cs42l43: Make handling missing spk-id GPIOs explicitKrzysztof Kozlowski
gpiod_get_array_optional() for spk-id GPIOs can return NULL, if they are missing, so do not pass the value to PTR_ERR but instead explicitly treat NULL as acceptable condition. The old code was correct, but misleading because PTR_ERR usually is used on errors. Reported by Smatch: drivers/spi/spi-cs42l43.c:241 cs42l43_get_speaker_id_gpios() warn: passing zero to 'PTR_ERR' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250501-n-smatch-fixes-v2-2-d2ad9c1f2e67@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-05spi: atmel-quadspi: Fix printed error code during DMA setupKrzysztof Kozlowski
On dma_request_chan() failure driver NULL-ifies the 'rx_chan' and immediately uses it as PTR_ERR() so dev_err_probe() prints incorrect error code. Rework the code so proper error code will be printed and NULL-ifying of 'rx_chan' will happen in common error handling block (failure of DMA setup is not fatal for the driver and further code depends on 'rx_chan' being non-NULL for DMA operations). Reported by Smatch: drivers/spi/atmel-quadspi.c:1287 atmel_qspi_dma_init() warn: passing zero to 'PTR_ERR' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250501-n-smatch-fixes-v2-1-d2ad9c1f2e67@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-04Linux 6.15-rc5v6.15-rc5Linus Torvalds
2025-05-04Merge tag 'perf-tools-fixes-for-v6.15-2025-05-04' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools Pull perf tools fixes from Namhyung Kim: "Just a couple of build fixes on arm64" * tag 'perf-tools-fixes-for-v6.15-2025-05-04' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: perf tools: Fix in-source libperf build perf tools: Fix arm64 build by generating unistd_64.h
2025-05-04Merge tag 'trace-v6.15-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Fix read out of bounds bug in tracing_splice_read_pipe() The size of the sub page being read can now be greater than a page. But the buffer used in tracing_splice_read_pipe() only allocates a page size. The data copied to the buffer is the amount in sub buffer which can overflow the buffer. Use min((size_t)trace_seq_used(&iter->seq), PAGE_SIZE) to limit the amount copied to the buffer to a max of PAGE_SIZE. - Fix the test for NULL from "!filter_hash" to "!*filter_hash" The add_next_hash() function checked for NULL at the wrong pointer level. - Do not use the array in trace_adjust_address() if there are no elements The trace_adjust_address() finds the offset of a module that was stored in the persistent buffer when reading the previous boot buffer to see if the address belongs to a module that was loaded in the previous boot. An array is created that matches currently loaded modules with previously loaded modules. The trace_adjust_address() uses that array to find the new offset of the address that's in the previous buffer. But if no module was loaded, it ends up reading the last element in an array that was never allocated. Check if nr_entries is zero and exit out early if it is. - Remove nested lock of trace_event_sem in print_event_fields() The print_event_fields() function iterates over the ftrace_events list and requires the trace_event_sem semaphore held for read. But this function is always called with that semaphore held for read. Remove the taking of the semaphore and replace it with lockdep_assert_held_read(&trace_event_sem) * tag 'trace-v6.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing: Do not take trace_event_sem in print_event_fields() tracing: Fix trace_adjust_address() when there is no modules in scratch area ftrace: Fix NULL memory allocation check tracing: Fix oob write in trace_seq_to_buffer()
2025-05-04Merge tag 'parisc-for-6.15-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fix from Helge Deller: "Fix a double SIGFPE crash" * tag 'parisc-for-6.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Fix double SIGFPE crash
2025-05-04parisc: Fix double SIGFPE crashHelge Deller
Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately. When the T bit is set, an assist exception trap occurs when when the co-processor encounters *any* floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace. The issue can be reproduced with this test program: root@parisc:~# cat fpe.c static void fpe_func(int sig, siginfo_t *i, void *v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); } int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); } root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 /* 20 vars */) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception Signed-off-by: Helge Deller <deller@gmx.de> Suggested-by: John David Anglin <dave.anglin@bell.net> Reported-by: Camm Maguire <camm@maguirefamily.org> Cc: stable@vger.kernel.org
2025-05-04Merge tag 'edac_urgent_for_v6.15_rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras Pull EDAC fixes from Borislav Petkov: - Test the correct structure member when handling correctable errors and avoid spurious interrupts, in altera_edac * tag 'edac_urgent_for_v6.15_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/altera: Set DDR and SDMMC interrupt mask before registration EDAC/altera: Test the correct error reg offset
2025-05-04Merge tag 'x86-urgent-2025-05-04' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fix from Ingo Molnar: "Fix SEV-SNP memory acceptance from the EFI stub for guests running at VMPL >0" * tag 'x86-urgent-2025-05-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/boot/sev: Support memory acceptance in the EFI stub under SVSM
2025-05-04Merge tag 'perf-urgent-2025-05-04' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull misc perf fixes from Ingo Molnar: - Require group events for branch counter groups and PEBS counter snapshotting groups to be x86 events. - Fix the handling of counter-snapshotting of non-precise events, where counter values may move backwards a bit, temporarily, confusing the code. - Restrict perf/KVM PEBS to guest-owned events. * tag 'perf-urgent-2025-05-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value. perf/x86/intel/ds: Fix counter backwards of non-precise events counters-snapshotting perf/x86/intel: Check the X86 leader for pebs_counter_event_group perf/x86/intel: Only check the group flag for X86 leader
2025-05-04Merge tag 'irq-urgent-2025-05-04' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fixes from Ingo Molnar: - Prevent NULL pointer dereference in msi_domain_debug_show() - Fix crash in the qcom-mpm irqchip driver when configuring interrupts for non-wake GPIOs * tag 'irq-urgent-2025-05-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs genirq/msi: Prevent NULL pointer dereference in msi_domain_debug_show()
2025-05-04x86/boot/sev: Support memory acceptance in the EFI stub under SVSMArd Biesheuvel
Commit: d54d610243a4 ("x86/boot/sev: Avoid shared GHCB page for early memory acceptance") provided a fix for SEV-SNP memory acceptance from the EFI stub when running at VMPL #0. However, that fix was insufficient for SVSM SEV-SNP guests running at VMPL >0, as those rely on a SVSM calling area, which is a shared buffer whose address is programmed into a SEV-SNP MSR, and the SEV init code that sets up this calling area executes much later during the boot. Given that booting via the EFI stub at VMPL >0 implies that the firmware has configured this calling area already, reuse it for performing memory acceptance in the EFI stub. Fixes: fcd042e86422 ("x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0") Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Co-developed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: <stable@vger.kernel.org> Cc: Dionna Amalie Glaze <dionnaglaze@google.com> Cc: Kevin Loughlin <kevinloughlin@google.com> Cc: linux-efi@vger.kernel.org Link: https://lore.kernel.org/r/20250428174322.2780170-2-ardb+git@google.com
generated by cgit (git 2.34.1) at 2025-09-07 10:53:01 +0000