* [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
* Re: [PATCH v4 2/3] thermal: spacemit: k1: Add thermal sensor support
From: Jie Gan @ 2026-04-10 8:25 UTC (permalink / raw)
To: Shuwei Wu, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: linux-pm, devicetree, linux-riscv, spacemit, linux-kernel,
Anand Moon, Troy Mitchell, Yao Zi, Vincent Legoll, Gong Shuai
In-Reply-To: <20260410-k1-thermal-v1-2-12c87dd063c3@mailbox.org>
On 4/10/2026 11:31 AM, Shuwei Wu wrote:
> The thermal sensor on K1 supports monitoring five temperature zones.
> The driver registers these sensors with the thermal framework
> and supports standard operations:
> - Reading temperature (millidegree Celsius)
> - Setting high/low thresholds for interrupts
>
> Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
> Reviewed-by: Anand Moon <linux.amoon@gmail.com>
> Tested-by: Anand Moon <linux.amoon@gmail.com>
> Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
> Reviewed-by: Yao Zi <me@ziyao.cc>
> Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
> Tested-by: Gong Shuai <gsh517025@gmail.com>
>
> ---
> Changes in v4:
> - Add 'depends on THERMAL_OF' in drivers/thermal/spacemit/Kconfig
>
> Changes in v3:
> - Align multi-line assignments as suggested by reviewer
> - Remove unnecessary variable definitions
>
> Changes in v2:
> - Rename k1_thermal.c to k1_tsensor.c for better hardware alignment
> - Move driver to drivers/thermal/spacemit/
> - Add Kconfig/Makefile for spacemit and update top-level build files
> - Refactor names, style, code alignment, and comments
> - Simplify probe and error handling
> ---
> drivers/thermal/Kconfig | 2 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/spacemit/Kconfig | 19 +++
> drivers/thermal/spacemit/Makefile | 3 +
> drivers/thermal/spacemit/k1_tsensor.c | 281 ++++++++++++++++++++++++++++++++++
> 5 files changed, 306 insertions(+)
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index b10080d61860..1c4a5cd5a23e 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -472,6 +472,8 @@ endmenu
>
> source "drivers/thermal/renesas/Kconfig"
>
> +source "drivers/thermal/spacemit/Kconfig"
> +
> source "drivers/thermal/tegra/Kconfig"
>
> config GENERIC_ADC_THERMAL
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index bb21e7ea7fc6..3b249195c088 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -65,6 +65,7 @@ obj-y += mediatek/
> obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
> obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
> obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
> +obj-y += spacemit/
> obj-$(CONFIG_SPRD_THERMAL) += sprd_thermal.o
> obj-$(CONFIG_KHADAS_MCU_FAN_THERMAL) += khadas_mcu_fan.o
> obj-$(CONFIG_LOONGSON2_THERMAL) += loongson2_thermal.o
> diff --git a/drivers/thermal/spacemit/Kconfig b/drivers/thermal/spacemit/Kconfig
> new file mode 100644
> index 000000000000..de7b5ece5af2
> --- /dev/null
> +++ b/drivers/thermal/spacemit/Kconfig
> @@ -0,0 +1,19 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +menu "SpacemiT thermal drivers"
> +depends on ARCH_SPACEMIT || COMPILE_TEST
> +
> +config SPACEMIT_K1_TSENSOR
> + tristate "SpacemiT K1 thermal sensor driver"
> + depends on THERMAL_OF
> + help
> + This driver provides support for the thermal sensor
> + integrated in the SpacemiT K1 SoC.
> +
> + The thermal sensor monitors temperatures for five thermal zones:
> + soc, package, gpu, cluster0, and cluster1. It supports reporting
> + temperature values and handling high/low threshold interrupts.
> +
> + Say Y here if you want to enable thermal monitoring on SpacemiT K1.
> + If compiled as a module, it will be called k1_tsensor.
> +
> +endmenu
> diff --git a/drivers/thermal/spacemit/Makefile b/drivers/thermal/spacemit/Makefile
> new file mode 100644
> index 000000000000..82b30741e4ec
> --- /dev/null
> +++ b/drivers/thermal/spacemit/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +obj-$(CONFIG_SPACEMIT_K1_TSENSOR) += k1_tsensor.o
> diff --git a/drivers/thermal/spacemit/k1_tsensor.c b/drivers/thermal/spacemit/k1_tsensor.c
> new file mode 100644
> index 000000000000..b742739e9019
> --- /dev/null
> +++ b/drivers/thermal/spacemit/k1_tsensor.c
> @@ -0,0 +1,281 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Thermal sensor driver for SpacemiT K1 SoC
> + *
> + * Copyright (C) 2026 Shuwei Wu <shuwei.wu@mailbox.org>
> + */
> +#include <linux/bitfield.h>
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset.h>
> +#include <linux/slab.h>
> +#include <linux/thermal.h>
> +
> +#include "../thermal_hwmon.h"
> +
> +#define K1_TSENSOR_PCTRL_REG 0x00
> +#define K1_TSENSOR_PCTRL_ENABLE BIT(0)
> +#define K1_TSENSOR_PCTRL_TEMP_MODE BIT(3)
> +#define K1_TSENSOR_PCTRL_RAW_SEL BIT(7)
> +
> +#define K1_TSENSOR_PCTRL_CTUNE GENMASK(11, 8)
> +#define K1_TSENSOR_PCTRL_SW_CTRL GENMASK(21, 18)
> +#define K1_TSENSOR_PCTRL_HW_AUTO_MODE BIT(23)
> +
> +#define K1_TSENSOR_EN_REG 0x08
> +#define K1_TSENSOR_EN_ALL GENMASK(MAX_SENSOR_NUMBER - 1, 0)
> +
> +#define K1_TSENSOR_TIME_REG 0x0C
> +#define K1_TSENSOR_TIME_WAIT_REF_CNT GENMASK(3, 0)
> +#define K1_TSENSOR_TIME_ADC_CNT_RST GENMASK(7, 4)
> +#define K1_TSENSOR_TIME_FILTER_PERIOD GENMASK(21, 20)
> +#define K1_TSENSOR_TIME_MASK GENMASK(23, 0)
> +
> +#define K1_TSENSOR_INT_CLR_REG 0x10
> +#define K1_TSENSOR_INT_EN_REG 0x14
> +#define K1_TSENSOR_INT_STA_REG 0x18
> +
> +#define K1_TSENSOR_INT_EN_MASK BIT(0)
> +#define K1_TSENSOR_INT_MASK(x) (GENMASK(2, 1) << ((x) * 2))
> +
> +#define K1_TSENSOR_DATA_BASE_REG 0x20
> +#define K1_TSENSOR_DATA_REG(x) (K1_TSENSOR_DATA_BASE_REG + ((x) / 2) * 4)
> +#define K1_TSENSOR_DATA_LOW_MASK GENMASK(15, 0)
> +#define K1_TSENSOR_DATA_HIGH_MASK GENMASK(31, 16)
> +
> +#define K1_TSENSOR_THRSH_BASE_REG 0x40
> +#define K1_TSENSOR_THRSH_REG(x) (K1_TSENSOR_THRSH_BASE_REG + ((x) * 4))
> +#define K1_TSENSOR_THRSH_LOW_MASK GENMASK(15, 0)
> +#define K1_TSENSOR_THRSH_HIGH_MASK GENMASK(31, 16)
> +
> +#define MAX_SENSOR_NUMBER 5
> +
> +/* Hardware offset value required for temperature calculation */
> +#define TEMPERATURE_OFFSET 278
> +
> +struct k1_tsensor_channel {
> + struct k1_tsensor *ts;
> + struct thermal_zone_device *tzd;
> + int id;
> +};
> +
> +struct k1_tsensor {
> + void __iomem *base;
> + struct k1_tsensor_channel ch[MAX_SENSOR_NUMBER];
> +};
> +
> +static void k1_tsensor_init(struct k1_tsensor *ts)
> +{
> + u32 val;
> +
> + /* Disable all the interrupts */
> + writel(0xffffffff, ts->base + K1_TSENSOR_INT_EN_REG);
> +
> + /* Configure ADC sampling time and filter period */
> + val = readl(ts->base + K1_TSENSOR_TIME_REG);
> + val &= ~K1_TSENSOR_TIME_MASK;
> + val |= K1_TSENSOR_TIME_FILTER_PERIOD |
> + K1_TSENSOR_TIME_ADC_CNT_RST |
> + K1_TSENSOR_TIME_WAIT_REF_CNT;
> + writel(val, ts->base + K1_TSENSOR_TIME_REG);
> +
> + /*
> + * Enable all sensors' auto mode, enable dither control,
> + * consecutive mode, and power up sensor.
> + */
> + val = readl(ts->base + K1_TSENSOR_PCTRL_REG);
> + val &= ~K1_TSENSOR_PCTRL_SW_CTRL;
> + val &= ~K1_TSENSOR_PCTRL_CTUNE;
> + val |= K1_TSENSOR_PCTRL_RAW_SEL |
> + K1_TSENSOR_PCTRL_TEMP_MODE |
> + K1_TSENSOR_PCTRL_HW_AUTO_MODE |
> + K1_TSENSOR_PCTRL_ENABLE;
> + writel(val, ts->base + K1_TSENSOR_PCTRL_REG);
> +
> + /* Enable thermal interrupt */
> + val = readl(ts->base + K1_TSENSOR_INT_EN_REG);
> + val |= K1_TSENSOR_INT_EN_MASK;
> + writel(val, ts->base + K1_TSENSOR_INT_EN_REG);
> +
> + /* Enable each sensor */
> + val = readl(ts->base + K1_TSENSOR_EN_REG);
> + val |= K1_TSENSOR_EN_ALL;
> + writel(val, ts->base + K1_TSENSOR_EN_REG);
> +}
> +
> +static void k1_tsensor_enable_irq(struct k1_tsensor_channel *ch)
> +{
> + struct k1_tsensor *ts = ch->ts;
> + u32 val;
> +
> + val = readl(ts->base + K1_TSENSOR_INT_CLR_REG);
> + val |= K1_TSENSOR_INT_MASK(ch->id);
> + writel(val, ts->base + K1_TSENSOR_INT_CLR_REG);
> +
> + val = readl(ts->base + K1_TSENSOR_INT_EN_REG);
> + val &= ~K1_TSENSOR_INT_MASK(ch->id);
> + writel(val, ts->base + K1_TSENSOR_INT_EN_REG);
> +}
> +
> +/*
> + * The conversion formula used is:
> + * T(m°C) = (((raw_value & mask) >> shift) - TEMPERATURE_OFFSET) * 1000
> + */
> +static int k1_tsensor_get_temp(struct thermal_zone_device *tz, int *temp)
> +{
> + struct k1_tsensor_channel *ch = thermal_zone_device_priv(tz);
> + struct k1_tsensor *ts = ch->ts;
> + u32 val;
> +
> + val = readl(ts->base + K1_TSENSOR_DATA_REG(ch->id));
> + if (ch->id % 2)
> + *temp = FIELD_GET(K1_TSENSOR_DATA_HIGH_MASK, val);
> + else
> + *temp = FIELD_GET(K1_TSENSOR_DATA_LOW_MASK, val);
> +
> + *temp -= TEMPERATURE_OFFSET;
> + *temp *= 1000;
> +
> + return 0;
> +}
> +
> +/*
> + * For each sensor, the hardware threshold register is 32 bits:
> + * - Lower 16 bits [15:0] configure the low threshold temperature.
> + * - Upper 16 bits [31:16] configure the high threshold temperature.
> + */
> +static int k1_tsensor_set_trips(struct thermal_zone_device *tz, int low, int high)
> +{
> + struct k1_tsensor_channel *ch = thermal_zone_device_priv(tz);
> + struct k1_tsensor *ts = ch->ts;
> + u32 val;
> +
> + if (low >= high)
> + return -EINVAL;
> +
> + if (low < 0)
> + low = 0;
> +
> + high = high / 1000 + TEMPERATURE_OFFSET;
Consider passes high = INT_MAX here:
high = INT/1000 + TEMPERATURE_OFFSET == 2147761;
> + low = low / 1000 + TEMPERATURE_OFFSET;
> +
> + val = readl(ts->base + K1_TSENSOR_THRSH_REG(ch->id));
> + val &= ~K1_TSENSOR_THRSH_HIGH_MASK;
> + val |= FIELD_PREP(K1_TSENSOR_THRSH_HIGH_MASK, high);
K1_TSENSOR_THRSH_HIGH_MASK is a 16-bit MASK:
FIELD_PREP(K1_TSENSOR_THRSH_HIGH_MASK, 2147761); <- overflow happened
the maximum value here will be changed to 50609 from 65536.
We should add a check here and limit the 'high' value here to avoid
overflow:
if (high > (int)((0xFFFF - TEMPERATURE_OFFSET) * 1000))
high = (0Xffff - TEMPERATURE_OFFSET) * 1000;
high = high / 1000 + TEMPERATURE_OFFSET;
...
> +
> + val &= ~K1_TSENSOR_THRSH_LOW_MASK;
> + val |= FIELD_PREP(K1_TSENSOR_THRSH_LOW_MASK, low);
> + writel(val, ts->base + K1_TSENSOR_THRSH_REG(ch->id));
> +
> + return 0;
> +}
> +
> +static const struct thermal_zone_device_ops k1_tsensor_ops = {
> + .get_temp = k1_tsensor_get_temp,
> + .set_trips = k1_tsensor_set_trips,
> +};
> +
> +static irqreturn_t k1_tsensor_irq_thread(int irq, void *data)
> +{
> + struct k1_tsensor *ts = (struct k1_tsensor *)data;
> + int mask, status, i;
> +
> + status = readl(ts->base + K1_TSENSOR_INT_STA_REG);
> +
> + for (i = 0; i < MAX_SENSOR_NUMBER; i++) {
> + if (status & K1_TSENSOR_INT_MASK(i)) {
> + mask = readl(ts->base + K1_TSENSOR_INT_CLR_REG);
> + mask |= K1_TSENSOR_INT_MASK(i);
> + writel(mask, ts->base + K1_TSENSOR_INT_CLR_REG);
> + thermal_zone_device_update(ts->ch[i].tzd, THERMAL_EVENT_UNSPECIFIED);
> + }
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int k1_tsensor_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct k1_tsensor *ts;
> + struct reset_control *reset;
> + struct clk *clk;
> + int i, irq, ret;
> +
> + ts = devm_kzalloc(dev, sizeof(*ts), GFP_KERNEL);
> + if (!ts)
> + return -ENOMEM;
> +
> + ts->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(ts->base))
> + return dev_err_probe(dev, PTR_ERR(ts->base), "Failed to get reg\n");
> +
> + reset = devm_reset_control_get_exclusive_deasserted(dev, NULL);
> + if (IS_ERR(reset))
> + return dev_err_probe(dev, PTR_ERR(reset), "Failed to get/deassert reset control\n");
> +
> + clk = devm_clk_get_enabled(dev, "core");
> + if (IS_ERR(clk))
> + return dev_err_probe(dev, PTR_ERR(clk), "Failed to get core clock\n");
> +
> + clk = devm_clk_get_enabled(dev, "bus");
> + if (IS_ERR(clk))
> + return dev_err_probe(dev, PTR_ERR(clk), "Failed to get bus clock\n");
> +
> + k1_tsensor_init(ts);
> +
> + for (i = 0; i < MAX_SENSOR_NUMBER; ++i) {
> + ts->ch[i].id = i;
> + ts->ch[i].ts = ts;
> + ts->ch[i].tzd = devm_thermal_of_zone_register(dev, i, ts->ch + i, &k1_tsensor_ops);
> + if (IS_ERR(ts->ch[i].tzd))
> + return PTR_ERR(ts->ch[i].tzd);
> +
> + /* Attach sysfs hwmon attributes for userspace monitoring */
> + ret = devm_thermal_add_hwmon_sysfs(dev, ts->ch[i].tzd);
> + if (ret)
> + dev_warn(dev, "Failed to add hwmon sysfs attributes\n");
> +
> + k1_tsensor_enable_irq(ts->ch + i);
should call after the devm_request_threaded_irq succeeds;
Thanks,
Jie
> + }
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0)
> + return irq;
> +
> + ret = devm_request_threaded_irq(dev, irq, NULL,
> + k1_tsensor_irq_thread,
> + IRQF_ONESHOT, "k1_tsensor", ts);
> + if (ret < 0)
> + return ret;
> +
> + platform_set_drvdata(pdev, ts);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id k1_tsensor_dt_ids[] = {
> + { .compatible = "spacemit,k1-tsensor" },
> + { /* sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(of, k1_tsensor_dt_ids);
> +
> +static struct platform_driver k1_tsensor_driver = {
> + .driver = {
> + .name = "k1_tsensor",
> + .of_match_table = k1_tsensor_dt_ids,
> + },
> + .probe = k1_tsensor_probe,
> +};
> +module_platform_driver(k1_tsensor_driver);
> +
> +MODULE_DESCRIPTION("SpacemiT K1 Thermal Sensor Driver");
> +MODULE_AUTHOR("Shuwei Wu <shuwei.wu@mailbox.org>");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: [PATCH 6/6] arm64: defconfig: make Tegra238 and Tegra264 Pinctrl a loadable module
From: Jon Hunter @ 2026-04-10 8:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, pshete, linux-gpio, devicetree, linux-tegra,
linux-kernel, arnd, bjorn.andersson, conor+dt, dmitry.baryshkov,
ebiggers, geert, krzk+dt, kuninori.morimoto.gx, linusw,
luca.weiss, michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp,
sven, thierry.reding, webgeek1234
In-Reply-To: <9408f231-7a12-425c-b8de-2990d3162bb3@kernel.org>
On 10/04/2026 07:37, Krzysztof Kozlowski wrote:
> On 09/04/2026 15:13, pshete@nvidia.com wrote:
>> From: Prathamesh Shete <pshete@nvidia.com>
>>
>> Building the Pinctrl driver into the kernel image increases its size.
>
> That's obvious.
>
>> These drivers are not required during early boot, build them as a loadable
>> module instead to reduce the kernel image size.
>
> So you replace built-in into module?
>>
>> Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
>> ---
>> arch/arm64/configs/defconfig | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>> index dd1ac01ee29b..f525670d3b84 100644
>> --- a/arch/arm64/configs/defconfig
>> +++ b/arch/arm64/configs/defconfig
>> @@ -711,6 +711,8 @@ CONFIG_PINCTRL_SC8280XP_LPASS_LPI=m
>> CONFIG_PINCTRL_SM8550_LPASS_LPI=m
>> CONFIG_PINCTRL_SM8650_LPASS_LPI=m
>> CONFIG_PINCTRL_SOPHGO_SG2000=y
>> +CONFIG_PINCTRL_TEGRA238=m
>> +CONFIG_PINCTRL_TEGRA264=m
>
> No, you just added as module. Why do we want them in upstream defconfig?
>
> Standard question, already asked Nvidia more than once.
Yes :-)
Prathamesh, what we need to do is ...
1. Add a patch to populate the pinctrl DT nodes for Tegra264 device.
2. In this patch, only enable pinctrl for Tegra264 because we are
lacking an upstream board for Tegra238 for that moment. In the commit
message we should add a comment to indicate with Tegra264 platform is
using this.
We can still merge the DT binding-doc changes and driver for Tegra238,
but no point to enable in the defconfig yet.
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v6 05/10] clk: realtek: Add support for gate clock
From: Yu-Chun Lin @ 2026-04-10 8:19 UTC (permalink / raw)
To: bmasney
Cc: afaerber, conor+dt, cy.huang, cylee12, devicetree, eleanor.lin,
james.tai, jyanchou, krzk+dt, linux-arm-kernel, linux-clk,
linux-kernel, linux-realtek-soc, mturquette, p.zabel, robh, sboyd,
stanley_chang
In-Reply-To: <ac_RcGSpVBpt3S7C@redhat.com>
Hi Brian,
> Hi Cheng-Yu,
>
> On Thu, Apr 02, 2026 at 03:39:52PM +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Introduce clk_regmap_gate_ops supporting enable, disable, is_enabled, and
> > disable_unused for standard regmap gate clocks.
>
> disable_unused is not implemented below.
>
Will remove it from commit message.
> >
> > Add clk_regmap_gate_ro_ops as a read-only variant exposing only is_enabled.
> >
> > 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 | 2 +
> > drivers/clk/realtek/clk-regmap-gate.c | 69 +++++++++++++++++++++++++++
> > drivers/clk/realtek/clk-regmap-gate.h | 65 +++++++++++++++++++++++++
> > 3 files changed, 136 insertions(+)
> > create mode 100644 drivers/clk/realtek/clk-regmap-gate.c
> > create mode 100644 drivers/clk/realtek/clk-regmap-gate.h
> >
> > diff --git a/drivers/clk/realtek/Makefile b/drivers/clk/realtek/Makefile
> > index a89ad77993e9..74375f8127ac 100644
> > --- a/drivers/clk/realtek/Makefile
> > +++ b/drivers/clk/realtek/Makefile
> > @@ -2,5 +2,7 @@
> > obj-$(CONFIG_RTK_CLK_COMMON) += clk-rtk.o
> >
> > clk-rtk-y += common.o
> > +
> > clk-rtk-y += clk-pll.o
> > +clk-rtk-y += clk-regmap-gate.o
> > clk-rtk-y += freq_table.o
> > diff --git a/drivers/clk/realtek/clk-regmap-gate.c b/drivers/clk/realtek/clk-regmap-gate.c
> > new file mode 100644
> > index 000000000000..8738d6c6f8dd
> > --- /dev/null
> > +++ b/drivers/clk/realtek/clk-regmap-gate.c
> > @@ -0,0 +1,69 @@
> > +// 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/bits.h>
> > +#include "clk-regmap-gate.h"
> > +#include <linux/clk-provider.h>
>
> linux/clk-provider.h needs to be included before clk-regmap-gate.h.
>
Ack.
> Also Sashiko reports that linux/export.h should also be included.
https://sashiko.dev/#/patchset/20260402073957.2742459-1-eleanor.lin%40realtek.com
>
> Brian
Ack.
Best Regards,
Yu-Chun.
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-04-10 8:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <3c57275e-0574-46e5-9893-053ae5cc22cb@kernel.org>
On 2026/4/10 下午2:42, Krzysztof Kozlowski wrote:
> On 10/04/2026 05:04, Hongliang Wang wrote:
>> Hi, Krzysztof
>>
>> On 2026/4/9 下午8:11, Krzysztof Kozlowski wrote:
>>> On 09/04/2026 14:03, Hongliang Wang wrote:
>>>> I have a question, the input clock of i2c controller can be described by
>>>> "clocks",
>>>> but there is no existing attribute can describe the divisor of the input
>>>> clock,
>>>> Can I define a new attribute named "clock-div" to describe it in DT
>>>> bindings?
>>>> or do you have any standard solutions for the divisor problem? Thank you.
>>>>
>>> You should determine/calculate the divisor in the driver code, depending
>>> on clocks and bus frequencies. You don't need a property for that, usually.
>> Not only clocks and bus frequencies, but also a third property is required.
>>
>> The frequency divison calculation formula of i2c is
>> Prcescale = clock_a/(clock_div*clock_s)-1
>>
>> There is three parameters in this formula:
>> clock_a represents the input clock, which is described by "clocks",
>> clock_s represents the i2c bus frequency, which is described by
>> "clock-frequency",
>> but there is no existing property to describe clock_div, which has
>> different value
>> on different platform (for example, it is 5 on 7a1000/7a2000, 4 on
>> 2K1000/2K2000,
>> 5.5 on 2K3000.), So I need a property to describe clock_div in this formula.
> So it is fixed per compatible? Then you do not need.
>
OK, I will fix the clock_div based on per compatible. thank you.
> Best regards,
> Krzysztof
Best regards,
Hongliang Wang
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: qcom: x1e80100-microsoft-romulus: add PM8010 camera regulators
From: Bryan O'Donoghue @ 2026-04-10 8:20 UTC (permalink / raw)
To: Oliver White, andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260409201717.108169-2-oliverjwhite07@gmail.com>
On 09/04/2026 21:17, 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>
> ---
> .../dts/qcom/x1e80100-microsoft-romulus.dtsi | 52 +++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi b/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
> index 14b5663a4d48..4427ecae423f 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
> @@ -857,6 +857,57 @@ vreg_l3j: ldo3 {
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
> };
> +
> + regulators-8 {
> + compatible = "qcom,pm8010-rpmh-regulators";
> + qcom,pmic-id = "m";
> +
> + vdd-l1-l2-supply = <&vreg_s5j>;
> + vdd-l3-l4-supply = <&vreg_s4c>;
> + vdd-l7-supply = <&vreg_bob1>;
> +
> + vreg_l1m_1p2: ldo1 {
> + regulator-name = "vreg_l1m_1p2";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1260000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l2m_1p2: ldo2 {
> + regulator-name = "vreg_l2m_1p2";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1260000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l3m_1p8: ldo3 {
> + regulator-name = "vreg_l3m_1p8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1900000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l4m_1p8: ldo4 {
> + regulator-name = "vreg_l4m_1p8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1900000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l5m_2p8: ldo5 {
> + regulator-name = "vreg_l5m_2p8";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <3072000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l7m_2p8: ldo7 {
> + regulator-name = "vreg_l7m_2p8";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <3072000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> + };
> };
>
> &gpu {
> @@ -867,6 +918,7 @@ &gpu_zap_shader {
> firmware-name = "qcom/x1e80100/microsoft/qcdxkmsuc8380.mbn";
> };
>
> +
> &i2c0 {
Dangling newline.
Can be fixed on application of the patch though.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
bod
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
From: Luca Weiss @ 2026-04-10 8:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss
In-Reply-To: <20260410-milos-ipa-v2-0-c699b6b8cf27@fairphone.com>
Configure and enable the node for IPA which enables mobile data on this
device.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
index c1899db46e71..31c6d6627619 100644
--- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
+++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
@@ -690,6 +690,15 @@ vreg_l7p: ldo7 {
/* AW86938FCR vibrator @ 0x5a */
};
+&ipa {
+ firmware-name = "qcom/milos/fairphone/fp6/ipa_fws.mbn";
+ memory-region = <&ipa_fw_mem>;
+
+ qcom,gsi-loader = "self";
+
+ status = "okay";
+};
+
&pm8550vs_c {
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: qcom: milos: Add IPA node
From: Luca Weiss @ 2026-04-10 8:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss, Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260410-milos-ipa-v2-0-c699b6b8cf27@fairphone.com>
Add the description of the IPA block in the Milos SoC.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
arch/arm64/boot/dts/qcom/milos.dtsi | 44 +++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
index a8536a873c69..9ef103d0e00c 100644
--- a/arch/arm64/boot/dts/qcom/milos.dtsi
+++ b/arch/arm64/boot/dts/qcom/milos.dtsi
@@ -1599,6 +1599,50 @@ adreno_smmu: iommu@3da0000 {
dma-coherent;
};
+ ipa: ipa@3f40000 {
+ compatible = "qcom,milos-ipa";
+
+ reg = <0x0 0x03f40000 0x0 0x10000>,
+ <0x0 0x03f50000 0x0 0x5000>,
+ <0x0 0x03e04000 0x0 0xfc000>;
+ reg-names = "ipa-reg",
+ "ipa-shared",
+ "gsi";
+
+ interrupts-extended = <&intc GIC_SPI 654 IRQ_TYPE_EDGE_RISING 0>,
+ <&intc GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH 0>,
+ <&smp2p_ipa_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_ipa_in 1 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "ipa",
+ "gsi",
+ "ipa-clock-query",
+ "ipa-setup-ready";
+
+ clocks = <&rpmhcc RPMH_IPA_CLK>;
+ clock-names = "core";
+
+ interconnects = <&aggre2_noc MASTER_IPA QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &cnoc_main SLAVE_IPA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "memory",
+ "config";
+
+ iommus = <&apps_smmu 0x4a0 0x0>,
+ <&apps_smmu 0x4a2 0x0>;
+
+ qcom,qmp = <&aoss_qmp>;
+
+ qcom,smem-states = <&smp2p_ipa_out 0>,
+ <&smp2p_ipa_out 1>;
+ qcom,smem-state-names = "ipa-clock-enabled-valid",
+ "ipa-clock-enabled";
+
+ sram = <&ipa_modem_tables>;
+
+ status = "disabled";
+ };
+
remoteproc_mpss: remoteproc@4080000 {
compatible = "qcom,milos-mpss-pas";
reg = <0x0 0x04080000 0x0 0x10000>;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/2] IPA v5.2 support for Milos and Fairphone (Gen. 6)
From: Luca Weiss @ 2026-04-10 8:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss, Konrad Dybcio, Dmitry Baryshkov
Add support for IPA v5.2 which can be found in the Milos SoC. And
finally enable it on Fairphone (Gen. 6) so that mobile data (4G/5G/..)
starts working.
Depends on:
* IPA v5.2 support
https://lore.kernel.org/linux-arm-msm/20260410-ipa-v5-2-v2-0-778422a05060@fairphone.com/T/
* Describe IMEM on Milos
https://lore.kernel.org/linux-arm-msm/20260410-milos-imem-v3-0-d215385fa5ab@fairphone.com/T/
I'd like to have specified these as b4 deps but somehow b4's behaving
quite weird with this series, adding many thousands of
prerequisite-patch-id, so I guess manually will need to be enough.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Changes in v2:
- Split net patches into a separate series
- Pick up tags
- Link to v1: https://patch.msgid.link/20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com
---
Luca Weiss (2):
arm64: dts: qcom: milos: Add IPA node
arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 9 +++++
arch/arm64/boot/dts/qcom/milos.dtsi | 44 ++++++++++++++++++++++++
2 files changed, 53 insertions(+)
---
base-commit: 0190c2c6dae368aeb9bf59a449ebe23f24bfa059
change-id: 20260403-milos-ipa-e5705aa87245
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ 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