* [PATCH v8 0/3] spi: support the SpacemiT K1 SPI controller
From: Guodong Xu @ 2026-04-11 3:04 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Alex Elder, Philipp Zabel, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-spi, devicetree, linux-riscv, spacemit, linux-kernel,
Guodong Xu, Alex Elder, Conor Dooley, Troy Mitchell, Yixun Lan
This series adds support for the SPI controller found in the SpacemiT
K1 SoC. The driver currently supports only master mode. The controller
has two 32-entry FIFOs and supports PIO and DMA for transfers.
Starting with v8, I am taking over from Alex Elder to shepherd this
series upstream. Alex developed versions 1 through 7.
Version 8 reworks the driver based on Mark Brown's review of v7, making
much better use of the SPI core framework.
(Note, this is a distinct series from the QSPI driver, which was
merged recently.)
-
Guodong
Between version 7 and version 8:
- Use // comments for the file header (Mark Brown)
- Remove open-coded DMA mapping (k1_spi_map_dma_buffer(),
k1_spi_unmap_dma_buffer(), k1_spi_map_dma_buffers(), the dummy
buffer, k1_spi_io struct); use SPI core DMA mapping via
transfer->tx_sg/rx_sg instead
- Add can_dma() callback, replacing open-coded transfer length
checks
- Add set_cs() callback for chip select control via the
TOP_HOLD_FRAME_LOW bit
- Switch from transfer_one_message() to transfer_one()
- DMA completion calls spi_finalize_current_transfer() directly
instead of using a completion
- Add SSP_STATUS_BCE (bit count error) to error detection
- Return IRQ_NONE early if no transfer is active, before
acknowledging interrupts
- Simplify k1_spi_driver_data struct
- ~160 fewer lines of code
Here is version 7 of this series:
https://lore.kernel.org/lkml/20251114185745.2838358-1-elder@riscstar.com/
Between version 6 and version 7:
- DIV_ROUND_UP_ULL() is now used when setting the speed, to address
two errors reported by the Intel kernel test robot on 32-bit builds
- Fixed a bug interpreting the resource pointer in k1_spi_dma_cleanup()
- The driver is now built as a module by default, if ARCH_SPACEMIT
is defined
Here is version 6 of this series:
https://lore.kernel.org/lkml/20251027125504.297033-1-elder@riscstar.com/
Between version 5 and version 6:
- Rebase only
Here is version 5 of this series:
https://lore.kernel.org/lkml/20251013123309.2252042-1-elder@riscstar.com/
Between version 4 and version 5:
- Added Yixun's Reviewed-by tag on patch 3
Here is version 4 of this series:
https://lore.kernel.org/lkml/20250925121714.2514932-1-elder@riscstar.com/
Between version 3 and version 4 (all suggested by Yixun):
- Fixed an underrun/overrun comment error
- Renamed a pinctrl node
- Formatted dmas and dma-names properties on one line
Here is version 3 of this series:
https://lore.kernel.org/lkml/20250922161717.1590690-1-elder@riscstar.com/
Between version 2 and version 3:
- Add Conor's Acked-by to patch 1
- Add Rob's Reviewed-by to patch 1
- Added imply_PDMA to the SPI_SPACEMIT_K1 Kconfig option
- Fixed a bug pointed out by Vivian (and Troy) in word-sized reads
- Added a comment stating we use 1, 2, or 4 bytes per word
- Cleaned up DMA channels properly in case of failure setting up
- No longer use devm_*() for allocating DMA channels or buffer
- Moved the SPI controller into the dma-bus memory region
Here is version 2 of this series:
https://lore.kernel.org/lkml/20250919155914.935608-1-elder@riscstar.com/
Between version 1 and version 2:
- Use enum rather than const for the binding compatible string
- Omit the label and status property in the binding example
- The spi-spacemit-k1.o make target is now added in sorted order
- The SPI_SPACEMIT_K1 config option is added in sorted order
- The SPI_SPACEMIT_K1 config does *not* depend on MMP_PDMA,
however MMP_PDMA is checked at runtime, and if not enabled,
DMA will not be used
- Read/modify/writes of registers no longer use an additional
"virt" variable to hold the address accessed
- The k1_spi_driver_data->ioaddr field has been renamed base
- The DMA address for the base address is maintained, rather than
saving the DMA address of the data register
- The spi-max-frequency property value is now bounds checked
- A local variable is now initialized to 0 in k1_spi_write_word()
- The driver name is now "k1-spi"
- DT aliases are used rather than spacemit,k1-ssp-id for bus number
- The order of two pin control properties was changed as requested
- Clock names and DMA names are now on one line in the "k1.dtsi"
- The interrupts property is used rather than interrupts-extended
Here is version 1 of this series:
https://lore.kernel.org/lkml/20250917220724.288127-1-elder@riscstar.com/
Alex Elder (3):
dt-bindings: spi: add SpacemiT K1 SPI support
spi: spacemit: introduce SpacemiT K1 SPI controller driver
riscv: dts: spacemit: define a SPI controller node
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
Alex Elder (3):
dt-bindings: spi: add SpacemiT K1 SPI support
spi: spacemit: introduce SpacemiT K1 SPI controller driver
riscv: dts: spacemit: define a SPI controller node
.../devicetree/bindings/spi/spacemit,k1-spi.yaml | 84 +++
arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 7 +
arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi | 20 +
arch/riscv/boot/dts/spacemit/k1.dtsi | 15 +
drivers/spi/Kconfig | 9 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-spacemit-k1.c | 782 +++++++++++++++++++++
7 files changed, 918 insertions(+)
---
base-commit: 7aaa8047eafd0bd628065b15757d9b48c5f9c07d
change-id: 20260407-spi-spacemit-k1-e0957c311152
Best regards,
--
Guodong Xu <guodong@riscstar.com>
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: dts: qcom: glymur: Add USB related nodes
From: Rob Herring @ 2026-04-10 14:52 UTC (permalink / raw)
To: Abel Vesa
Cc: Bjorn Andersson, Konrad Dybcio, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Wesley Cheng, Pankaj Patil, linux-arm-msm,
devicetree, linux-kernel, linux-usb, Wesley Cheng, Konrad Dybcio,
Dmitry Baryshkov
In-Reply-To: <20260320-dts-qcom-glymur-add-usb-support-v7-1-ba367eda6010@oss.qualcomm.com>
On Fri, Mar 20, 2026 at 12:56:52PM +0200, Abel Vesa wrote:
> From: Wesley Cheng <wesley.cheng@oss.qualcomm.com>
>
> The Glymur USB subsystem contains three USB 3.2 Gen 2 controllers,
> one USB 3.2 multi-port controller, and one USB 2.0-only controller.
> This includes five SS USB QMP PHYs (three combo and two UNI) and six M31
> eUSB2 PHYs.
>
> All controllers are based on SNPS DWC3, so describe them as Qualcomm
> flattened DWC3 nodes.
>
> Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com>
> Co-developed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Tested-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/glymur.dtsi | 691 ++++++++++++++++++++++++++++++++++-
> 1 file changed, 686 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> index bde287f645ee..641707ba1e78 100644
> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> @@ -750,11 +750,11 @@ gcc: clock-controller@100000 {
> <0>, /* UFS PHY RX Symbol 0 */
> <0>, /* UFS PHY RX Symbol 1 */
> <0>, /* UFS PHY TX Symbol 0 */
> - <0>, /* USB3 PHY 0 */
> - <0>, /* USB3 PHY 1 */
> - <0>, /* USB3 PHY 2 */
> - <0>, /* USB3 UNI PHY pipe 0 */
> - <0>, /* USB3 UNI PHY pipe 1 */
> + <&usb_0_qmpphy QMP_USB43DP_USB3_PIPE_CLK>,
> + <&usb_1_qmpphy QMP_USB43DP_USB3_PIPE_CLK>,
> + <&usb_2_qmpphy QMP_USB43DP_USB3_PIPE_CLK>,
> + <&usb_mp_qmpphy0 QMP_USB43DP_USB3_PIPE_CLK>,
> + <&usb_mp_qmpphy1 QMP_USB43DP_USB3_PIPE_CLK>,
> <0>, /* USB4 PHY 0 pcie pipe */
> <0>, /* USB4 PHY 0 Max pipe */
> <0>, /* USB4 PHY 1 pcie pipe */
> @@ -2264,6 +2264,254 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
> };
> };
>
> + usb_hs_phy: phy@fa0000 {
> + compatible = "qcom,glymur-m31-eusb2-phy",
> + "qcom,sm8750-m31-eusb2-phy";
> + reg = <0x0 0x00fa0000 0x0 0x154>;
> + #phy-cells = <0>;
> +
> + clocks = <&tcsr TCSR_USB2_1_CLKREF_EN>;
> + clock-names = "ref";
> +
> + resets = <&gcc GCC_QUSB2PHY_USB20_HS_BCR>;
> +
> + status = "disabled";
> + };
> +
> + usb_mp_hsphy0: phy@fa1000 {
> + compatible = "qcom,glymur-m31-eusb2-phy",
> + "qcom,sm8750-m31-eusb2-phy";
> +
> + reg = <0x0 0x00fa1000 0x0 0x29c>;
> + #phy-cells = <0>;
> +
> + clocks = <&tcsr TCSR_USB2_1_CLKREF_EN>;
> + clock-names = "ref";
> +
> + resets = <&gcc GCC_QUSB2PHY_HS0_MP_BCR>;
> +
> + status = "disabled";
> + };
> +
> + usb_mp_hsphy1: phy@fa2000 {
> + compatible = "qcom,glymur-m31-eusb2-phy",
> + "qcom,sm8750-m31-eusb2-phy";
> +
> + reg = <0x0 0x00fa2000 0x0 0x29c>;
> + #phy-cells = <0>;
> +
> + clocks = <&tcsr TCSR_USB2_2_CLKREF_EN>;
> + clock-names = "ref";
> +
> + resets = <&gcc GCC_QUSB2PHY_HS1_MP_BCR>;
> +
> + status = "disabled";
> + };
> +
> + usb_mp_qmpphy0: phy@fa3000 {
> + compatible = "qcom,glymur-qmp-usb3-uni-phy";
> + reg = <0x0 0x00fa3000 0x0 0x2000>;
> +
> + clocks = <&gcc GCC_USB3_MP_PHY_AUX_CLK>,
> + <&tcsr TCSR_USB3_0_CLKREF_EN>,
> + <&rpmhcc RPMH_CXO_CLK>,
> + <&gcc GCC_USB3_MP_PHY_COM_AUX_CLK>,
> + <&gcc GCC_USB3_MP_PHY_PIPE_0_CLK>;
> + clock-names = "aux",
> + "clkref",
> + "ref",
> + "com_aux",
> + "pipe";
> +
> + power-domains = <&gcc GCC_USB3_MP_SS0_PHY_GDSC>;
> +
> + resets = <&gcc GCC_USB3_MP_SS0_PHY_BCR>,
> + <&gcc GCC_USB3UNIPHY_PHY_MP0_BCR>;
> + reset-names = "phy",
> + "phy_phy";
> +
> + clock-output-names = "usb3_uni_phy_0_pipe_clk_src";
> + #clock-cells = <0>;
> + #phy-cells = <0>;
> +
> + status = "disabled";
> + };
> +
> + usb_mp_qmpphy1: phy@fa5000 {
> + compatible = "qcom,glymur-qmp-usb3-uni-phy";
> + reg = <0x0 0x00fa5000 0x0 0x2000>;
> +
> + clocks = <&gcc GCC_USB3_MP_PHY_AUX_CLK>,
> + <&tcsr TCSR_USB3_1_CLKREF_EN>,
> + <&rpmhcc RPMH_CXO_CLK>,
> + <&gcc GCC_USB3_MP_PHY_COM_AUX_CLK>,
> + <&gcc GCC_USB3_MP_PHY_PIPE_1_CLK>;
> + clock-names = "aux",
> + "clkref",
> + "ref",
> + "com_aux",
> + "pipe";
New warnings:
4 (qcom,glymur-qmp-usb3-uni-phy): clock-names: ['aux', 'clkref', 'ref', 'com_aux', 'pipe'] is too long
4 (qcom,glymur-qmp-usb3-uni-phy): clock-names:3: 'pipe' was expected
4 (qcom,glymur-qmp-usb3-uni-phy): clock-names:2: 'com_aux' was expected
4 (qcom,glymur-qmp-usb3-uni-phy): clock-names:1: 'ref' was expected
1 (qcom,glymur-qmp-usb3-uni-phy): clocks: [[70, 329], [42, 9], [58, 0], [70, 331], [70, 332]] is too long
1 (qcom,glymur-qmp-usb3-uni-phy): clocks: [[70, 329], [42, 10], [58, 0], [70, 331], [70, 334]] is too long
1 (qcom,glymur-qmp-usb3-uni-phy): clocks: [[56, 329], [29, 9], [44, 0], [56, 331], [56, 332]] is too long
1 (qcom,glymur-qmp-usb3-uni-phy): clocks: [[56, 329], [29, 10], [44, 0], [56, 331], [56, 334]] is too long
You did test this series for DT warnings before sending, right? Please
fix and ensure they get into 7.1.
Rob
^ permalink raw reply
* Re: [PATCH v1 5/5] irqchip: starfive: Implement irq_set_type and irq_ack hooks
From: Thomas Gleixner @ 2026-04-10 14:46 UTC (permalink / raw)
To: Changhuang Liang, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel
Cc: linux-kernel, devicetree, linux-riscv, Ley Foon Tan,
Changhuang Liang
In-Reply-To: <20260410090106.622781-6-changhuang.liang@starfivetech.com>
On Fri, Apr 10 2026 at 02:01, Changhuang Liang wrote:
s/hooks/callbacks and please use function notation irq_set_type() and ....
> +static void starfive_intc_mod(struct starfive_irq_chip *irqc, u32 reg,
> + u32 mask, u32 data)
No line break required. You have 100 characters.
> +static int starfive_intc_set_type(struct irq_data *d, unsigned int type)
> +{
> + struct starfive_irq_chip *irqc = irq_data_get_irq_chip_data(d);
> + u32 i, bitpos, ty_pos, ty_shift, tmp;
> +
> + i = d->hwirq / STARFIVE_INTC_SRC_IRQ_NUM;
> + bitpos = d->hwirq % STARFIVE_INTC_SRC_IRQ_NUM;
> + ty_pos = bitpos / STARFIVE_INTC_TYPE_NUM;
> + ty_shift = (bitpos % STARFIVE_INTC_TYPE_NUM) * 2;
> +
> + switch (type) {
> + case IRQF_TRIGGER_LOW:
> + tmp = STARFIVE_INTC_TRIGGER_LOW << ty_shift;
tmp is not really an intuitive variable name.
> + irq_set_handler_locked(d, handle_level_irq);
> + break;
> + case IRQF_TRIGGER_HIGH:
> + tmp = STARFIVE_INTC_TRIGGER_HIGH << ty_shift;
> + irq_set_handler_locked(d, handle_level_irq);
> + break;
> + case IRQF_TRIGGER_FALLING:
> + tmp = STARFIVE_INTC_TRIGGER_NEGEDGE << ty_shift;
> + irq_set_handler_locked(d, handle_edge_irq);
> + break;
> + case IRQF_TRIGGER_RISING:
> + tmp = STARFIVE_INTC_TRIGGER_POSEDGE << ty_shift;
> + irq_set_handler_locked(d, handle_edge_irq);
This can be simplified so it avoids to have a function in every case
statement:
switch (type) {
case IRQF_TRIGGER_LOW:
trigger = STARFIVE_INTC_TRIGGER_LOW;
handler = handle_level_irq;
break;
case ...
}
irq_set_handler_locked(d, handler);
typeval = trigger << ty_shift;
You get the idea.
> + raw_spin_lock(&irqc->lock);
guard(...)
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v1 4/5] irqchip: starfive: Increase the interrupt source number up to 64
From: Thomas Gleixner @ 2026-04-10 14:37 UTC (permalink / raw)
To: Changhuang Liang, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel
Cc: linux-kernel, devicetree, linux-riscv, Ley Foon Tan,
Changhuang Liang
In-Reply-To: <20260410090106.622781-5-changhuang.liang@starfivetech.com>
On Fri, Apr 10 2026 at 02:01, Changhuang Liang wrote:
> From: Mason Huo <mason.huo@starfivetech.com>
>
> StarFive JHB100 SoC interrupt controller actually supports 64 interrupt
> sources, the original code only supported up to 32. now it is extended
> to 64.
>
> Signed-off-by: Mason Huo <mason.huo@starfivetech.com>
> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> ---
> drivers/irqchip/irq-starfive-jhb100-intc.c | 43 ++++++++++++++--------
> 1 file changed, 28 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/irqchip/irq-starfive-jhb100-intc.c b/drivers/irqchip/irq-starfive-jhb100-intc.c
> index 312a4634870a..d5ecbb603a58 100644
> --- a/drivers/irqchip/irq-starfive-jhb100-intc.c
> +++ b/drivers/irqchip/irq-starfive-jhb100-intc.c
> @@ -18,10 +18,11 @@
> #include <linux/reset.h>
> #include <linux/spinlock.h>
>
> -#define STARFIVE_INTC_SRC0_CLEAR 0x10
> -#define STARFIVE_INTC_SRC0_MASK 0x14
> -#define STARFIVE_INTC_SRC0_INT 0x1c
> +#define STARFIVE_INTC_SRC_CLEAR(n) (0x10 + ((n) * 0x20))
> +#define STARFIVE_INTC_SRC_MASK(n) (0x14 + ((n) * 0x20))
> +#define STARFIVE_INTC_SRC_INT(n) (0x1c + ((n) * 0x20))
>
> +#define STARFIVE_INTC_NUM 2
> #define STARFIVE_INTC_SRC_IRQ_NUM 32
>
> struct starfive_irq_chip {
> @@ -53,18 +54,26 @@ static void starfive_intc_bit_clear(struct starfive_irq_chip *irqc,
> static void starfive_intc_unmask(struct irq_data *d)
> {
> struct starfive_irq_chip *irqc = irq_data_get_irq_chip_data(d);
> + int i, bitpos;
> +
> + i = d->hwirq / STARFIVE_INTC_SRC_IRQ_NUM;
> + bitpos = d->hwirq % STARFIVE_INTC_SRC_IRQ_NUM;
>
> raw_spin_lock(&irqc->lock);
> - starfive_intc_bit_clear(irqc, STARFIVE_INTC_SRC0_MASK, BIT(d->hwirq));
> + starfive_intc_bit_clear(irqc, STARFIVE_INTC_SRC_MASK(i), BIT(bitpos));
> raw_spin_unlock(&irqc->lock);
> }
As you are touching this code, please convert the locking to guard()
guard(raw_spinlock)(&irqc->lock);
starfive_intc_bit_clear(irqc, STARFIVE_INTC_SRC0_MASK, BIT(d->hwirq));
> + for (i = 0; i < STARFIVE_INTC_NUM; i++) {
for (int i = 0; ...)
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v1 3/5] irqchip: starfive: Use devm_ interfaces to simplify resource release
From: Thomas Gleixner @ 2026-04-10 14:32 UTC (permalink / raw)
To: Changhuang Liang, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel
Cc: linux-kernel, devicetree, linux-riscv, Ley Foon Tan,
Changhuang Liang
In-Reply-To: <20260410090106.622781-4-changhuang.liang@starfivetech.com>
On Fri, Apr 10 2026 at 02:01, Changhuang Liang wrote:
> - irqc->base = of_iomap(intc, 0);
> + irqc->base = devm_platform_ioremap_resource(pdev, 0);
> if (!irqc->base) {
> - pr_err("Unable to map registers\n");
> + dev_err(&pdev->dev, "unable to map registers\n");
> ret = -ENXIO;
> goto err_free;
You can eliminate err_free as well by doing:
struct startfive_irq_chip *irqc __free(kfree) = kzalloc_obj(*irqc);
....
dev_info(..);
retain_and_null_ptr(irqc);
return 0;
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v1 2/5] irqchip: starfive: Convert the word "jh8100" to "jhb100"
From: Thomas Gleixner @ 2026-04-10 14:26 UTC (permalink / raw)
To: Changhuang Liang, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel
Cc: linux-kernel, devicetree, linux-riscv, Ley Foon Tan,
Changhuang Liang
In-Reply-To: <20260410090106.622781-3-changhuang.liang@starfivetech.com>
On Fri, Apr 10 2026 at 02:01, Changhuang Liang wrote:
Please use the documented prefix scheme, i.e. irqchip/....:
Your subject line might be more descriptive when it says:
Rename jh8100 to jhb100
Thanks,
tglx
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: broadcom: rpi-5: Add RP1 PWM node
From: Andrea della Porta @ 2026-04-10 14:09 UTC (permalink / raw)
To: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Andrea della Porta,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
In-Reply-To: <cover.1775829499.git.andrea.porta@suse.com>
From: Stanimir Varbanov <svarbanov@suse.de>
The RP1 chipset used on the Raspberry Pi 5 features an integrated
PWM controller to drive the cooling fan.
Add the corresponding DT node for this PWM controller.
Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
Co-developed-by: Andrea della Porta <andrea.porta@suse.com>
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
---
arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts | 12 ++++++++++++
arch/arm64/boot/dts/broadcom/rp1-common.dtsi | 10 ++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts
index 2856082814462..a4e5ba23bf536 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts
@@ -64,12 +64,24 @@ phy1: ethernet-phy@1 {
};
&rp1_gpio {
+ fan_pwm_default_state: fan-pwm-default-state {
+ function = "pwm1";
+ pins = "gpio45";
+ bias-pull-down;
+ };
+
usb_vbus_default_state: usb-vbus-default-state {
function = "vbus1";
groups = "vbus1";
};
};
+&rp1_pwm {
+ pinctrl-0 = <&fan_pwm_default_state>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
&rp1_usb0 {
pinctrl-0 = <&usb_vbus_default_state>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/broadcom/rp1-common.dtsi b/arch/arm64/boot/dts/broadcom/rp1-common.dtsi
index 5a815c3797945..d0f4d6be75500 100644
--- a/arch/arm64/boot/dts/broadcom/rp1-common.dtsi
+++ b/arch/arm64/boot/dts/broadcom/rp1-common.dtsi
@@ -26,6 +26,16 @@ rp1_clocks: clocks@40018000 {
<200000000>; // RP1_CLK_SYS
};
+ rp1_pwm: pwm@4009c000 {
+ compatible = "raspberrypi,rp1-pwm";
+ reg = <0x00 0x4009c000 0x0 0x100>;
+ clocks = <&rp1_clocks RP1_CLK_PWM1>;
+ assigned-clocks = <&rp1_clocks RP1_CLK_PWM1>;
+ assigned-clock-rates = <50000000>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
rp1_gpio: pinctrl@400d0000 {
compatible = "raspberrypi,rp1-gpio";
reg = <0x00 0x400d0000 0x0 0xc000>,
--
2.35.3
^ permalink raw reply related
* [PATCH v2 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Andrea della Porta @ 2026-04-10 14:09 UTC (permalink / raw)
To: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Andrea della Porta,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
In-Reply-To: <cover.1775829499.git.andrea.porta@suse.com>
From: Naushir Patuck <naush@raspberrypi.com>
The Raspberry Pi RP1 southbridge features an embedded PWM
controller with 4 output channels, alongside an RPM interface
to read the fan speed on the Raspberry Pi 5.
Add the supporting driver.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Co-developed-by: Stanimir Varbanov <svarbanov@suse.de>
Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
---
drivers/pwm/Kconfig | 9 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-rp1.c | 344 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 354 insertions(+)
create mode 100644 drivers/pwm/pwm-rp1.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 6f3147518376a..32031f2af75af 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -625,6 +625,15 @@ config PWM_ROCKCHIP
Generic PWM framework driver for the PWM controller found on
Rockchip SoCs.
+config PWM_RASPBERRYPI_RP1
+ bool "RP1 PWM support"
+ depends on MISC_RP1 || COMPILE_TEST
+ depends on HAS_IOMEM
+ select REGMAP_MMIO
+ select MFD_SYSCON
+ help
+ PWM framework driver for Raspberry Pi RP1 controller.
+
config PWM_SAMSUNG
tristate "Samsung PWM support"
depends on PLAT_SAMSUNG || ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 0dc0d2b69025d..59f29f60f9123 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_PWM_RENESAS_RZG2L_GPT) += pwm-rzg2l-gpt.o
obj-$(CONFIG_PWM_RENESAS_RZ_MTU3) += pwm-rz-mtu3.o
obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o
obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
+obj-$(CONFIG_PWM_RASPBERRYPI_RP1) += pwm-rp1.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
obj-$(CONFIG_PWM_SIFIVE) += pwm-sifive.o
obj-$(CONFIG_PWM_SL28CPLD) += pwm-sl28cpld.o
diff --git a/drivers/pwm/pwm-rp1.c b/drivers/pwm/pwm-rp1.c
new file mode 100644
index 0000000000000..b88c697d9567e
--- /dev/null
+++ b/drivers/pwm/pwm-rp1.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * pwm-rp1.c
+ *
+ * Raspberry Pi RP1 PWM.
+ *
+ * Copyright © 2026 Raspberry Pi Ltd.
+ *
+ * Author: Naushir Patuck (naush@raspberrypi.com)
+ *
+ * Based on the pwm-bcm2835 driver by:
+ * Bart Tanghe <bart.tanghe@thomasmore.be>
+ *
+ * Datasheet: https://pip-assets.raspberrypi.com/categories/892-raspberry-pi-5/documents/RP-008370-DS-1-rp1-peripherals.pdf?disposition=inline
+ *
+ * Limitations:
+ * - Channels can be enabled/disabled and their duty cycle and period can
+ * be updated glitchlessly. Update are synchronized with the next strobe
+ * at the end of the current period of the respective channel, once the
+ * update bit is set. The update flag is global, not per-channel.
+ * - Channels are phase-capable, but on RPi5, the firmware can use a channel
+ * phase register to report the RPM of the fan connected to that PWM
+ * channel. As a result, phase control will be ignored for now.
+ */
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+
+#define RP1_PWM_GLOBAL_CTRL 0x000
+#define RP1_PWM_CHANNEL_CTRL(x) (0x014 + ((x) * 0x10))
+#define RP1_PWM_RANGE(x) (0x018 + ((x) * 0x10))
+#define RP1_PWM_PHASE(x) (0x01C + ((x) * 0x10))
+#define RP1_PWM_DUTY(x) (0x020 + ((x) * 0x10))
+
+/* 8:FIFO_POP_MASK + 0:Trailing edge M/S modulation */
+#define RP1_PWM_CHANNEL_DEFAULT (BIT(8) + BIT(0))
+#define RP1_PWM_CHANNEL_ENABLE(x) BIT(x)
+#define RP1_PWM_POLARITY BIT(3)
+#define RP1_PWM_SET_UPDATE BIT(31)
+#define RP1_PWM_MODE_MASK GENMASK(1, 0)
+
+#define RP1_PWM_NUM_PWMS 4
+
+struct rp1_pwm {
+ struct regmap *regmap;
+ struct clk *clk;
+ unsigned long clk_rate;
+ bool clk_enabled;
+};
+
+struct rp1_pwm_waveform {
+ u32 period_ticks;
+ u32 duty_ticks;
+ bool enabled;
+ bool inverted_polarity;
+};
+
+static const struct regmap_config rp1_pwm_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = 0x60,
+};
+
+static void rp1_pwm_apply_config(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+ u32 value;
+
+ /* update the changed registers on the next strobe to avoid glitches */
+ regmap_read(rp1->regmap, RP1_PWM_GLOBAL_CTRL, &value);
+ value |= RP1_PWM_SET_UPDATE;
+ regmap_write(rp1->regmap, RP1_PWM_GLOBAL_CTRL, value);
+}
+
+static int rp1_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+
+ /* init channel to reset defaults */
+ regmap_write(rp1->regmap, RP1_PWM_CHANNEL_CTRL(pwm->hwpwm), RP1_PWM_CHANNEL_DEFAULT);
+ return 0;
+}
+
+static int rp1_pwm_round_waveform_tohw(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ const struct pwm_waveform *wf,
+ void *_wfhw)
+{
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+ struct rp1_pwm_waveform *wfhw = _wfhw;
+ u64 clk_rate = rp1->clk_rate;
+ u64 ticks;
+
+ ticks = mul_u64_u64_div_u64(wf->period_length_ns, clk_rate, NSEC_PER_SEC);
+
+ if (ticks > U32_MAX)
+ ticks = U32_MAX;
+ wfhw->period_ticks = ticks;
+
+ if (wf->duty_offset_ns + wf->duty_length_ns >= wf->period_length_ns) {
+ ticks = mul_u64_u64_div_u64(wf->period_length_ns - wf->duty_length_ns,
+ clk_rate, NSEC_PER_SEC);
+ wfhw->inverted_polarity = true;
+ } else {
+ ticks = mul_u64_u64_div_u64(wf->duty_length_ns, clk_rate, NSEC_PER_SEC);
+ wfhw->inverted_polarity = false;
+ }
+
+ if (ticks > wfhw->period_ticks)
+ ticks = wfhw->period_ticks;
+ wfhw->duty_ticks = ticks;
+
+ wfhw->enabled = !!wfhw->duty_ticks;
+
+ return 0;
+}
+
+static int rp1_pwm_round_waveform_fromhw(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ const void *_wfhw,
+ struct pwm_waveform *wf)
+{
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+ const struct rp1_pwm_waveform *wfhw = _wfhw;
+ u64 clk_rate = rp1->clk_rate;
+ u32 ticks;
+
+ memset(wf, 0, sizeof(*wf));
+
+ if (!wfhw->enabled)
+ return 0;
+
+ wf->period_length_ns = DIV_ROUND_UP_ULL((u64)wfhw->period_ticks * NSEC_PER_SEC, clk_rate);
+
+ if (wfhw->inverted_polarity) {
+ wf->duty_length_ns = DIV_ROUND_UP_ULL((u64)wfhw->duty_ticks * NSEC_PER_SEC,
+ clk_rate);
+ } else {
+ wf->duty_offset_ns = DIV_ROUND_UP_ULL((u64)wfhw->duty_ticks * NSEC_PER_SEC,
+ clk_rate);
+ ticks = wfhw->period_ticks - wfhw->duty_ticks;
+ wf->duty_length_ns = DIV_ROUND_UP_ULL((u64)ticks * NSEC_PER_SEC, clk_rate);
+ }
+
+ return 0;
+}
+
+static int rp1_pwm_write_waveform(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ const void *_wfhw)
+{
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+ const struct rp1_pwm_waveform *wfhw = _wfhw;
+ u32 value;
+
+ /* set period and duty cycle */
+ regmap_write(rp1->regmap,
+ RP1_PWM_RANGE(pwm->hwpwm), wfhw->period_ticks);
+ regmap_write(rp1->regmap,
+ RP1_PWM_DUTY(pwm->hwpwm), wfhw->duty_ticks);
+
+ /* set polarity */
+ regmap_read(rp1->regmap, RP1_PWM_CHANNEL_CTRL(pwm->hwpwm), &value);
+ if (!wfhw->inverted_polarity)
+ value &= ~RP1_PWM_POLARITY;
+ else
+ value |= RP1_PWM_POLARITY;
+ regmap_write(rp1->regmap, RP1_PWM_CHANNEL_CTRL(pwm->hwpwm), value);
+
+ /* enable/disable */
+ regmap_read(rp1->regmap, RP1_PWM_GLOBAL_CTRL, &value);
+ if (wfhw->enabled)
+ value |= RP1_PWM_CHANNEL_ENABLE(pwm->hwpwm);
+ else
+ value &= ~RP1_PWM_CHANNEL_ENABLE(pwm->hwpwm);
+ regmap_write(rp1->regmap, RP1_PWM_GLOBAL_CTRL, value);
+
+ rp1_pwm_apply_config(chip, pwm);
+
+ return 0;
+}
+
+static int rp1_pwm_read_waveform(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ void *_wfhw)
+{
+ struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
+ struct rp1_pwm_waveform *wfhw = _wfhw;
+ u32 value;
+
+ regmap_read(rp1->regmap, RP1_PWM_GLOBAL_CTRL, &value);
+ wfhw->enabled = !!(value & RP1_PWM_CHANNEL_ENABLE(pwm->hwpwm));
+
+ regmap_read(rp1->regmap, RP1_PWM_CHANNEL_CTRL(pwm->hwpwm), &value);
+ wfhw->inverted_polarity = !!(value & RP1_PWM_POLARITY);
+
+ if (wfhw->enabled) {
+ regmap_read(rp1->regmap, RP1_PWM_RANGE(pwm->hwpwm), &wfhw->period_ticks);
+ regmap_read(rp1->regmap, RP1_PWM_DUTY(pwm->hwpwm), &wfhw->duty_ticks);
+ } else {
+ wfhw->period_ticks = 0;
+ wfhw->duty_ticks = 0;
+ }
+
+ return 0;
+}
+
+static const struct pwm_ops rp1_pwm_ops = {
+ .sizeof_wfhw = sizeof(struct rp1_pwm_waveform),
+ .request = rp1_pwm_request,
+ .round_waveform_tohw = rp1_pwm_round_waveform_tohw,
+ .round_waveform_fromhw = rp1_pwm_round_waveform_fromhw,
+ .read_waveform = rp1_pwm_read_waveform,
+ .write_waveform = rp1_pwm_write_waveform,
+};
+
+static int rp1_pwm_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ unsigned long clk_rate;
+ struct pwm_chip *chip;
+ void __iomem *base;
+ struct rp1_pwm *rp1;
+ int ret;
+
+ chip = devm_pwmchip_alloc(dev, RP1_PWM_NUM_PWMS, sizeof(*rp1));
+ if (IS_ERR(chip))
+ return PTR_ERR(chip);
+
+ rp1 = pwmchip_get_drvdata(chip);
+
+ base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ rp1->regmap = devm_regmap_init_mmio(dev, base, &rp1_pwm_regmap_config);
+ if (IS_ERR(rp1->regmap))
+ return dev_err_probe(dev, PTR_ERR(rp1->regmap), "Cannot initialize regmap\n");
+
+ ret = of_syscon_register_regmap(np, rp1->regmap);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to register syscon\n");
+
+ rp1->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(rp1->clk))
+ return dev_err_probe(dev, PTR_ERR(rp1->clk), "Clock not found\n");
+
+ ret = clk_prepare_enable(rp1->clk);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to enable clock\n");
+ rp1->clk_enabled = true;
+
+ ret = devm_clk_rate_exclusive_get(dev, rp1->clk);
+ if (ret) {
+ dev_err_probe(dev, ret, "Fail to get exclusive rate\n");
+ goto err_disable_clk;
+ }
+
+ clk_rate = clk_get_rate(rp1->clk);
+ if (!clk_rate) {
+ ret = dev_err_probe(dev, -EINVAL, "Failed to get clock rate\n");
+ goto err_disable_clk;
+ }
+ rp1->clk_rate = clk_rate;
+
+ chip->ops = &rp1_pwm_ops;
+
+ platform_set_drvdata(pdev, chip);
+
+ ret = devm_pwmchip_add(dev, chip);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to register PWM chip\n");
+ goto err_disable_clk;
+ }
+
+ return 0;
+
+err_disable_clk:
+ clk_disable_unprepare(rp1->clk);
+
+ return ret;
+}
+
+static int rp1_pwm_suspend(struct device *dev)
+{
+ struct rp1_pwm *rp1 = dev_get_drvdata(dev);
+
+ if (rp1->clk_enabled) {
+ clk_disable_unprepare(rp1->clk);
+ rp1->clk_enabled = false;
+ }
+
+ return 0;
+}
+
+static int rp1_pwm_resume(struct device *dev)
+{
+ struct rp1_pwm *rp1 = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(rp1->clk);
+ if (ret) {
+ dev_err(dev, "Failed to enable clock on resume: %d\n", ret);
+ return ret;
+ }
+
+ rp1->clk_enabled = true;
+
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(rp1_pwm_pm_ops, rp1_pwm_suspend, rp1_pwm_resume);
+
+static const struct of_device_id rp1_pwm_of_match[] = {
+ { .compatible = "raspberrypi,rp1-pwm" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, rp1_pwm_of_match);
+
+static struct platform_driver rp1_pwm_driver = {
+ .probe = rp1_pwm_probe,
+ .driver = {
+ .name = "rp1-pwm",
+ .of_match_table = rp1_pwm_of_match,
+ .pm = pm_ptr(&rp1_pwm_pm_ops),
+ .suppress_bind_attrs = true,
+ },
+};
+module_platform_driver(rp1_pwm_driver);
+
+MODULE_DESCRIPTION("RP1 PWM driver");
+MODULE_AUTHOR("Naushir Patuck <naush@raspberrypi.com>");
+MODULE_AUTHOR("Andrea della Porta <andrea.porta@suse.com>");
+MODULE_LICENSE("GPL");
--
2.35.3
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
From: Andrea della Porta @ 2026-04-10 14:09 UTC (permalink / raw)
To: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Andrea della Porta,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
In-Reply-To: <cover.1775829499.git.andrea.porta@suse.com>
From: Naushir Patuck <naush@raspberrypi.com>
Add the devicetree binding documentation for the PWM
controller found in the Raspberry Pi RP1 chipset.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Co-developed-by: Stanimir Varbanov <svarbanov@suse.de>
Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
---
.../bindings/pwm/raspberrypi,rp1-pwm.yaml | 54 +++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
diff --git a/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml b/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
new file mode 100644
index 0000000000000..6f8461d0454f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/raspberrypi,rp1-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raspberry Pi RP1 PWM controller
+
+maintainers:
+ - Naushir Patuck <naush@raspberrypi.com>
+
+allOf:
+ - $ref: pwm.yaml#
+
+description: |
+ The PWM peripheral is a flexible waveform generator with a
+ variety of operational modes. It has the following features:
+ - four independent output channels
+ - 32-bit counter widths
+ - Seven output generation modes
+ - Optional per-channel output inversion
+ - Optional duty-cycle data FIFO with DMA support
+ - Optional sigma-delta noise shaping engine
+ Serves as a fan speed provider to other nodes for a PWM-connected
+ fan using shared registers (syscon).
+
+properties:
+ compatible:
+ const: raspberrypi,rp1-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pwm@98000 {
+ compatible = "raspberrypi,rp1-pwm";
+ reg = <0x98000 0x100>;
+ clocks = <&rp1_clocks 17>;
+ #pwm-cells = <3>;
+ };
--
2.35.3
^ permalink raw reply related
* [PATCH v2 0/3] Add RP1 PWM controller support
From: Andrea della Porta @ 2026-04-10 14:09 UTC (permalink / raw)
To: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Andrea della Porta,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
This patchset adds support for the PWM controller found on the
Raspberry Pi RP1 southbridge. This is necessary to operate the
cooling fan connected to one of the PWM channels.
The tachometer pin for the fan speed is managed by the firmware
running on the RP1's M-core. It uses the PHASE2 register
to report the RPM, which is then exported by this driver via
syscon registers. A subsequent patch will add a new device
and driver to read the RPM and export this value via hwmon.
Subsequent patches will also add the CPU thermal zone, which
acts as a consumer of the PWM device.
Best regards,
Andrea
CHANGES in V2:
- bindings: added syscon to the description
- bindings: changed additionalProperties to unevaluatedProperties
- dts: reordered pwm node to follow the unit address ordering
- Kconfig/Makefile: renamed config option to PWM_RASPBERRYPI_RP1
- Kconfig: added dependency for syscon/regmap
- driver: added 'Limitations' and 'Datasheet' paragraphs in top comment
- driver: all macros are now prefixed by RP1_PWM_
- driver: implemented waveform callbacks instead of legacy ones
- driver: dropped hwmon device registration for fan speed (this will be
handled in a separate patch with its own driver reading the value via
syscon)
- driver: added new regmap/syscon to export the registers.
- driver: added a comment in rp1_pwm_apply_config() to describe what it does
- driver: added a comment to rp1_pwm_request() to define the purpose of the
last write
- driver: new clk_enabled flag to deal with the clock on suspend/resume path
- driver: clk_rate is now obtained during probe right after exclusive_get()
- driver/Kconfig: module is now static only and has suppress_bind_attr to
avoid racing with syscon consumer drivers and with syscon unload issue
Naushir Patuck (2):
dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
pwm: rp1: Add RP1 PWM controller driver
Stanimir Varbanov (1):
arm64: dts: broadcom: rpi-5: Add RP1 PWM node
.../bindings/pwm/raspberrypi,rp1-pwm.yaml | 54 +++
.../boot/dts/broadcom/bcm2712-rpi-5-b.dts | 12 +
arch/arm64/boot/dts/broadcom/rp1-common.dtsi | 10 +
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-rp1.c | 344 ++++++++++++++++++
6 files changed, 430 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
create mode 100644 drivers/pwm/pwm-rp1.c
--
2.35.3
^ permalink raw reply
* Re: [PATCH v5 2/4] ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver
From: Mark Brown @ 2026-04-10 14:02 UTC (permalink / raw)
To: Sen Wang
Cc: linux-sound, lgirdwood, robh, krzk+dt, conor+dt, devicetree,
perex, tiwai, shenghao-ding, kevin-lu, baojun.xu, niranjan.hy,
l-badrinarayanan, devarsht, v-singh1, linux-kernel
In-Reply-To: <20260409220607.686146-3-sen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 445 bytes --]
On Thu, Apr 09, 2026 at 05:06:04PM -0500, Sen Wang wrote:
> The TAS675x (TAS6754, TAS67524) are quad-channel, digital-input
> Class-D amplifiers with an integrated DSP, controlled over I2C.
> They support I2S and TDM serial audio interfaces.
This looks mostly good, but one issue I see is that AFAICT we only stop
fault_check_work during runtime suspsend - if runtime PM is disabled, or
if the driver is removed, the work will be left running.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/7] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Markus Schneider-Pargmann @ 2026-04-10 13:54 UTC (permalink / raw)
To: Vignesh Raghavendra, Rob Herring, Markus Schneider-Pargmann (TI)
Cc: Bjorn Andersson, Mathieu Poirier, Krzysztof Kozlowski,
Conor Dooley, Suman Anna, Nishanth Menon, Tero Kristo,
Vishal Mahaveer, Kevin Hilman, Dhruva Gole, Sebin Francis,
Kendall Willis, Akashdeep Kaur, linux-remoteproc, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <6a4aecff-f662-4620-8572-3309ea6a81e2@ti.com>
[-- Attachment #1: Type: text/plain, Size: 4163 bytes --]
Hi Vignesh,
On Thu Apr 9, 2026 at 11:46 AM CEST, Vignesh Raghavendra wrote:
> Hi Markus
>
> On 08/04/26 20:33, Rob Herring wrote:
>> On Wed, Mar 18, 2026 at 10:14 AM Markus Schneider-Pargmann (TI)
>> <msp@baylibre.com> wrote:
>>>
>>> Hi,
>>>
>>> Split the firmware memory region in more specific parts so it is better
>>> described where which information is stored. Specifically the LPM metadata
>>> region is important as bootloader software like U-Boot has to know where
>>> that data is to be able to read that data and resume from RAM.
>>>
>>> IO+DDR is a deep sleep state in which a few pins are set to be sensitive
>>> for wakeup while the DDR is kept in self refresh. Everything else is
>>> powered off.
>>>
>>> The changes in this series were suggested as part of the IO+DDR u-boot series:
>>> https://lore.kernel.org/r/814c211f-a9eb-4311-bb84-165b1a69755f@ti.com
>>>
>>> There are currently no real users of the memory-region that is split in
>>> this series. The size of the memory-region in total stays the same.
>>> The new layout is derived from the software running on the r5f
>>> processor:
>>> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62ax-sk/r5fss0-0_freertos/ti-arm-clang/linker.cmd#L172
>>> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/source/drivers/device_manager/sciclient.h#L459
>>>
>>> Additionally the two important devicetree nodes for resuming from IO+DDR
>>> have the bootph-pre-ram flag added as this data needs to be read before
>>> the RAM is in use.
>>>
>>> Best
>>> Markus
>>>
>>> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
>>> ---
>>> Changes in v3:
>>> - Squash the enforcement of the memory-region-names requirement in the
>>> patch adding the memory-region-names, as suggested.
>>> - Link to v2: https://lore.kernel.org/r/20260312-topic-am62a-ioddr-dt-v6-19-v2-0-37cb7ceec658@baylibre.com
>>>
>>> Changes in v2:
>>> - Make memory-region-names required if memory-region is present
>>> - Fixup memory-region and memory-region-names conditions. Require either
>>> 2 or 6 regions for memory-region and memory-region-names
>>> - Reword and restructure the binding documentation for memory-region and
>>> memory-region-names
>>> - Add memory-region-names to all uses of memory-region
>>> - Link to v1: https://lore.kernel.org/r/20260303-topic-am62a-ioddr-dt-v6-19-v1-0-12fe72bb40d2@baylibre.com
>>>
>>> ---
>>> Markus Schneider-Pargmann (TI) (7):
>>> dt-bindings: remoteproc: k3-r5f: Split up memory regions
>>> dt-bindings: remoteproc: k3-r5f: Add memory-region-names
>>> arm64: dts: ti: k3: Use memory-region-names for r5f
>>> arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
>>> arm64: dts: ti: k3-am62p5-sk: Split r5f memory region
>>> arm64: dts: ti: k3-am62a7-sk: Add r5f nodes to pre-ram bootphase
>>> arm64: dts: ti: k3-am62p5-sk: Add r5f nodes to pre-ram bootphase
>>
>> TI folks, Please make sure these dts patches are picked up for 7.1.
>> There's now a crap load of warnings in next with the binding change:
>>
>> 58 (ti,am62-r5fss): r5f@78000000: 'memory-region-names' is a
>> required property
>
> [...]
>
>> If they aren't applied, making 'memory-region-names' required needs
>> to be dropped from the binding.
>>
>
> This breaks DT backward compatibility. Why is memory-region-names now a
> required item and cannot be assumed as "dma" and "firmware" as default?
> Is that intentional (should have at least had a Fixes tag then if the
> original definition was wrong)?
Conor suggested to make the memory-region-names required for easier
distinction of the layouts:
https://lore.kernel.org/all/20260303-payphone-pancake-b6068c545bc3@spud/
And a follow-up discussion here:
https://lore.kernel.org/all/20260313-kettle-craftily-aa087e6b74db@spud/
Also I don't think it really breaks backward compatibility. I don't
think there is any user for it and the previous binding documentation
only refers to it as reserved regions.
Best
Markus
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 289 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/5] arm64: dts: qcom: sdm845-xiaomi-beryllium-tianma: Disable MDSS
From: David Heidelberg @ 2026-04-10 13:51 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sam Day, linux-arm-msm, devicetree, linux-kernel,
phone-devel, Petr Hodina
In-Reply-To: <73fyiqoxxg2gg5244wkukepdfw6lnguq63si22qsx2ueyna4hu@l4vyykvn43oo>
On 18/03/2026 15:47, Dmitry Baryshkov wrote:
> On Tue, Mar 17, 2026 at 11:12:35PM +0100, David Heidelberg via B4 Relay wrote:
>> From: Petr Hodina <petr.hodina@protonmail.com>
>>
>> Currently the panel driver for tianma is broken.
>> Disable MDSS to prevent DRM taking over the framebuffer.
>
> I'd still hope that somebody can get it to work. I'd start by using
> prepare_prev_first. Sumit reported the panel as working in 2020 and I
> have no doubts that it was the case. Another option migt be something
> related to the dispcc (see my [1]).
Sadly, the prepare_prev_first didn't solve the issue. The framebuffer -> MDSS
takover happens, but at greetd (login) loading screen goes black and never restores.
Will need more work.
David>
> [1] https://lore.kernel.org/linux-arm-msm/20260217-sdm845-hdk-v1-1-866f1965fef7@oss.qualcomm.com/
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: sram: Allow multiple-word prefixes to sram subnode
From: Rob Herring @ 2026-04-10 13:45 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Krzysztof Kozlowski, Conor Dooley, devicetree, linux-kernel,
Luca Weiss, Konrad Dybcio
In-Reply-To: <20260409-topic-sram_dtbindings_misc-v2-1-59dc6b0dec45@oss.qualcomm.com>
On Thu, Apr 9, 2026 at 5:04 AM Konrad Dybcio <konradybcio@kernel.org> wrote:
>
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Currently, foo-sram is allowed, but foo-bar-sram is not.
>
> Allow it so that more complex names aren't unnecessarily simplified.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> Changes in v2:
> - Update the regex to disallow names starting with just a hyphen
> - Rewrite (foo|)+ into (foo)*
> - Link to v1: https://lore.kernel.org/r/20260408-topic-sram_dtbindings_misc-v1-1-00556167e136@oss.qualcomm.com
> ---
> Documentation/devicetree/bindings/sram/sram.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: purwa-iot-evk: Add camss node
From: Krzysztof Kozlowski @ 2026-04-10 13:43 UTC (permalink / raw)
To: Wenmeng Liu, Bryan O'Donoghue, Robert Foss, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <c9cea1d2-a51f-4c38-8ae9-db868b86a928@oss.qualcomm.com>
On 10/04/2026 10:38, Wenmeng Liu wrote:
>>> +&camss {
>>> + status = "okay";
>>> +};
>>
>> Hmm.
>>
>> I don't agree with this. Enabling the CAMSS node with just the TPG is of
>> very low value to an end-user and doesn't "prove out" the CSIPHY, TPG
>> and RDI path - which is the minimum entry point in upstream right now.
>>
>> I don't support less than a sensor at minimum.
>>
>> You guys must have a sensor you've used with this board ?
>>
>
> Yes we have, but both not upstreamed sensor, we currently have no plans
> for sensor upstream, perhaps this work will be carried out later.
>
Then, as Bryan said, this patch should not be sent. It brings no value
to the user of this DTS, because users-with-out-of-tree-patches can have
this as well out of tree.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: renesas: Add missing #mux-state-cells to usb2phy-reset nodes
From: Ulf Hansson @ 2026-04-10 13:42 UTC (permalink / raw)
To: Tommaso Merciai
Cc: Geert Uytterhoeven, tomm.merciai, peda, p.zabel,
linux-renesas-soc, biju.das.jz, Magnus Damm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree, linux-kernel
In-Reply-To: <adZaXSDsv4f9d8Bp@tom-desktop>
On Wed, 8 Apr 2026 at 15:38, Tommaso Merciai
<tommaso.merciai.xr@bp.renesas.com> wrote:
>
> Hi Geert,
> Thanks for your comments.
>
> On Wed, Apr 08, 2026 at 03:07:44PM +0200, Geert Uytterhoeven wrote:
> > Hi Tommaso,
> >
> > On Tue, 7 Apr 2026 at 17:35, Tommaso Merciai
> > <tommaso.merciai.xr@bp.renesas.com> wrote:
> > > The renesas,rzv2h-usb2phy-reset binding schema defines #mux-state-cells as a
> > > required property. Add it to the USB2 PHY reset nodes in the RZ/V2H and RZ/V2N
> > > device trees to fix dtbs_check warnings.
> > >
> > > "arch/arm64/boot/dts/renesas/r9a09g056n48-rzv2n-evk.dtb: usb20phy-reset@15830000 (renesas,r9a09g056-usb2phy-reset): '#mux-state-cells' is a required property"
> > > "arch/arm64/boot/dts/renesas/r9a09g056n48-rzv2n-evk-cn15-emmc.dtb: usb20phy-reset@15830000 (renesas,r9a09g056-usb2phy-reset): '#mux-state-cells' is a required property"
> > > "arch/arm64/boot/dts/renesas/r9a09g056n48-rzv2n-evk-cn15-sd.dtb: usb20phy-reset@15830000 (renesas,r9a09g056-usb2phy-reset): '#mux-state-cells' is a required property"
> > > "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dtb: usb20phy-reset@15830000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> > > "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dtb: usb21phy-reset@15840000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> > > "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk-cn15-emmc.dtb: usb20phy-reset@15830000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> > > "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk-cn15-emmc.dtb: usb21phy-reset@15840000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> > > "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk-cn15-sd.dtb: usb20phy-reset@15830000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> > > "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk-cn15-sd.dtb: usb21phy-reset@15840000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> > >
> > > Kind Regards,
> > > Tommaso
> > >
> > > Tommaso Merciai (2):
> > > arm64: dts: renesas: r9a09g057: Add #mux-state-cells to
> > > usb2{0,1}phyrst
> > > arm64: dts: renesas: r9a09g056: Add #mux-state-cells to usb20phyrst
> >
> > Does this series supersedes "[PATCH v5 16/22] arm64: dts: renesas:
> > r9a09g056: Add USB2.0 VBUS_SEL mux-controller support"[1] and "[PATCH
> > v5 17/22] arm64: dts: renesas: r9a09g056: Add USB2.0 PHY VBUS internal
> > regulator node"[2]?
>
> Yes, thanks.
>
> From v5 only [0] missing.
> But I think Ulf is planning to pick [0].
I didn't get confirmation from Peter, so I decided to wait.
If there is an rc8 on Monday I can pick it up for v7.1, otherwise
please re-submit when v7.1-rc1 is out.
>
> I will rebase/send RZ/G3E USB2.0 dt patches later.
>
> [0] https://patchwork.kernel.org/project/linux-renesas-soc/patch/cda933586ef7ca119dbbcef45a921c29dd517698.1775047175.git.tommaso.merciai.xr@bp.renesas.com/
>
>
> Kind Regards,
> Tommaso
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v3 4/7] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Markus Schneider-Pargmann @ 2026-04-10 13:42 UTC (permalink / raw)
To: Vignesh Raghavendra, Markus Schneider-Pargmann (TI),
Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Suman Anna, Nishanth Menon,
Tero Kristo
Cc: Vishal Mahaveer, Kevin Hilman, Dhruva Gole, Sebin Francis,
Kendall Willis, Akashdeep Kaur, linux-remoteproc, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <8673745d-aad2-49d3-b3af-556de7037b69@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]
Hi Vignesh,
On Fri Apr 10, 2026 at 6:30 AM CEST, Vignesh Raghavendra wrote:
> Hi Markus
>
> On 18/03/26 20:43, Markus Schneider-Pargmann (TI) wrote:
>> Split the firmware memory region in more specific parts so it is better
>> described where to find which information. Specifically the LPM metadata
>> region is important as bootloader software like U-Boot has to know where
>> that data is to be able to read that data.
>>
>> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
>> ---
>> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 40 +++++++++++++++++++++++++++++++--
>> 1 file changed, 38 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>> index e99bdbc2e0cbdf858f1631096f9c2a086191bab3..c381cc33064ec427751a9ac5bcdff745a9559a89 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>> @@ -59,9 +59,33 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
>> no-map;
>> };
>>
>> - wkup_r5fss0_core0_memory_region: memory@9c900000 {
>> + wkup_r5fss0_core0_ipc_region: memory@9c900000 {
>
> There are still references to wkup_r5fss0_core0_memory_region in
> k3-am62a-ti-ipc-firmware.dtsi (same comment applies to next 2 patches as
> well)
>
> Dont those need to be updated too?
I only updated the sk boards as these are the only ones that have IO+DDR
support that I know works and need the new memory region layout. But
thinking about this, updating the memory region structure shouldn't be a
problem for the other boards either, of course I can't tell if IO+DDR
would work on them, but the new memory region layout shouldn't break
anything.
I can respin the series or do a followup series with modifications for
all boards if you like.
Best
Markus
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 289 bytes --]
^ permalink raw reply
* [PATCH v1 2/5] irqchip: starfive: Convert the word "jh8100" to "jhb100"
From: Changhuang Liang @ 2026-04-10 9:01 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner,
Philipp Zabel
Cc: linux-kernel, devicetree, linux-riscv, Ley Foon Tan,
Changhuang Liang
In-Reply-To: <20260410090106.622781-1-changhuang.liang@starfivetech.com>
The StarFive JH8100 SoC was discontinued before production. The
newly taped-out JHB100 SoC uses the same interrupt controller IP.
Rename the driver file, Kconfig symbol, and internal references
from "jh8100" to "jhb100" to accurately reflect the supported
hardware.
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
---
MAINTAINERS | 4 ++--
drivers/irqchip/Kconfig | 6 +++---
drivers/irqchip/Makefile | 2 +-
...arfive-jh8100-intc.c => irq-starfive-jhb100-intc.c} | 10 +++++-----
4 files changed, 11 insertions(+), 11 deletions(-)
rename drivers/irqchip/{irq-starfive-jh8100-intc.c => irq-starfive-jhb100-intc.c} (94%)
diff --git a/MAINTAINERS b/MAINTAINERS
index a2961727e3d1..93cbe852ac0b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25309,11 +25309,11 @@ F: Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
F: drivers/phy/starfive/phy-jh7110-pcie.c
F: drivers/phy/starfive/phy-jh7110-usb.c
-STARFIVE JH8100 EXTERNAL INTERRUPT CONTROLLER DRIVER
+STARFIVE JHB100 EXTERNAL INTERRUPT CONTROLLER DRIVER
M: Changhuang Liang <changhuang.liang@starfivetech.com>
S: Supported
F: Documentation/devicetree/bindings/interrupt-controller/starfive,jhb100-intc.yaml
-F: drivers/irqchip/irq-starfive-jh8100-intc.c
+F: drivers/irqchip/irq-starfive-jhb100-intc.c
STATIC BRANCH/CALL
M: Peter Zijlstra <peterz@infradead.org>
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index f07b00d7fef9..697c6b2e006c 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -651,13 +651,13 @@ config SIFIVE_PLIC
select IRQ_DOMAIN_HIERARCHY
select GENERIC_IRQ_EFFECTIVE_AFF_MASK if SMP
-config STARFIVE_JH8100_INTC
- bool "StarFive JH8100 External Interrupt Controller"
+config STARFIVE_JHB100_INTC
+ bool "StarFive JHB100 External Interrupt Controller"
depends on ARCH_STARFIVE || COMPILE_TEST
default ARCH_STARFIVE
select IRQ_DOMAIN_HIERARCHY
help
- This enables support for the INTC chip found in StarFive JH8100
+ This enables support for the INTC chip found in StarFive JHB100
SoC.
If you don't know what to do here, say Y.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 26aa3b6ec99f..c686caaa4451 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -108,7 +108,7 @@ obj-$(CONFIG_RISCV_APLIC_MSI) += irq-riscv-aplic-msi.o
obj-$(CONFIG_RISCV_IMSIC) += irq-riscv-imsic-state.o irq-riscv-imsic-early.o irq-riscv-imsic-platform.o
obj-$(CONFIG_RISCV_RPMI_SYSMSI) += irq-riscv-rpmi-sysmsi.o
obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o
-obj-$(CONFIG_STARFIVE_JH8100_INTC) += irq-starfive-jh8100-intc.o
+obj-$(CONFIG_STARFIVE_JHB100_INTC) += irq-starfive-jhb100-intc.o
obj-$(CONFIG_ACLINT_SSWI) += irq-aclint-sswi.o
obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o
obj-$(CONFIG_IMX_INTMUX) += irq-imx-intmux.o
diff --git a/drivers/irqchip/irq-starfive-jh8100-intc.c b/drivers/irqchip/irq-starfive-jhb100-intc.c
similarity index 94%
rename from drivers/irqchip/irq-starfive-jh8100-intc.c
rename to drivers/irqchip/irq-starfive-jhb100-intc.c
index bb62ef363d0b..2c9cdad7f377 100644
--- a/drivers/irqchip/irq-starfive-jh8100-intc.c
+++ b/drivers/irqchip/irq-starfive-jhb100-intc.c
@@ -1,13 +1,13 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * StarFive JH8100 External Interrupt Controller driver
+ * StarFive JHB100 External Interrupt Controller driver
*
* Copyright (C) 2023 StarFive Technology Co., Ltd.
*
* Author: Changhuang Liang <changhuang.liang@starfivetech.com>
*/
-#define pr_fmt(fmt) "irq-starfive-jh8100: " fmt
+#define pr_fmt(fmt) "irq-starfive-jhb100: " fmt
#include <linux/bitops.h>
#include <linux/clk.h>
@@ -71,7 +71,7 @@ static void starfive_intc_mask(struct irq_data *d)
}
static struct irq_chip intc_dev = {
- .name = "StarFive JH8100 INTC",
+ .name = "StarFive JHB100 INTC",
.irq_unmask = starfive_intc_unmask,
.irq_mask = starfive_intc_mask,
};
@@ -199,9 +199,9 @@ static int starfive_intc_probe(struct platform_device *pdev, struct device_node
}
IRQCHIP_PLATFORM_DRIVER_BEGIN(starfive_intc)
-IRQCHIP_MATCH("starfive,jh8100-intc", starfive_intc_probe)
+IRQCHIP_MATCH("starfive,jhb100-intc", starfive_intc_probe)
IRQCHIP_PLATFORM_DRIVER_END(starfive_intc)
-MODULE_DESCRIPTION("StarFive JH8100 External Interrupt Controller");
+MODULE_DESCRIPTION("StarFive JHB100 External Interrupt Controller");
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Changhuang Liang <changhuang.liang@starfivetech.com>");
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] arm64: dts: qcom: milos: Add IMEM node
From: Konrad Dybcio @ 2026-04-10 13:32 UTC (permalink / raw)
To: Luca Weiss, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260410-milos-imem-v3-2-d215385fa5ab@fairphone.com>
On 4/10/26 9:31 AM, Luca Weiss wrote:
> Add a node for the IMEM found on Milos, which contains pil-reloc-info
> and the modem tables for IPA, among others.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH] arm64: dts: qcom: hamoa: Add interconnects to primary USB3 controller
From: Konrad Dybcio @ 2026-04-10 13:32 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Add the interconnect paths to enable drivers to vote on them, ensuring
the necessary NoC bandwidth is available.
This hasn't been done before, as prior to commit 05566ebcc0cd
("clk: qcom: gcc-x1e80100: Keep GCC USB QTB clock always ON"), this
would cause an inexplicable crash upon resume from system suspend.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/hamoa.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 051dee076416..233c7ab4c52c 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -5318,6 +5318,13 @@ usb_1_ss0: usb@a600000 {
resets = <&gcc GCC_USB30_PRIM_BCR>;
+ interconnects = <&usb_south_anoc MASTER_USB3_0 QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_USB3_0 QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "usb-ddr",
+ "apps-usb";
+
wakeup-source;
iommus = <&apps_smmu 0x1420 0x0>;
---
base-commit: db7efce4ae23ad5e42f5f55428f529ff62b86fab
change-id: 20260410-topic-hamoa_usb_icc-7f8d5bbef94b
Best regards,
--
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v3 1/2] dt-bindings: sram: Document qcom,milos-imem
From: Rob Herring (Arm) @ 2026-04-10 13:27 UTC (permalink / raw)
To: Luca Weiss
Cc: Krzysztof Kozlowski, Konrad Dybcio, linux-arm-msm, linux-kernel,
Krzysztof Kozlowski, devicetree, phone-devel, Bjorn Andersson,
Conor Dooley, ~postmarketos/upstreaming
In-Reply-To: <20260410-milos-imem-v3-1-d215385fa5ab@fairphone.com>
On Fri, 10 Apr 2026 09:31:06 +0200, Luca Weiss wrote:
> Add compatible for Milos SoC IMEM.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> Documentation/devicetree/bindings/sram/sram.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2] dt-binding: leds: publish common bindings under dual license
From: Rob Herring @ 2026-04-10 13:22 UTC (permalink / raw)
To: Corvin Köhne
Cc: linux-kernel, open list:LED SUBSYSTEM, Pavel Machek,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Lee Jones, Krzysztof Kozlowski, Conor Dooley, Corvin Köhne,
Ashley Towns, Dan Murphy, Gergo Koteles, INAGAKI Hiroshi,
Jacek Anaszewski, Olliver Schinagl, Pavel Machek,
Rafał Miłecki, Roderick Colenbrander,
Krzysztof Kozlowski
In-Reply-To: <20260408062942.7128-1-corvin.koehne@gmail.com>
On Wed, Apr 08, 2026 at 08:29:42AM +0200, Corvin Köhne wrote:
> From: Corvin Köhne <c.koehne@beckhoff.com>
>
> Changes leds/common.h DT binding header file to be published under GPLv2
> or BSD-2-Clause license terms. This change allows this common LED
> bindings header file to be used in software components as bootloaders
> and OSes that are not published under GPLv2 terms.
>
> All contributors to leds/common.h file in copy.
>
> Cc: Ashley Towns <mail@ashleytowns.id.au>
I don't think a one line change is copyright-able work.
> Cc: Dan Murphy <dmurphy@ti.com>
Dan doesn't appear in git blame.
> Cc: Gergo Koteles <soyer@irl.hu>
Another oneliner.
> Cc: INAGAKI Hiroshi <musashino.open@gmail.com>
only 3 lines... Shrug
> Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> Cc: Olliver Schinagl <oliver@schinagl.nl>
Just adding more colors to the list.
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Rafał Miłecki <rafal@milecki.pl>
> Cc: Roderick Colenbrander <roderick@gaikai.com>
5 lines of basically the same thing.
So really, I think it is mainly Jacek's and Pavel's acks we need.
Rob
^ permalink raw reply
* Re: [PATCH v6 10/21] dt-bindings: display: renesas,rzg2l-du: Add support for RZ/G3E SoC
From: Tommaso Merciai @ 2026-04-10 13:21 UTC (permalink / raw)
To: Laurent Pinchart
Cc: tomm.merciai, geert, linux-renesas-soc, biju.das.jz,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Magnus Damm,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <20260409132420.GD2634584@killaraus.ideasonboard.com>
Hi Laurent,
On 4/9/26 15:24, Laurent Pinchart wrote:
> On Thu, Apr 09, 2026 at 01:15:18PM +0200, Tommaso Merciai wrote:
>> On 4/8/26 17:00, Laurent Pinchart wrote:
>>> On Wed, Apr 08, 2026 at 04:44:48PM +0200, Tommaso Merciai wrote:
>>>> On 4/8/26 16:16, Laurent Pinchart wrote:
>>>>> On Wed, Apr 08, 2026 at 04:02:14PM +0200, Tommaso Merciai wrote:
>>>>>> On 4/8/26 14:24, Laurent Pinchart wrote:
>>>>>>> On Wed, Apr 08, 2026 at 12:36:55PM +0200, Tommaso Merciai wrote:
>>>>>>>> The RZ/G3E SoC has 2 LCD controllers (LCDC), each containing a Frame
>>>>>>>> Compression Processor (FCPVD), a Video Signal Processor (VSPD), and a
>>>>>>>> Display Unit (DU).
>>>>>>>>
>>>>>>>> - LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
>>>>>>>> - LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
>>>>>>>>
>>>>>>>> Add a new SoC-specific compatible string 'renesas,r9a09g047-du'.
>>>>>>>>
>>>>>>>> Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" to
>>>>>>>> allow up to four output ports, and explicitly disable port@2 and port@3
>>>>>>>> for existing SoCs that do not expose them.
>>>>>>>>
>>>>>>>> Describe the four output ports of the RZ/G3E DU:
>>>>>>>>
>>>>>>>> - port@0: DSI (available on both LCDC instances)
>>>>>>>> - port@1: DPAD / parallel RGB (LCDC1 only)
>>>>>>>> - port@2: LVDS channel 0 (LCDC0 only)
>>>>>>>> - port@3: LVDS channel 1 (available on both LCDC instances)
>>>>>>>>
>>>>>>>> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
>>>>>>>> ---
>>>>>>>> v5->v6:
>>>>>>>> - Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" and
>>>>>>>> explicitly disable port@2 and port@3 for existing SoCs that do not expose
>>>>>>>> them.
>>>>>>>> - Reworked ports numbering + improved/fixed ports descriptions in the
>>>>>>>> bindings documentation.
>>>>>>>> - Improved commit body.
>>>>>>>>
>>>>>>>> v4->v5:
>>>>>>>> - Dropped renesas,id property and updated bindings
>>>>>>>> accordingly.
>>>>>>>>
>>>>>>>> v2->v3:
>>>>>>>> - No changes.
>>>>>>>>
>>>>>>>> v2->v3:
>>>>>>>> - No changes.
>>>>>>>>
>>>>>>>> v1->v2:
>>>>>>>> - Use single compatible string instead of multiple compatible strings
>>>>>>>> for the two DU instances, leveraging a 'renesas,id' property to
>>>>>>>> differentiate between DU0 and DU1.
>>>>>>>> - Updated commit message accordingly.
>>>>>>>>
>>>>>>>> .../bindings/display/renesas,rzg2l-du.yaml | 30 ++++++++++++++++++-
>>>>>>>> 1 file changed, 29 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
>>>>>>>> index 5add3b832eab..32da0b5ec88c 100644
>>>>>>>> --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
>>>>>>>> +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
>>>>>>>> @@ -20,6 +20,7 @@ properties:
>>>>>>>> - enum:
>>>>>>>> - renesas,r9a07g043u-du # RZ/G2UL
>>>>>>>> - renesas,r9a07g044-du # RZ/G2{L,LC}
>>>>>>>> + - renesas,r9a09g047-du # RZ/G3E
>>>>>>>> - renesas,r9a09g057-du # RZ/V2H(P)
>>>>>>>> - items:
>>>>>>>> - enum:
>>>>>>>> @@ -61,7 +62,7 @@ properties:
>>>>>>>> model-dependent. Each port shall have a single endpoint.
>>>>>>>>
>>>>>>>> patternProperties:
>>>>>>>> - "^port@[0-1]$":
>>>>>>>> + "^port@[0-3]$":
>>>>>>>> $ref: /schemas/graph.yaml#/properties/port
>>>>>>>> unevaluatedProperties: false
>>>>>>>>
>>>>>>>> @@ -103,6 +104,8 @@ allOf:
>>>>>>>> port@0:
>>>>>>>> description: DPI
>>>>>>>> port@1: false
>>>>>>>> + port@2: false
>>>>>>>> + port@3: false
>>>>>>>>
>>>>>>>> required:
>>>>>>>> - port@0
>>>>>>>> @@ -119,6 +122,8 @@ allOf:
>>>>>>>> description: DSI
>>>>>>>> port@1:
>>>>>>>> description: DPI
>>>>>>>> + port@2: false
>>>>>>>> + port@3: false
>>>>>>>>
>>>>>>>> required:
>>>>>>>> - port@0
>>>>>>>> @@ -135,9 +140,32 @@ allOf:
>>>>>>>> port@0:
>>>>>>>> description: DSI
>>>>>>>> port@1: false
>>>>>>>> + port@2: false
>>>>>>>> + port@3: false
>>>>>>>>
>>>>>>>> required:
>>>>>>>> - port@0
>>>>>>>> + - if:
>>>>>>>> + properties:
>>>>>>>> + compatible:
>>>>>>>> + contains:
>>>>>>>> + const: renesas,r9a09g047-du
>>>>>>>> + then:
>>>>>>>> + properties:
>>>>>>>> + ports:
>>>>>>>> + properties:
>>>>>>>> + port@0:
>>>>>>>> + description: DSI
>>>>>>>> + port@1:
>>>>>>>> + description: DPAD
>>>>>>>> + port@2:
>>>>>>>> + description: LVDS, Channel 0
>>>>>>>> + port@3:
>>>>>>>> + description: LVDS, Channel 1
>>>>>>>> +
>>>>>>>> + required:
>>>>>>>> + - port@0
>>>>>>>> + - port@3
>>>>>>>
>>>>>>> Why are ports 1 and 2 not required ?
>>>>>>
>>>>>> About this we had a similar discussion on v5[0]
>>>>>> We are using the same compatible and:
>>>>>>
>>>>>> - LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
>>>>>> |
>>>>>> --> then has:
>>>>>> port@0
>>>>>> port@2
>>>>>> port@3
>>>>>>
>>>>>>
>>>>>> - LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
>>>>>> |
>>>>>> --> then has:
>>>>>> port@0
>>>>>> port@1
>>>>>> port@3
>>>>>
>>>>> Ah yes, I forget there are two LCDC instances with different output
>>>>> configurations.
>>>>>
>>>>> Something still looks a bit weird to me though. For LCDC1, which
>>>>> supports a single LVDS channel, you use the port described as the second
>>>>> LVDS channel. Is there a reason not to use port@2 ?
>>>>
>>>> 9.11 Low Voltage Differential Signaling (LVDS)
>>>> 9.11.1.2 Block Diagram
>>>> Figure 9.11-1 shows a block diagram of LVDS.
>>>>
>>>> LCDC1 is connected to LVDS, Channel 1
>>>> For this reason I'm using port@3.
>>>
>>> Re-reading that, I think I've misinterpreted the hardware architecture.
>>> Doesn't the DU have a single output, that is connected the multiple
>>> encoders (LVDS and DSI for LCDC0 and LVDS, DSI and DPI for LCDC1) ? It
>>> seems modelling it with a single port and multiple endpoints would
>>> better match the device.
>>>
>>> For LVDS in particular, I see a single LVDS encoder with two channels,
>>> so there should not be two LVDS output ports in the DU. The two ports
>>> should be on the output of the LVDS device.
>>
>> You are suggesting the following dt architecture:
>>
>> du0: display@16460000 {
>> compatible = "renesas,r9a09g047-du";
>> reg = <0 0x16460000 0 0x10000>;
>> interrupts = <GIC_SPI 882 IRQ_TYPE_LEVEL_HIGH>;
>> clocks = <&cpg CPG_MOD 0xed>,
>> <&cpg CPG_MOD 0xee>,
>> <&cpg CPG_MOD 0xef>;
>> clock-names = "aclk", "pclk", "vclk";
>> power-domains = <&cpg>;
>> resets = <&cpg 0xdc>;
>> renesas,vsps = <&vspd0 0>;
>> status = "disabled";
>>
>> port {
>> du0_out_dsi: endpoint@0 {
>> reg = <0>;
>> };
>>
>> du0_out_lvds0: endpoint@2 {
>> reg = <2>;
>> };
>>
>> du0_out_lvds1: endpoint@3 {
>> reg = <3>;
>> };
>> }
>> };
>>
>> du1: display@16490000 {
>> compatible = "renesas,r9a09g047-du";
>> reg = <0 0x16490000 0 0x10000>;
>> interrupts = <GIC_SPI 922 IRQ_TYPE_LEVEL_HIGH>;
>> clocks = <&cpg CPG_MOD 0x1a8>,
>> <&cpg CPG_MOD 0x1a9>,
>> <&cpg CPG_MOD 0x1aa>;
>> clock-names = "aclk", "pclk", "vclk";
>> power-domains = <&cpg>;
>> resets = <&cpg 0x11e>;
>> renesas,vsps = <&vspd1 0>;
>> status = "disabled";
>>
>> port {
>> du1_out_dsi: endpoint@0 {
>> reg = <0>;
>> };
>>
>> du1_out_rgb: endpoint@1 {
>> reg = <1>;
>> };
>>
>> du1_out_lvds1: endpoint@3 {
>> reg = <3>;
>> };
>> }
>> };
>>
>>
>> Please correct me if I'm wrong.
>
> That's right. It would match the hardware, or at least my understanding
> of the hardware based on the documentation. As far as I can tell, each
> DU has a single 24-bit output port connected to multiple encoders.
Thanks for the clarification.
I want to make sure I understand the intended architecture correctly,
because I see a potential conflict between your feedback on the two patches.
For [1], you confirmed the two separate DU nodes (DU0 and DU1) with the
single-port/multi-endpoint model. That maps to two separate platform
devices, which means two separate DRM devices.
For [2], you suggested:
"you can have one DRM device that covers two LCDCs, with one CRTC each,
both connected to the same DSI encoder. Userspace then selects which
CRTC drives which connector."
Please correct me if I'm wrong but to me these two appear to be
incompatible. With two separate DRM devices,the DSI encoder and its
connector can only belong to one of them. Userspace cannot select
between CRTCs across two DRM devices.
To support the single-DRM-device model you describe, both DU0 and DU1
would need to be managed by a single driver instance, similar to R-Car
DU which aggregate multiple LCDC channels into one DRM device.
Using a single DRM device that spawn 2 crtc (1 du dt node ) this use
case can be tested with the following cmds:
modetest -M rzg2l-du -s 58@55:800x600-56.25@XR24
modetest -M rzg2l-du -s 58@56:800x600-56.25@XR24
Could you clarify which architecture is the intended direction?
Option A: Two separate DRM devices (2 DU dt nodes, current approach),
with the DSI input selected via DT configuration.
The dynamic vclk selection I implemented still applies,
but runtime CRTC switching from userspace is not possible.
Option B: A single DRM device aggregating both DU instances (1 DU dt node),
with two CRTCs both connected to the DSI encoder.
[1]
https://patchwork.kernel.org/project/linux-renesas-soc/patch/8f814f22ff62dcde6153260e2c8c29a5415c9a89.1775636898.git.tommaso.merciai.xr@bp.renesas.com/
[2]
https://patchwork.kernel.org/project/linux-renesas-soc/patch/9e0f64dd5e1efb0d27219416121c91a19da96ebd.1775636898.git.tommaso.merciai.xr@bp.renesas.com/
Kind Regards,
Tommaso
>
>>>>>> Then port@1 is required for DU1 but not for DU0.
>>>>>> Same port@2 is required for DU0 but not for DU1.
>>>>>>
>>>>>> [0] https://patchwork.kernel.org/project/linux-renesas-soc/patch/ca022fdbba5236c36e0cb3095db4c31e8e0cb1b8.1770996493.git.tommaso.merciai.xr@bp.renesas.com/
>>>>>>
>>>>>>>>
>>>>>>>> examples:
>>>>>>>> # RZ/G2L DU
>
^ permalink raw reply
* Re: [PATCH net-next v3 01/12] dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
From: Lorenzo Bianconi @ 2026-04-10 13:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, benjamin.larsson, linux-arm-kernel, linux-mediatek,
netdev, devicetree
In-Reply-To: <20260410025717.1809904-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]
> This is an AI-generated review of your patch. The human sending this
> email says "For your consideration."
> ---
> dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
>
> This commit introduces the ethernet-port property to model a net_device
> connected via an external arbiter to the GDM3 or GDM4 ports on EN7581
> and AN7583 SoCs.
>
> > diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> > index fbe2ddcdd909c..ebbd433e9c9fb 100644
> > --- a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> > +++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> > @@ -130,6 +130,30 @@ patternProperties:
> > maximum: 4
> > description: GMAC port identifier
> >
> > + '#address-cells':
> > + const: 1
> > + '#size-cells':
> > + const: 0
> > +
> > + patternProperties:
> > + "^ethernet-port@[0-5]$":
>
> The commit message states that GDM1 and GDM2 do not support connection
> with the external arbiter. However, since this pattern property appears to
> be placed inside the generic ^ethernet@[1-4]$ block, does this allow a
> device tree to incorrectly configure ethernet-port subnodes on ethernet@1
> or ethernet@2 and still pass schema validation?
ack, I will fix it in v4
>
> Could this be restricted to GDM3 and GDM4, perhaps by splitting the
> patternProperties or using an if/then block based on the reg property?
>
> > + type: object
> > + unevaluatedProperties: false
> > + $ref: ethernet-controller.yaml#
>
> Does referencing ethernet-controller.yaml cause a validation conflict here?
>
> The ethernet-controller.yaml schema enforces a strict nodename pattern
> of ^ethernet(@.*)?$. Since these new nodes use the -port suffix and are
> named ethernet-port@X, will they unconditionally fail the node name
> validation enforced by the referenced schema during dt_binding_check?
ack, I will fix it in v4
Regards,
Lorenzo
>
> [ ... ]
> --
> pw-bot: cr
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 02/12] net: airoha: Set PPE cpu port for GDM2 if loopback is enabled
From: Lorenzo Bianconi @ 2026-04-10 12:52 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, benjamin.larsson, linux-arm-kernel, linux-mediatek,
netdev, devicetree
In-Reply-To: <20260410025720.1809934-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3218 bytes --]
> This is an AI-generated review of your patch. The human sending this
> email says "For your consideration."
> ---
> net: airoha: Move airoha_qdma pointer in airoha_gdm_dev struct
>
> This commit moves the airoha_qdma pointer from the airoha_gdm_port struct
> to the airoha_gdm_dev struct. This ensures the QDMA block used depends on
> the specific net_device WAN/LAN configuration.
>
> [ ... ]
>
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
>
> [ ... ]
>
> > @@ -1497,9 +1498,10 @@ static void airoha_qdma_stop_napi(struct airoha_qdma *qdma)
> > }
> > }
> >
> > -static void airoha_update_hw_stats(struct airoha_gdm_port *port)
> > +static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
> > {
> > - struct airoha_eth *eth = port->qdma->eth;
> > + struct airoha_gdm_port *port = dev->port;
> > + struct airoha_eth *eth = dev->eth;
> > u32 val, i = 0;
> >
> > spin_lock(&port->stats.lock);
>
> This isn't a bug introduced by this patch, but does this spin_lock()
> carry a deadlock risk?
>
> Because ndo_get_stats64() can be called from atomic context (e.g., from a
> softirq), if a process context caller holds port->stats.lock and is
> interrupted by a softirq on the same CPU that also triggers dev_get_stats(),
> the softirq could spin forever waiting for the lock.
>
> Should this be upgraded to spin_lock_bh() to ensure local softirqs are
> disabled during the critical section?
I was not able to spot any point in the networking stack where
ndo_get_stats64 callback is run from a softirq. Moreover,
airoha_update_hw_stats() is never executed in any napi in airoha_eth
driver. It seems to me spin_lock() is enough here. Am I missing something?
>
> [ ... ]
>
> > --- a/drivers/net/ethernet/airoha/airoha_eth.h
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> > @@ -534,12 +534,12 @@ struct airoha_qdma {
> >
> > struct airoha_gdm_dev {
> > struct airoha_gdm_port *port;
> > + struct airoha_qdma *qdma;
> > struct net_device *dev;
> > struct airoha_eth *eth;
> > };
> >
> > struct airoha_gdm_port {
> > - struct airoha_qdma *qdma;
> > struct airoha_gdm_dev *dev;
> > int id;
>
> This isn't a bug introduced by this patch, but since the qdma pointer
> is being moved to better align with the hardware structure, should
> qos_sq_bmap, cpu_tx_packets, and fwd_tx_packets be moved to
> struct airoha_qdma as well?
>
> Because QDMA1 is shared by all WAN ports (GDM 2, 3, 4) and qos_sq_bmap
> is currently tracked per-port instead of per-QDMA, each WAN port
> independently allocates QDMA1 channels starting from index 0. Does this
> cause different ports to overwrite each other's hardware QoS configurations
> in the shared QDMA1 block?
>
> Furthermore, cpu_tx_packets and fwd_tx_packets cache per-channel ETS
> hardware counters but are single u64 scalar variables in the port structure.
> When querying stats for multiple channels, do these scalar caches get
> overwritten with values from completely different channels, resulting in
> incorrect delta calculations?
ack, I will fix it in v4.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox