* [PATCH v3 2/2] riscv: dts: spacemit: enable USB3 on OrangePi R2S
From: Chukun Pan @ 2026-04-10 10:00 UTC (permalink / raw)
To: Yixun Lan
Cc: Rob Herring, Paul Walmsley, Alexandre Ghiti, Albert Ou,
Palmer Dabbelt, Conor Dooley, Krzysztof Kozlowski, linux-riscv,
linux-kernel, devicetree, spacemit, Chukun Pan
In-Reply-To: <20260410100010.1197804-1-amadeus@jmu.edu.cn>
Enable the DWC3 USB3.0 controller and its associated PHY on the
OrangePi R2S. The USB regulator provides VBUS for USB2 and USB3
ports, but the USB2 ports are handled by a separate controller.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
.../boot/dts/spacemit/k1-orangepi-r2s.dts | 24 +++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
index 409a6db269ae..bc68721e6263 100644
--- a/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
@@ -40,6 +40,20 @@ vcc4v0: regulator-vcc4v0 {
regulator-max-microvolt = <4000000>;
vin-supply = <&vcc_5v0>;
};
+
+ vcc5v0_usb: regulator-vcc5v0-usb {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio K1_GPIO(126) GPIO_ACTIVE_HIGH>;
+ regulator-name = "vcc5v0_usb";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc_5v0>;
+ };
+};
+
+&combo_phy {
+ status = "okay";
};
&emmc {
@@ -109,3 +123,13 @@ &uart0 {
pinctrl-0 = <&uart0_2_cfg>;
status = "okay";
};
+
+&usbphy2 {
+ status = "okay";
+};
+
+&usb_dwc3 {
+ dr_mode = "host";
+ vbus-supply = <&vcc5v0_usb>;
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/2] riscv: dts: spacemit: add fixed regulators for OrangePi R2S
From: Chukun Pan @ 2026-04-10 10:00 UTC (permalink / raw)
To: Yixun Lan
Cc: Rob Herring, Paul Walmsley, Alexandre Ghiti, Albert Ou,
Palmer Dabbelt, Conor Dooley, Krzysztof Kozlowski, linux-riscv,
linux-kernel, devicetree, spacemit, Chukun Pan
In-Reply-To: <20260410100010.1197804-1-amadeus@jmu.edu.cn>
Define the power input and the 4V power as fixed regulator supplies.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
.../boot/dts/spacemit/k1-orangepi-r2s.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
index de75f6aac740..409a6db269ae 100644
--- a/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
@@ -21,6 +21,25 @@ aliases {
chosen {
stdout-path = "serial0";
};
+
+ vcc_5v0: regulator-vcc-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_5v0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ vcc4v0: regulator-vcc4v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc4v0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <4000000>;
+ regulator-max-microvolt = <4000000>;
+ vin-supply = <&vcc_5v0>;
+ };
};
&emmc {
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/3] riscv: dts: spacemit: enable USB3 on OrangePi
From: Chukun Pan @ 2026-04-10 10:00 UTC (permalink / raw)
To: Yixun Lan
Cc: Rob Herring, Paul Walmsley, Alexandre Ghiti, Albert Ou,
Palmer Dabbelt, Conor Dooley, Krzysztof Kozlowski, linux-riscv,
linux-kernel, devicetree, spacemit, Chukun Pan
Changes in v3:
- Drop OrangePi RV2 part to avoid conflicts
- Link to v2: https://lore.kernel.org/lkml/20260402100007.110201-1-amadeus@jmu.edu.cn/
Changes in v2:
- Drop common board dtsi and PCIe regulator
- Enable USB3 on OrangePi R2S and RV2 boards
- Link to v1: https://lore.kernel.org/lkml/20260116100001.208334-2-amadeus@jmu.edu.cn/
The schematic of OrangePi RV2 is available at:
https://drive.google.com/drive/folders/1pcI_U0C3VJKTCg8A1zj08CwNbohnONSR
Chukun Pan (2):
riscv: dts: spacemit: add fixed regulators for OrangePi R2S
riscv: dts: spacemit: enable USB3 on OrangePi R2S
.../boot/dts/spacemit/k1-orangepi-r2s.dts | 43 +++++++++++++++++++
1 file changed, 43 insertions(+)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Krzysztof Kozlowski @ 2026-04-10 9:57 UTC (permalink / raw)
To: Akhil R
Cc: Frank.Li, acpica-devel, alexandre.belloni, conor+dt, devicetree,
ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon, linux-i3c,
linux-kernel, linux, miquel.raynal, p.zabel, rafael, robh,
sakari.ailus, wsa+renesas
In-Reply-To: <20260410083710.54993-1-akhilrajeev@nvidia.com>
On 10/04/2026 10:37, Akhil R wrote:
> On Fri, 10 Apr 2026 09:18:48 +0200, Krzysztof Kozlowski wrote:
>> On 10/04/2026 08:57, Guenter Roeck wrote:
>>> On 4/9/26 23:39, Krzysztof Kozlowski wrote:
>>>> On 09/04/2026 12:57, Akhil R wrote:
>>>>> Add I3C subsystem support, DesignWare I3C master controller, and
>>>>> SPD5118 hwmon sensor as modules to the defconfig and therefore
>>>>> enable the support for SPD5118 sensor on SOCAMM found in NVIDIA
>>>>> Vera platforms.
>>>>
>>>> git grep for "Vera" gave me zero results. Are you sure this is an
>>>> upstream platform? Please point the DTS using this.
>>>>
>>>
>>> I think this is an ACPI based system, or at least that is what Google search
>>> tells me.
>>
>> Thanks. Following Google Vera is either a "CPU" or entire architecture
>> (at least that's how they call it), so it does not have SPD5118 sensor.
>
> SOCAMM is a Memory Module. SPD5118, as it's Kconfig mentions, is a sensor
> found within such memory modules. I didn't quite get why would you state
> that the SOCAMM present in Vera architecture (or CPU) does not have
> SPD5118 in it.
I said that CPU or entire architecture does not have it.
Commit is pretty vague in helping me to figure out the things I asked
for in last email.
>
> Pasting the below from the Vera Rubin product page [1] -
> "NVIDIA Vera CPUs add enhanced serviceability with small-outline
> compression-attached memory modules (SOCAMM) LPDDR5X and in-system tests
> for the CPU cores."
>
> [1]: https://www.nvidia.com/en-us/data-center/technologies/rubin/
So this is for Vera Rubin? For what is this exactly?
>
>>
>>
>> "Nvidia vera socamm" gives me something about "rubin". It's not me who
>> should be guessing all this.
>>
>> "nvidia vera socamm SPD5118" gives me even less, so justification is flaky.
>>
>> To remind, this commit msg should convince why generic kernel for
>> developers affecting all possible platforms - not end users, because
>> they always use distro kernels - should enable these configs. And it
>> should bring me clear rule what I can or cannot remove from defconfig,
>> if in 2 years I come and start pruning it from symbols.
>
> I found little details on what we should be adding in the defconfig. It
Then maybe we should not be adding it to defconfig?
We usually do not make changes which we do not know why we are making
them. IOW, every commit must be useful for the community and this is
achieved by either explicit or implicit answer why doing this.
And I gave in the past clear guidelines - this is config for the
upstream kernel developers to use the upstream hardware and/or for
distros to understand what is needed to support that upstream hardware
(although last part in theory, because many distros do variantion of
allmodconfig, so they don't really care about our defconfig).
> would help if you could share some guidance. Do you mean to say that the
> defconfig should include only the configs which are necessary in
> development platforms and not in end-products?
No, the type of product does not matter because upstream supports every
type of product. Upstream does not say "oh, you run end-product, so we
don't care about you". But defconfig is not used by endusers and has
zero meaning to them.
It seems to missed or ignored one more reason I wrote:
>> And it
>> should bring me clear rule what I can or cannot remove from defconfig,
>> if in 2 years I come and start pruning it from symbols.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 3/5] irqchip: starfive: Use devm_ interfaces to simplify resource release
From: Changhuang Liang @ 2026-04-10 9:53 UTC (permalink / raw)
To: Philipp Zabel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thomas Gleixner
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-riscv@lists.infradead.org, Leyfoon Tan
In-Reply-To: <631d4d65fdbda29cfbc0b96987b5f56fcd5116ea.camel@pengutronix.de>
Hi, Philipp,
Thanks for the review.
> On Fr, 2026-04-10 at 02:01 -0700, Changhuang Liang wrote:
> > Use devm_ interfaces to simplify resource release. Make clock and
> > reset get optional as they are not used on the JHB100 SoC. Replace pr_
> > logging with dev_* logging.
> >
> > Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> > ---
> > drivers/irqchip/irq-starfive-jhb100-intc.c | 44
> > ++++++++--------------
> > 1 file changed, 15 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/irqchip/irq-starfive-jhb100-intc.c
> > b/drivers/irqchip/irq-starfive-jhb100-intc.c
> > index 2c9cdad7f377..312a4634870a 100644
> > --- a/drivers/irqchip/irq-starfive-jhb100-intc.c
> > +++ b/drivers/irqchip/irq-starfive-jhb100-intc.c
> [...]
> > @@ -127,48 +125,44 @@ static int starfive_intc_probe(struct
> platform_device *pdev, struct device_node
> > if (!irqc)
> > return -ENOMEM;
> >
> > - 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;
> > }
> >
> > - rst = of_reset_control_get_exclusive(intc, NULL);
> > + rst = devm_reset_control_get_optional(&pdev->dev, NULL);
>
> Please use devm_reset_control_get_optional_exclusive() directly.
Thank you for the reminder. I found that I can use devm_reset_control_get_optional_exclusive_deasserted
to simplify the code in next version.
> > if (IS_ERR(rst)) {
> > - pr_err("Unable to get reset control %pe\n", rst);
> > + dev_err(&pdev->dev, "Unable to get reset control %pe\n", rst);
>
> Consider using dev_err_probe() to stop printing -EPROBE_DEFER.
>
Best Regards,
Changhunag
^ permalink raw reply
* Re: [PATCH 7/7] clk: sunxi-ng: Add Allwinner A733 RTC CCU support
From: Junhui Liu @ 2026-04-10 9:49 UTC (permalink / raw)
To: wens, Junhui Liu
Cc: Michael Turquette, Stephen Boyd, Jernej Skrabec, Samuel Holland,
Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard, linux-clk, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-rtc, devicetree, André Przywara
In-Reply-To: <CAGb2v64euL+QNXiJdTn0JygYLXg0WoguPSprKT4sKGZGVZbwug@mail.gmail.com>
On Sat Mar 28, 2026 at 10:41 PM CST, Chen-Yu Tsai wrote:
> On Wed, Jan 21, 2026 at 7:04 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
>>
>> Add support for the internal CCU found in the RTC module of the Allwinner
>> A733 SoC. While the basic 16MHz (IOSC) and 32kHz logic remains compatible
>> with older SoCs like the sun6i, the A733 introduces several new features.
>>
>> The A733 RTC CCU supports choosing one of three external crystal
>> frequencies: 19.2MHz, 24MHz, and 26MHz. It features hardware detection
>> logic to automatically identify the frequency used on the board and
>> exports this DCXO signal as the "hosc" clock.
>>
>> Furthermore, the driver implements logic to derive a 32kHz reference
>> from the HOSC. This is achieved through a muxed clock path using fixed
>> pre-dividers to normalize the different crystal frequencies to ~32kHz.
>
> Have you tested whether the actually normalizes the frequency, i.e.
> selects a different divider based on the DCXO frequency? Otherwise
> we're just lying about the frequency.
I only have A733 boards with 26MHz crystals, so I couldn't test all
crystal configurations. However, I exported the "hosc_32k" clock
(referred to as dcxo24M_div32k_clk in the vendor driver) to a physical
pin via the fanout path and measured it with the oscilloscope.
Observations:
- Normal conditions: The frequency remains stable within the 32.744 kHz
to 32.791 kHz range.
- Forced condition: I grounded the R24 resistor on radxa A7A board to
trick the SoC into detecting a 24MHz crystal while the actual input
remained 26MHz. In this case, the frequency became unstable but still
stayed around the 32.2 kHz to 33.3 kHz range.
Based on these results, it appears the hardware does attempt to
normalize the frequency towards 32.768 kHz via some internal logic.
>
>> This path reuses the same hardware mux registers as the HOSC clock.
>>
>> Additionally, this CCU provides several gate clocks for specific
>> peripherals, including SerDes, HDMI, and UFS. The driver is implemented
>> as an auxiliary driver to be bound to the sun6i-rtc driver.
>>
>> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
>> ---
>> drivers/clk/sunxi-ng/Kconfig | 5 +
>> drivers/clk/sunxi-ng/Makefile | 2 +
>> drivers/clk/sunxi-ng/ccu-sun60i-a733-rtc.c | 204 +++++++++++++++++++++++++++++
>> drivers/clk/sunxi-ng/ccu-sun60i-a733-rtc.h | 18 +++
>> drivers/clk/sunxi-ng/ccu_rtc.h | 7 +
>> 5 files changed, 236 insertions(+)
>>
[...]
>> +
>> +static const struct clk_parent_data hosc_parents[] = {
>> + { .fw_name = "osc24M" },
>> + { .fw_name = "osc19M" },
>> + { .fw_name = "osc26M" },
>> + { .fw_name = "osc24M" },
>> +};
>
> As mentioned in my reply to the binding, this is wrong. There is only
> one input.
>
> The most you can do is check the rate of the parent clock against the
> detected one, and _scream_ that the DT is wrong. And maybe override
> the reported frequency.
I will add a warning message if the frequency detected by the driver
does not match the one in the DT.
>
> If you want to do the latter, you could add a new fixed rate gated
> clock type to our library. You would fill in the rate before the
> clocks get registered. I probably wouldn't go that far. We want people
> to have correct hardware descriptions.
>
> Funnily enough Allwinner's BSP actually implements a fixed rate gate
> for the next 24M-to-32k divider clock.
Yes, I noticed that as well. I agree, and I will model this path as a
simple fixed-rate clock (32768Hz) in v2.
>
>> +
>> +struct ccu_mux hosc_clk = {
>> + .enable = DCXO_CTRL_DCXO_EN,
>> + .mux = _SUNXI_CCU_MUX(14, 2),
>> + .common = {
>> + .reg = DCXO_CTRL_REG,
>> + .hw.init = CLK_HW_INIT_PARENTS_DATA("hosc",
>> + hosc_parents,
>> + &ccu_mux_ro_ops,
>> + 0),
>> + },
>> +};
>
> So this is wrong.
>
>> +
>> +static const struct ccu_mux_fixed_prediv hosc_32k_predivs[] = {
>> + { .index = 0, .div = 732 },
>
> Why is it 732 instead of 750?
As mentioned above, the target frequency is 32.768kHz rather than
32.0kHz. However, since I will drop this prediv array and use a
fixed-rate clock instead, I think this will no longer be an issue.
--
Best regards,
Junhui Liu
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: qcom: x1e80100-microsoft-romulus: add PM8010 camera regulators
From: Konrad Dybcio @ 2026-04-10 9:49 UTC (permalink / raw)
To: Oliver White, andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: bod, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260409201717.108169-2-oliverjwhite07@gmail.com>
On 4/9/26 10:17 PM, Oliver White wrote:
> Add the PM8010 regulator outputs used by the front-facing OV02C10
> camera module on Microsoft Romulus.
>
> These rails provide the supplies referenced by the camera enablement patch.
>
> Signed-off-by: Oliver White <oliverjwhite07@gmail.com>
> ---
FWIW the regulator config is a little different, at least on my device
that reports (in device manager -> cameras -> details -> hardware IDs
or similar) to have
MSHW0470 FRONT_RGB (OV02...)
MSHW0472 FRONT_IR (ID SMO55F0, it's likely a STMicro VD55G0)
All voltages are flat, no ranges
LDO1 (RGB) 1.2 V
LDO2 (IR) 1.2 V
LDO3 (RGB) 1.8 V
LDO4 (IR) 1.8 V
LDO5 (RGB) 2.8 V
LDO6 (IR) 1.8 V
LDO7 remains unused, and would be only used with an IR sensor that's
MSHW0492 or MSHW0562
Konrad
^ permalink raw reply
* RE: [PATCH v2 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Yu-Chun Lin [林祐君] @ 2026-04-10 9:39 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰], linusw@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
afaerber@suse.com, TY_Chang[張子逸]
In-Reply-To: <CAMRc=MfUh_OuxS4SC6QzSOg_PMNc9i9crGYgBASrbVUgHDHSCw@mail.gmail.com>
Hi Bart,
> On Wed, 8 Apr 2026 04:52:42 +0200, Yu-Chun Lin <eleanor.lin@realtek.com>
> said:
> > From: Tzuyi Chang <tychang@realtek.com>
> >
> > Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
> >
> > Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
> > which manages pins via shared bank registers, the RTD1625 introduces a
> > per-pin register architecture. Each GPIO line now has its own
> > dedicated 32-bit control register to manage configuration
> > independently, including direction, output value, input value,
> > interrupt enable, and debounce. Therefore, this distinct hardware
> > design requires a separate driver.
> >
> > Reviewed-by: Linus Walleij <linusw@kernel.org>
> > Signed-off-by: Tzuyi Chang <tychang@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v2:
> > - Remove "default y".
> > - Add base_offset member to struct rtd1625_gpio_info to handle merged
> regions.
> > ---
> > drivers/gpio/Kconfig | 11 +
> > drivers/gpio/Makefile | 1 +
> > drivers/gpio/gpio-rtd1625.c | 584
> > ++++++++++++++++++++++++++++++++++++
> > 3 files changed, 596 insertions(+)
> > create mode 100644 drivers/gpio/gpio-rtd1625.c
> >
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index
> > 5ee11a889867..281549ad72ac 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -638,6 +638,17 @@ config GPIO_RTD
> > Say yes here to support GPIO functionality and GPIO interrupt on
> > Realtek DHC SoCs.
> >
> > +config GPIO_RTD1625
> > + tristate "Realtek DHC RTD1625 GPIO support"
> > + depends on ARCH_REALTEK || COMPILE_TEST
> > + select GPIOLIB_IRQCHIP
> > + help
> > + This option enables support for the GPIO controller on Realtek
> > + DHC (Digital Home Center) RTD1625 SoC.
> > +
> > + Say yes here to support both basic GPIO line functionality
> > + and GPIO interrupt handling capabilities for this platform.
> > +
> > config GPIO_SAMA5D2_PIOBU
> > tristate "SAMA5D2 PIOBU GPIO support"
> > depends on MFD_SYSCON
> > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index
> > c05f7d795c43..c95ba218d53a 100644
> > --- a/drivers/gpio/Makefile
> > +++ b/drivers/gpio/Makefile
> > @@ -159,6 +159,7 @@ obj-$(CONFIG_GPIO_REALTEK_OTTO)
> += gpio-realtek-otto.o
> > obj-$(CONFIG_GPIO_REG) += gpio-reg.o
> > obj-$(CONFIG_GPIO_ROCKCHIP) += gpio-rockchip.o
> > obj-$(CONFIG_GPIO_RTD) += gpio-rtd.o
> > +obj-$(CONFIG_GPIO_RTD1625) += gpio-rtd1625.o
> > obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
> > obj-$(CONFIG_GPIO_SAMA5D2_PIOBU) += gpio-sama5d2-piobu.o
> > obj-$(CONFIG_GPIO_SCH311X) += gpio-sch311x.o
> > diff --git a/drivers/gpio/gpio-rtd1625.c b/drivers/gpio/gpio-rtd1625.c
> > new file mode 100644 index 000000000000..bcc1bbb115fa
> > --- /dev/null
> > +++ b/drivers/gpio/gpio-rtd1625.c
> > @@ -0,0 +1,584 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Realtek DHC RTD1625 gpio driver
> > + *
> > + * Copyright (c) 2023 Realtek Semiconductor Corp.
>
> No modifications since 2023?
>
Will include 2026.
> > + */
> > +
> > +#include <linux/bitfield.h>
> > +#include <linux/bitops.h>
> > +#include <linux/gpio/driver.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/irqchip.h>
> > +#include <linux/irqchip/chained_irq.h> #include <linux/irqdomain.h>
> > +#include <linux/module.h> #include <linux/platform_device.h> #include
> > +<linux/property.h> #include <linux/spinlock.h> #include
> > +<linux/types.h>
> > +
> > +#define RTD1625_GPIO_DIR BIT(0)
> > +#define RTD1625_GPIO_OUT BIT(2)
> > +#define RTD1625_GPIO_IN BIT(4)
> > +#define RTD1625_GPIO_EDGE_INT_DP BIT(6) #define
> > +RTD1625_GPIO_EDGE_INT_EN BIT(8) #define
> RTD1625_GPIO_LEVEL_INT_EN
> > +BIT(16) #define RTD1625_GPIO_LEVEL_INT_DP BIT(18) #define
> > +RTD1625_GPIO_DEBOUNCE GENMASK(30, 28) #define
> > +RTD1625_GPIO_DEBOUNCE_WREN BIT(31)
> > +
> > +#define RTD1625_GPIO_WREN(x) ((x) << 1)
> > +
> > +/* Write-enable masks for all GPIO configs and reserved hardware bits
> > +*/ #define RTD1625_ISO_GPIO_WREN_ALL 0x8000aa8a #define
> > +RTD1625_ISOM_GPIO_WREN_ALL 0x800aaa8a
> > +
> > +#define RTD1625_GPIO_DEBOUNCE_1US 0
> > +#define RTD1625_GPIO_DEBOUNCE_10US 1
> > +#define RTD1625_GPIO_DEBOUNCE_100US 2 #define
> > +RTD1625_GPIO_DEBOUNCE_1MS 3 #define
> RTD1625_GPIO_DEBOUNCE_10MS 4
> > +#define RTD1625_GPIO_DEBOUNCE_20MS 5 #define
> > +RTD1625_GPIO_DEBOUNCE_30MS 6 #define
> RTD1625_GPIO_DEBOUNCE_50MS 7
> > +
> > +#define GPIO_CONTROL(gpio) ((gpio) * 4)
> > +
> > +/**
> > + * struct rtd1625_gpio_info - Specific GPIO register information
> > + * @num_gpios: The number of GPIOs
> > + * @irq_type_support: Supported IRQ types
> > + * @gpa_offset: Offset for GPIO assert interrupt status registers
> > + * @gpda_offset: Offset for GPIO deassert interrupt status registers
> > + * @level_offset: Offset of level interrupt status register
> > + * @write_en_all: Write-enable mask for all configurable bits */
> > +struct rtd1625_gpio_info {
> > + unsigned int num_gpios;
> > + unsigned int irq_type_support;
> > + unsigned int base_offset;
> > + unsigned int gpa_offset;
> > + unsigned int gpda_offset;
> > + unsigned int level_offset;
> > + unsigned int write_en_all;
> > +};
>
> Please remove the tabs in the above struct.
>
Ack.
> > +
> > +struct rtd1625_gpio {
> > + struct gpio_chip gpio_chip;
> > + const struct rtd1625_gpio_info *info;
> > + void __iomem *base;
> > + void __iomem *irq_base;
> > + unsigned int irqs[3];
> > + raw_spinlock_t lock;
> > + unsigned int *save_regs;
> > +};
>
> I'd also personally remove these tabs here but won't die on that hill.
>
Ack.
> > +
> > +static unsigned int rtd1625_gpio_gpa_offset(struct rtd1625_gpio
> > +*data, unsigned int offset) {
> > + return data->info->gpa_offset + ((offset / 32) * 4); }
> > +
> > +static unsigned int rtd1625_gpio_gpda_offset(struct rtd1625_gpio
> > +*data, unsigned int offset) {
> > + return data->info->gpda_offset + ((offset / 32) * 4); }
> > +
> > +static unsigned int rtd1625_gpio_level_offset(struct rtd1625_gpio
> > +*data, unsigned int offset) {
> > + return data->info->level_offset + ((offset / 32) * 4); }
>
> Looking at these, I'm under the impression that this driver could quite easily be
> converted to using gpio-mmio or even gpio-regmap with an MMIO regmap,
> have you looked into it by any chance?
>
> Bart
We did look into gpio-mmio and gpio-regmap, but they are not quite suitable for
our platform due to the specific hardware design:
1. Per-GPIO Dedicated Registers: Unlike typical GPIO controllers that pack 32 pins
into a single 32-bit register (1 bit per pin), our hardware uses a dedicated 32-bit
register for each individual GPIO. This single register controls the
input/output state, direction, and interrupt trigger type for that specific pin.
2. Write-Enable (WREN) Mask Mechanism: Our hardware requires a specific Write-Enable
mask to be written simultaneously when updating the register values.
3. Hardware Debounce: We also need to support hardware debounce settings per pin,
which requires custom configuration via set_config mapped to these specific per-pin
registers.
Because of these hardware constraints, manually implementing the gpio_chip callbacks
seems to be the most straightforward
Best Regards,
Yu-Chun
^ permalink raw reply
* [PATCH v1 0/5] Add interrupt controller for JHB100 SoC
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
This patchset adds external interrupt controller driver for the StarFive
JHB100 SoC. It supports up to 64 interrupt sources, and both level and
edge trigger types.
Changhuang Liang (4):
dt-bindings: interrupt-controller: Convert the word "jh8100" to
"jhb100"
irqchip: starfive: Convert the word "jh8100" to "jhb100"
irqchip: starfive: Use devm_ interfaces to simplify resource release
irqchip: starfive: Implement irq_set_type and irq_ack hooks
Mason Huo (1):
irqchip: starfive: Increase the interrupt source number up to 64
...00-intc.yaml => starfive,jhb100-intc.yaml} | 12 +-
MAINTAINERS | 6 +-
drivers/irqchip/Kconfig | 6 +-
drivers/irqchip/Makefile | 2 +-
drivers/irqchip/irq-starfive-jh8100-intc.c | 207 -------------
drivers/irqchip/irq-starfive-jhb100-intc.c | 278 ++++++++++++++++++
6 files changed, 289 insertions(+), 222 deletions(-)
rename Documentation/devicetree/bindings/interrupt-controller/{starfive,jh8100-intc.yaml => starfive,jhb100-intc.yaml} (81%)
delete mode 100644 drivers/irqchip/irq-starfive-jh8100-intc.c
create mode 100644 drivers/irqchip/irq-starfive-jhb100-intc.c
--
2.25.1
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: perf: marvell: Add CN20K DDR PMU binding
From: Geethasowjanya Akula @ 2026-04-10 9:28 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
mark.rutland@arm.com, will@kernel.org, krzk+dt@kernel.org
In-Reply-To: <20260408-fancy-slick-locust-ff68fe@quoll>
>-----Original Message-----
>From: Krzysztof Kozlowski <krzk@kernel.org>
>Sent: Wednesday, April 8, 2026 12:39 PM
>To: Geethasowjanya Akula <gakula@marvell.com>
>Cc: linux-perf-users@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
>kernel@lists.infradead.org; devicetree@vger.kernel.org;
>mark.rutland@arm.com; will@kernel.org; krzk+dt@kernel.org
>Subject: [EXTERNAL] Re: [PATCH v4 1/2] dt-bindings: perf: marvell: Add CN20K
>DDR PMU binding
>On Tue, Apr 07, 2026 at 09:05:10PM +0530, Geetha sowjanya wrote:
>> Marvell CN20K SoCs integrate a DDR Performance Monitoring Unit (PMU)
>> associated with the DDR controller. The block provides hardware
>> counters to monitor DDR traffic and performance events and is accessed
>> via a dedicated MMIO region.
>>
>> The CN20K DDR PMU is functionally equivalent to the CN10K DDR PMU,
>> with minor register offset differences. This binding documents the
>> CN20K variant and introduces a specific compatible string to allow
>> software to distinguish between the two implementations.
>
>Drop last sentence, I already asked for that.
will drop the last sentence as requested in the next revision.
>
>>
>> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
>> ---
>> .../bindings/perf/marvell-cn20k-ddr-pmu.yaml | 39
>> +++++++++++++++++++
>
>Still wrong filename.
Sorry for the confusion. The intended filename is: marvell,cn20k-ddr-pmu.yaml
>
>Best regards,
>Krzysztof
^ permalink raw reply
* Re: [PATCH v1 3/5] irqchip: starfive: Use devm_ interfaces to simplify resource release
From: Philipp Zabel @ 2026-04-10 9:27 UTC (permalink / raw)
To: Changhuang Liang, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thomas Gleixner
Cc: linux-kernel, devicetree, linux-riscv, Ley Foon Tan
In-Reply-To: <20260410090106.622781-4-changhuang.liang@starfivetech.com>
On Fr, 2026-04-10 at 02:01 -0700, Changhuang Liang wrote:
> Use devm_ interfaces to simplify resource release. Make clock and reset
> get optional as they are not used on the JHB100 SoC. Replace pr_ logging
> with dev_* logging.
>
> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> ---
> drivers/irqchip/irq-starfive-jhb100-intc.c | 44 ++++++++--------------
> 1 file changed, 15 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/irqchip/irq-starfive-jhb100-intc.c b/drivers/irqchip/irq-starfive-jhb100-intc.c
> index 2c9cdad7f377..312a4634870a 100644
> --- a/drivers/irqchip/irq-starfive-jhb100-intc.c
> +++ b/drivers/irqchip/irq-starfive-jhb100-intc.c
[...]
> @@ -127,48 +125,44 @@ static int starfive_intc_probe(struct platform_device *pdev, struct device_node
> if (!irqc)
> return -ENOMEM;
>
> - 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;
> }
>
> - rst = of_reset_control_get_exclusive(intc, NULL);
> + rst = devm_reset_control_get_optional(&pdev->dev, NULL);
Please use devm_reset_control_get_optional_exclusive() directly.
> if (IS_ERR(rst)) {
> - pr_err("Unable to get reset control %pe\n", rst);
> + dev_err(&pdev->dev, "Unable to get reset control %pe\n", rst);
Consider using dev_err_probe() to stop printing -EPROBE_DEFER.
regards
Philipp
^ permalink raw reply
* Re: [PATCH v2 8/8] arm64: dts: qcom: eliza: Add support for MM clock controllers
From: Taniya Das @ 2026-04-10 9:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Ajit Pandey, Imran Shaik, Jagadeesh Kona,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20260410-ludicrous-rousing-pudu-dbe5be@quoll>
On 4/10/2026 1:14 PM, Krzysztof Kozlowski wrote:
> On Thu, Apr 09, 2026 at 11:40:49PM +0530, Taniya Das wrote:
>> Add the device nodes for the multimedia clock controllers (cambistmclkcc,
>> camcc, videocc, gpucc) for Qualcomm Eliza SoC.
>>
>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/eliza.dtsi | 54 +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 54 insertions(+)
>
> Note that this patch and drivers parches were likely not tested.
>
> Please mark patches you wish others to test as RFT.
>
Krzysztof, please find the logs, if you need the clk_summary I can add
those as well.
/ # dmesg
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd801]
[ 0.000000] Linux version
7.0.0-rc7-next-20260408-00008-g476992104d28-dirty ()
(aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld
(GNU Binutils for Ubuntu) 2.38) #19 SMP PREEMPT Thu Apr 9 16:46:11
+0530 2026
[ 0.000000] KASLR enabled
[ 0.000000] random: crng init done
[ 0.000000] Machine model: Qualcomm Technologies, Inc. Eliza MTP
[ 0.000000] printk: debug: ignoring loglevel setting.
[ 0.000000] efi: UEFI not found.
[ 0.000000] earlycon: qcom_geni0 at MMIO 0x0000000000894000 (options
'115200n8')
[ 0.000000] printk: legacy bootconsole [qcom_geni0] enabled
[ 0.000000] OF: reserved mem: 0x0000000080000000..0x0000000080dfffff
(14336 KiB) nomap non-reusable gunyah-hyp@80000000
[ 0.000000] OF: reserved mem: 0x0000000080e00000..0x0000000080e3ffff
(256 KiB) nomap non-reusable cpusys-vm-mem@80e00000
[ 0.000000] OF: reserved mem: 0x0000000081200000..0x00000000813fffff
(2048 KiB) nomap non-reusable cpucp@81200000
[ 0.000000] OF: reserved mem: 0x0000000081a00000..0x0000000081a3ffff
(256 KiB) nomap non-reusable xbl-dtlog@81a00000
[ 0.000000] OF: reserved mem: 0x0000000081c00000..0x0000000081c5ffff
(384 KiB) nomap non-reusable aop-image@81c00000
[ 0.000000] OF: reserved mem: 0x0000000081c60000..0x0000000081c7ffff
(128 KiB) nomap non-reusable aop-cmd-db@81c60000
[ 0.000000] OF: reserved mem: 0x0000000081c80000..0x0000000081cf3fff
(464 KiB) nomap non-reusable aop-tme-uefi-merged@81c80000
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: rtc: sun6i: Add Allwinner A733 support
From: Junhui Liu @ 2026-04-10 9:18 UTC (permalink / raw)
To: wens, Junhui Liu
Cc: Michael Turquette, Stephen Boyd, Jernej Skrabec, Samuel Holland,
Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard, linux-clk, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-rtc, devicetree
In-Reply-To: <CAGb2v67844OPwE6VJ0PAs5LsmCa2h0FvXOBUomZ50dM5tZ0Zow@mail.gmail.com>
Hi ChenYu,
Thanks for your patient review.
On Sat Mar 28, 2026 at 8:37 PM CST, Chen-Yu Tsai wrote:
> On Wed, Jan 21, 2026 at 7:03 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
>>
>> The RTC module in the Allwinner A733 SoC is functionally compatible with
>> the sun6i RTC, but its internal Clock Control Unit (CCU) has significant
>> changes.
>>
>> The A733 supports selecting the oscillator between three frequencies:
>> 19.2MHz, 24MHz, and 26MHz. The RTC CCU relies on hardware to detect
>> which frequency is actually used on the board. By defining all three
>> frequencies as fixed-clocks in the device tree, the driver can identify
>> the hardware-detected frequency and expose it to the rest of the system.
>
> No. The board device tree shall have the exact and correct frequency
> defined in the external crystal device node. The operating system can
> use the hardware-detected frequency to "fix" the in-system representation
> if it is off.
Okay, I will keep only one main external crystal in the device tree.
>
>> Additionally, the A733 RTC CCU provides several new DCXO gate clocks for
>> specific modules, including SerDes, HDMI, and UFS.
>>
>> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
>> ---
>> .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 38 ++++++++++++++++++++--
>> include/dt-bindings/clock/sun60i-a733-rtc.h | 16 +++++++++
>> 2 files changed, 52 insertions(+), 2 deletions(-)
>>
[...]
>> diff --git a/include/dt-bindings/clock/sun60i-a733-rtc.h b/include/dt-bindings/clock/sun60i-a733-rtc.h
>> new file mode 100644
>> index 000000000000..8a2b5facad73
>> --- /dev/null
>> +++ b/include/dt-bindings/clock/sun60i-a733-rtc.h
>> @@ -0,0 +1,16 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
>> +
>> +#ifndef _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_
>> +#define _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_
>> +
>> +#define CLK_IOSC 0
>> +#define CLK_OSC32K 1
>> +#define CLK_HOSC 2
>
> The DCXO enable control has been present since at least the H6. We just
> never added it, as we would never disable it anyway.
I will remove it.
>
> If you compare the RTC clock trees of the A733 and A523, the only addition
> besides the new gates seems to be the LOSC auto selection. But even that
> is just an illusion, as the A523 has the same registers for that.
>
> One could say the A733 RTC is almost backward compatible to the A523, if
> not for the two fastboot registers the A523 has at 0x120 and 0x124.
>
> So I ask that you try to integrate the differences into the existing
> driver and bindings. You can tweak and export internal clks if you
> need.
Okay, I will try to integrate the A733 RTC support into the existing
driver and bindings.
But first I would like to ask for your advice on how to correctly
organize the device tree binding header for the clocks? I have two ideas
in mind:
1. Add the common internal clocks (e.g., CLK_RTC_32K) to the existing
sun6i-rtc.h. Then, create a new sun60i-a733-rtc.h which includes
the old sun6i-rtc.h and appends the A733-specific clock gates.
2. Simply append all the new A733-specific clock IDs directly to the
bottom of the existing sun6i-rtc.h, sharing the same header file for all
SoCs utilizing this driver.
>
>> +#define CLK_RTC_32K 3
>
> AFAICT besides being an internal clock, this is also fed to GPIO for
> debounce? We probably need to expose this on the A523 as well.
>
I will do it.
>
> Thanks
> ChenYu
>
--
Best regards,
Junhui Liu
^ permalink raw reply
* RE: [PATCH v5 2/2] leds: ltc3220: Add Support for LTC3220 18 channel LED Driver
From: Escala, Edelweise @ 2026-04-10 9:17 UTC (permalink / raw)
To: Lee Jones
Cc: Pavel Machek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DS0PR03MB72281D6EEF372B2E5C73533EED7BA@DS0PR03MB7228.namprd03.prod.outlook.com>
Hello Lee,
I would like to know your recommendation regarding this query before sending in a new version.
Right now what I've done is add comment which references the binding file.
> > > + if (aggregated_led_found && num_leds > 1)
> > > + return dev_err_probe(&client->dev, -EINVAL,
> > > + "Aggregated LED must be the only LED
> > node\n");
> >
> > Must it? Why? Where does it say that?
>
> Aggregated LED mode uses the hardware's "quick-write" feature which
> broadcasts writes to all 18 channels simultaneously. This is a hardware limitation
> - when quick-write mode is enabled, writing to LED channel 1 automatically
> updates ALL channels. Controlling LED individually is still possible however if LED
> 1 is changed all LED value will change.
>
> The device tree binding currently supports two mutually exclusive modes:
> - Multiple independent LED nodes (quick-write disabled), OR
> - Single aggregated LED node with led-sources (quick-write enabled)
>
> This aggregated LED approach was suggested in v2 review:
> https://lore.kernel.org/all/20260112-ltc3220-driver-v2-0-
> d043058fc4df@analog.com/
>
> However, we'd like your recommendation on this design. Would it be better to:
> 1. Keep the aggregated LED mode with hardware quick-write2. Drop aggregated
> mode and let userspace control all 18 LEDs individually
> (userspace can loop to set brightness if synchronized control is needed)
>
Thank you,
Edelweise Escala
^ permalink raw reply
* [PATCH v1 1/5] dt-bindings: interrupt-controller: 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 binding file, compatible string, and MAINTAINERS entry
from "jh8100" to "jhb100". In JHB100 SoC, The clocks and resets are
not operated by users, but they exist in the hardware. Mark them as
optional.
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
---
...ve,jh8100-intc.yaml => starfive,jhb100-intc.yaml} | 12 ++++--------
MAINTAINERS | 2 +-
2 files changed, 5 insertions(+), 9 deletions(-)
rename Documentation/devicetree/bindings/interrupt-controller/{starfive,jh8100-intc.yaml => starfive,jhb100-intc.yaml} (81%)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/starfive,jhb100-intc.yaml
similarity index 81%
rename from Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100-intc.yaml
rename to Documentation/devicetree/bindings/interrupt-controller/starfive,jhb100-intc.yaml
index ada5788602d6..576b1d6c7973 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100-intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/starfive,jhb100-intc.yaml
@@ -1,13 +1,13 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: http://devicetree.org/schemas/interrupt-controller/starfive,jh8100-intc.yaml#
+$id: http://devicetree.org/schemas/interrupt-controller/starfive,jhb100-intc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: StarFive External Interrupt Controller
description:
- StarFive SoC JH8100 contain a external interrupt controller. It can be used
+ StarFive SoC JHB100 contain a external interrupt controller. It can be used
to handle high-level input interrupt signals. It also send the output
interrupt signal to RISC-V PLIC.
@@ -16,7 +16,7 @@ maintainers:
properties:
compatible:
- const: starfive,jh8100-intc
+ const: starfive,jhb100-intc
reg:
maxItems: 1
@@ -40,8 +40,6 @@ properties:
required:
- compatible
- reg
- - clocks
- - resets
- interrupts
- interrupt-controller
- "#interrupt-cells"
@@ -51,10 +49,8 @@ additionalProperties: false
examples:
- |
interrupt-controller@12260000 {
- compatible = "starfive,jh8100-intc";
+ compatible = "starfive,jhb100-intc";
reg = <0x12260000 0x10000>;
- clocks = <&syscrg_ne 76>;
- resets = <&syscrg_ne 13>;
interrupts = <45>;
interrupt-controller;
#interrupt-cells = <1>;
diff --git a/MAINTAINERS b/MAINTAINERS
index d238590a31f2..a2961727e3d1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25312,7 +25312,7 @@ F: drivers/phy/starfive/phy-jh7110-usb.c
STARFIVE JH8100 EXTERNAL INTERRUPT CONTROLLER DRIVER
M: Changhuang Liang <changhuang.liang@starfivetech.com>
S: Supported
-F: Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100-intc.yaml
+F: Documentation/devicetree/bindings/interrupt-controller/starfive,jhb100-intc.yaml
F: drivers/irqchip/irq-starfive-jh8100-intc.c
STATIC BRANCH/CALL
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 2/3] pmdomain: core: add support for power-domains-child-ids
From: Ulf Hansson @ 2026-04-10 8:57 UTC (permalink / raw)
To: Kevin Hilman
Cc: Rob Herring, Geert Uytterhoeven, linux-pm, devicetree,
linux-kernel, arm-scmi, linux-arm-kernel
In-Reply-To: <7h4iljskvz.fsf@baylibre.com>
On Fri, 10 Apr 2026 at 02:45, Kevin Hilman <khilman@baylibre.com> wrote:
>
> Ulf Hansson <ulf.hansson@linaro.org> writes:
>
> > On Wed, 11 Mar 2026 at 01:19, Kevin Hilman (TI) <khilman@baylibre.com> wrote:
> >>
> >> Currently, PM domains can only support hierarchy for simple
> >> providers (e.g. ones with #power-domain-cells = 0).
> >>
> >> Add support for oncell providers as well by adding a new property
> >> `power-domains-child-ids` to describe the parent/child relationship.
> >>
> >> For example, an SCMI PM domain provider has multiple domains, each of
> >> which might be a child of diffeent parent domains. In this example,
> >> the parent domains are MAIN_PD and WKUP_PD:
> >>
> >> scmi_pds: protocol@11 {
> >> reg = <0x11>;
> >> #power-domain-cells = <1>;
> >> power-domains = <&MAIN_PD>, <&WKUP_PD>;
> >> power-domains-child-ids = <15>, <19>;
> >> };
> >>
> >> With this example using the new property, SCMI PM domain 15 becomes a
> >> child domain of MAIN_PD, and SCMI domain 19 becomes a child domain of
> >> WKUP_PD.
> >>
> >> To support this feature, add two new core functions
> >>
> >> - of_genpd_add_child_ids()
> >> - of_genpd_remove_child_ids()
> >>
> >> which can be called by pmdomain providers to add/remove child domains
> >> if they support the new property power-domains-child-ids.
> >>
> >> Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
> >
> > Thanks for working on this! It certainly is a missing feature!
>
> You're welcome, thanks for the detailed review.
>
> >> ---
> >> drivers/pmdomain/core.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> include/linux/pm_domain.h | 16 ++++++++++++++++
> >> 2 files changed, 185 insertions(+)
> >>
> >> diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
> >> index 61c2277c9ce3..acb45dd540b7 100644
> >> --- a/drivers/pmdomain/core.c
> >> +++ b/drivers/pmdomain/core.c
> >> @@ -2909,6 +2909,175 @@ static struct generic_pm_domain *genpd_get_from_provider(
> >> return genpd;
> >> }
> >>
> >> +/**
> >> + * of_genpd_add_child_ids() - Parse power-domains-child-ids property
> >> + * @np: Device node pointer associated with the PM domain provider.
> >> + * @data: Pointer to the onecell data associated with the PM domain provider.
> >> + *
> >> + * Parse the power-domains and power-domains-child-ids properties to establish
> >> + * parent-child relationships for PM domains. The power-domains property lists
> >> + * parent domains, and power-domains-child-ids lists which child domain IDs
> >> + * should be associated with each parent.
> >> + *
> >> + * Returns 0 on success, -ENOENT if properties don't exist, or negative error code.
> >
> > I think we should avoid returning specific error codes for specific
> > errors, simply because it usually becomes messy.
> >
> > If I understand correctly the intent here is to allow the caller to
> > check for -ENOENT and potentially avoid bailing out as it may not
> > really be an error, right?
>
> Right, -ENOENT is not an error of parsing, it's to indicate that there
> are no child-ids to be parsed.
>
> > Perhaps a better option is to return the number of children for whom
> > we successfully assigned parents. Hence 0 or a positive value allows
> > the caller to understand what happened. More importantly, a negative
> > error code then really becomes an error for the caller to consider.
>
> I explored this a bit, but it gets messy quick. It means we have to
> track cases where only some of the children were added as well as when
> all children were added. Personally, I think this should be an "all or
> nothing" thing. If all the children cannot be parsed/added, then none
> of them should be added.
>
> This also allows the remove to not have to care about how many were
> added, and just remove them all, with the additional benefit of not
> having to track the state of how many children were successfully added.
>
I fully agree, it should be all or nothing. Failing with one
child/parent should end up with an error code being returned.
That said, it still seems to make perfect sense to return the number
of children for whom we assigned parents for, no?
[...]
> >> +int of_genpd_remove_child_ids(struct device_node *np,
> >> + struct genpd_onecell_data *data)
> >> +{
> >> + struct of_phandle_args parent_args;
> >> + struct generic_pm_domain *parent_genpd, *child_genpd;
> >> + struct of_phandle_iterator it;
> >> + const struct property *prop;
> >> + const __be32 *item;
> >> + u32 child_id;
> >> + int ret;
> >> +
> >> + /* Check if both properties exist */
> >> + if (of_count_phandle_with_args(np, "power-domains", "#power-domain-cells") <= 0)
> >> + return -ENOENT;
> >> +
> >> + prop = of_find_property(np, "power-domains-child-ids", NULL);
> >> + if (!prop)
> >> + return -ENOENT;
> >> +
> >> + item = of_prop_next_u32(prop, NULL, &child_id);
> >
> > Similar comments as for of_genpd_add_child_ids().
> >
> > Moreover, I think we should remove the children in the reverse order
> > of how we added them.
>
> I'm curious why does the order matter? The children are all siblings
> (no hierarchy), so why would the order be important?
It might not be that important, but generally, it seems like a good
idea to me to reverse the order when undoing things.
>
> I'm not ware of a phandle iterator/helper to parse in the reverse, so
> that would mean iterating once to create a list, and then walking it in
> reverse. Seems unnecessary.
Sure, I leave the call to you, to see what fits best.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset
From: Konrad Dybcio @ 2026-04-10 8:55 UTC (permalink / raw)
To: Dmitry Baryshkov, David Heidelberg
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Ulf Hansson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-clk, linux-kernel, devicetree
In-Reply-To: <xbbaffnmi6z5ohzw3p4m6ox75gasgc3nw5cf6yo7h3td2bmsrb@px2mntm74rhb>
On 4/9/26 11:24 PM, Dmitry Baryshkov wrote:
> On Thu, Apr 09, 2026 at 10:38:15PM +0200, David Heidelberg wrote:
>> On 18/02/2026 16:59, Dmitry Baryshkov wrote:
>>> On Wed, Feb 18, 2026 at 03:28:01PM +0100, Konrad Dybcio wrote:
>>>>
>>>>
>>>> On 18-Feb-26 12:58, Dmitry Baryshkov wrote:
>>>>> On Wed, Feb 18, 2026 at 12:24:26PM +0100, Konrad Dybcio wrote:
>>>>>> On 2/18/26 12:18 PM, David Heidelberg wrote:
>>>>>>> On 18/02/2026 11:30, Konrad Dybcio wrote:
>>>>>>>> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
>>>>>>>>> From: David Heidelberg <david@ixit.cz>
>>>>>>>>>
>>>>>>>>> If the OS does not support recovering the state left by the
>>>>>>>>> bootloader it needs a way to reset display hardware, so that it can
>>>>>>>>> start from a clean state. Add a reference to the relevant reset.
>>>>>>>>
>>>>>>>> This is not the relevant reset
>>>>>>>>
>>>>>>>> You want MDSS_CORE_BCR @ 0xaf0_2000
>>>>>>>
>>>>>>> Thanks, I prepared the fixes [1].
>>>>>>>
>>>>>>> I'll try to test it if it's not breaking anything for us and send as v2 of [2].
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
>>>>>>> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
>>>>>>
>>>>>> Please don't alter the contents of dt-bindings, it really doesn't matter
>>>>>> if on sdm845 it's reset0 or reset1, that's why we define them in the first
>>>>>> place
>>>>>
>>>>> I dpn't think that will pass. Current reset is defined as RSCC, we can't
>>>>> change that to CORE behind the scene. I'd prefer David's approach.
>>>>
>>>> Back when I replied, David had a patch that removed the current RSCC
>>>> reset definition in dt-bindings (at index 0) and re-used that index
>>>> for CORE, putting RSCC at index 1. Perhaps it's better to link to
>>>> specific commits when making comments, note to self :P
>>>
>>> Yes, I saw the commit having two resets. Anyway, as we saw, it doesn't
>>> work.
>>
>> So, finally I spent "so much effort" (read throwing it at LLM) looking at:
>>
>> arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402,
>> iova=0x9d4bb500, fsynr=0x170021, cbfrsynra=0xc88, cb=11
>> arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0xc88
>> arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
>
> [...]
>
>>
>> These (or very similar warnings) are around sdm845 definitely 6.19+ /
>> linux-next kernels for some time, but pretty harmless.
>>
>> LLM suggested multiple fixes, but when presenting possibility of
>> implementing mdss reset it found it as most preferable [1].
>>
>> Adding MDSS reset would most likely solve it. It's not critical, but not
>> nice to see many red lines in the dmesg.
>>
>> Is there something I could experiment with to get closer to have proper MDSS reset?
>
> I don't have a sensible solution at this point. We tried using the MDSS
> reset on several SDM845 devices, but they just reset. So... I don't have
> any possible solution.
The older context talks about altering the existing dt-bindings values
and now we're at hardware (mis)behaving? What is the issue here?
Konrad
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: ipq5210: add the bootph-all property
From: Krzysztof Kozlowski @ 2026-04-10 8:54 UTC (permalink / raw)
To: Kathiravan Thirumoorthy, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <9d99f3ad-e2ec-4a17-ab07-3d379dc28d55@oss.qualcomm.com>
On 10/04/2026 10:41, Kathiravan Thirumoorthy wrote:
>
> On 4/9/2026 3:33 PM, Krzysztof Kozlowski wrote:
>> On 09/04/2026 11:28, Kathiravan Thirumoorthy wrote:
>>> Add the bootph-all property to the nodes which are utilized by the
>>> bootloaders.
>> Uh oh, so it started for qcom too? I really don't like how these bootph
>> properties spread all over, so please provide arguments - which pure
>> upstream bootloaders exactly and why exactly these nodes.
>
> This is needed for U-Boot SPL for IPQ5210 [1].
Mention U-Boot SPL in commit msg and add Link for commit msg (or
changelog if other prefers that).
>
> [1] -
> https://lore.kernel.org/u-boot/20260408091136.2794546-1-varadarajan.narayanan@oss.qualcomm.com/
>
>>> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts | 5 +++++
>>> arch/arm64/boot/dts/qcom/ipq5210.dtsi | 10 ++++++++++
>>> 2 files changed, 15 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts b/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts
>>> index 941f866ecfe9..56dbc506da78 100644
>>> --- a/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts
>>> +++ b/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts
>>> @@ -17,6 +17,7 @@ aliases {
>>>
>>> chosen {
>>> stdout-path = "serial0";
>>> + bootph-all;
>> Since when do we add bootph-all to chosen? Which broken bootloader
>> ignores chosen?
>>
>> This really makes me wonder that you do all this for some downstream forks.
>
> U-Boot doesn't need it, but U-Boot SPL needs it.
I understand, but let me rephrase my question better. Which bootloader
build process ignores chosen when preparing final DTB for the target?
Maybe that build process needs to be fixed.
>
>>> };
>>> };
>>>
>>> @@ -41,6 +42,7 @@ qup_uart1_default_state: qup-uart1-default-state {
>>> function = "qup_se1";
>>> drive-strength = <6>;
>>> bias-pull-down;
>>> + bootph-all;
>>> };
>> And that's a pin, not a device. What is the point of marking it? The
>> device needing this pin will have phandle which must pull the node.
>
> This is because of the fdtgrep tool's limitations, which removes these
> nodes in the final DTB if this property is not present.
fdtgrep should be fixed. I see no point in marking obvious dependencies.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: ipq5210: add the bootph-all property
From: Kathiravan Thirumoorthy @ 2026-04-10 8:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <8fe36a5e-1ebc-4c5f-9c3b-3c50ebd2274e@kernel.org>
On 4/9/2026 3:33 PM, Krzysztof Kozlowski wrote:
> On 09/04/2026 11:28, Kathiravan Thirumoorthy wrote:
>> Add the bootph-all property to the nodes which are utilized by the
>> bootloaders.
> Uh oh, so it started for qcom too? I really don't like how these bootph
> properties spread all over, so please provide arguments - which pure
> upstream bootloaders exactly and why exactly these nodes.
This is needed for U-Boot SPL for IPQ5210 [1].
[1] -
https://lore.kernel.org/u-boot/20260408091136.2794546-1-varadarajan.narayanan@oss.qualcomm.com/
>> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts | 5 +++++
>> arch/arm64/boot/dts/qcom/ipq5210.dtsi | 10 ++++++++++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts b/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts
>> index 941f866ecfe9..56dbc506da78 100644
>> --- a/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts
>> +++ b/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts
>> @@ -17,6 +17,7 @@ aliases {
>>
>> chosen {
>> stdout-path = "serial0";
>> + bootph-all;
> Since when do we add bootph-all to chosen? Which broken bootloader
> ignores chosen?
>
> This really makes me wonder that you do all this for some downstream forks.
U-Boot doesn't need it, but U-Boot SPL needs it.
>> };
>> };
>>
>> @@ -41,6 +42,7 @@ qup_uart1_default_state: qup-uart1-default-state {
>> function = "qup_se1";
>> drive-strength = <6>;
>> bias-pull-down;
>> + bootph-all;
>> };
> And that's a pin, not a device. What is the point of marking it? The
> device needing this pin will have phandle which must pull the node.
This is because of the fdtgrep tool's limitations, which removes these
nodes in the final DTB if this property is not present.
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
From: Konrad Dybcio @ 2026-04-10 8:39 UTC (permalink / raw)
To: Luca Weiss, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260410-milos-ipa-v2-2-c699b6b8cf27@fairphone.com>
On 4/10/26 10:17 AM, Luca Weiss wrote:
> Configure and enable the node for IPA which enables mobile data on this
> device.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: purwa-iot-evk: Add camss node
From: Wenmeng Liu @ 2026-04-10 8:38 UTC (permalink / raw)
To: 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: <765e4740-cf13-4d4e-ab69-c1abe1c39d34@linaro.org>
Hi Bryan,
On 4/10/2026 4:16 PM, Bryan O'Donoghue wrote:
> On 10/04/2026 05:25, Wenmeng Liu wrote:
>> nable camss node for purwa iot evk board camss tpg support.
>>
>> Signed-off-by: Wenmeng Liu<wenmeng.liu@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/purwa-iot-evk.dts | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts b/arch/arm64/
>> boot/dts/qcom/purwa-iot-evk.dts
>> index
>> ad503beec1d3d8c671d3564942a74c484de762d0..eef03f1eb2a950c06294159be3f97169fb487265 100644
>> --- a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
>> +++ b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
>> @@ -734,6 +734,10 @@ retimer_ss2_con_sbu_out: endpoint {
>> };
>> };
>> +&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.
And ack comments on the previous patch.
Thanks,
Wenmeng
^ permalink raw reply
* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Akhil R @ 2026-04-10 8:37 UTC (permalink / raw)
To: krzk
Cc: Frank.Li, acpica-devel, akhilrajeev, alexandre.belloni, conor+dt,
devicetree, ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon,
linux-i3c, linux-kernel, linux, miquel.raynal, p.zabel, rafael,
robh, sakari.ailus, wsa+renesas
In-Reply-To: <9e1093e6-18f9-4edc-8659-510245c5d6db@kernel.org>
On Fri, 10 Apr 2026 09:18:48 +0200, Krzysztof Kozlowski wrote:
> On 10/04/2026 08:57, Guenter Roeck wrote:
>> On 4/9/26 23:39, Krzysztof Kozlowski wrote:
>>> On 09/04/2026 12:57, Akhil R wrote:
>>>> Add I3C subsystem support, DesignWare I3C master controller, and
>>>> SPD5118 hwmon sensor as modules to the defconfig and therefore
>>>> enable the support for SPD5118 sensor on SOCAMM found in NVIDIA
>>>> Vera platforms.
>>>
>>> git grep for "Vera" gave me zero results. Are you sure this is an
>>> upstream platform? Please point the DTS using this.
>>>
>>
>> I think this is an ACPI based system, or at least that is what Google search
>> tells me.
>
> Thanks. Following Google Vera is either a "CPU" or entire architecture
> (at least that's how they call it), so it does not have SPD5118 sensor.
SOCAMM is a Memory Module. SPD5118, as it's Kconfig mentions, is a sensor
found within such memory modules. I didn't quite get why would you state
that the SOCAMM present in Vera architecture (or CPU) does not have
SPD5118 in it.
Pasting the below from the Vera Rubin product page [1] -
"NVIDIA Vera CPUs add enhanced serviceability with small-outline
compression-attached memory modules (SOCAMM) LPDDR5X and in-system tests
for the CPU cores."
[1]: https://www.nvidia.com/en-us/data-center/technologies/rubin/
>
>
> "Nvidia vera socamm" gives me something about "rubin". It's not me who
> should be guessing all this.
>
> "nvidia vera socamm SPD5118" gives me even less, so justification is flaky.
>
> To remind, this commit msg should convince why generic kernel for
> developers affecting all possible platforms - not end users, because
> they always use distro kernels - should enable these configs. And it
> should bring me clear rule what I can or cannot remove from defconfig,
> if in 2 years I come and start pruning it from symbols.
I found little details on what we should be adding in the defconfig. It
would help if you could share some guidance. Do you mean to say that the
defconfig should include only the configs which are necessary in
development platforms and not in end-products?
Regards,
Akhil
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: purwa: Fix GPU IOMMU property
From: Konrad Dybcio @ 2026-04-10 8:37 UTC (permalink / raw)
To: Akhil P Oommen, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rob Clark, Dmitry Baryshkov,
freedreno
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260410-purwa-gpu-dt-fix-v1-1-4637892156cf@oss.qualcomm.com>
On 4/9/26 11:08 PM, Akhil P Oommen wrote:
> Purwa's GPU does not support SID 1, which is typically used for
> LPAC-related traffic. Remove SID 1 from the GPU node's iommus property to
> accurately describe the hardware. This fixes the splat below, seen with
> some versions of Gunyah hypervisor:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 8/8] arm64: dts: qcom: eliza: Add support for MM clock controllers
From: Bryan O'Donoghue @ 2026-04-10 8:26 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <328b388c-438e-4f91-9384-0dad903355a5@oss.qualcomm.com>
On 10/04/2026 04:55, Taniya Das wrote:
>> Why do these two controllers have no power-domains ?
> Bryan, on Eliza the videocc and camcc are connected on CX and MXA.
Shouldn't you at least have:
power-domains = <&rpmhpd RPMHPD_CX> ?
And even
power-domains = <&rpmhpd RPMHPD_MX>,
<&rpmhpd RPMHPD_CX>;
power-domain-names = "mx",
"cx";
Konrad's suggestion to me was that MXA should have a vote in my CSIPHY
series I think he and Jagadeesh discussed it but I'm not sure if they
_concluded_ what was the right thing to do.
Right now I'm representing the dependency. MXA is always on ... and
there's nothing to do voting for it @ MX ?
---
bod
^ permalink raw reply
* RE: [PATCH v6 06/10] clk: realtek: Add support for mux clock
From: Yu-Chun Lin [林祐君] @ 2026-04-10 8:24 UTC (permalink / raw)
To: Brian Masney
Cc: mturquette@baylibre.com, sboyd@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, p.zabel@pengutronix.de,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安], devicetree@vger.kernel.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <ac_UkRiqWb6fSc1I@redhat.com>
Hi Brian,
> Hi Yu-Chun and Cheng-Yu,
>
> On Thu, Apr 02, 2026 at 03:39:53PM +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Add a simple regmap-based clk_ops implementation for Realtek mux clocks.
> >
> > The implementation supports parent selection and rate determination
> > through regmap-backed register access.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v6:
> > - Add the headers used in c file to follow the "Include What You Use"
> principle.
> > ---
> > drivers/clk/realtek/Makefile | 1 +
> > drivers/clk/realtek/clk-regmap-mux.c | 48
> > ++++++++++++++++++++++++++++ drivers/clk/realtek/clk-regmap-mux.h |
> > 43 +++++++++++++++++++++++++
> > 3 files changed, 92 insertions(+)
> > create mode 100644 drivers/clk/realtek/clk-regmap-mux.c
> > create mode 100644 drivers/clk/realtek/clk-regmap-mux.h
> >
> > diff --git a/drivers/clk/realtek/Makefile
> > b/drivers/clk/realtek/Makefile index 74375f8127ac..f90dc57fcfdb 100644
> > --- a/drivers/clk/realtek/Makefile
> > +++ b/drivers/clk/realtek/Makefile
> > @@ -5,4 +5,5 @@ clk-rtk-y += common.o
> >
> > clk-rtk-y += clk-pll.o
> > clk-rtk-y += clk-regmap-gate.o
> > +clk-rtk-y += clk-regmap-mux.o
> > clk-rtk-y += freq_table.o
> > diff --git a/drivers/clk/realtek/clk-regmap-mux.c
> > b/drivers/clk/realtek/clk-regmap-mux.c
> > new file mode 100644
> > index 000000000000..068b056d61f0
> > --- /dev/null
> > +++ b/drivers/clk/realtek/clk-regmap-mux.c
> > @@ -0,0 +1,48 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2017 Realtek Semiconductor Corporation
> > + * Author: Cheng-Yu Lee <cylee12@realtek.com> */
> > +
> > +#include <linux/regmap.h>
> > +#include <linux/clk-provider.h>
>
> Sort the includes.
>
Ack.
> > +#include "clk-regmap-mux.h"
> > +
> > +static u8 clk_regmap_mux_get_parent(struct clk_hw *hw) {
> > + struct clk_regmap_mux *clkm = to_clk_regmap_mux(hw);
> > + int num_parents = clk_hw_get_num_parents(hw);
> > + u32 val;
> > + int ret;
> > +
> > + ret = regmap_read(clkm->clkr.regmap, clkm->mux_ofs, &val);
> > + if (ret)
> > + return 0;
>
> This is another case where it'd be nice to get the get_parent declaration fixed.
> Stephen recently linked to some work of his from 2022 here.
>
> https://lore.kernel.org/linux-clk/177431305509.5403.15386021337517970667
> @lazor/
>
> There's nothing for you to do right now.
>
> > +
> > + val = val >> clkm->shift & clkm->mask;
>
> I know there's the order of operations, however for clarity I would just include
> some () here to make it clear the expected order.
Ack.
> > +
> > + if (val >= num_parents)
>
> Remove newline before if.
Ack.
>
> > + return 0;
> > +
> > + return val;
>
> Or you could just use a ternary operator:
>
> return val >= num_parents ? 0 : val;
>
Ack.
> > +}
> > +
> > +static int clk_regmap_mux_set_parent(struct clk_hw *hw, u8 index) {
> > + struct clk_regmap_mux *clkm = to_clk_regmap_mux(hw);
> > +
> > + return regmap_update_bits(clkm->clkr.regmap, clkm->mux_ofs,
> > + clkm->mask << clkm->shift, index <<
> > +clkm->shift); }
> > +
> > +const struct clk_ops rtk_clk_regmap_mux_ops = {
> > + .set_parent = clk_regmap_mux_set_parent,
> > + .get_parent = clk_regmap_mux_get_parent,
> > + .determine_rate = __clk_mux_determine_rate, };
> > +EXPORT_SYMBOL_NS_GPL(rtk_clk_regmap_mux_ops, "REALTEK_CLK");
> > +
> > +const struct clk_ops rtk_clk_regmap_mux_ro_ops = {
> > + .get_parent = clk_regmap_mux_get_parent, };
> > +EXPORT_SYMBOL_NS_GPL(rtk_clk_regmap_mux_ro_ops, "REALTEK_CLK");
>
> rtk_clk_regmap_mux_ro_ops is exported, however the declaration is not
> actually declared in any header files.
>
> Brian
Since it is currently unused, I will drop the 'rtk_clk_regmap_mux_ro_ops'
implementation.
Best Regards,
Yu-Chun.
^ 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