summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'soc-fixes-6.5-2' of ↵Linus Torvalds2023-08-0228-78/+130
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "A couple of platforms get a lone dts fix each: - SoCFPGA: Fix incorrect I2C property for SCL signal - Renesas: Fix interrupt names for MTU3 channels on RZ/G2L and RZ/V2L. - Juno/Vexpress: remove a dangling symlink - at91: sam9x60 SoC detection compatible strings - nspire: Fix arm primecell compatible string On the NXP i.MX platform, there multiple issues that get addressed: - A couple of ARM DTS fixes for i.MX6SLL usbphy and supported CPU frequency of sk-imx53 board - Add missing pull-up for imx8mn-var-som onboard PHY reset pinmux - A couple of imx8mm-venice fixes from Tim Harvey to diable disp_blk_ctrl - A couple of phycore-imx8mm fixes from Yashwanth Varakala to correct VPU label and gpio-line-names - Fix imx8mp-blk-ctrl driver to register HSIO PLL clock as bus_power_dev child, so that runtime PM can translate into the necessary GPC power domain action On the driver side, there are two fixes for tegra memory controller drivers addressing regressions from the merge window, a couple of minor correctness fixes for SCMI and SMCCC firmware, as well as a build fix for an lcd backlight driver" * tag 'soc-fixes-6.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (22 commits) backlight: corgi_lcd: fix missing prototype memory: tegra: make icc_set_bw return zero if BWMGR not supported arm64: dts: renesas: rzg2l: Update overfow/underflow IRQ names for MTU3 channels dt-bindings: serial: atmel,at91-usart: update compatible for sam9x60 ARM: dts: at91: sam9x60: fix the SOC detection ARM: dts: nspire: Fix arm primecell compatible string firmware: arm_scmi: Fix chan_free cleanup on SMC firmware: arm_scmi: Drop OF node reference in the transport channel setup soc: imx: imx8mp-blk-ctrl: register HSIO PLL clock as bus_power_dev child ARM: dts: nxp/imx: limit sk-imx53 supported frequencies firmware: arm_scmi: Fix signed error return values handling firmware: smccc: Fix use of uninitialised results structure arm64: dts: freescale: Fix VPU G2 clock arm64: dts: imx8mn-var-som: add missing pull-up for onboard PHY reset pinmux arm64: dts: phycore-imx8mm: Correction in gpio-line-names arm64: dts: phycore-imx8mm: Label typo-fix of VPU ARM: dts: nxp/imx6sll: fix wrong property name in usbphy node arm64: dts: imx8mm-venice-gw7904: disable disp_blk_ctrl arm64: dts: imx8mm-venice-gw7903: disable disp_blk_ctrl arm64: dts: arm: Remove the dangling vexpress-v2m-rs1.dtsi symlink ...
| * Merge tag 'socfpga_dts_fix_for_v6.5' of ↵Arnd Bergmann2023-07-272-2/+2
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into arm/fixes SoCFPGA dts fix for v6.5 - Fix incorrect I2C property for SCL signal * tag 'socfpga_dts_fix_for_v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: arm64: dts: stratix10: fix incorrect I2C property for SCL signal Link: https://lore.kernel.org/r/20230724145617.887443-1-dinguyen@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| | * arm64: dts: stratix10: fix incorrect I2C property for SCL signalDinh Nguyen2023-07-112-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The correct dts property for the SCL falling time is "i2c-scl-falling-time-ns". Fixes: c8da1d15b8a4 ("arm64: dts: stratix10: i2c clock running out of spec") Cc: stable@vger.kernel.org Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
| * | Merge tag 'renesas-fixes-for-v6.5-tag1' of ↵Arnd Bergmann2023-07-272-16/+16
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/fixes Renesas fixes for v6.5 - Fix interrupt names for MTU3 channels on RZ/G2L and RZ/V2L. * tag 'renesas-fixes-for-v6.5-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: arm64: dts: renesas: rzg2l: Update overfow/underflow IRQ names for MTU3 channels Link: https://lore.kernel.org/r/cover.1690463347.git.geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| | * | arm64: dts: renesas: rzg2l: Update overfow/underflow IRQ names for MTU3 channelsBiju Das2023-07-252-16/+16
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per R01UH0914EJ0130 Rev.1.30 HW manual the MTU3 overflow/underflow interrupt names start with 'tci' instead of 'tgi'. Replace the below overflow/underflow interrupt names: - tgiv0->tciv0 - tgiv1->tciv1 - tgiu1->tciu1 - tgiv2->tciv2 - tgiu2->tciu2 - tgiv3->tciv3 - tgiv4->tciv4 - tgiv6->tciv6 - tgiv7->tciv7 - tgiv8->tciv8 - tgiu8->tciu8 Fixes: 26336d66d021 ("arm64: dts: renesas: r9a07g044: Add MTU3a node") Fixes: dd123dd01def ("arm64: dts: renesas: r9a07g054: Add MTU3a node") 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/20230724091927.123847-5-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
| * | Merge tag 'memory-controller-drv-fixes-6.5' of ↵Arnd Bergmann2023-07-274-24/+44
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/fixes Memory controller drivers - fixes for v6.5 Two fixes are needed for Tegra194 memory controllers caused by the same Tegra PCI commit merged in v6.5-rc1. The Tegra PCI requires now interconnect from the memory controller, which was set only for Tegra234, but not for Tegra194, causing probe deferrals. Expose some dummy interconnect provider for Tegra194, to satisfy PCI driver needs. * tag 'memory-controller-drv-fixes-6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl: memory: tegra: make icc_set_bw return zero if BWMGR not supported memory: tegra: Add dummy implementation on Tegra194 Link: https://lore.kernel.org/r/20230726084811.124038-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| | * | memory: tegra: make icc_set_bw return zero if BWMGR not supportedSumit Gupta2023-07-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Return zero from icc_set_bw() to MC client driver if MRQ_BWMGR_INT is not supported by the BPMP-FW. Currently, 'EINVAL' is returned which causes error message in client drivers even when the platform doesn't support scaling. Fixes: 9365bf006f53 ("PCI: tegra194: Add interconnect support in Tegra234") Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20230621134400.23070-5-sumitg@nvidia.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
| | * | memory: tegra: Add dummy implementation on Tegra194Thierry Reding2023-07-104-22/+42
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the introduction of commit 9365bf006f53 ("PCI: tegra194: Add interconnect support in Tegra234"), the PCI driver on Tegra194 and later requires an interconnect provider. However, a provider is currently only exposed on Tegra234 and this causes PCI on Tegra194 to defer probe indefinitely. Fix this by adding a dummy implementation on Tegra194. This allows nodes to be provided to interconnect consumers, but doesn't do any bandwidth accounting or frequency scaling. Fixes: 9365bf006f53 ("PCI: tegra194: Add interconnect support in Tegra234") Reported-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Sumit Gupta <sumitg@nvidia.com> Tested-by: Sumit Gupta <sumitg@nvidia.com> Link: https://lore.kernel.org/r/20230629160132.768940-1-thierry.reding@gmail.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
| * | Merge tag 'imx-fixes-6.5' of ↵Arnd Bergmann2023-07-279-7/+25
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 6.5: - A couple of ARM DTS fixes for i.MX6SLL usbphy and supported CPU frequency of sk-imx53 board - Add missing pull-up for imx8mn-var-som onboard PHY reset pinmux - A couple of imx8mm-venice fixes from Tim Harvey to diable disp_blk_ctrl - A couple of phycore-imx8mm fixes from Yashwanth Varakala to correct VPU label and gpio-line-names - Fix imx8mp-blk-ctrl driver to register HSIO PLL clock as bus_power_dev child, so that runtime PM can translate into the necessary GPC power domain action * tag 'imx-fixes-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: soc: imx: imx8mp-blk-ctrl: register HSIO PLL clock as bus_power_dev child ARM: dts: nxp/imx: limit sk-imx53 supported frequencies arm64: dts: freescale: Fix VPU G2 clock arm64: dts: imx8mn-var-som: add missing pull-up for onboard PHY reset pinmux arm64: dts: phycore-imx8mm: Correction in gpio-line-names arm64: dts: phycore-imx8mm: Label typo-fix of VPU ARM: dts: nxp/imx6sll: fix wrong property name in usbphy node arm64: dts: imx8mm-venice-gw7904: disable disp_blk_ctrl arm64: dts: imx8mm-venice-gw7903: disable disp_blk_ctrl Link: https://lore.kernel.org/r/20230725075837.GR151430@dragon Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| | * | soc: imx: imx8mp-blk-ctrl: register HSIO PLL clock as bus_power_dev childLucas Stach2023-07-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The blk-ctrl device is deliberately placed outside of the GPC power domain as it needs to control the power sequencing of the blk-ctrl domains together with the GPC domains. Clock runtime PM works by operating on the clock parent device, which doesn't translate into the neccessary GPC power domain action if the clk parent is not part of the GPC power domain. Use the bus_power_device as the parent for the clock to trigger the proper GPC domain actions on clock runtime power management. Fixes: 2cbee26e5d59 ("soc: imx: imx8mp-blk-ctrl: expose high performance PLL clock") Reported-by: Yannic Moog <Y.Moog@phytec.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Yannic Moog <y.moog@phytec.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | ARM: dts: nxp/imx: limit sk-imx53 supported frequenciesDmitry Baryshkov2023-07-191-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SK-IMX53 board, bearing i.MX536A CPU, is not stable when running at 1.2 GHz (default iMX53 maximum). The SoC is only rated up to 800 MHz. Disable 1.2 GHz and 1 GHz frequencies. Fixes: 0b8576d8440a ("ARM: dts: imx: Add support for SK-iMX53 board") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | arm64: dts: freescale: Fix VPU G2 clockBenjamin Gaignard2023-07-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Set VPU G2 clock to 300MHz like described in documentation. This fixes pixels error occurring with large resolution ( >= 2560x1600) HEVC test stream when using the postprocessor to produce NV12. Fixes: 4ac7e4a81272 ("arm64: dts: imx8mq: Enable both G1 and G2 VPU's with vpu-blk-ctrl") Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | arm64: dts: imx8mn-var-som: add missing pull-up for onboard PHY reset pinmuxHugo Villeneuve2023-07-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For SOMs with an onboard PHY, the RESET_N pull-up resistor is currently deactivated in the pinmux configuration. When the pinmux code selects the GPIO function for this pin, with a default direction of input, this prevents the RESET_N pin from being taken to the proper 3.3V level (deasserted), and this results in the PHY being not detected since it is held in reset. Taken from RESET_N pin description in ADIN13000 datasheet: This pin requires a 1K pull-up resistor to AVDD_3P3. Activate the pull-up resistor to fix the issue. Fixes: ade0176dd8a0 ("arm64: dts: imx8mn-var-som: Add Variscite VAR-SOM-MX8MN System on Module") Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | arm64: dts: phycore-imx8mm: Correction in gpio-line-namesYashwanth Varakala2023-07-182-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove unused nINT_ETHPHY entry from gpio-line-names in gpio1 nodes of phyCORE-i.MX8MM and phyBOARD-Polis-i.MX8MM devicetrees. Fixes: ae6847f26ac9 ("arm64: dts: freescale: Add phyBOARD-Polis-i.MX8MM support") Signed-off-by: Yashwanth Varakala <y.varakala@phytec.de> Signed-off-by: Cem Tenruh <c.tenruh@phytec.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | arm64: dts: phycore-imx8mm: Label typo-fix of VPUYashwanth Varakala2023-07-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Corrected the label of the VPU regulator node (buck 3) from reg_vdd_gpu to reg_vdd_vpu. Fixes: ae6847f26ac9 ("arm64: dts: freescale: Add phyBOARD-Polis-i.MX8MM support") Signed-off-by: Yashwanth Varakala <y.varakala@phytec.de> Signed-off-by: Cem Tenruh <c.tenruh@phytec.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | ARM: dts: nxp/imx6sll: fix wrong property name in usbphy nodeXu Yang2023-07-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Property name "phy-3p0-supply" is used instead of "phy-reg_3p0-supply". Fixes: 9f30b6b1a957 ("ARM: dts: imx: Add basic dtsi file for imx6sll") cc: <stable@vger.kernel.org> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | arm64: dts: imx8mm-venice-gw7904: disable disp_blk_ctrlTim Harvey2023-07-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GW7904 does not connect the VDD_MIPI power rails thus MIPI is disabled. However we must also disable disp_blk_ctrl as it uses the pgc_mipi power domain and without it being disabled imx8m-blk-ctrl will fail to probe: imx8m-blk-ctrl 32e28000.blk-ctrl: error -ETIMEDOUT: failed to attach power domain "mipi-dsi" imx8m-blk-ctrl: probe of 32e28000.blk-ctrl failed with error -110 Fixes: b999bdaf0597 ("arm64: dts: imx: Add i.mx8mm Gateworks gw7904 dts support") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | arm64: dts: imx8mm-venice-gw7903: disable disp_blk_ctrlTim Harvey2023-07-171-0/+4
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GW7903 does not connect the VDD_MIPI power rails thus MIPI is disabled. However we must also disable disp_blk_ctrl as it uses the pgc_mipi power domain and without it being disabled imx8m-blk-ctrl will fail to probe: imx8m-blk-ctrl 32e28000.blk-ctrl: error -ETIMEDOUT: failed to attach power domain "mipi-dsi" imx8m-blk-ctrl: probe of 32e28000.blk-ctrl failed with error -110 Fixes: a72ba91e5bc7 ("arm64: dts: imx: Add i.mx8mm Gateworks gw7903 dts support") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| * | backlight: corgi_lcd: fix missing prototypeArnd Bergmann2023-07-273-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The corgi_lcd_limit_intensity() function is called from platform and defined in a driver, but the driver does not see the declaration: drivers/video/backlight/corgi_lcd.c:434:6: error: no previous prototype for 'corgi_lcd_limit_intensity' [-Werror=missing-prototypes] 434 | void corgi_lcd_limit_intensity(int limit) Move the prototype into a header that can be included from both sides to shut up the warning. Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * | dt-bindings: serial: atmel,at91-usart: update compatible for sam9x60Durai Manickam KR2023-07-241-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is only one debug unit in the sam9x60 SOC and it has the chipid register. So, the dbgu compatible strings are valid only for debug usart. Defining these dbgu compatible strings are not valid for flexcom usart. So adding the items which is valid only for flexcom usart and removing the microchip,sam9x60-usart compatible string from the enum list as no usart node defines only this specific compatible string. Signed-off-by: Durai Manickam KR <durai.manickamkr@microchip.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230718065735.10187-2-durai.manickamkr@microchip.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * | Merge tag 'scmi-smccc-fixes-6.5' of ↵Arnd Bergmann2023-07-244-12/+23
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Arm SCMI and SMCCC fixes for v6.5 Set of fixes addressing issues: 1. Possible use of uninitialised results structure in the SMCCC SOC_ID driver if the driver fails to complete the initialisation 2. Missed signed error return value handling from simple_write_to_buffer() used in scmi_dbg_raw_mode_common_write() 3. The OF node reference obtained is not dropped if node is incompatible with "arm,scmi-shmem" in the mailbox as well as SMC transport channel setup 4. The possibility of a late response to an in-flight pending transaction that could end up triggering the interrupt handler after the SCMI core has cleaned up the transport channel as part of core driver remove * tag 'scmi-smccc-fixes-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Fix chan_free cleanup on SMC firmware: arm_scmi: Drop OF node reference in the transport channel setup firmware: arm_scmi: Fix signed error return values handling firmware: smccc: Fix use of uninitialised results structure Link: https://lore.kernel.org/r/20230721114052.3371923-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| | * | firmware: arm_scmi: Fix chan_free cleanup on SMCCristian Marussi2023-07-201-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SCMI transport based on SMC can optionally use an additional IRQ to signal message completion. The associated interrupt handler is currently allocated using devres but on shutdown the core SCMI stack will call .chan_free() well before any managed cleanup is invoked by devres. As a consequence, the arrival of a late reply to an in-flight pending transaction could still trigger the interrupt handler well after the SCMI core has cleaned up the channels, with unpleasant results. Inhibit further message processing on the IRQ path by explicitly freeing the IRQ inside .chan_free() callback itself. Fixes: dd820ee21d5e ("firmware: arm_scmi: Augment SMC/HVC to allow optional interrupt") Reported-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20230719173533.2739319-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
| | * | firmware: arm_scmi: Drop OF node reference in the transport channel setupKrzysztof Kozlowski2023-07-192-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OF node reference obtained from of_parse_phandle() should be dropped if node is not compatible with arm,scmi-shmem. Fixes: 507cd4d2c5eb ("firmware: arm_scmi: Add compatibility checks for shmem node") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20230719061652.8850-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
| | * | firmware: arm_scmi: Fix signed error return values handlingSukrut Bellary2023-07-181-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Handle signed error return values returned by simple_write_to_buffer(). In case of an error, return the error code. Fixes: 3c3d818a9317 ("firmware: arm_scmi: Add core raw transmission support") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Sukrut Bellary <sukrut.bellary@linux.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/20230718085529.258899-1-sukrut.bellary@linux.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
| | * | firmware: smccc: Fix use of uninitialised results structurePunit Agrawal2023-07-181-3/+2
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 35727af2b15d ("irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4") moved the initialisation of the SoC version to arm_smccc_version_init() but forgot to update the results structure and it's usage. Fix the use of the uninitialised results structure and update the error strings. Fixes: 35727af2b15d ("irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4") Signed-off-by: Punit Agrawal <punit.agrawal@bytedance.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Vikram Sethi <vsethi@nvidia.com> Cc: Shanker Donthineni <sdonthineni@nvidia.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230717171702.424253-1-punit.agrawal@bytedance.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
| * | ARM: dts: at91: sam9x60: fix the SOC detectionDurai Manickam KR2023-07-211-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the dbgu compatible strings in the UART submodule of the flexcom for the proper SOC detection. Fixes: 99c808335877 (ARM: dts: at91: sam9x60: Add missing flexcom definitions) Signed-off-by: Durai Manickam KR <durai.manickamkr@microchip.com> Link: https://lore.kernel.org/r/20230712100042.317856-1-durai.manickamkr@microchip.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * | ARM: dts: nspire: Fix arm primecell compatible stringSudeep Holla2023-07-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c44e0503e5fd ("docs: dt: fix documented Primecell compatible string") removed the last occurrence of incorrect "arm,amba-primecell" compatible string, but somehow one occurrence of the same is left in the nspire platform. Fix the same by replacing it with the correct "arm,primecell" compatible. Cc: Rob Herring <robh+dt@kernel.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: Conor Dooley <conor+dt@kernel.org> Cc: devicetree@vger.kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20230711092617.1412815-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * | Merge tag 'juno-fix-6.5' of ↵Arnd Bergmann2023-07-211-1/+0
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Armv8 Juno/Vexpress DTS fix for v6.5 A single simple fix removing dangling symlink left as part of arm dts files movement to vendor sub-directories. It is harmless and causes no issue for the build but scripts copying files see errors/failures. * tag 'juno-fix-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: arm64: dts: arm: Remove the dangling vexpress-v2m-rs1.dtsi symlink Link: https://lore.kernel.org/r/20230721112359.3369716-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| | * | arm64: dts: arm: Remove the dangling vexpress-v2m-rs1.dtsi symlinkSudeep Holla2023-07-131-1/+0
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 724ba6751532 ("ARM: dts: Move .dts files to vendor sub-directories") moved all arm vendor specific DTS into the sub-directory and updated vexpress-v2f-1xv7-ca53x2.dts accordingly to include vexpress-v2m-rs1.dtsi from the right path. However the symlink was left dangling which is harmless and causes no issue for the build. Just remove the dangling symlink now that it is noticed and reported. Fixes: 724ba6751532 ("ARM: dts: Move .dts files to vendor sub-directories") Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org> Cc: Rob Herring <robh+dt@kernel.org> Reported-by: Avram Lubkin <avram@rockhopper.net> Reported-by: Darren Kenny <darren.kenny@oracle.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/r/20230706085534.300828-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* | | Merge tag 'bitmap-6.5-rc5' of https://github.com:/norov/linuxLinus Torvalds2023-08-024-7/+20
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull bitmap fixes from Yury Norov: - Fix for bitmap documentation - Fix for kernel build under certain configurations * tag 'bitmap-6.5-rc5' of https://github.com:/norov/linux: lib/bitmap: workaround const_eval test build failure cpumask: eliminate kernel-doc warnings
| * | | lib/bitmap: workaround const_eval test build failureYury Norov2023-07-182-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building with Clang, and when KASAN and GCOV_PROFILE_ALL are both enabled, the test fails to build [1]: >> lib/test_bitmap.c:920:2: error: call to '__compiletime_assert_239' declared with 'error' attribute: BUILD_BUG_ON failed: !__builtin_constant_p(res) BUILD_BUG_ON(!__builtin_constant_p(res)); ^ include/linux/build_bug.h:50:2: note: expanded from macro 'BUILD_BUG_ON' BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) ^ include/linux/build_bug.h:39:37: note: expanded from macro 'BUILD_BUG_ON_MSG' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^ include/linux/compiler_types.h:352:2: note: expanded from macro 'compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ include/linux/compiler_types.h:340:2: note: expanded from macro '_compiletime_assert' __compiletime_assert(condition, msg, prefix, suffix) ^ include/linux/compiler_types.h:333:4: note: expanded from macro '__compiletime_assert' prefix ## suffix(); \ ^ <scratch space>:185:1: note: expanded from here __compiletime_assert_239 Originally it was attributed to s390, which now looks seemingly wrong. The issue is not related to bitmap code itself, but it breaks build for a given configuration. Disabling the const_eval test under that config may potentially hide other bugs. Instead, workaround it by disabling GCOV for the test_bitmap unless the compiler will get fixed. [1] https://github.com/ClangBuiltLinux/linux/issues/1874 Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202307171254.yFcH97ej-lkp@intel.com/ Fixes: dc34d5036692 ("lib: test_bitmap: add compile-time optimization/evaluations assertions") Co-developed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Yury Norov <yury.norov@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
| * | | cpumask: eliminate kernel-doc warningsRandy Dunlap2023-07-172-3/+10
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update lib/cpumask.c and <linux/cpumask.h> to fix all kernel-doc warnings: include/linux/cpumask.h:185: warning: Function parameter or member 'srcp1' not described in 'cpumask_first_and' include/linux/cpumask.h:185: warning: Function parameter or member 'srcp2' not described in 'cpumask_first_and' include/linux/cpumask.h:185: warning: Excess function parameter 'src1p' description in 'cpumask_first_and' include/linux/cpumask.h:185: warning: Excess function parameter 'src2p' description in 'cpumask_first_and' lib/cpumask.c:59: warning: Function parameter or member 'node' not described in 'alloc_cpumask_var_node' lib/cpumask.c:169: warning: Function parameter or member 'src1p' not described in 'cpumask_any_and_distribute' lib/cpumask.c:169: warning: Function parameter or member 'src2p' not described in 'cpumask_any_and_distribute' Fixes: 7b4967c53204 ("cpumask: Add alloc_cpumask_var_node()") Fixes: 839cad5fa54b ("cpumask: fix function description kernel-doc notation") Fixes: 93ba139ba819 ("cpumask: use find_first_and_bit()") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Yury Norov <yury.norov@gmail.com>
* | | Merge tag 'exfat-for-6.5-rc5' of ↵Linus Torvalds2023-08-022-20/+22
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat Pull exfat fixes from Namjae Jeon: - Fix page allocation failure from allocation bitmap by using kvmalloc_array/kvfree - Add the check to validate if filename entries exceeds max filename length - Fix potential deadlock condition from dir_emit*() * tag 'exfat-for-6.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat: exfat: release s_lock before calling dir_emit() exfat: check if filename entries exceeds max filename length exfat: use kvmalloc_array/kvfree instead of kmalloc_array/kfree
| * | | exfat: release s_lock before calling dir_emit()Sungjong Seo2023-07-151-15/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a potential deadlock reported by syzbot as below: ====================================================== WARNING: possible circular locking dependency detected 6.4.0-next-20230707-syzkaller #0 Not tainted ------------------------------------------------------ syz-executor330/5073 is trying to acquire lock: ffff8880218527a0 (&mm->mmap_lock){++++}-{3:3}, at: mmap_read_lock_killable include/linux/mmap_lock.h:151 [inline] ffff8880218527a0 (&mm->mmap_lock){++++}-{3:3}, at: get_mmap_lock_carefully mm/memory.c:5293 [inline] ffff8880218527a0 (&mm->mmap_lock){++++}-{3:3}, at: lock_mm_and_find_vma+0x369/0x510 mm/memory.c:5344 but task is already holding lock: ffff888019f760e0 (&sbi->s_lock){+.+.}-{3:3}, at: exfat_iterate+0x117/0xb50 fs/exfat/dir.c:232 which lock already depends on the new lock. Chain exists of: &mm->mmap_lock --> mapping.invalidate_lock#3 --> &sbi->s_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&sbi->s_lock); lock(mapping.invalidate_lock#3); lock(&sbi->s_lock); rlock(&mm->mmap_lock); Let's try to avoid above potential deadlock condition by moving dir_emit*() out of sbi->s_lock coverage. Fixes: ca06197382bd ("exfat: add directory operations") Cc: stable@vger.kernel.org #v5.7+ Reported-by: syzbot+1741a5d9b79989c10bdc@syzkaller.appspotmail.com Link: https://lore.kernel.org/lkml/00000000000078ee7e060066270b@google.com/T/#u Tested-by: syzbot+1741a5d9b79989c10bdc@syzkaller.appspotmail.com Signed-off-by: Sungjong Seo <sj1557.seo@samsung.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
| * | | exfat: check if filename entries exceeds max filename lengthNamjae Jeon2023-07-131-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | exfat_extract_uni_name copies characters from a given file name entry into the 'uniname' variable. This variable is actually defined on the stack of the exfat_readdir() function. According to the definition of the 'exfat_uni_name' type, the file name should be limited 255 characters (+ null teminator space), but the exfat_get_uniname_from_ext_entry() function can write more characters because there is no check if filename entries exceeds max filename length. This patch add the check not to copy filename characters when exceeding max filename length. Cc: stable@vger.kernel.org Cc: Yuezhang Mo <Yuezhang.Mo@sony.com> Reported-by: Maxim Suhanov <dfirblog@gmail.com> Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
| * | | exfat: use kvmalloc_array/kvfree instead of kmalloc_array/kfreegaoming2023-07-111-3/+3
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The call stack shown below is a scenario in the Linux 4.19 kernel. Allocating memory failed where exfat fs use kmalloc_array due to system memory fragmentation, while the u-disk was inserted without recognition. Devices such as u-disk using the exfat file system are pluggable and may be insert into the system at any time. However, long-term running systems cannot guarantee the continuity of physical memory. Therefore, it's necessary to address this issue. Binder:2632_6: page allocation failure: order:4, mode:0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null) Call trace: [242178.097582] dump_backtrace+0x0/0x4 [242178.097589] dump_stack+0xf4/0x134 [242178.097598] warn_alloc+0xd8/0x144 [242178.097603] __alloc_pages_nodemask+0x1364/0x1384 [242178.097608] kmalloc_order+0x2c/0x510 [242178.097612] kmalloc_order_trace+0x40/0x16c [242178.097618] __kmalloc+0x360/0x408 [242178.097624] load_alloc_bitmap+0x160/0x284 [242178.097628] exfat_fill_super+0xa3c/0xe7c [242178.097635] mount_bdev+0x2e8/0x3a0 [242178.097638] exfat_fs_mount+0x40/0x50 [242178.097643] mount_fs+0x138/0x2e8 [242178.097649] vfs_kern_mount+0x90/0x270 [242178.097655] do_mount+0x798/0x173c [242178.097659] ksys_mount+0x114/0x1ac [242178.097665] __arm64_sys_mount+0x24/0x34 [242178.097671] el0_svc_common+0xb8/0x1b8 [242178.097676] el0_svc_handler+0x74/0x90 [242178.097681] el0_svc+0x8/0x340 By analyzing the exfat code,we found that continuous physical memory is not required here,so kvmalloc_array is used can solve this problem. Cc: stable@vger.kernel.org Signed-off-by: gaoming <gaoming20@hihonor.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
* | | Merge tag 'scsi-fixes' of ↵Linus Torvalds2023-08-023-6/+7
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Three small fixes, all in drivers" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: pm80xx: Fix error return code in pm8001_pci_probe() scsi: zfcp: Defer fc_rport blocking until after ADISC response scsi: storvsc: Limit max_sectors for virtual Fibre Channel devices
| * | | scsi: pm80xx: Fix error return code in pm8001_pci_probe()Yang Yingliang2023-07-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If pm8001_init_sas_add() fails, return error code in pm8001_pci_probe(). Fixes: 14a8f116cdc0 ("scsi: pm80xx: Add GET_NVMD timeout during probe") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230725125706.566990-1-yangyingliang@huawei.com Reviewed-by: Igor Pylypiv <ipylypiv@google.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | | scsi: zfcp: Defer fc_rport blocking until after ADISC responseSteffen Maier2023-07-251-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Storage devices are free to send RSCNs, e.g. for internal state changes. If this happens on all connected paths, zfcp risks temporarily losing all paths at the same time. This has strong requirements on multipath configuration such as "no_path_retry queue". Avoid such situations by deferring fc_rport blocking until after the ADISC response, when any actual state change of the remote port became clear. The already existing port recovery triggers explicitly block the fc_rport. The triggers are: on ADISC reject or timeout (typical cable pull case), and on ADISC indicating that the remote port has changed its WWPN or the port is meanwhile no longer open. As a side effect, this also removes a confusing direct function call to another work item function zfcp_scsi_rport_work() instead of scheduling that other work item. It was probably done that way to have the rport block side effect immediate and synchronous to the caller. Fixes: a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors") Cc: stable@vger.kernel.org #v2.6.30+ Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com> Signed-off-by: Steffen Maier <maier@linux.ibm.com> Link: https://lore.kernel.org/r/20230724145156.3920244-1-maier@linux.ibm.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | | scsi: storvsc: Limit max_sectors for virtual Fibre Channel devicesMichael Kelley2023-07-231-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Hyper-V host is queried to get the max transfer size that it supports, and this value is used to set max_sectors for the synthetic SCSI controller. However, this max transfer size may be too large for virtual Fibre Channel devices, which are limited to 512 Kbytes. If a larger transfer size is used with a vFC device, Hyper-V always returns an error, and storvsc logs a message like this where the SRB status and SCSI status are both zero: hv_storvsc <GUID>: tag#197 cmd 0x8a status: scsi 0x0 srb 0x0 hv 0xc0000001 Add logic to limit the max transfer size to 512 Kbytes for vFC devices. Fixes: 1d3e0980782f ("scsi: storvsc: Correct reporting of Hyper-V I/O size limits") Cc: stable@vger.kernel.org Signed-off-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/1689887102-32806-1-git-send-email-mikelley@microsoft.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
* | | | word-at-a-time: use the same return type for has_zero regardless of endiannessndesaulniers@google.com2023-08-022-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compiling big-endian targets with Clang produces the diagnostic: fs/namei.c:2173:13: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] } while (!(has_zero(a, &adata, &constants) | has_zero(b, &bdata, &constants))); ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || fs/namei.c:2173:13: note: cast one or both operands to int to silence this warning It appears that when has_zero was introduced, two definitions were produced with different signatures (in particular different return types). Looking at the usage in hash_name() in fs/namei.c, I suspect that has_zero() is meant to be invoked twice per while loop iteration; using logical-or would not update `bdata` when `a` did not have zeros. So I think it's preferred to always return an unsigned long rather than a bool than update the while loop in hash_name() to use a logical-or rather than bitwise-or. [ Also changed powerpc version to do the same - Linus ] Link: https://github.com/ClangBuiltLinux/linux/issues/1832 Link: https://lore.kernel.org/lkml/20230801-bitwise-v1-1-799bec468dc4@google.com/ Fixes: 36126f8f2ed8 ("word-at-a-time: make the interfaces truly generic") Debugged-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | | Linux 6.5-rc4v6.5-rc4Linus Torvalds2023-07-301-1/+1
| | | |
* | | | Merge tag 'spi-fix-v6.5-rc3' of ↵Linus Torvalds2023-07-301-5/+49
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A bunch of fixes for the Qualcomm QSPI driver, fixing multiple issues with the newly added DMA mode - it had a number of issues exposed when tested in a wider range of use cases, both race condition style issues and issues with different inputs to those that had been used in test" * tag 'spi-fix-v6.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: spi-qcom-qspi: Add mem_ops to avoid PIO for badly sized reads spi: spi-qcom-qspi: Fallback to PIO for xfers that aren't multiples of 4 bytes spi: spi-qcom-qspi: Add DMA_CHAIN_DONE to ALL_IRQS spi: spi-qcom-qspi: Call dma_wmb() after setting up descriptors spi: spi-qcom-qspi: Use GFP_ATOMIC flag while allocating for descriptor spi: spi-qcom-qspi: Ignore disabled interrupts' status in isr
| * | | | spi: spi-qcom-qspi: Add mem_ops to avoid PIO for badly sized readsDouglas Anderson2023-07-261-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the patch ("spi: spi-qcom-qspi: Fallback to PIO for xfers that aren't multiples of 4 bytes") we detect reads that we can't handle properly and fallback to PIO mode. While that's correct behavior, we can do better by adding "spi_controller_mem_ops" for our controller. Once we do this then the caller will give us a transfer that's a multiple of 4-bytes so we can DMA. Fixes: b5762d95607e ("spi: spi-qcom-qspi: Add DMA mode support") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> Link: https://lore.kernel.org/r/20230725110226.2.Id4a39804e01e4a06dae9b73fd2a5194c4c7ea453@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | | spi: spi-qcom-qspi: Fallback to PIO for xfers that aren't multiples of 4 bytesDouglas Anderson2023-07-261-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Qualcomm QSPI driver appears to require that any reads using DMA are a mutliple of 4 bytes. If this isn't true then the controller will clobber any extra bytes in memory following the last word. Let's detect this and falback to PIO. This fixes problems reported by slub_debug=FZPUA, which would complain about "kmalloc Redzone overwritten". One such instance said: 0xffffff80c29d541a-0xffffff80c29d541b @offset=21530. First byte 0x0 instead of 0xcc Allocated in mtd_kmalloc_up_to+0x98/0xac age=36 cpu=3 pid=6658 Tracing through what was happening I saw that, while we often did DMA tranfers of 0x1000 bytes, sometimes we'd end up doing ones of 0x41a bytes. Those 0x41a byte transfers were the problem. NOTE: a future change will enable the SPI "mem ops" to help avoid this case, but it still seems good to add the extra check in the transfer. Fixes: b5762d95607e ("spi: spi-qcom-qspi: Add DMA mode support") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230725110226.1.Ia2f980fc7cd0b831e633391f0bb1272914d8f381@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | | spi: spi-qcom-qspi: Add DMA_CHAIN_DONE to ALL_IRQSVijaya Krishna Nivarthi2023-07-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add latest added DMA_CHAIN_DONE irq to QSPI_ALL_IRQS that encompasses all of the qspi IRQs. Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/1690285689-30233-5-git-send-email-quic_vnivarth@quicinc.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | | spi: spi-qcom-qspi: Call dma_wmb() after setting up descriptorsVijaya Krishna Nivarthi2023-07-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After setting up dma descriptors and before initiaiting dma transfer, call dma_wmb() to ensure all writes go through. This doesn't fix any reported problem but is added for safety. Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> Fixes: b5762d95607e ("spi: spi-qcom-qspi: Add DMA mode support") Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/1690285689-30233-4-git-send-email-quic_vnivarth@quicinc.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | | spi: spi-qcom-qspi: Use GFP_ATOMIC flag while allocating for descriptorVijaya Krishna Nivarthi2023-07-251-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While allocating for DMA descriptor, GFP_KERNEL flag is being used and this allocation happens within critical section with spinlock acquired. This generates a static checker warning. Use GFP_ATOMIC to prevent sleeping; and since this increases chances of allocation failure, add handling accordingly. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/abc223e8-44af-40bb-a0bd-9865b393f435@moroto.mountain/ Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> Fixes: b5762d95607e ("spi: spi-qcom-qspi: Add DMA mode support") Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/1690285689-30233-3-git-send-email-quic_vnivarth@quicinc.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | | spi: spi-qcom-qspi: Ignore disabled interrupts' status in isrVijaya Krishna Nivarthi2023-07-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During FIFO/DMA modes dynamic switching, only corresponding interrupts are enabled. However its possible that FIFO related interrupt status registers get set during DMA mode. For example WR_FIFO_EMPTY bit is set during DMA TX. Ignore such status bits so that they don't trip unwanted operations. Suggested-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> Fixes: b5762d95607e ("spi: spi-qcom-qspi: Add DMA mode support") Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/1690285689-30233-2-git-send-email-quic_vnivarth@quicinc.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | | | | Merge tag 'regulator-fix-v6.5-rc3' of ↵Linus Torvalds2023-07-301-5/+5
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "A couple of small fixes for the the mt6358 driver, fixing error reporting and a bootstrapping issue" * tag 'regulator-fix-v6.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: mt6358: Fix incorrect VCN33 sync error message regulator: mt6358: Sync VCN33_* enable status after checking ID
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-31 08:24:21 +0000