Samin Guo [Fri, 3 Mar 2023 08:49:31 +0000 (16:49 +0800)]
riscv: dts: starfive: jh7110: Add ethernet device nodes
Add JH7110 ethernet device node to support gmac driver for the JH7110
RISC-V SoC.
Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com>
Signed-off-by: Samin Guo <samin.guo@starfivetech.com>
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Samin Guo [Thu, 2 Mar 2023 11:52:37 +0000 (19:52 +0800)]
net: stmmac: starfive_dmac: Add phy interface settings
dwmac supports multiple modess. When working under rmii and rgmii,
you need to set different phy interfaces.
According to the dwmac document, when working in rmii, it needs to be
set to 0x4, and rgmii needs to be set to 0x1.
The phy interface needs to be set in syscon, the format is as follows:
starfive,syscon: <&syscon, offset, shift>
Signed-off-by: Samin Guo <samin.guo@starfivetech.com>
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Samin Guo [Fri, 3 Mar 2023 08:50:58 +0000 (16:50 +0800)]
net: stmmac: Add glue layer for StarFive JH7110 SoC
This adds StarFive dwmac driver support on the StarFive JH7110 SoC.
Co-developed-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Samin Guo <samin.guo@starfivetech.com>
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Yanhong Wang [Mon, 31 Oct 2022 10:08:15 +0000 (18:08 +0800)]
dt-bindings: net: Add support StarFive dwmac
Add documentation to describe StarFive dwmac driver(GMAC).
Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com>
Signed-off-by: Samin Guo <samin.guo@starfivetech.com>
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Samin Guo [Mon, 27 Feb 2023 10:26:04 +0000 (18:26 +0800)]
dt-bindings: net: snps,dwmac: Add 'ahb' reset/reset-name
According to:
stmmac_platform.c: stmmac_probe_config_dt
stmmac_main.c: stmmac_dvr_probe
dwmac controller may require one (stmmaceth) or two (stmmaceth+ahb)
reset signals, and the maxItems of resets/reset-names is going to be 2.
The gmac of Starfive Jh7110 SOC must have two resets.
it uses snps,dwmac-5.20 IP.
Signed-off-by: Samin Guo <samin.guo@starfivetech.com>
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Emil Renner Berthing [Sun, 7 Aug 2022 20:26:00 +0000 (22:26 +0200)]
net: stmmac: platform: Add snps,dwmac-5.20 IP compatible string
Add "snps,dwmac-5.20" compatible string for 5.20 version that can avoid
to define some platform data in the glue layer.
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Samin Guo <samin.guo@starfivetech.com>
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Emil Renner Berthing [Mon, 8 Aug 2022 15:13:34 +0000 (17:13 +0200)]
dt-bindings: net: snps,dwmac: Add dwmac-5.20 version
Add dwmac-5.20 IP version to snps.dwmac.yaml
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Samin Guo <samin.guo@starfivetech.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
William Qiu [Wed, 1 Mar 2023 08:45:11 +0000 (16:45 +0800)]
riscv: dts: starfive: Add PWM node
Adding StarFive PWM controller node to VisionFive 2 SoC.
Signed-off-by: William Qiu <william.qiu@starfivetech.com>
William Qiu [Tue, 21 Mar 2023 05:52:28 +0000 (13:52 +0800)]
pwm: starfive: Add PWM driver support
Add Pulse Width Modulation driver support for StarFive
JH7110 soc.
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Signed-off-by: William Qiu <william.qiu@starfivetech.com>
William Qiu [Tue, 21 Mar 2023 05:52:27 +0000 (13:52 +0800)]
dt-bindings: PWM: Add StarFive PWM module
Add documentation to describe StarFive Pulse Width Modulation
controller driver.
Signed-off-by: William Qiu <william.qiu@starfivetech.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
William Qiu [Thu, 2 Mar 2023 08:42:57 +0000 (16:42 +0800)]
riscv: dts: starfive: jh7110: Add qspi controller node
Add the quad spi controller node for the Starfive JH7110 SoC.
Signed-off-by: William Qiu <william.qiu@starfivetech.com>
William Qiu [Thu, 2 Mar 2023 10:52:21 +0000 (18:52 +0800)]
spi: cadence-quadspi: Add support for StarFive JH7110 QSPI
Add QSPI reset operation in device probe and add RISCV support to
QUAD SPI Kconfig.
Co-developed-by: Ziv Xu <ziv.xu@starfivetech.com>
Signed-off-by: Ziv Xu <ziv.xu@starfivetech.com>
Signed-off-by: William Qiu <william.qiu@starfivetech.com>
Link: https://lore.kernel.org/r/20230302105221.197421-3-william.qiu@starfivetech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
William Qiu [Thu, 2 Mar 2023 10:52:20 +0000 (18:52 +0800)]
dt-bindings: qspi: cdns,qspi-nor: constrain minItems/maxItems of resets
The QSPI controller needs three reset items to work properly on JH7110 SoC,
so there is need to change the maxItems's value to 3 and add minItems
whose value is equal to 2. Other platforms do not have this constraint.
Signed-off-by: William Qiu <william.qiu@starfivetech.com>
Link: https://lore.kernel.org/r/20230302105221.197421-2-william.qiu@starfivetech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
William Qiu [Wed, 15 Feb 2023 09:51:55 +0000 (17:51 +0800)]
riscv: dts: starfive: Add mmc node
Adds the mmc node for the StarFive JH7110 SoC.
Set mmco node to emmc and set mmc1 node to sd.
Signed-off-by: William Qiu <william.qiu@starfivetech.com>
Xingyu Wu [Tue, 1 Nov 2022 13:54:04 +0000 (21:54 +0800)]
riscv: dts: jh7110: starfive: Add timer node
Add the timer node for the Starfive JH7110 SoC.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Tue, 1 Nov 2022 13:45:06 +0000 (21:45 +0800)]
clocksource: Add StarFive timer driver
Add timer driver for the StarFive JH7110 SoC.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Tue, 1 Nov 2022 08:50:47 +0000 (16:50 +0800)]
dt-bindings: timer: Add timer for StarFive JH7110 SoC
Add bindings for the timer on the JH7110 RISC-V SoC
by StarFive Technology Ltd.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Thu, 3 Nov 2022 02:37:08 +0000 (10:37 +0800)]
riscv: dts: starfive: jh7110: Add watchdog node
Add the watchdog node for the Starfive JH7110 SoC.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Mon, 6 Mar 2023 02:42:07 +0000 (10:42 +0800)]
riscv: dts: starfive: jh7100: Add watchdog node
Add watchdog node for the StarFive JH7100 RISC-V SoC.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Xingyu Wu [Thu, 3 Nov 2022 02:29:12 +0000 (10:29 +0800)]
drivers: watchdog: Add StarFive Watchdog driver
Add watchdog driver for the StarFive JH7100 and JH7110 SoC.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Wed, 2 Nov 2022 08:48:26 +0000 (16:48 +0800)]
dt-bindings: watchdog: Add watchdog for StarFive JH7100 and JH7110
Add bindings to describe the watchdog for the StarFive JH7100/JH7110 SoC.
And Use JH7100 as first StarFive SoC with watchdog.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Xingyu Wu [Thu, 16 Mar 2023 03:05:14 +0000 (11:05 +0800)]
riscv: dts: starfive: jh7110: Add PLL clock node and modify syscrg node
Add the PLL clock node for the Starfive JH7110 SoC and
modify the SYSCRG node to add PLL clocks.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Thu, 16 Mar 2023 03:05:13 +0000 (11:05 +0800)]
clk: starfive: jh7110-sys: Modify PLL clocks source
Modify PLL clocks source to be got from dts instead of
the fixed factor clocks.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Thu, 16 Mar 2023 03:05:12 +0000 (11:05 +0800)]
dt-bindings: clock: jh7110-syscrg: Add PLL clock inputs
Add PLL clock inputs from PLL clock generator.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Xingyu Wu [Thu, 16 Mar 2023 03:05:11 +0000 (11:05 +0800)]
dt-bindings: soc: starfive: syscon: Add optional patternProperties
Add optional compatible and patternProperties.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Thu, 16 Mar 2023 03:05:10 +0000 (11:05 +0800)]
clk: starfive: Add StarFive JH7110 PLL clock driver
Add driver for the StarFive JH7110 PLL clock controller.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Thu, 16 Mar 2023 03:05:09 +0000 (11:05 +0800)]
dt-bindings: clock: Add StarFive JH7110 PLL clock generator
Add bindings for the PLL clock generator on the JH7110 RISC-V SoC.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Xingyu Wu [Tue, 25 Oct 2022 06:48:25 +0000 (14:48 +0800)]
riscv: dts: starfive: jh7110: Add STGCRG/ISPCRG/VOUTCRG nodes
Add STGCRG/ISPCRG/VOUTCRG new node to support JH7110
System-Top-Group, Image-Signal-Process and Video-Output
clock and reset drivers for the JH7110 RISC-V SoC.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Xingyu Wu [Tue, 14 Mar 2023 12:44:03 +0000 (20:44 +0800)]
riscv: dts: starfive: jh7110: Add DVP and HDMI TX pixel external clocks
Add DVP and HDMI TX pixel external fixed clocks and the rates are
74.25MHz and 297MHz.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Tue, 14 Mar 2023 12:44:02 +0000 (20:44 +0800)]
clk: starfive: Add StarFive JH7110 Video-Output clock driver
Add driver for the StarFive JH7110 Video-Output clock controller.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Tue, 14 Mar 2023 12:44:01 +0000 (20:44 +0800)]
reset: starfive: jh7110: Add StarFive Video-Output reset support
Add auxiliary_device_id to support StarFive JH7110 Video-Output resets
of which the auxiliary device name is "clk_starfive_jh71x0.reset-vout".
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Tue, 14 Mar 2023 12:44:00 +0000 (20:44 +0800)]
dt-bindings: clock: Add StarFive JH7110 Video-Output clock and reset generator
Add bindings for the Video-Output clock and reset generator (VOUTCRG)
on the JH7110 RISC-V SoC by StarFive Ltd.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Xingyu Wu [Tue, 14 Mar 2023 12:43:59 +0000 (20:43 +0800)]
clk: starfive: Add StarFive JH7110 Image-Signal-Process clock driver
Add driver for the StarFive JH7110 Image-Signal-Process clock controller.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Tue, 14 Mar 2023 12:43:58 +0000 (20:43 +0800)]
reset: starfive: jh7110: Add StarFive Image-Signal-Process reset support
Add auxiliary_device_id to support StarFive JH7110 Image-Signal-Process
resets of which the auxiliary device name is
"clk_starfive_jh71x0.reset-isp".
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Tue, 14 Mar 2023 12:43:57 +0000 (20:43 +0800)]
dt-bindings: clock: Add StarFive JH7110 Image-Signal-Process clock and reset generator
Add bindings for the Image-Signal-Process clock and reset
generator (ISPCRG) on the JH7110 RISC-V SoC by StarFive Ltd.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Emil Renner Berthing [Tue, 14 Mar 2023 12:43:56 +0000 (20:43 +0800)]
clk: starfive: Add StarFive JH7110 System-Top-Group clock driver
Add driver for the StarFive JH7110 System-Top-Group clock controller.
Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Co-developed-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Tue, 14 Mar 2023 12:43:55 +0000 (20:43 +0800)]
reset: starfive: jh7110: Add StarFive System-Top-Group reset support
Add auxiliary_device_id to support StarFive JH7110 System-Top-Group resets
of which the auxiliary device name is "clk_starfive_jh71x0.reset-stg".
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Xingyu Wu [Tue, 14 Mar 2023 12:43:54 +0000 (20:43 +0800)]
dt-bindings: clock: Add StarFive JH7110 System-Top-Group clock and reset generator
Add bindings for the System-Top-Group clock and reset generator (STGCRG)
on the JH7110 RISC-V SoC by StarFive Ltd.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
William Qiu [Wed, 15 Mar 2023 05:58:13 +0000 (13:58 +0800)]
riscv: dts: starfive: Add syscon node
Add stg_syscon/sys_syscon/aon_syscon node for JH7110 Soc.
Signed-off-by: William Qiu <william.qiu@starfivetech.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
William Qiu [Wed, 15 Mar 2023 05:58:12 +0000 (13:58 +0800)]
dt-bindings: soc: starfive: Add StarFive syscon doc
Add documentation to describe StarFive System Controller Registers.
Signed-off-by: William Qiu <william.qiu@starfivetech.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Walker Chen [Mon, 16 Jan 2023 07:14:52 +0000 (15:14 +0800)]
riscv: dts: starfive: add pmu controller node
Add the pmu controller node for the Starfive JH7110 SoC. The PMU needs
to be used by other modules such as VPU, ISP, etc.
Signed-off-by: Walker Chen <walker.chen@starfivetech.com>
Emil Renner Berthing [Sat, 9 Jul 2022 12:37:38 +0000 (14:37 +0200)]
riscv: dts: starfive: Add StarFive JH7110 VisionFive 2 board device tree
Add a minimal device tree for StarFive JH7110 VisionFive 2 board
which has version A and version B. Support booting and basic
clock/reset/pinctrl/uart drivers.
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Co-developed-by: Jianlong Huang <jianlong.huang@starfivetech.com>
Signed-off-by: Jianlong Huang <jianlong.huang@starfivetech.com>
Co-developed-by: Hal Feng <hal.feng@starfivetech.com>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Jianlong Huang [Fri, 9 Sep 2022 01:41:38 +0000 (09:41 +0800)]
riscv: dts: starfive: Add StarFive JH7110 pin function definitions
Add pin function definitions for StarFive JH7110 SoC.
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Co-developed-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Jianlong Huang <jianlong.huang@starfivetech.com>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Sat, 9 Jul 2022 12:37:38 +0000 (14:37 +0200)]
riscv: dts: starfive: Add initial StarFive JH7110 device tree
Add initial device tree for the JH7110 RISC-V SoC by StarFive
Technology Ltd.
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Co-developed-by: Jianlong Huang <jianlong.huang@starfivetech.com>
Signed-off-by: Jianlong Huang <jianlong.huang@starfivetech.com>
Co-developed-by: Hal Feng <hal.feng@starfivetech.com>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Hal Feng [Sun, 19 Feb 2023 14:47:33 +0000 (22:47 +0800)]
dt-bindings: riscv: Add SiFive S7 compatible
Add a new compatible string in cpu.yaml for SiFive S7 CPU
core which is used on SiFive U74-MC core complex etc.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Sun, 10 Jul 2022 20:12:44 +0000 (22:12 +0200)]
dt-bindings: interrupt-controller: Add StarFive JH7110 plic
Add compatible string for StarFive JH7110 plic.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Sun, 10 Jul 2022 20:10:44 +0000 (22:10 +0200)]
dt-bindings: timer: Add StarFive JH7110 clint
Add compatible string for the StarFive JH7110 clint.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Hal Feng [Sat, 12 Nov 2022 15:39:59 +0000 (23:39 +0800)]
reset: starfive: Add StarFive JH7110 reset driver
Add auxiliary driver to support StarFive JH7110 system
and always-on resets.
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Sun, 24 Jul 2022 17:43:38 +0000 (19:43 +0200)]
clk: starfive: Add StarFive JH7110 always-on clock driver
Add driver for the StarFive JH7110 always-on clock controller
and register an auxiliary device for always-on reset controller
which is named as "reset-aon".
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Co-developed-by: Hal Feng <hal.feng@starfivetech.com>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Sat, 9 Jul 2022 21:57:57 +0000 (23:57 +0200)]
clk: starfive: Add StarFive JH7110 system clock driver
Add driver for the StarFive JH7110 system clock controller and
register an auxiliary device for system reset controller which
is named as "reset-sys".
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Co-developed-by: Hal Feng <hal.feng@starfivetech.com>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Sun, 24 Jul 2022 19:03:29 +0000 (21:03 +0200)]
dt-bindings: clock: Add StarFive JH7110 always-on clock and reset generator
Add bindings for the always-on clock and reset generator (AONCRG) on the
JH7110 RISC-V SoC by StarFive Ltd.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Mon, 11 Jul 2022 18:59:24 +0000 (20:59 +0200)]
dt-bindings: clock: Add StarFive JH7110 system clock and reset generator
Add bindings for the system clock and reset generator (SYSCRG) on the
JH7110 RISC-V SoC by StarFive Ltd.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Wed, 24 Nov 2021 00:30:54 +0000 (01:30 +0100)]
reset: starfive: jh71x0: Use 32bit I/O on 32bit registers
We currently use 64bit I/O on the 32bit registers. This works because
there are an even number of assert and status registers, so they're only
ever accessed in pairs on 64bit boundaries.
There are however other reset controllers for audio and video on the
JH7100 SoC with only one status register that isn't 64bit aligned so
64bit I/O results in an unaligned access exception.
Switch to 32bit I/O in preparation for supporting these resets too.
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Sat, 12 Nov 2022 08:25:53 +0000 (16:25 +0800)]
reset: starfive: Rename "jh7100" to "jh71x0" for the common code
For the common code will be shared with the StarFive JH7110 SoC.
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Sat, 9 Jul 2022 21:32:56 +0000 (23:32 +0200)]
reset: starfive: Extract the common JH71X0 reset code
Extract the common JH71X0 reset code for reusing them to
support JH7110 SoC.
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Sat, 9 Jul 2022 21:32:56 +0000 (23:32 +0200)]
reset: starfive: Factor out common JH71X0 reset code
The StarFive JH7100 SoC has additional reset controllers for audio and
video, but the registers follow the same structure. On the JH7110 the
reset registers don't get their own memory range, but instead follow the
clock control registers. The registers still follow the same structure
though, so let's factor out the common code to handle all these cases.
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Sat, 20 Nov 2021 17:30:33 +0000 (18:30 +0100)]
reset: Create subdirectory for StarFive drivers
This moves the StarFive JH7100 reset driver to a new subdirectory in
preparation for adding more StarFive reset drivers.
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Hal Feng [Thu, 9 Mar 2023 07:04:34 +0000 (15:04 +0800)]
reset: starfive: Replace SOC_STARFIVE with ARCH_STARFIVE
Using ARCH_FOO symbol is preferred than SOC_FOO.
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Tue, 1 Nov 2022 02:27:02 +0000 (10:27 +0800)]
clk: starfive: Rename "jh7100" to "jh71x0" for the common code
Rename some variables from "jh7100" or "JH7100" to "jh71x0"
or "JH71X0".
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Tue, 1 Nov 2022 02:27:02 +0000 (10:27 +0800)]
clk: starfive: Rename clk-starfive-jh7100.h to clk-starfive-jh71x0.h
Rename clk-starfive-jh7100.h to clk-starfive-jh71x0.h for making
the code to be common.
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Emil Renner Berthing [Sun, 10 Jul 2022 09:07:13 +0000 (11:07 +0200)]
clk: starfive: Factor out common JH7100 and JH7110 code
The clock control registers on the StarFive JH7100 and JH7110 work
identically, so factor out the code then drivers for the two SoCs
can share it without depending on each other. No functional change.
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Hal Feng [Thu, 9 Mar 2023 06:14:45 +0000 (14:14 +0800)]
clk: starfive: Replace SOC_STARFIVE with ARCH_STARFIVE
Using ARCH_FOO symbol is preferred than SOC_FOO.
Set obj-y for starfive/ in Makefile, so the StarFive drivers
can be compiled with COMPILE_TEST=y but ARCH_STARFIVE=n.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Conor Dooley [Sun, 20 Nov 2022 20:59:41 +0000 (20:59 +0000)]
RISC-V: introduce ARCH_FOO kconfig aliases for SOC_FOO symbols
To facilitate a transfer from SOC_FOO to ARCH_FOO, over a release cycle,
introduce some aliases so that drivers etc that use the SOC_FOO symbols
can be converted.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
To me, the most straight-forward conversion looks like so:
- this patch is applied in week 2 of the merge window, to avoid
any conflicts with the Renesas tree
- all users of the SOC_ variants can be converted over a release cycle
(or more) & no trees need to merge an immutable branch.
- we convert defconfig etc over after all users are converted
- doing it over at least one release cycle means that `make oldconfig`
will keep people's configs working as they upgrade
- any new SoC families added uses ARCH_FOO
Change-Id: I176b3cddcdbd2591d639d4696d42844e52c87f6a
Cristian Ciocaltea [Mon, 17 Oct 2022 21:05:42 +0000 (00:05 +0300)]
riscv: dts: starfive: Add StarFive VisionFive V1 device tree
Add initial device tree for the StarFive VisionFive V1 SBC, which
is similar with the already supported BeagleV Starlight Beta board,
both being based on the StarFive JH7100 SoC.
Link: https://github.com/starfive-tech/VisionFive
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Cristian Ciocaltea [Mon, 17 Oct 2022 21:05:41 +0000 (00:05 +0300)]
riscv: dts: starfive: Add common DT for JH7100 based boards
In preparation for adding initial device tree support for the StarFive
VisionFive board, which is similar with BeagleV Starlight, move most
of the content from jh7100-beaglev-starlight.dts to a new file, to be
shared between the two boards.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
William Qiu [Wed, 15 Feb 2023 11:32:47 +0000 (19:32 +0800)]
mmc: starfive: Add sdio/emmc driver support
Add sdio/emmc driver support for StarFive JH7110 soc.
Change-Id: Ic2d6ff5241f3e6be2a6952643a4836edb30fed06
Tested-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: William Qiu <william.qiu@starfivetech.com>
Link: https://lore.kernel.org/r/20230215113249.47727-3-william.qiu@starfivetech.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
William Qiu [Wed, 15 Feb 2023 11:32:46 +0000 (19:32 +0800)]
dt-bindings: mmc: Add StarFive MMC module
Add documentation to describe StarFive designware mobile storage
host controller driver.
Signed-off-by: William Qiu <william.qiu@starfivetech.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230215113249.47727-2-william.qiu@starfivetech.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Jianlong Huang [Thu, 9 Feb 2023 14:37:02 +0000 (22:37 +0800)]
pinctrl: starfive: Add StarFive JH7110 aon controller driver
Add pinctrl driver for StarFive JH7110 SoC aon pinctrl controller.
Co-developed-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Jianlong Huang <jianlong.huang@starfivetech.com>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Link: https://lore.kernel.org/r/20230209143702.44408-5-hal.feng@starfivetech.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Jianlong Huang [Thu, 9 Feb 2023 14:37:01 +0000 (22:37 +0800)]
pinctrl: starfive: Add StarFive JH7110 sys controller driver
Add pinctrl driver for StarFive JH7110 SoC sys pinctrl controller.
Co-developed-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Jianlong Huang <jianlong.huang@starfivetech.com>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Link: https://lore.kernel.org/r/20230209143702.44408-4-hal.feng@starfivetech.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Jianlong Huang [Thu, 9 Feb 2023 14:37:00 +0000 (22:37 +0800)]
dt-bindings: pinctrl: Add StarFive JH7110 aon pinctrl
Add pinctrl bindings for StarFive JH7110 SoC aon pinctrl controller.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jianlong Huang <jianlong.huang@starfivetech.com>
Co-developed-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Link: https://lore.kernel.org/r/20230209143702.44408-3-hal.feng@starfivetech.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Jianlong Huang [Thu, 9 Feb 2023 14:36:59 +0000 (22:36 +0800)]
dt-bindings: pinctrl: Add StarFive JH7110 sys pinctrl
Add pinctrl bindings for StarFive JH7110 SoC sys pinctrl controller.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jianlong Huang <jianlong.huang@starfivetech.com>
Co-developed-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Link: https://lore.kernel.org/r/20230209143702.44408-2-hal.feng@starfivetech.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Emil Renner Berthing [Tue, 20 Dec 2022 01:12:41 +0000 (09:12 +0800)]
dt-bindings: riscv: Add StarFive JH7110 SoC and VisionFive 2 board
Add device tree bindings for the StarFive JH7110 RISC-V SoC
and the VisionFive 2 board equipped with it.
VisionFive 2 board has version A and version B, which are
different in gmac and phy chip. The version A board has one
1000Mbps and one 100Mbps Ethernet ports while the version B
board has two 1000Mbps Ethernet ports.
Link: https://doc-en.rvspace.org/Doc_Center/jh7110.html
Link: https://doc-en.rvspace.org/Doc_Center/visionfive_2.html
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Emil Renner Berthing [Tue, 20 Dec 2022 01:12:44 +0000 (09:12 +0800)]
dt-bindings: sifive,ccache0: Support StarFive JH7110 SoC
This cache controller is also used on the StarFive JH7110 SoC.
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Walker Chen [Thu, 19 Jan 2023 09:44:47 +0000 (17:44 +0800)]
soc: starfive: Add StarFive JH71XX pmu driver
Add pmu driver for the StarFive JH71XX SoC.
As the power domains provider, the Power Management Unit (PMU) is
designed for including multiple PM domains that can be used for power
gating of selected IP blocks for power saving by reduced leakage
current. It accepts software encourage command to switch the power mode
of SoC.
Signed-off-by: Walker Chen <walker.chen@starfivetech.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Walker Chen [Thu, 19 Jan 2023 09:44:46 +0000 (17:44 +0800)]
dt-bindings: power: Add starfive,jh7110-pmu
Add bindings for the Power Management Unit on the StarFive JH7110 SoC.
Signed-off-by: Walker Chen <walker.chen@starfivetech.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Greg Kroah-Hartman [Wed, 19 Jul 2023 14:22:18 +0000 (16:22 +0200)]
Linux 6.1.39
Link: https://lore.kernel.org/r/20230716194923.861634455@linuxfoundation.org
Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
Tested-by: Conor Dooley <conor.dooley@microchip.com>
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20230717185609.886113843@linuxfoundation.org
Link: https://lore.kernel.org/r/20230717201547.359923764@linuxfoundation.org
Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com>
Tested-by: Ron Economos <re@w6rz.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Tested-by: Allen Pais <apais@linux.microsoft.com>
Tested-by: SeongJae Park <sj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andres Freund [Sun, 16 Jul 2023 18:13:06 +0000 (12:13 -0600)]
io_uring: Use io_schedule* in cqring wait
Commit
8a796565cec3601071cbbd27d6304e202019d014 upstream.
I observed poor performance of io_uring compared to synchronous IO. That
turns out to be caused by deeper CPU idle states entered with io_uring,
due to io_uring using plain schedule(), whereas synchronous IO uses
io_schedule().
The losses due to this are substantial. On my cascade lake workstation,
t/io_uring from the fio repository e.g. yields regressions between 20%
and 40% with the following command:
./t/io_uring -r 5 -X0 -d 1 -s 1 -c 1 -p 0 -S$use_sync -R 0 /mnt/t2/fio/write.0.0
This is repeatable with different filesystems, using raw block devices
and using different block devices.
Use io_schedule_prepare() / io_schedule_finish() in
io_cqring_wait_schedule() to address the difference.
After that using io_uring is on par or surpassing synchronous IO (using
registered files etc makes it reliably win, but arguably is a less fair
comparison).
There are other calls to schedule() in io_uring/, but none immediately
jump out to be similarly situated, so I did not touch them. Similarly,
it's possible that mutex_lock_io() should be used, but it's not clear if
there are cases where that matters.
Cc: stable@vger.kernel.org # 5.10+
Cc: Pavel Begunkov <asml.silence@gmail.com>
Cc: io-uring@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andres Freund <andres@anarazel.de>
Link: https://lore.kernel.org/r/20230707162007.194068-1-andres@anarazel.de
[axboe: minor style fixup]
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Artur Rojek [Mon, 10 Jul 2023 23:31:32 +0000 (01:31 +0200)]
sh: hd64461: Handle virq offset for offchip IRQ base and HD64461 IRQ
commit
7c28a35e19fafa1d3b367bcd3ec4021427a9397b upstream.
A recent change to start counting SuperH IRQ #s from 16 breaks support
for the Hitachi HD64461 companion chip.
Move the offchip IRQ base and HD64461 IRQ # by 16 in order to
accommodate for the new virq numbering rules.
Fixes:
a8ac2961148e ("sh: Avoid using IRQ0 on SH3 and SH4")
Signed-off-by: Artur Rojek <contact@artur-rojek.eu>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Link: https://lore.kernel.org/r/20230710233132.69734-1-contact@artur-rojek.eu
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Sun, 9 Jul 2023 13:10:43 +0000 (15:10 +0200)]
sh: mach-dreamcast: Handle virq offset in cascaded IRQ demux
commit
3d20f7a6eb76afdf9d4ad9cb864c2e2da9c38e1f upstream.
Take into account the virq offset when translating cascaded interrupts.
Fixes:
a8ac2961148e8c72 ("sh: Avoid using IRQ0 on SH3 and SH4")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Link: https://lore.kernel.org/r/7d0cb246c9f1cd24bb1f637ec5cb67e799a4c3b8.1688908227.git.geert+renesas@glider.be
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Sun, 9 Jul 2023 13:10:23 +0000 (15:10 +0200)]
sh: mach-highlander: Handle virq offset in cascaded IRL demux
commit
a2601b8d8f077368c6d113b4d496559415c6d495 upstream.
Take into account the virq offset when translating cascaded IRL
interrupts.
Fixes:
a8ac2961148e8c72 ("sh: Avoid using IRQ0 on SH3 and SH4")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Link: https://lore.kernel.org/r/4fcb0d08a2b372431c41e04312742dc9e41e1be4.1688908186.git.geert+renesas@glider.be
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Sun, 9 Jul 2023 11:15:49 +0000 (13:15 +0200)]
sh: mach-r2d: Handle virq offset in cascaded IRL demux
commit
ab8aa4f0956d2e0fb8344deadb823ef743581795 upstream.
When booting rts7751r2dplus_defconfig on QEMU, the system hangs due to
an interrupt storm on IRQ 20. IRQ 20 aka event 0x280 is a cascaded IRL
interrupt, which maps to IRQ_VOYAGER, the interrupt used by the Silicon
Motion SM501 multimedia companion chip. As rts7751r2d_irq_demux() does
not take into account the new virq offset, the interrupt is no longer
translated, leading to an unhandled interrupt.
Fix this by taking into account the virq offset when translating
cascaded IRL interrupts.
Fixes:
a8ac2961148e8c72 ("sh: Avoid using IRQ0 on SH3 and SH4")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Closes: https://lore.kernel.org/r/
fbfea3ad-d327-4ad5-ac9c-
648c7ca3fe1f@roeck-us.net
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/2c99d5df41c40691f6c407b7b6a040d406bc81ac.1688901306.git.geert+renesas@glider.be
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Schmitz [Tue, 4 Jul 2023 23:38:08 +0000 (11:38 +1200)]
block/partition: fix signedness issue for Amiga partitions
commit
7eb1e47696aa231b1a567846bbe3a1e1befe1854 upstream.
Making 'blk' sector_t (i.e. 64 bit if LBD support is active) fails the
'blk>0' test in the partition block loop if a value of (signed int) -1 is
used to mark the end of the partition block list.
Explicitly cast 'blk' to signed int to allow use of -1 to terminate the
partition block linked list.
Fixes:
b6f3f28f604b ("block: add overflow checks for Amiga partition support")
Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Link: https://lore.kernel.org/r/024ce4fa-cc6d-50a2-9aae-3701d0ebf668@xenosoft.de
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Reviewed-by: Martin Steigerwald <martin@lichtvoll.de>
Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sherry Sun [Mon, 19 Jun 2023 08:06:13 +0000 (16:06 +0800)]
tty: serial: fsl_lpuart: add earlycon for imx8ulp platform
commit
e0edfdc15863ec80a1d9ac6e174dbccc00206dd0 upstream.
Add earlycon support for imx8ulp platform.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20230619080613.16522-1-sherry.sun@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason A. Donenfeld [Mon, 3 Jul 2023 01:27:05 +0000 (03:27 +0200)]
wireguard: netlink: send staged packets when setting initial private key
commit
f58d0a9b4c6a7a5199c3af967e43cc8b654604d4 upstream.
Packets bound for peers can queue up prior to the device private key
being set. For example, if persistent keepalive is set, a packet is
queued up to be sent as soon as the device comes up. However, if the
private key hasn't been set yet, the handshake message never sends, and
no timer is armed to retry, since that would be pointless.
But, if a user later sets a private key, the expectation is that those
queued packets, such as a persistent keepalive, are actually sent. So
adjust the configuration logic to account for this edge case, and add a
test case to make sure this works.
Maxim noticed this with a wg-quick(8) config to the tune of:
[Interface]
PostUp = wg set %i private-key somefile
[Peer]
PublicKey = ...
Endpoint = ...
PersistentKeepalive = 25
Here, the private key gets set after the device comes up using a PostUp
script, triggering the bug.
Fixes:
e7096c131e51 ("net: WireGuard secure network tunnel")
Cc: stable@vger.kernel.org
Reported-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Tested-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Link: https://lore.kernel.org/wireguard/87fs7xtqrv.fsf@gmail.com/
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason A. Donenfeld [Mon, 3 Jul 2023 01:27:04 +0000 (03:27 +0200)]
wireguard: queueing: use saner cpu selection wrapping
commit
7387943fa35516f6f8017a3b0e9ce48a3bef9faa upstream.
Using `% nr_cpumask_bits` is slow and complicated, and not totally
robust toward dynamic changes to CPU topologies. Rather than storing the
next CPU in the round-robin, just store the last one, and also return
that value. This simplifies the loop drastically into a much more common
pattern.
Fixes:
e7096c131e51 ("net: WireGuard secure network tunnel")
Cc: stable@vger.kernel.org
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Tested-by: Manuel Leiner <manuel.leiner@gmx.de>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thadeu Lima de Souza Cascardo [Wed, 5 Jul 2023 21:05:35 +0000 (18:05 -0300)]
netfilter: nf_tables: prevent OOB access in nft_byteorder_eval
commit
caf3ef7468f7534771b5c44cd8dbd6f7f87c2cbd upstream.
When evaluating byteorder expressions with size 2, a union with 32-bit and
16-bit members is used. Since the 16-bit members are aligned to 32-bit,
the array accesses will be out-of-bounds.
It may lead to a stack-out-of-bounds access like the one below:
[ 23.095215] ==================================================================
[ 23.095625] BUG: KASAN: stack-out-of-bounds in nft_byteorder_eval+0x13c/0x320
[ 23.096020] Read of size 2 at addr
ffffc90000007948 by task ping/115
[ 23.096358]
[ 23.096456] CPU: 0 PID: 115 Comm: ping Not tainted 6.4.0+ #413
[ 23.096770] Call Trace:
[ 23.096910] <IRQ>
[ 23.097030] dump_stack_lvl+0x60/0xc0
[ 23.097218] print_report+0xcf/0x630
[ 23.097388] ? nft_byteorder_eval+0x13c/0x320
[ 23.097577] ? kasan_addr_to_slab+0xd/0xc0
[ 23.097760] ? nft_byteorder_eval+0x13c/0x320
[ 23.097949] kasan_report+0xc9/0x110
[ 23.098106] ? nft_byteorder_eval+0x13c/0x320
[ 23.098298] __asan_load2+0x83/0xd0
[ 23.098453] nft_byteorder_eval+0x13c/0x320
[ 23.098659] nft_do_chain+0x1c8/0xc50
[ 23.098852] ? __pfx_nft_do_chain+0x10/0x10
[ 23.099078] ? __kasan_check_read+0x11/0x20
[ 23.099295] ? __pfx___lock_acquire+0x10/0x10
[ 23.099535] ? __pfx___lock_acquire+0x10/0x10
[ 23.099745] ? __kasan_check_read+0x11/0x20
[ 23.099929] nft_do_chain_ipv4+0xfe/0x140
[ 23.100105] ? __pfx_nft_do_chain_ipv4+0x10/0x10
[ 23.100327] ? lock_release+0x204/0x400
[ 23.100515] ? nf_hook.constprop.0+0x340/0x550
[ 23.100779] nf_hook_slow+0x6c/0x100
[ 23.100977] ? __pfx_nft_do_chain_ipv4+0x10/0x10
[ 23.101223] nf_hook.constprop.0+0x334/0x550
[ 23.101443] ? __pfx_ip_local_deliver_finish+0x10/0x10
[ 23.101677] ? __pfx_nf_hook.constprop.0+0x10/0x10
[ 23.101882] ? __pfx_ip_rcv_finish+0x10/0x10
[ 23.102071] ? __pfx_ip_local_deliver_finish+0x10/0x10
[ 23.102291] ? rcu_read_lock_held+0x4b/0x70
[ 23.102481] ip_local_deliver+0xbb/0x110
[ 23.102665] ? __pfx_ip_rcv+0x10/0x10
[ 23.102839] ip_rcv+0x199/0x2a0
[ 23.102980] ? __pfx_ip_rcv+0x10/0x10
[ 23.103140] __netif_receive_skb_one_core+0x13e/0x150
[ 23.103362] ? __pfx___netif_receive_skb_one_core+0x10/0x10
[ 23.103647] ? mark_held_locks+0x48/0xa0
[ 23.103819] ? process_backlog+0x36c/0x380
[ 23.103999] __netif_receive_skb+0x23/0xc0
[ 23.104179] process_backlog+0x91/0x380
[ 23.104350] __napi_poll.constprop.0+0x66/0x360
[ 23.104589] ? net_rx_action+0x1cb/0x610
[ 23.104811] net_rx_action+0x33e/0x610
[ 23.105024] ? _raw_spin_unlock+0x23/0x50
[ 23.105257] ? __pfx_net_rx_action+0x10/0x10
[ 23.105485] ? mark_held_locks+0x48/0xa0
[ 23.105741] __do_softirq+0xfa/0x5ab
[ 23.105956] ? __dev_queue_xmit+0x765/0x1c00
[ 23.106193] do_softirq.part.0+0x49/0xc0
[ 23.106423] </IRQ>
[ 23.106547] <TASK>
[ 23.106670] __local_bh_enable_ip+0xf5/0x120
[ 23.106903] __dev_queue_xmit+0x789/0x1c00
[ 23.107131] ? __pfx___dev_queue_xmit+0x10/0x10
[ 23.107381] ? find_held_lock+0x8e/0xb0
[ 23.107585] ? lock_release+0x204/0x400
[ 23.107798] ? neigh_resolve_output+0x185/0x350
[ 23.108049] ? mark_held_locks+0x48/0xa0
[ 23.108265] ? neigh_resolve_output+0x185/0x350
[ 23.108514] neigh_resolve_output+0x246/0x350
[ 23.108753] ? neigh_resolve_output+0x246/0x350
[ 23.109003] ip_finish_output2+0x3c3/0x10b0
[ 23.109250] ? __pfx_ip_finish_output2+0x10/0x10
[ 23.109510] ? __pfx_nf_hook+0x10/0x10
[ 23.109732] __ip_finish_output+0x217/0x390
[ 23.109978] ip_finish_output+0x2f/0x130
[ 23.110207] ip_output+0xc9/0x170
[ 23.110404] ip_push_pending_frames+0x1a0/0x240
[ 23.110652] raw_sendmsg+0x102e/0x19e0
[ 23.110871] ? __pfx_raw_sendmsg+0x10/0x10
[ 23.111093] ? lock_release+0x204/0x400
[ 23.111304] ? __mod_lruvec_page_state+0x148/0x330
[ 23.111567] ? find_held_lock+0x8e/0xb0
[ 23.111777] ? find_held_lock+0x8e/0xb0
[ 23.111993] ? __rcu_read_unlock+0x7c/0x2f0
[ 23.112225] ? aa_sk_perm+0x18a/0x550
[ 23.112431] ? filemap_map_pages+0x4f1/0x900
[ 23.112665] ? __pfx_aa_sk_perm+0x10/0x10
[ 23.112880] ? find_held_lock+0x8e/0xb0
[ 23.113098] inet_sendmsg+0xa0/0xb0
[ 23.113297] ? inet_sendmsg+0xa0/0xb0
[ 23.113500] ? __pfx_inet_sendmsg+0x10/0x10
[ 23.113727] sock_sendmsg+0xf4/0x100
[ 23.113924] ? move_addr_to_kernel.part.0+0x4f/0xa0
[ 23.114190] __sys_sendto+0x1d4/0x290
[ 23.114391] ? __pfx___sys_sendto+0x10/0x10
[ 23.114621] ? __pfx_mark_lock.part.0+0x10/0x10
[ 23.114869] ? lock_release+0x204/0x400
[ 23.115076] ? find_held_lock+0x8e/0xb0
[ 23.115287] ? rcu_is_watching+0x23/0x60
[ 23.115503] ? __rseq_handle_notify_resume+0x6e2/0x860
[ 23.115778] ? __kasan_check_write+0x14/0x30
[ 23.116008] ? blkcg_maybe_throttle_current+0x8d/0x770
[ 23.116285] ? mark_held_locks+0x28/0xa0
[ 23.116503] ? do_syscall_64+0x37/0x90
[ 23.116713] __x64_sys_sendto+0x7f/0xb0
[ 23.116924] do_syscall_64+0x59/0x90
[ 23.117123] ? irqentry_exit_to_user_mode+0x25/0x30
[ 23.117387] ? irqentry_exit+0x77/0xb0
[ 23.117593] ? exc_page_fault+0x92/0x140
[ 23.117806] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[ 23.118081] RIP: 0033:0x7f744aee2bba
[ 23.118282] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
[ 23.119237] RSP: 002b:
00007ffd04a7c9f8 EFLAGS:
00000246 ORIG_RAX:
000000000000002c
[ 23.119644] RAX:
ffffffffffffffda RBX:
00007ffd04a7e0a0 RCX:
00007f744aee2bba
[ 23.120023] RDX:
0000000000000040 RSI:
000056488e9e6300 RDI:
0000000000000003
[ 23.120413] RBP:
000056488e9e6300 R08:
00007ffd04a80320 R09:
0000000000000010
[ 23.120809] R10:
0000000000000000 R11:
0000000000000246 R12:
0000000000000040
[ 23.121219] R13:
00007ffd04a7dc38 R14:
00007ffd04a7ca00 R15:
00007ffd04a7e0a0
[ 23.121617] </TASK>
[ 23.121749]
[ 23.121845] The buggy address belongs to the virtual mapping at
[ 23.121845] [
ffffc90000000000,
ffffc90000009000) created by:
[ 23.121845] irq_init_percpu_irqstack+0x1cf/0x270
[ 23.122707]
[ 23.122803] The buggy address belongs to the physical page:
[ 23.123104] page:
0000000072ac19f0 refcount:1 mapcount:0 mapping:
0000000000000000 index:0x0 pfn:0x24a09
[ 23.123609] flags: 0xfffffc0001000(reserved|node=0|zone=1|lastcpupid=0x1fffff)
[ 23.123998] page_type: 0xffffffff()
[ 23.124194] raw:
000fffffc0001000 ffffea0000928248 ffffea0000928248 0000000000000000
[ 23.124610] raw:
0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
[ 23.125023] page dumped because: kasan: bad access detected
[ 23.125326]
[ 23.125421] Memory state around the buggy address:
[ 23.125682]
ffffc90000007800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 23.126072]
ffffc90000007880: 00 00 00 00 00 f1 f1 f1 f1 f1 f1 00 00 f2 f2 00
[ 23.126455] >
ffffc90000007900: 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00 00 00
[ 23.126840] ^
[ 23.127138]
ffffc90000007980: 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 f3 f3
[ 23.127522]
ffffc90000007a00: f3 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
[ 23.127906] ==================================================================
[ 23.128324] Disabling lock debugging due to kernel taint
Using simple s16 pointers for the 16-bit accesses fixes the problem. For
the 32-bit accesses, src and dst can be used directly.
Fixes:
96518518cc41 ("netfilter: add nftables")
Cc: stable@vger.kernel.org
Reported-by: Tanguy DUBROCA (@SidewayRE) from @Synacktiv working with ZDI
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Reviewed-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thadeu Lima de Souza Cascardo [Wed, 5 Jul 2023 12:12:55 +0000 (09:12 -0300)]
netfilter: nf_tables: do not ignore genmask when looking up chain by id
commit
515ad530795c118f012539ed76d02bacfd426d89 upstream.
When adding a rule to a chain referring to its ID, if that chain had been
deleted on the same batch, the rule might end up referring to a deleted
chain.
This will lead to a WARNING like following:
[ 33.098431] ------------[ cut here ]------------
[ 33.098678] WARNING: CPU: 5 PID: 69 at net/netfilter/nf_tables_api.c:2037 nf_tables_chain_destroy+0x23d/0x260
[ 33.099217] Modules linked in:
[ 33.099388] CPU: 5 PID: 69 Comm: kworker/5:1 Not tainted 6.4.0+ #409
[ 33.099726] Workqueue: events nf_tables_trans_destroy_work
[ 33.100018] RIP: 0010:nf_tables_chain_destroy+0x23d/0x260
[ 33.100306] Code: 8b 7c 24 68 e8 64 9c ed fe 4c 89 e7 e8 5c 9c ed fe 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7 c3 cc cc cc cc <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7
[ 33.101271] RSP: 0018:
ffffc900004ffc48 EFLAGS:
00010202
[ 33.101546] RAX:
0000000000000001 RBX:
ffff888006fc0a28 RCX:
0000000000000000
[ 33.101920] RDX:
0000000000000000 RSI:
0000000000000000 RDI:
0000000000000000
[ 33.102649] RBP:
ffffc900004ffc78 R08:
0000000000000000 R09:
0000000000000000
[ 33.103018] R10:
0000000000000000 R11:
0000000000000000 R12:
ffff8880135ef500
[ 33.103385] R13:
0000000000000000 R14:
dead000000000122 R15:
ffff888006fc0a10
[ 33.103762] FS:
0000000000000000(0000) GS:
ffff888024c80000(0000) knlGS:
0000000000000000
[ 33.104184] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 33.104493] CR2:
00007fe863b56a50 CR3:
00000000124b0001 CR4:
0000000000770ee0
[ 33.104872] PKRU:
55555554
[ 33.104999] Call Trace:
[ 33.105113] <TASK>
[ 33.105214] ? show_regs+0x72/0x90
[ 33.105371] ? __warn+0xa5/0x210
[ 33.105520] ? nf_tables_chain_destroy+0x23d/0x260
[ 33.105732] ? report_bug+0x1f2/0x200
[ 33.105902] ? handle_bug+0x46/0x90
[ 33.106546] ? exc_invalid_op+0x19/0x50
[ 33.106762] ? asm_exc_invalid_op+0x1b/0x20
[ 33.106995] ? nf_tables_chain_destroy+0x23d/0x260
[ 33.107249] ? nf_tables_chain_destroy+0x30/0x260
[ 33.107506] nf_tables_trans_destroy_work+0x669/0x680
[ 33.107782] ? mark_held_locks+0x28/0xa0
[ 33.107996] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10
[ 33.108294] ? _raw_spin_unlock_irq+0x28/0x70
[ 33.108538] process_one_work+0x68c/0xb70
[ 33.108755] ? lock_acquire+0x17f/0x420
[ 33.108977] ? __pfx_process_one_work+0x10/0x10
[ 33.109218] ? do_raw_spin_lock+0x128/0x1d0
[ 33.109435] ? _raw_spin_lock_irq+0x71/0x80
[ 33.109634] worker_thread+0x2bd/0x700
[ 33.109817] ? __pfx_worker_thread+0x10/0x10
[ 33.110254] kthread+0x18b/0x1d0
[ 33.110410] ? __pfx_kthread+0x10/0x10
[ 33.110581] ret_from_fork+0x29/0x50
[ 33.110757] </TASK>
[ 33.110866] irq event stamp: 1651
[ 33.111017] hardirqs last enabled at (1659): [<
ffffffffa206a209>] __up_console_sem+0x79/0xa0
[ 33.111379] hardirqs last disabled at (1666): [<
ffffffffa206a1ee>] __up_console_sem+0x5e/0xa0
[ 33.111740] softirqs last enabled at (1616): [<
ffffffffa1f5d40e>] __irq_exit_rcu+0x9e/0xe0
[ 33.112094] softirqs last disabled at (1367): [<
ffffffffa1f5d40e>] __irq_exit_rcu+0x9e/0xe0
[ 33.112453] ---[ end trace
0000000000000000 ]---
This is due to the nft_chain_lookup_byid ignoring the genmask. After this
change, adding the new rule will fail as it will not find the chain.
Fixes:
837830a4b439 ("netfilter: nf_tables: add NFTA_RULE_CHAIN_ID attribute")
Cc: stable@vger.kernel.org
Reported-by: Mingi Cho of Theori working with ZDI
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Reviewed-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florent Revest [Mon, 3 Jul 2023 14:52:16 +0000 (16:52 +0200)]
netfilter: conntrack: Avoid nf_ct_helper_hash uses after free
commit
6eef7a2b933885a17679eb8ed0796ddf0ee5309b upstream.
If nf_conntrack_init_start() fails (for example due to a
register_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini()
clean-up path frees the nf_ct_helper_hash map.
When built with NF_CONNTRACK=y, further netfilter modules (e.g:
netfilter_conntrack_ftp) can still be loaded and call
nf_conntrack_helpers_register(), independently of whether nf_conntrack
initialized correctly. This accesses the nf_ct_helper_hash dangling
pointer and causes a uaf, possibly leading to random memory corruption.
This patch guards nf_conntrack_helper_register() from accessing a freed
or uninitialized nf_ct_helper_hash pointer and fixes possible
uses-after-free when loading a conntrack module.
Cc: stable@vger.kernel.org
Fixes:
12f7a505331e ("netfilter: add user-space connection tracking helper infrastructure")
Signed-off-by: Florent Revest <revest@chromium.org>
Reviewed-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pablo Neira Ayuso [Sun, 25 Jun 2023 22:42:18 +0000 (00:42 +0200)]
netfilter: nf_tables: unbind non-anonymous set if rule construction fails
commit
3e70489721b6c870252c9082c496703677240f53 upstream.
Otherwise a dangling reference to a rule object that is gone remains
in the set binding list.
Fixes:
26b5a5712eb8 ("netfilter: nf_tables: add NFT_TRANS_PREPARE_ERROR to deal with bound set/chain")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lukas Bulwahn [Wed, 16 Nov 2022 12:49:32 +0000 (13:49 +0100)]
mtd: parsers: refer to ARCH_BCMBCA instead of ARCH_BCM4908
commit
085679b15b5af65f9610f619afde41da0f966194 upstream.
Commit
dd5c672d7ca9 ("arm64: bcmbca: Merge ARCH_BCM4908 to ARCH_BCMBCA")
removes config ARCH_BCM4908 as config ARCH_BCMBCA has the same intent.
Probably due to concurrent development, commit
002181f5b150 ("mtd: parsers:
add Broadcom's U-Boot parser") introduces 'Broadcom's U-Boot partition
parser' that depends on ARCH_BCM4908, but this use was not visible during
the config refactoring from the commit above. Hence, these two changes
create a reference to a non-existing config symbol.
Adjust the MTD_BRCM_U_BOOT definition to refer to ARCH_BCMBCA instead of
ARCH_BCM4908 to remove the reference to the non-existing config symbol
ARCH_BCM4908.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20221116124932.4748-1-lukas.bulwahn@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Imre Deak [Thu, 16 Mar 2023 13:17:14 +0000 (15:17 +0200)]
drm/i915/tc: Fix system resume MST mode restore for DP-alt sinks
commit
06f66261a1567d66b9d35c87393b6edfbea4c8f8 upstream.
At least restoring the MST topology during system resume needs to use
AUX before the display HW readout->sanitization sequence is complete,
but on TC ports the PHY may be in the wrong mode for this, resulting in
the AUX transfers to fail.
The initial TC port mode is kept fixed as BIOS left it for the above HW
readout sequence (to prevent changing the mode on an enabled port). If
the port is disabled this initial mode is TBT - as in any case the PHY
ownership is not held - even if a DP-alt sink is connected. Thus, the
AUX transfers during this time will use TBT mode instead of the expected
DP-alt mode and so time out.
Fix the above by connecting the PHY during port initialization if the
port is disabled, which will switch to the expected mode (DP-alt in the
above case).
As the encoder/pipe HW state isn't read-out yet at this point, check if
the port is enabled based on the DDI_BUF enabled flag. Save the read-out
initial mode, so intel_tc_port_sanitize_mode() can check this wrt. the
read-out encoder HW state.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-5-imre.deak@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Imre Deak [Thu, 16 Mar 2023 13:17:12 +0000 (15:17 +0200)]
drm/i915/tc: Fix TC port link ref init for DP MST during HW readout
commit
67165722c27cc46de112a4e10b450170c8980a6f upstream.
An enabled TC MST port holds one TC port link reference, regardless of
the number of enabled streams on it, but the TC port HW readout takes
one reference for each active MST stream.
Fix the HW readout, taking only one reference for MST ports.
This didn't cause an actual problem, since the encoder HW readout doesn't
yet support reading out the MST HW state.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-3-imre.deak@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Imre Deak [Thu, 22 Sep 2022 17:21:48 +0000 (20:21 +0300)]
drm/i915: Fix TypeC mode initialization during system resume
commit
a82796a2e332d108b2d3aff38509caad370f69b5 upstream.
During system resume DP MST requires AUX to be working already before
the HW state readout of the given encoder. Since AUX requires the
encoder/PHY TypeC mode to be initialized, which atm only happens during
HW state readout, these AUX transfers can change the TypeC mode
incorrectly (disconnecting the PHY for an enabled encoder) and trigger
the state check WARNs in intel_tc_port_sanitize().
Fix this by initializing the TypeC mode earlier both during driver
loading and system resume and making sure that the mode can't change
until the encoder's state is read out. While at it add the missing
DocBook comments and rename
intel_tc_port_sanitize()->intel_tc_port_sanitize_mode() for consistency.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220922172148.2913088-1-imre.deak@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liam R. Howlett [Thu, 6 Jul 2023 18:51:35 +0000 (14:51 -0400)]
mm/mmap: Fix extra maple tree write
based on commit
0503ea8f5ba73eb3ab13a81c1eefbaf51405385a upstream.
This was inadvertently fixed during the removal of __vma_adjust().
When __vma_adjust() is adjusting next with a negative value (pushing
vma->vm_end lower), there would be two writes to the maple tree. The
first write is unnecessary and uses all allocated nodes in the maple
state. The second write is necessary but will need to allocate nodes
since the first write has used the allocated nodes. This may be a
problem as it may not be safe to allocate at this time, such as a low
memory situation. Fix the issue by avoiding the first write and only
write the adjusted "next" VMA.
Reported-by: John Hsu <John.Hsu@mediatek.com>
Link: https://lore.kernel.org/lkml/9cb8c599b1d7f9c1c300d1a334d5eb70ec4d7357.camel@mediatek.com/
Cc: stable@vger.kernel.org
Cc: linux-mm@kvack.org
Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Darrick J. Wong [Sat, 15 Jul 2023 06:31:14 +0000 (09:31 +0300)]
xfs: fix xfs_inodegc_stop racing with mod_delayed_work
commit
2254a7396a0ca6309854948ee1c0a33fa4268cec upstream.
syzbot reported this warning from the faux inodegc shrinker that tries
to kick off inodegc work:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 102 at kernel/workqueue.c:1445 __queue_work+0xd44/0x1120 kernel/workqueue.c:1444
RIP: 0010:__queue_work+0xd44/0x1120 kernel/workqueue.c:1444
Call Trace:
__queue_delayed_work+0x1c8/0x270 kernel/workqueue.c:1672
mod_delayed_work_on+0xe1/0x220 kernel/workqueue.c:1746
xfs_inodegc_shrinker_scan fs/xfs/xfs_icache.c:2212 [inline]
xfs_inodegc_shrinker_scan+0x250/0x4f0 fs/xfs/xfs_icache.c:2191
do_shrink_slab+0x428/0xaa0 mm/vmscan.c:853
shrink_slab+0x175/0x660 mm/vmscan.c:1013
shrink_one+0x502/0x810 mm/vmscan.c:5343
shrink_many mm/vmscan.c:5394 [inline]
lru_gen_shrink_node mm/vmscan.c:5511 [inline]
shrink_node+0x2064/0x35f0 mm/vmscan.c:6459
kswapd_shrink_node mm/vmscan.c:7262 [inline]
balance_pgdat+0xa02/0x1ac0 mm/vmscan.c:7452
kswapd+0x677/0xd60 mm/vmscan.c:7712
kthread+0x2e8/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
This warning corresponds to this code in __queue_work:
/*
* For a draining wq, only works from the same workqueue are
* allowed. The __WQ_DESTROYING helps to spot the issue that
* queues a new work item to a wq after destroy_workqueue(wq).
*/
if (unlikely(wq->flags & (__WQ_DESTROYING | __WQ_DRAINING) &&
WARN_ON_ONCE(!is_chained_work(wq))))
return;
For this to trip, we must have a thread draining the inodedgc workqueue
and a second thread trying to queue inodegc work to that workqueue.
This can happen if freezing or a ro remount race with reclaim poking our
faux inodegc shrinker and another thread dropping an unlinked O_RDONLY
file:
Thread 0 Thread 1 Thread 2
xfs_inodegc_stop
xfs_inodegc_shrinker_scan
xfs_is_inodegc_enabled
<yes, will continue>
xfs_clear_inodegc_enabled
xfs_inodegc_queue_all
<list empty, do not queue inodegc worker>
xfs_inodegc_queue
<add to list>
xfs_is_inodegc_enabled
<no, returns>
drain_workqueue
<set WQ_DRAINING>
llist_empty
<no, will queue list>
mod_delayed_work_on(..., 0)
__queue_work
<sees WQ_DRAINING, kaboom>
In other words, everything between the access to inodegc_enabled state
and the decision to poke the inodegc workqueue requires some kind of
coordination to avoid the WQ_DRAINING state. We could perhaps introduce
a lock here, but we could also try to eliminate WQ_DRAINING from the
picture.
We could replace the drain_workqueue call with a loop that flushes the
workqueue and queues workers as long as there is at least one inode
present in the per-cpu inodegc llists. We've disabled inodegc at this
point, so we know that the number of queued inodes will eventually hit
zero as long as xfs_inodegc_start cannot reactivate the workers.
There are four callers of xfs_inodegc_start. Three of them come from the
VFS with s_umount held: filesystem thawing, failed filesystem freezing,
and the rw remount transition. The fourth caller is mounting rw (no
remount or freezing possible).
There are three callers ofs xfs_inodegc_stop. One is unmounting (no
remount or thaw possible). Two of them come from the VFS with s_umount
held: fs freezing and ro remount transition.
Hence, it is correct to replace the drain_workqueue call with a loop
that drains the inodegc llists.
Fixes:
6191cf3ad59f ("xfs: flush inodegc workqueue tasks before cancel")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Darrick J. Wong [Sat, 15 Jul 2023 06:31:13 +0000 (09:31 +0300)]
xfs: disable reaping in fscounters scrub
commit
2d5f38a31980d7090f5bf91021488dc61a0ba8ee upstream.
The fscounters scrub code doesn't work properly because it cannot
quiesce updates to the percpu counters in the filesystem, hence it
returns false corruption reports. This has been fixed properly in
one of the online repair patchsets that are under review by replacing
the xchk_disable_reaping calls with an exclusive filesystem freeze.
Disabling background gc isn't sufficient to fix the problem.
In other words, scrub doesn't need to call xfs_inodegc_stop, which is
just as well since it wasn't correct to allow scrub to call
xfs_inodegc_start when something else could be calling xfs_inodegc_stop
(e.g. trying to freeze the filesystem).
Neuter the scrubber for now, and remove the xchk_*_reaping functions.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Darrick J. Wong [Sat, 15 Jul 2023 06:31:12 +0000 (09:31 +0300)]
xfs: check that per-cpu inodegc workers actually run on that cpu
commit
b37c4c8339cd394ea6b8b415026603320a185651 upstream.
Now that we've allegedly worked out the problem of the per-cpu inodegc
workers being scheduled on the wrong cpu, let's put in a debugging knob
to let us know if a worker ever gets mis-scheduled again.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Darrick J. Wong [Sat, 15 Jul 2023 06:31:11 +0000 (09:31 +0300)]
xfs: explicitly specify cpu when forcing inodegc delayed work to run immediately
commit
03e0add80f4cf3f7393edb574eeb3a89a1db7758 upstream.
I've been noticing odd racing behavior in the inodegc code that could
only be explained by one cpu adding an inode to its inactivation llist
at the same time that another cpu is processing that cpu's llist.
Preemption is disabled between get/put_cpu_ptr, so the only explanation
is scheduler mayhem. I inserted the following debug code into
xfs_inodegc_worker (see the next patch):
ASSERT(gc->cpu == smp_processor_id());
This assertion tripped during overnight tests on the arm64 machines, but
curiously not on x86_64. I think we haven't observed any resource leaks
here because the lockfree list code can handle simultaneous llist_add
and llist_del_all functions operating on the same list. However, the
whole point of having percpu inodegc lists is to take advantage of warm
memory caches by inactivating inodes on the last processor to touch the
inode.
The incorrect scheduling seems to occur after an inodegc worker is
subjected to mod_delayed_work(). This wraps mod_delayed_work_on with
WORK_CPU_UNBOUND specified as the cpu number. Unbound allows for
scheduling on any cpu, not necessarily the same one that scheduled the
work.
Because preemption is disabled for as long as we have the gc pointer, I
think it's safe to use current_cpu() (aka smp_processor_id) to queue the
delayed work item on the correct cpu.
Fixes:
7cf2b0f9611b ("xfs: bound maximum wait time for inodegc work")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Mon, 3 Jul 2023 14:49:11 +0000 (16:49 +0200)]
fs: no need to check source
commit
66d8fc0539b0d49941f313c9509a8384e4245ac1 upstream.
The @source inode must be valid. It is even checked via IS_SWAPFILE()
above making it pretty clear. So no need to check it when we unlock.
What doesn't need to exist is the @target inode. The lock_two_inodes()
helper currently swaps the @inode1 and @inode2 arguments if @inode1 is
NULL to have consistent lock class usage. However, we know that at least
for vfs_rename() that @inode1 is @source and thus is never NULL as per
above. We also know that @source is a different inode than @target as
that is checked right at the beginning of vfs_rename(). So we know that
@source is valid and locked and that @target is locked. So drop the
check whether @source is non-NULL.
Fixes:
28eceeda130f ("fs: Lock moved directories")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/
202307030026.9sE2pk2x-lkp@intel.com
Message-Id: <
20230703-vfs-rename-source-v1-1-
37eebb29b65b@kernel.org>
[brauner: use commit message from patch I sent concurrently]
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yu Kuai [Sat, 10 Jun 2023 02:20:01 +0000 (10:20 +0800)]
blktrace: use inline function for blk_trace_remove() while blktrace is disabled
commit
cbe7cff4a76bc749dd70264ca5cf924e2adf9296 upstream.
If config is disabled, call blk_trace_remove() directly will trigger
build warning, hence use inline function instead, prepare to fix
blktrace debugfs entries leakage.
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20230610022003.2557284-2-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>