* Re: [PATCH v16 05/10] x86: kexec_file: Use crash_prepare_headers() helper to simplify code
From: Borislav Petkov @ 2026-06-18 0:41 UTC (permalink / raw)
To: Jinjie Ruan
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
leitao, coxu, Liam.Howlett, ryan.roberts, osandov, jbohac,
cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-6-ruanjinjie@huawei.com>
On Mon, Jun 08, 2026 at 03:34:54PM +0800, Jinjie Ruan wrote:
> Subject: Re: [PATCH v16 05/10] x86: kexec_file: Use crash_prepare_headers() helper to simplify code
Use proper subject prefix: "x86/crash: ..."
> Use the newly introduced crash_prepare_headers() function to replace
> the existing prepare_elf_headers(), allocate cmem and exclude crash kernel
> memory in the crash core, which reduce code duplication.
>
> Only the following three architecture functions need to be implemented:
> - arch_get_system_nr_ranges(). Call get_nr_ram_ranges_callback()
> to pre-count the max number of memory ranges.
>
> - arch_crash_populate_cmem(). Use prepare_elf64_ram_headers_callback()
> to collect the memory ranges and fills them into cmem.
>
> - arch_crash_exclude_ranges(). Exclude the low 1M for x86.
>
> By the way, remove the unused "nr_mem_ranges" in
s/By the way/While at it/
> arch_crash_handle_hotplug_event().
>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Vivek Goyal <vgoyal@redhat.com>
> Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Acked-by: Baoquan He <bhe@redhat.com>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> arch/x86/kernel/crash.c | 89 +++++------------------------------------
> 1 file changed, 11 insertions(+), 78 deletions(-)
With those nitpicks above addressed:
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH v7 0/6] Enable I2C on SA8255p Qualcomm platforms
From: Andi Shyti @ 2026-06-18 1:36 UTC (permalink / raw)
To: Praveen Talari
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Bjorn Andersson, Mukesh Kumar Savaliya, Viken Dadhaniya,
Mattijs Korpershoek, linux-arm-msm, linux-i2c, devicetree,
linux-kernel, bjorn.andersson, konrad.dybcio, aniket.randive,
chandana.chiluveru, prasad.sodagudi, Krzysztof Kozlowski,
Nikunj Kela
In-Reply-To: <20260617-enable-i2c-on-sa8255p-v7-0-ad736dbeab57@oss.qualcomm.com>
Hi Praveen,
> Praveen Talari (6):
> dt-bindings: i2c: Describe SA8255p
> i2c: qcom-geni: Isolate serial engine setup
> i2c: qcom-geni: Move resource initialization to separate function
> i2c: qcom-geni: Use resources helper APIs in runtime PM functions
> i2c: qcom-geni: Store of_device_id data in driver private struct
> i2c: qcom-geni: Enable I2C on SA8255p Qualcomm platforms
merged to i2c/i2c-for-7.2.
Thanks,
Andi
^ permalink raw reply
* RE: [PATCH v4 1/5] dt-bindings: soc: cix,sky1-system-control: add audss system control
From: Joakim Zhang @ 2026-06-18 1:38 UTC (permalink / raw)
To: Conor Dooley, krzk+dt@kernel.org
Cc: mturquette@baylibre.com, sboyd@kernel.org, bmasney@redhat.com,
robh@kernel.org, conor+dt@kernel.org, p.zabel@pengutronix.de,
Gary Yang, cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260617-chummy-automatic-6c11e9958bbf@spud>
Hello,
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, June 17, 2026 11:54 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>
> Cc: mturquette@baylibre.com; sboyd@kernel.org; bmasney@redhat.com;
> robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> p.zabel@pengutronix.de; Gary Yang <gary.yang@cixtech.com>; cix-kernel-
> upstream <cix-kernel-upstream@cixtech.com>; linux-clk@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v4 1/5] dt-bindings: soc: cix,sky1-system-control: add audss
> system control
>
> On Wed, Jun 17, 2026 at 02:04:33PM +0800, joakim.zhang@cixtech.com wrote:
> > From: Joakim Zhang <joakim.zhang@cixtech.com>
> >
> > The Cix Sky1 Audio Subsystem (AUDSS) groups audio-related clock, reset
> > and control registers in a dedicated CRU block. Software reset lines
> > are exposed on the syscon parent via #reset-cells, following the same
> > model as the existing Sky1 FCH and S5 system control bindings.
> >
> > A clock-controller child node is required under the audss syscon. It
> > has no reg property of its own and accesses the parent register block
> > for mux, divider and gate fields.
> >
> > The AUDSS is also controlled by one power domain and reset part.
> >
> > Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> > ---
> > .../soc/cix/cix,sky1-system-control.yaml | 48 +++++++++++++++++++
> > .../reset/cix,sky1-audss-system-control.h | 25 ++++++++++
> > 2 files changed, 73 insertions(+)
> > create mode 100644
> > include/dt-bindings/reset/cix,sky1-audss-system-control.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml
> > b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml index a01a515222c6..5a1cd5c24ade 100644
> > ---
> > a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml
> > +++ b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-contro
> > +++ l.yaml
> > @@ -19,6 +19,7 @@ properties:
> > - enum:
> > - cix,sky1-system-control
> > - cix,sky1-s5-system-control
> > + - cix,sky1-audss-system-control
> > - const: syscon
>
> If the only thing these share are being a reset controller and having a syscon
> fallback, I think it should be in a different file.
>
Thanks for the review. I'll split the AUDSS bindings into a separate YAML file.
One follow-up: should the AUDSS CRU driver be split out as well? I'm inclined to do that, so each binding maps to its own driver, but wanted to check whether you'd prefer a separate audss reset driver or keeping everything in reset-sky1 before I rework the series.
Hello @krzk+dt@kernel.org, what's your opinion?
Thanks,
Joakim
^ permalink raw reply
* RE: [PATCH v4 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss clock controller
From: Joakim Zhang @ 2026-06-18 1:43 UTC (permalink / raw)
To: Conor Dooley
Cc: mturquette@baylibre.com, sboyd@kernel.org, bmasney@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
p.zabel@pengutronix.de, Gary Yang, cix-kernel-upstream,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260617-clinic-blank-61289f8fc1c2@spud>
Hello,
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, June 17, 2026 11:56 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>
> Cc: mturquette@baylibre.com; sboyd@kernel.org; bmasney@redhat.com;
> robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> p.zabel@pengutronix.de; Gary Yang <gary.yang@cixtech.com>; cix-kernel-
> upstream <cix-kernel-upstream@cixtech.com>; linux-clk@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v4 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss
> clock controller
>
> On Wed, Jun 17, 2026 at 02:04:35PM +0800, joakim.zhang@cixtech.com wrote:
> > From: Joakim Zhang <joakim.zhang@cixtech.com>
> >
> > The AUDSS CRU contains an internal clock tree of muxes, dividers and
> > gates for DSP, I2S, HDA, DMAC and related blocks. The clock provider
> > is a child node of the cix,sky1-audss-system-control syscon and
> > accesses registers through the parent MMIO region.
>
> Why can this not just be part of the parent syscon node?
The clock and reset blocks are handled by different subsystems and maintainers (clk vs reset). Putting the clock provider on the parent syscon node would mean a single driver has to register both the reset controller and the clock provider on one device, which doesn't fit well.
Thanks,
Joakim
^ permalink raw reply
* Re: [PATCH v16 00/10] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-06-18 1:45 UTC (permalink / raw)
To: Mike Rapoport
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, pasha.tatashin,
pratyush, ruirui.yang, rdunlap, peterz, feng.tang, dapeng1.mi,
kees, elver, kuba, lirongqing, ebiggers, paulmck, leitao, coxu,
Liam.Howlett, ryan.roberts, osandov, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, adityag, liaoyuanhong,
seanjc, fuqiang.wang, ardb, chenjiahao16, guoren, x86, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, devicetree, kexec
In-Reply-To: <ajLr53EK6mJbng-7@kernel.org>
On 6/18/2026 2:48 AM, Mike Rapoport wrote:
> Hi Jinjie,
>
> On Mon, Jun 08, 2026 at 03:34:49PM +0800, Jinjie Ruan wrote:
>> The crash memory allocation, and the exclude of crashk_res, crashk_low_res
>> and crashk_cma memory are almost identical across different architectures,
>> This patch set handle them in crash core in a general way, which eliminate
>> a lot of duplication code.
>>
>> And add support for crashkernel CMA reservation for arm64 and riscv.
>>
>> This patch set is rebased on v7.1-rc1.
>
> Please rebase this set on v7.2-rc1 once that's out.
>
> I'm going to queue it in the liveupdate tree then to expose to the wider
> testing.
>
> Meanwhile it would be great to chase riscv and x86 maintainers for acks :)
Thanks! That sounds great.
I will rebase this patch set on v7.2-rc1 as soon as it is out and send v17.
In the meantime, I will CC and reach out to the RISC-V and x86
maintainers to request their reviews and Acks.
Best regards,
Jinjie
>
^ permalink raw reply
* Re: [PATCH v16 06/10] riscv: kexec_file: Use crash_prepare_headers() helper to simplify code
From: Jinjie Ruan @ 2026-06-18 1:54 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
leitao, coxu, Liam.Howlett, ryan.roberts, osandov, jbohac,
cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-7-ruanjinjie@huawei.com>
On 6/8/2026 3:34 PM, Jinjie Ruan wrote:
> Use the newly introduced crash_prepare_headers() function to replace
> the existing prepare_elf_headers(), allocate cmem and exclude crash kernel
> memory in the crash core, which reduce code duplication.
>
> Only the following two architecture functions need to be implemented:
> - arch_get_system_nr_ranges(). Call get_nr_ram_ranges_callback()
> to pre-counts the max number of memory ranges.
>
> - arch_crash_populate_cmem(). Use prepare_elf64_ram_headers_callback()
> to collects the memory ranges and fills them into cmem.
Hi Paul, Palmer, Albert, Alexandre and RISC-V maintainers,
Sorry for the interruption.
This patch set aims to clean up and refactor the crash memory allocation
and the exclusion logic of crashk_res, crashk_low_res, and crashk_cma.
Currently, these routines are almost identical across different
architectures, leading to a lot of duplicated code.
This series consolidates the logic into the generic crash core, removing
redundant implementations from architecture-specific directories,
including arch/riscv.
There are no functional changes intended for RISC-V.
The patches will be queued in the liveupdate tree for wider testing.
Could you please take a look at the RISC-V side and consider providing
an Acked-by?
The patch series can be reviewed here:
https://lore.kernel.org/all/20260608073459.3119290-1-ruanjinjie@huawei.com/
Thank you very much for your time and review!
Best regards,
Jinjie
>
> Cc: Paul Walmsley <pjw@kernel.org>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Albert Ou <aou@eecs.berkeley.edu>
> Cc: Alexandre Ghiti <alex@ghiti.fr>
> Cc: Guo Ren <guoren@kernel.org>
> Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Acked-by: Baoquan He <bhe@redhat.com>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> arch/riscv/kernel/machine_kexec_file.c | 47 +++++++-------------------
> 1 file changed, 12 insertions(+), 35 deletions(-)
>
> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
> index 3f7766057cac..439cbc50dfa6 100644
> --- a/arch/riscv/kernel/machine_kexec_file.c
> +++ b/arch/riscv/kernel/machine_kexec_file.c
> @@ -44,6 +44,15 @@ static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
> return 0;
> }
>
> +unsigned int arch_get_system_nr_ranges(void)
> +{
> + unsigned int nr_ranges = 2; /* For exclusion of crashkernel region */
> +
> + walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
> +
> + return nr_ranges;
> +}
> +
> static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
> {
> struct crash_mem *cmem = arg;
> @@ -55,41 +64,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
> return 0;
> }
>
> -static int prepare_elf_headers(void **addr, unsigned long *sz)
> +int arch_crash_populate_cmem(struct crash_mem *cmem)
> {
> - struct crash_mem *cmem;
> - unsigned int nr_ranges;
> - int ret;
> -
> - nr_ranges = 2; /* For exclusion of crashkernel region */
> - walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
> -
> - cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
> - if (!cmem)
> - return -ENOMEM;
> -
> - cmem->max_nr_ranges = nr_ranges;
> - cmem->nr_ranges = 0;
> - ret = walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
> - if (ret)
> - goto out;
> -
> - /* Exclude crashkernel region */
> - ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
> - if (ret)
> - goto out;
> -
> - if (crashk_low_res.end) {
> - ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
> - if (ret)
> - goto out;
> - }
> -
> - ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
> -
> -out:
> - kfree(cmem);
> - return ret;
> + return walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
> }
>
> static char *setup_kdump_cmdline(struct kimage *image, char *cmdline,
> @@ -281,7 +258,7 @@ int load_extra_segments(struct kimage *image, unsigned long kernel_start,
> if (image->type == KEXEC_TYPE_CRASH) {
> void *headers;
> unsigned long headers_sz;
> - ret = prepare_elf_headers(&headers, &headers_sz);
> + ret = crash_prepare_headers(true, &headers, &headers_sz, NULL);
> if (ret) {
> pr_err("Preparing elf core header failed\n");
> goto out;
^ permalink raw reply
* Re: [PATCH v3 2/2] drm/tiny: add support for PIXPAPER 4.26 monochrome e-ink panel
From: LiangCheng Wang @ 2026-06-18 2:33 UTC (permalink / raw)
To: Thomas Zimmermann, Devarsh Thakkar, Maarten Lankhorst,
Maxime Ripard, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Wig Cheng
Cc: dri-devel, devicetree, linux-kernel, Tomi Valkeinen,
LiangCheng Wang
In-Reply-To: <9fb7915b-dc46-45af-bba1-a3d3a59b5e49@suse.de>
Hi Thomas,
Thanks for the review, and no worries about the timing.
Before I spin a v4 for these comments, I'd like to confirm the overall
direction, since it affects whether this should remain a standalone driver
at all.
In parallel, Devarsh Thakkar is adding a generic Solomon SSD16xx e-paper
driver (panel-ssd16xx.c, currently v1 in review). The PIXPAPER 4.26 uses an
SSD1677, which is part of that family; Devarsh has said he will add SSD1677
support in the next revision (v2) of his series, after which this panel
could be supported there as a panel entry rather than as a separate driver.
That work isn't posted yet, but I had agreed that consolidating under
panel-ssd16xx.c is the better long-term direction.
I'd appreciate your guidance on how to proceed -- whether it is better to
keep iterating on this standalone driver, or to hold it and add the
PIXPAPER 4.26 panel to panel-ssd16xx.c once that driver supports SSD1677.
I'm happy to go whichever way you prefer.
Regards,
LiangCheng
^ permalink raw reply
* Re: [PATCH v4 7/7] arm64: dts: qcom: mahua: Switch pcie5_phy ref clock to RPMH_CXO_CLK
From: Qiang Yu @ 2026-06-18 2:34 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <a956a733-7bb0-46f3-bf21-142d5cb8fc3e@oss.qualcomm.com>
On Wed, Jun 17, 2026 at 02:11:33PM +0200, Konrad Dybcio wrote:
> On 6/15/26 10:51 AM, Qiang Yu wrote:
> > On Tue, Jun 09, 2026 at 03:06:02PM +0200, Konrad Dybcio wrote:
> >> On 5/28/26 4:29 AM, Qiang Yu wrote:
> >>> PCIe5 PHY on Mahua gets refclk from CXO0 pad directly, so no QREF
> >>> clkref_en voting is required. Override the clock list to use RPMH_CXO_CLK
> >>> directly instead.
> >>
> >> This is the last piece of the puzzle that this series is missing.
> >> There's no QREF clkref_en, but there is a refgen that needs to be
> >> powered. For PCIe5 on Mahua this would be L2F_E0 (0p9) and L4H_E0
> >> (1p2).
> >>
> >> I think the easiest (laziest?) solution would be to add dummy clocks
> >> in the clkref driver and only toggle the required regulators. Another
> >> option is to defer back to individual drivers (such as PCIe QMPPHY).
> >>
> >> I kinda like the "one central node to drive power" approach, but I'm
> >> not sure others agree, since it stretches truth just a tiny bit
> >> (although not as much as one would think since there are *some*
> >> controls for the transparent-to-the-OS hw pieces in these paths still
> >> in TCSR).. Dmitry, Krzysztof, would you object to that?
> >>
> >
> > PCIe5 PHY on Mahua does not use QREF at all, so there is no refgen for
> > QREF either. The refgen supplies you mentioned are for the PCIe5 PHY
> > itself, not for QREF. For other PHYs that do use QREF, there are two
> > refgens: one for QREF (voted here in the TCSR clkref driver) and one for
> > the PHY (which should be voted in the PHY driver).
>
> Okay, so in this case we have the refgen regulator hardwired into the
> PHY block and we just consume it from the PHY node&driver, am I following
> correctly?
>
The refgen regulators are not hardwired into the QREF or PHY blocks
directly. They power the REFGEN block, which provides the reference
voltage to QREF and PHY.
- Qiang Yu
^ permalink raw reply
* Re: [PATCH 1/3] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Marek Vasut @ 2026-06-18 2:21 UTC (permalink / raw)
To: Geert Uytterhoeven, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdU0SJ0q2hcpu+qZCH3eZ5eFDyo8Z964h9DhuSaQ7QdHSg@mail.gmail.com>
On 6/17/26 10:26 AM, Geert Uytterhoeven wrote:
Hello Geert,
>> +static void rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
>> +{
>> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
>> + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
>> + u32 val;
>> +
>> + /* Make sure MSICAP0 MSIE is configured. */
>> + val = dw_pcie_readl_dbi(dw, MSICAP0);
>> + if (pci_msi_enabled())
>> + val |= MSICAP0_MSIE;
>> + else
>> + val &= ~MSICAP0_MSIE;
>> + dw_pcie_writel_dbi(dw, MSICAP0, val);
>> +
>> + if (!pci_msi_enabled() || pp->use_imsi_rx) {
>> + /* Clear AXIINTC mapping. */
>> + writel(0, rcar->base + AXIINTCADDR);
>> + writel(0, rcar->base + AXIINTCCONT);
>> + } else {
>> + /* Point AXIINTC to GIC ITS and enable. */
>> + writel(AXIINTCADDR_VAL, rcar->base + AXIINTCADDR);
>> + writel(INTC_EN | INTC_MASK, rcar->base + AXIINTCCONT);
>> + }
>> +
>> + /* Configure MSI interrupt signal */
>> + val = readl(rcar->base + PCIEINTSTS0EN);
>> + if (pci_msi_enabled())
>> + val |= MSI_CTRL_INT;
>> + else
>> + val &= ~MSI_CTRL_INT;
>> + writel(val, rcar->base + PCIEINTSTS0EN);
>> +}
>> +
>> static int rcar_gen4_pcie_enable_device(struct pci_host_bridge *bridge,
>
> FTR, this has a contextual dependency on "[PATCH v2] PCI: rcar-gen4:
> Limit Max_Read_Request_Size and Max_Payload_Size to 256 Bytes"
> (https://lore.kernel.org/all/20260519195219.189323-1-marek.vasut+renesas@mailbox.org).
It is not an explicit dependency, I only had these patches in my tree
and clearly that was an interaction. I'll rebase this dependency out for V2.
Thanks!
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marek Vasut @ 2026-06-18 2:38 UTC (permalink / raw)
To: Geert Uytterhoeven, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdX7XuHQDSsX4P7NZ46_OnCX2o25szuALwSs2z+PHq+JNg@mail.gmail.com>
On 6/17/26 9:09 AM, Geert Uytterhoeven wrote:
Hello Geert,
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -4901,6 +4901,18 @@ static bool __maybe_unused its_enable_rk3568002(void *data)
>> return true;
>> }
>>
>> +static bool __maybe_unused its_enable_renesas_gen4(void *data)
>> +{
>> + if (!of_machine_is_compatible("renesas,r8a779f0") &&
>> + !of_machine_is_compatible("renesas,r8a779g0") &&
>> + !of_machine_is_compatible("renesas,r8a779h0"))
>
> of_machine_compatible_match() with an array of strings might generate
> smaller code (I didn't check if 3 entries is enough to trip the balance).
Let me handle that as part of suggestion from Marc.
^ permalink raw reply
* Re: [PATCH 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marek Vasut @ 2026-06-18 2:50 UTC (permalink / raw)
To: Marc Zyngier, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <864ij1tyrj.wl-maz@kernel.org>
On 6/17/26 9:24 AM, Marc Zyngier wrote:
Hello Marc,
>> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
>> or APB interface configured to 32 bit, it can therefore access only
>> the first 4 GiB of physical address space. This information comes from
>> R-Car V4H Interface Specification sheet, there is currently no technical
>> update number assigned to this limitation. Further input from hardware
>> engineer indicates that this limitation also applies to R-Car S4 and V4M.
>> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
>> limitation.
My concern is this ^ , I do not have an erratum number, because there
isn't one. I am in touch with the hardware engineer and I did get a
glimpse at internal details of the three SoC, which confirm the
limitations. Is this sufficient ?
>> Note that the 0x0201743b GIC600 ID is not Renesas-specific, it is
>> common for many ARM GICv3 implementations. Therefore, add an extra
>
> Not quite. It designates GIC600 unambiguously.
What I am trying to communicate is, that the 0x0201743b ID is not ID of
the Renesas GIC implementation, but it is a generic ARM GIC600 ID. That
is why we cannot match the quirk on the ID (it is generic ARM GIC600
ID), and instead we have to match the quirk on the [ ID combined with
of_machine_is_compatible("renesas,...") ].
> It is just that GIC600
> is integrated in zillions of SoCs, most of which don't have this
> problem (the machine I'm typing this from has a GIC600 *and* 96GB of
> RAM).
Right.
Shall I reword this paragraph somehow to make it clearer ?
>> of_machine_is_compatible() check.
>>
>> The GIC600 implementation in R-Car S4/V4H/V4M is r1p6.
>
> Is this relevant?
I included it for the sake of completeness and to provide all relevant
information, based on previous discussions about similar limitations
that I could find on lore.k.o
[...]
>> +#ifdef CONFIG_RENESAS_ERRATUM_GEN4GICITS1
>> + {
>> + .desc = "ITS: Renesas R-Car Gen4 GIC600 32-bit limit",
>> + .iidr = 0x0201743b,
>> + .mask = 0xffffffff,
>> + .init = its_enable_renesas_gen4,
>> + },
>> #endif
>> {
>> }
>
>
> Honestly, that's a bit too much copy-paste for my taste. Just refactor
> the erratum handling to be more generic, something like this:
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 291d7668cc8da..380c4758647d2 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -4894,10 +4894,17 @@ static bool __maybe_unused its_enable_quirk_hip09_162100801(void *data)
> return true;
> }
>
> -static bool __maybe_unused its_enable_rk3568002(void *data)
> +static const char * const dma_impaired_platforms[] = {
> +#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
> + "rockchip,rk3566",
> + "rockchip,rk3568",
> +#endif
> + NULL,
> +};
> +
> +static bool __maybe_unused its_enable_dma32(void *data)
> {
> - if (!of_machine_is_compatible("rockchip,rk3566") &&
> - !of_machine_is_compatible("rockchip,rk3568"))
> + if (!of_machine_compatible_match(dma_impaired_platforms))
> return false;
>
> gfp_flags_quirk |= GFP_DMA32;
> @@ -4972,14 +4979,12 @@ static const struct gic_quirk its_quirks[] = {
> .property = "dma-noncoherent",
> .init = its_set_non_coherent,
> },
> -#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
> {
> - .desc = "ITS: Rockchip erratum RK3568002",
> + .desc = "ITS: Broken GIC600 integration limited to 32bit PA",
> .iidr = 0x0201743b,
> .mask = 0xffffffff,
> - .init = its_enable_rk3568002,
> + .init = its_enable_dma32,
> },
> -#endif
> {
> }
> };
>
> Then add the two lines you need in a separate patch.
Will do in V2.
> In the future, please provide a cover letter when you have more than a
> single patch (git will happily generate one for you).
OK
^ permalink raw reply
* Re: [PATCH 1/3] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Marek Vasut @ 2026-06-18 3:21 UTC (permalink / raw)
To: Manivannan Sadhasivam, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Marc Zyngier, Rob Herring,
devicetree, linux-arm-kernel, linux-doc, linux-kernel,
linux-renesas-soc
In-Reply-To: <lstafqaogzunb2azyqwvtt3swrk42nu3n5zyct2la5fqxomaqg@wyrz3qolhist>
On 6/17/26 12:33 PM, Manivannan Sadhasivam wrote:
Hello Manivannan,
[...]
>> +/* INTC address */
>> +#define AXIINTCADDR 0x0a00
>> +/* GITS GIC ITS translation register */
>> +#define AXIINTCADDR_VAL 0xf1050000
>
> As Marc pointed out, this address should be fetched from DT, not hardcoded in
> the driver.
I will reply to Marc when I have this ready for V2.
>> +
>> +/* INTC control & mask */
>> +#define AXIINTCCONT 0x0a04
>> +#define INTC_EN BIT(31)
>> +#define INTC_MASK GENMASK(11, 2)
>> +
>> /* PCIe Power Management Control */
>> #define PCIEPWRMNGCTRL 0x0070
>> #define APP_CLK_REQ_N BIT(11)
>> @@ -305,6 +319,39 @@ static struct rcar_gen4_pcie *rcar_gen4_pcie_alloc(struct platform_device *pdev)
>> return rcar;
>> }
>>
>> +static void rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
>> +{
>> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
>> + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
>> + u32 val;
>> +
>> + /* Make sure MSICAP0 MSIE is configured. */
>> + val = dw_pcie_readl_dbi(dw, MSICAP0);
>> + if (pci_msi_enabled())
>> + val |= MSICAP0_MSIE;
>> + else
>> + val &= ~MSICAP0_MSIE;
>> + dw_pcie_writel_dbi(dw, MSICAP0, val);
>> +
>> + if (!pci_msi_enabled() || pp->use_imsi_rx) {
>
> If MSI is not enabled, then what's the point in clearing these registers (also
> above)? I see it as a redundant code. Is there a necessity to clear them?
AXIINTCCONT INTC_EN should not be set if MSI is disabled, this code
makes sure it is not set, even if it might have been left set e.g. by
prior stage. So no, this is not redundant code, this makes sure the
controller is correctly configured.
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: rng: timeriomem_rng: add reg-io-width and mask properties
From: Krzysztof Kozlowski @ 2026-06-18 4:11 UTC (permalink / raw)
To: Jad Keskes, Krzysztof Kozlowski
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Conor Dooley,
Alexander Clouter, linux-crypto, devicetree, linux-kernel
In-Reply-To: <20260617114436.1909659-1-inasj268@gmail.com>
On 17/06/2026 13:44, Jad Keskes wrote:
> Add optional reg-io-width (1, 2, or 4 bytes) and mask properties to the
> binding. reg-io-width selects the bus access size, mask is ANDed with
> the raw register value to allow only the entropy-bearing bits through.
>
> Update the example to show a typical 1-byte configuration.
> Update SPDX to dual license to match kernel convention.
And did you Cc all of the copyright holders?
> Drop the misleading '32-bit aligned' constraint from the reg
> description since alignment now depends on the configured width.
>
> Signed-off-by: Jad Keskes <inasj268@gmail.com>
> ---
> .../bindings/rng/timeriomem_rng.yaml | 48 +++++++++++++++----
> 1 file changed, 40 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml b/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml
> index 4754174e9849..740bc52bf474 100644
> --- a/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml
> +++ b/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml
> @@ -1,10 +1,16 @@
> -# SPDX-License-Identifier: GPL-2.0-only
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Don't mix multiple changes into one commit.
> %YAML 1.2
> ---
> $id: http://devicetree.org/schemas/rng/timeriomem_rng.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: TimerIO Random Number Generator
> +title: Timer IOMEM Hardware Random Number Generator
> +
> +description: |
> + This binding covers platforms that have a single IO memory address which
Do not describe the binding. Describe the hardware.
> + provides periodic random data. The driver reads from the address at a
Do not describe drivers. Describe the hardware.
> + fixed interval, returning a configurable-width value masked to the desired
> + bits.
>
> maintainers:
> - Krzysztof Kozlowski <krzk@kernel.org>
> @@ -13,9 +19,17 @@ properties:
> compatible:
> const: timeriomem_rng
>
> + reg:
> + maxItems: 1
> + description:
> + Base address to sample from. Must be aligned to the configured access
> + width (1, 2, or 4 bytes) and at least that wide.
> +
> period:
> $ref: /schemas/types.yaml#/definitions/uint32
> - description: wait time in microseconds to use between samples
> + description:
> + Interval in microseconds between reads. New random data is expected to
> + be available at this rate.
>
> quality:
> $ref: /schemas/types.yaml#/definitions/uint32
> @@ -26,16 +40,26 @@ properties:
> instead. Note that the default quality is usually zero which disables
> using this rng to automatically fill the kernel's entropy pool.
>
> - reg:
> - maxItems: 1
> + reg-io-width:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 4
> + enum: [1, 2, 4]
> description:
> - Base address to sample from. Currently 'reg' must be at least four bytes
> - wide and 32-bit aligned.
> + Access width in bytes. Determines whether the read is performed as
> + an 8-bit, 16-bit, or 32-bit bus access.
> +
> + mask:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 0xFFFFFFFF
> + description:
> + Mask applied to the value read from the register. Bits set to 0 in
> + the mask are cleared in the output data. Default (no mask) passes
> + all bits through.
>
> required:
> - compatible
> - - period
> - reg
> + - period
>
> additionalProperties: false
>
> @@ -46,3 +70,11 @@ examples:
> reg = <0x44 0x04>;
> period = <1000000>;
> };
> +
> + rng@64 {
> + compatible = "timeriomem_rng";
> + reg = <0x64 0x01>;
> + period = <50000>;
> + reg-io-width = <1>;
> + mask = <0xFF>;
> + };
Grow existing example. Or why can't it grow?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: rng: timeriomem_rng: add reg-io-width and mask properties
From: Krzysztof Kozlowski @ 2026-06-18 4:12 UTC (permalink / raw)
To: Jad Keskes, Krzysztof Kozlowski
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Conor Dooley,
Alexander Clouter, linux-crypto, devicetree, linux-kernel
In-Reply-To: <20260617114436.1909659-1-inasj268@gmail.com>
On 17/06/2026 13:44, Jad Keskes wrote:
> Add optional reg-io-width (1, 2, or 4 bytes) and mask properties to the
> binding. reg-io-width selects the bus access size, mask is ANDed with
> the raw register value to allow only the entropy-bearing bits through.
>
> Update the example to show a typical 1-byte configuration.
> Update SPDX to dual license to match kernel convention.
> Drop the misleading '32-bit aligned' constraint from the reg
> description since alignment now depends on the configured width.
>
> Signed-off-by: Jad Keskes <inasj268@gmail.com>
> ---
> .../bindings/rng/timeriomem_rng.yaml | 48 +++++++++++++++----
> 1 file changed, 40 insertions(+), 8 deletions(-)
... And where is any changelog?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 2/8] media: v4l2-fwnode: Add common helper library for 1-to-1 subdev registration
From: Frank Li @ 2026-06-18 4:13 UTC (permalink / raw)
To: Sakari Ailus
Cc: Mauro Carvalho Chehab, Michael Riesch, Laurent Pinchart, Frank Li,
Martin Kepplinger-Novakovic, Rui Miguel Silva, Purism Kernel Team,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-media, linux-kernel,
imx, devicetree, linux-arm-kernel
In-Reply-To: <ajMhZP5YHuQdhc5M@kekkonen.localdomain>
On Thu, Jun 18, 2026 at 01:36:20AM +0300, Sakari Ailus wrote:
> Hi Frank,
>
> Thanks for the patch.
Thanks for you quick reply.
>
> On Wed, Jun 17, 2026 at 03:50:12PM -0400, Frank.Li@oss.nxp.com wrote:
> > From: Frank Li <Frank.Li@nxp.com>
> >
> > Many V4L2 subdev drivers implement the same registration and media pad
> > setup logic for simple pipelines consisting of a single sink pad and a
> > single source pad. As a result, the same boilerplate code is duplicated
> > across multiple drivers.
> >
> > Introduce a common helper library for 1-to-1 subdevs to encapsulate the
> > registration, media entity initialization, and cleanup paths. Drivers
> > can embed a struct v4l2_subdev_1to1 instance and use the provided helper
> > APIs instead of open-coding the setup sequence.
>
> I appreciate your efforts in trying to reduce the amount of code drivers
> need simply to get things done but I think there are a few issues with the
> approach taken in this patch:
>
> - The new helpers aren't generic enough, but require two pads; one sink,
> one source.
It can cover many case already, there are many bridge type subdev. after
glace of all code, many CSI2RX is type device. It should one kind important
type/case, like sensors.
And I plan do 1 TO N replicator driver, which duplicate 1 sink pad to N
source pad (with/without register config), plus exist video-mux driver,
It think It can cover more than 80% cases.
> You could provide special helpers for just this case, but
> right now it looks like that if there's something you need that the
> helper assumes you don't, you can't use the helper at all. In other
> words, more modularity would be nice.
We can add it later if need, which easy to replace 1to1 API, like I did
for sensor one.
>
> - The new helper should work with the existing types and not add new types
> (struct v4l2_subdev_1to1).
May be save vep data into v4l2_subdev to avoid parse it every time. and
enhence media_entity_pads_init() to avoid refer caller data.
>
> - There should be a way to provide default V4L2 fwnode endpoint
> configuration as well as to validate the obtained configuration.
Do you means remote_bustype_cap_mask information get from a callback?
>
> I don't have a good proposal to address the above but at least one way I
> can think of making error handling easier would be to use devm_() for
> teardown in more places we to today. That certainly does have its own
> issues though.
I tried it before, media and v4l2's clean up is not revised order of init.
Sorry, I can't find original thread. I remember laurnet pinchart said there
are order problem.
1 v4l2_subdev_init()
2. v4l2_async_subdev_nf_init()
3. v4l2_async_nf_register()
4. media_entity_pads_init()
5 v4l2_async_register_subdev()
v4l2_async_unregister_subdev(sd);
v4l2_subdev_cleanup(sd); // Not sure if it save to move to last step
media_entity_cleanup(&sd->entity);
v4l2_async_nf_unregister(&csi2->notifier);
v4l2_async_nf_cleanup(&csi2->notifier);
Frank
>
> --
> Kind regards,
>
> Sakari Ailus
^ permalink raw reply
* Re: [PATCH] dt-bindings: sound: add toshiba,apb-dummy-codec binding
From: Krzysztof Kozlowski @ 2026-06-18 4:15 UTC (permalink / raw)
To: Pablo D. Bergamasco
Cc: broonie, conor+dt, devicetree, krzk+dt, lgirdwood, linux-kernel,
linux-sound, mgreer, robh, vaibhav.sr
In-Reply-To: <20260617145509.1782137-1-danpablo@gmail.com>
On 17/06/2026 16:55, Pablo D. Bergamasco wrote:
> On Wed, Jun 17, 2026, Krzysztof Kozlowski wrote:
>> Nope. We don't take bindings for staging. Isn't this documented in
>> staging docs already?
>
> I checked drivers/staging/greybus/Documentation/ and found only
> firmware and sysfs documentation. There is no existing DT binding
> documentation for the "toshiba,apb-dummy-codec" compatible string.
>
> Should I add the binding documentation within the staging directory
> itself, or is there a preferred approach for staging drivers?
We don't take bindings for staging drivers outside. I do not know if it
makes sense to have any bindings inside staging itself. Honestly it does
not matter to me.
You should not be fixing checkpatch warnings blindly.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level triggered.
From: Parthiban.Veerasooran @ 2026-06-18 4:26 UTC (permalink / raw)
To: Selvamani.Rajagopal, andrew+netdev, davem, edumazet, kuba, pabeni,
robh, krzk+dt, conor+dt, Pier.Beruto
Cc: andrew, netdev, linux-kernel, Conor.Dooley, devicetree
In-Reply-To: <CYYPR02MB9828B41845A534BDF0B0C17083E42@CYYPR02MB9828.namprd02.prod.outlook.com>
Hi Selvamani,
On 17/06/26 10:24 am, Selvamani Rajagopal wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
>> Subject: Re: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level
>> triggered.
>>
>>
>> Hi Selvamani,
>>
>> I did a quick test by connecting Mikroe LAN8651 Click to a Raspberry Pi
>> 4 and shared the feedback below. Please let me know if you need any
>> further details.
>
> Parthiban,
>
> Thanks for testing this.
>
> Though the NULL pointer reference after skb_put is a clue, I am working with our team to see we can see this crash in our setup.
> Will keep you updated.
Sure, thank you.
Best regards,
Parthiban V
>
>>
>> [ 8276.691064] eth1: Receive buffer overflow error
>> [ 8281.662600] Unable to handle kernel NULL pointer dereference at
>> virtual address 0000000000000074> drm_panel_orientation_quirks backlight nfnetlink
>> [ 8281.839427] pc : skb_put+0x14/0x80
>> [ 8281.842864] lr : oa_tc6_macphy_threaded_irq+0x428/0x880 [lan865x_t1s]
>
^ permalink raw reply
* RE: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level triggered.
From: Selvamani Rajagopal @ 2026-06-18 4:26 UTC (permalink / raw)
To: Parthiban.Veerasooran@microchip.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Piergiorgio Beruto
Cc: andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Conor.Dooley@microchip.com,
devicetree@vger.kernel.org
In-Reply-To: <7c89df6b-32ac-46c8-8400-945879037f2e@microchip.com>
> Subject: Re: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level
> triggered.
>
>
>
> Test case 2: Two LAN8651 instances on the same RPI4
>
> Setup:
>
> RPI4 #1 + LAN8651 (IP: 192.168.10.101) <--- RPI4 #2 + EVB-LAN8670-USB
> (IP: 192.168.10.102)
> RPI4 #1 + LAN8651 (IP: 192.168.20.101) <--- RPI4 #2 + EVB-LAN8670-USB
> (IP: 192.168.20.102)
>
> Result:
>
Parthiban,
It appears that we can't reproduce the crash you saw in your setup. Code has been running
all day with 5+ millions of "™Receive buffer overflow error" (Yes. I added a counter to see how
many times, code returns EAGAIN error code)
One obvious reason is that our EVB has only one network interface. Just like your setup in Test case 1,
where you didn't see any issue.
AI review bot Sashiko suggested one potential issue where skb pointers aren't protected. But those
concerns are in transmit path. This crash seems to be in receive path. If you think that might help,
I can generate a patch for that.
What do you suggest? Since you are able to see the crash, would you have time to investigate?
Sincerely
Selva
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths
From: Aaron Kling @ 2026-06-18 4:37 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <eddd77cc-fabc-4a2e-aff9-602895495ad1@oss.qualcomm.com>
On Wed, Jun 17, 2026 at 5:41 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 6/6/26 12:36 AM, Aaron Kling via B4 Relay wrote:
> > From: Aaron Kling <webgeek1234@gmail.com>
> >
> > Add the OPP tables for each CPU cluster (cpu0-1-2-3-4-5 & cpu6-7) to
> > permit scaling the Last Level Cache Controller (LLCC) and DDR frequency
> > by aggregating bandwidth requests of all CPU core with reference to the
> > current OPP they are configured in by the hardware.
> >
> > The effect is proper caches & DDR frequency scaling when CPU cores
> > change frequency.
> >
> > The OPP tables were built using the downstream memlat ddr & llcc tables
> > for each cluster types with the actual cpufreq LUT tables from running a
> > CQ8725S device.
> >
> > Also add the interconnect entry for each cpu, with 2 different paths:
> > - CPU to Last Level Cache Controller (LLCC)
> > - Last Level Cache Controller (LLCC) to DDR
> >
> > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > ---
> > arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths
> > ---
>
> [...]
>
> > + cpu6_opp_table: opp-table-cpu6 {
> > + compatible = "operating-points-v2";
> > + opp-shared;
> > +
> > + opp-1017600000 {
> > + opp-hz = /bits/ 64 <1017600000>;
> > + opp-peak-kBps = <(1353000 * 16) (350000 * 4)>;
>
> I think this should be * 4 in both cases since the interconnect driver
> ignores the channel count for a node in peak voting. We may have a bug
> in all other DTs here.
If this is confirmed, I can update this patch. I based the
calculations on my sm8550 copy of this change, which in turn was based
on the sm8650 change. If this is wrong, that means one piece is
scaling 4x too quickly? Making it a power consumption issue, not a
performance issue.
> BTW, are there no lower OPPs for the fast cores?
Not on cq8725s at least. These lists came from an AYN Odin 3 with that
soc. I don't have any sm8750 proper devices to see if that's any
different.
Aaron
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: PCI: qcom: Document the Hawi PCIe Controller
From: Matthew Leung @ 2026-06-18 4:44 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, linux-arm-msm, linux-pci,
devicetree, linux-kernel
In-Reply-To: <m2kwzigrz4fbdedzr2bj2auqtvafj6qstbplghssato4d6tdnd@ftug3clgxmd6>
On Fri, Jun 12, 2026 at 09:22:10AM +0300, Dmitry Baryshkov wrote:
> On Thu, Jun 11, 2026 at 06:17:57PM -0700, Matthew Leung wrote:
> > On Sun, Jun 07, 2026 at 11:01:10PM +0300, Dmitry Baryshkov wrote:
> > > On Fri, May 29, 2026 at 01:10:08AM +0000, Matthew Leung wrote:
> > > > Add a dedicated schema for the PCIe controllers found on the Hawi
> > > > platform.
> > > >
> > > > Signed-off-by: Matthew Leung <matthew.leung@oss.qualcomm.com>
> > > > ---
> > > > .../devicetree/bindings/pci/qcom,hawi-pcie.yaml | 204 +++++++++++++++++++++
> > > > 1 file changed, 204 insertions(+)
> > > >
> > > > +
> > > > +examples:
> > > > + - |
> > > > + #include <dt-bindings/clock/qcom,hawi-gcc.h>
> > > > + #include <dt-bindings/gpio/gpio.h>
> > > > + #include <dt-bindings/interconnect/qcom,icc.h>
> > > > + #include <dt-bindings/interconnect/qcom,hawi-rpmh.h>
> > >
> > > Stop referencing clocks and interconnect header files. Replace used nocs
> > > with ephemeral values.
> > >
> > > > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > +
> > > > + soc {
> > > > + #address-cells = <2>;
> > > > + #size-cells = <2>;
> > >
> > > Not looking around should be a sin. Take a look at other Qualcomm PCIe
> > > bindings. Compare them to yours. Then fix yours to follow.
> > >
> > > Hint: the extra soc node is useless. This is just an example, so use the
> > > default, 1 cells for address and size.
> >
> > Thank you for the feedback. This new binding follows the examples set in
> > the qcom,pcie-sm8x50 bindings and retains the same formatting (extra soc
> > node and header references).
>
> Hmm, interesting. Then I'm a sinner :-)
>
> I looked at msm8996, but I didn't notice that the rest of the files use
> the soc node (and match what you've sent). Please excuse me.
It's all good! :)
>
> >
> > I understand the example can be simplified with your suggestions but
> > want additional confirmation that these will be the convention for new
> > bindings going forward.
>
> At least, let's keep it for now. The other comment stands. To remove
> dependencies please use ephemeral nodes instead of depending on DT
> bindings from other subsystems.
Agree. Will update in next version.
>
> >
> > >
> > > > +
> > > > + pcie@1c00000 {
> > > > + compatible = "qcom,hawi-pcie";
> > > > + reg = <0 0x01c00000 0 0x3000>,
> > > > + <0 0x40000000 0 0xf1d>,
> > > > + <0 0x40000f20 0 0xa8>,
> > > > + <0 0x40001000 0 0x1000>,
> > > > + <0 0x40100000 0 0x100000>;
> > > > + reg-names = "parf", "dbi", "elbi", "atu", "config";
> > > > + ranges = <0x01000000 0x0 0x00000000 0x0 0x40200000 0x0 0x100000>,
> > > > + <0x02000000 0x0 0x40300000 0x0 0x40300000 0x0 0x3d00000>;
> > > > +
> > > > + bus-range = <0x00 0xff>;
> > > > + device_type = "pci";
> > > > + linux,pci-domain = <0>;
> > > > + num-lanes = <2>;
> > > > +
> > > > + #address-cells = <3>;
> > > > + #size-cells = <2>;
> > > > +
> > > > + clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
> > >
> > > <&gcc_pcie_0_aux_clk>, etc.
> > >
> > > > + <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
> > > > + <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
> > > > + <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
> > > > + <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>,
> > > > + <&gcc GCC_AGGRE_NOC_PCIE_AXI_CLK>,
> > > > + <&gcc GCC_CNOC_PCIE_SF_AXI_CLK>;
> > >
> > > --
> > > With best wishes
> > > Dmitry
>
> --
> With best wishes
> Dmitry
^ permalink raw reply
* [PATCH 00/11] pmdomain: st: ux500: Implement ux500 power domains
From: Linus Walleij @ 2026-06-18 5:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Mark Brown, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Vinod Koul, Frank Li, Lee Jones
Cc: linux-arm-kernel, devicetree, linux-pm, dri-devel, dmaengine,
Linus Walleij, Linus Walleij
Today the Ux500 SoC specifically DB8500 is using what is called
"EPOD regulators" (EPOD = Electric POwer Domain) to control its power domains.
This was done like this because at the time, power domains did not exist as a
concept in the Linux kernel.
This patch series completes the ambitious work started in
commit cd931dcfda5e ("ARM: ux500: Initial support for PM domains") which added
a dummy domain driver for Ux500 in the following steps:
- Convert the old Ux500 power domain text DT bindings to YAML schema.
- Extend the bindings with all the 16 power domains actually existing
in the hardware.
- Add these domains to the existing ux500 power domain driver (still as dummy
domains).
- Add the power domains to the DB8500 SoC DTSI file.
- Move code over from the EPOD regulators to the actual power domain driver.
Since the two drivers now control the same hardware, make the drivers
mutually exclusive.
- Modify the MCDE display driver to use the power domain instead of
the EPOS regulators.
- Modify the DMA40 DMA controller to use the power domain instead of
the EPOD regulators.
- Delete the old EPOD regulators.
- Implement regulators activating the VANA and VSMPS2 power domains for the
power domain voltage rails that are routed off-chip as external supplies,
re-using the existing EPOD regulator bindings.
- Delete the references to the unused EPOD regulators from the device tree,
keeping the references to VANA and VSMPS2.
This is a bit of brain transplant on the Ux500, and the series is not very
boot-bisectable.
For simplicity, the series can be merged in separate paths and subsystems as
there are no build-time dependencies, as long as the result ends up in kernel
v7.3. Once the concept and patches are ACKed by the power domain folks, I will
send the patches that can be split out individually to each maintainer and
it can all be merged in parallel.
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
Linus Walleij (11):
dt-bindings: power: Convert Ux500 PM domains to schema
dt-bindings: Add the actual power domains on U8500
pmdomain: st: ux500: Implement more power domains
ARM: dts: ux500: Rename power domains node
ARM: dts: ux500: Add power domains
pmdomain: st: ux500: Control DB8500 EPODs
drm/mcde: Use power domain for display power
dmaengine: ste_dma40: Use power domain for LCLA SRAM
regulator: db8500-prcmu: Remove EPOD regulators
regulator: db8500: Add power domain regulators
ARM: dts: ux500: Remove DB8500 EPOD regulators
.../devicetree/bindings/arm/ux500/power_domain.txt | 35 --
.../power/stericsson,ux500-pm-domains.yaml | 46 ++
MAINTAINERS | 1 +
arch/arm/boot/dts/st/ste-dbx5x0.dtsi | 134 ++----
arch/arm/mach-ux500/Kconfig | 2 +-
drivers/dma/ste_dma40.c | 97 ++--
drivers/gpu/drm/mcde/mcde_clk_div.c | 4 +-
drivers/gpu/drm/mcde/mcde_display.c | 11 +-
drivers/gpu/drm/mcde/mcde_drm.h | 2 -
drivers/gpu/drm/mcde/mcde_drv.c | 63 +--
drivers/gpu/drm/mcde/mcde_dsi.c | 1 -
drivers/mfd/db8500-prcmu.c | 239 +---------
drivers/pmdomain/st/ste-ux500-pm-domain.c | 353 ++++++++++++++-
drivers/regulator/Kconfig | 22 +-
drivers/regulator/Makefile | 3 +-
drivers/regulator/db8500-prcmu.c | 501 ---------------------
drivers/regulator/db8500-regulator.c | 221 +++++++++
drivers/regulator/dbx500-prcmu.c | 155 -------
drivers/regulator/dbx500-prcmu.h | 55 ---
include/dt-bindings/arm/ux500_pm_domains.h | 17 +-
include/linux/regulator/db8500-prcmu.h | 38 --
21 files changed, 748 insertions(+), 1252 deletions(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260618-ux500-power-domains-v7-1-3c9d095828c2
Best regards,
--
Linus Walleij <linusw@kernel.org>
^ permalink raw reply
* [PATCH 01/11] dt-bindings: power: Convert Ux500 PM domains to schema
From: Linus Walleij @ 2026-06-18 5:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Mark Brown, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Vinod Koul, Frank Li, Lee Jones
Cc: linux-arm-kernel, devicetree, linux-pm, dri-devel, dmaengine,
Linus Walleij
In-Reply-To: <20260618-ux500-power-domains-v7-1-v1-0-eb5e50b1a588@kernel.org>
Convert the legacy Ux500 power domain text binding to YAML.
Move it under bindings/power.
Reference the generic power-domain schema.
Update MAINTAINERS for the new path.
Assisted-by: Codex:gpt-5-5
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
.../devicetree/bindings/arm/ux500/power_domain.txt | 35 ----------------
.../power/stericsson,ux500-pm-domains.yaml | 46 ++++++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 47 insertions(+), 35 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/ux500/power_domain.txt b/Documentation/devicetree/bindings/arm/ux500/power_domain.txt
deleted file mode 100644
index 5679d1742d3e..000000000000
--- a/Documentation/devicetree/bindings/arm/ux500/power_domain.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-* ST-Ericsson UX500 PM Domains
-
-UX500 supports multiple PM domains which are used to gate power to one or
-more peripherals on the SOC.
-
-The implementation of PM domains for UX500 are based upon the generic PM domain
-and use the corresponding DT bindings.
-
-==PM domain providers==
-
-Required properties:
- - compatible: Must be "stericsson,ux500-pm-domains".
- - #power-domain-cells : Number of cells in a power domain specifier, must be 1.
-
-Example:
- pm_domains: pm_domains0 {
- compatible = "stericsson,ux500-pm-domains";
- #power-domain-cells = <1>;
- };
-
-==PM domain consumers==
-
-Required properties:
- - power-domains: A phandle and PM domain specifier. Below are the list of
- valid specifiers:
-
- Index Specifier
- ----- ---------
- 0 DOMAIN_VAPE
-
-Example:
- sdi0_per1@80126000 {
- compatible = "arm,pl18x", "arm,primecell";
- power-domains = <&pm_domains DOMAIN_VAPE>
- };
diff --git a/Documentation/devicetree/bindings/power/stericsson,ux500-pm-domains.yaml b/Documentation/devicetree/bindings/power/stericsson,ux500-pm-domains.yaml
new file mode 100644
index 000000000000..72c39c083efb
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/stericsson,ux500-pm-domains.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/stericsson,ux500-pm-domains.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST-Ericsson UX500 power domains
+
+maintainers:
+ - Linus Walleij <linusw@kernel.org>
+ - Ulf Hansson <ulfh@kernel.org>
+
+description:
+ The UX500 power domain controller gates power to one or more peripherals on
+ the SoC. Domain specifiers use one cell containing one of the DOMAIN_*
+ indexes defined in dt-bindings/arm/ux500_pm_domains.h.
+
+allOf:
+ - $ref: power-domain.yaml#
+
+properties:
+ compatible:
+ const: stericsson,ux500-pm-domains
+
+ '#power-domain-cells':
+ const: 1
+
+required:
+ - compatible
+ - '#power-domain-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/arm/ux500_pm_domains.h>
+
+ pm_domains: power-controller {
+ compatible = "stericsson,ux500-pm-domains";
+ #power-domain-cells = <1>;
+ };
+
+ sdi0_per1@80126000 {
+ compatible = "arm,pl18x", "arm,primecell";
+ power-domains = <&pm_domains DOMAIN_VAPE>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index c8d4b913f26c..a984c4647cc7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3167,6 +3167,7 @@ F: Documentation/devicetree/bindings/arm/ux500.yaml
F: Documentation/devicetree/bindings/arm/ux500/
F: Documentation/devicetree/bindings/gpio/st,nomadik-gpio.yaml
F: Documentation/devicetree/bindings/i2c/st,nomadik-i2c.yaml
+F: Documentation/devicetree/bindings/power/stericsson,ux500-pm-domains.yaml
F: arch/arm/boot/dts/st/ste-*
F: arch/arm/mach-nomadik/
F: arch/arm/mach-ux500/
--
2.54.0
^ permalink raw reply related
* [PATCH 02/11] dt-bindings: Add the actual power domains on U8500
From: Linus Walleij @ 2026-06-18 5:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Mark Brown, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Vinod Koul, Frank Li, Lee Jones
Cc: linux-arm-kernel, devicetree, linux-pm, dri-devel, dmaengine,
Linus Walleij, Linus Walleij
In-Reply-To: <20260618-ux500-power-domains-v7-1-v1-0-eb5e50b1a588@kernel.org>
This file has been left in an unfinished state just defining
the root power domain for the U8500 SoC. Fix it up by adding
the actual existing power domains in this SoC.
The PRCMU code and old regulator driver is mentioning some
*_RET domains, this means "retention" and is a state in the
domain and not a domain of its own.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
include/dt-bindings/arm/ux500_pm_domains.h | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/dt-bindings/arm/ux500_pm_domains.h b/include/dt-bindings/arm/ux500_pm_domains.h
index 9bd764f0c9e6..1c168e59ac90 100644
--- a/include/dt-bindings/arm/ux500_pm_domains.h
+++ b/include/dt-bindings/arm/ux500_pm_domains.h
@@ -8,8 +8,23 @@
#define _DT_BINDINGS_ARM_UX500_PM_DOMAINS_H
#define DOMAIN_VAPE 0
+#define DOMAIN_VARM 1
+#define DOMAIN_VMODEM 2
+#define DOMAIN_VPLL 3
+#define DOMAIN_VSMPS1 4
+#define DOMAIN_VSMPS2 5
+#define DOMAIN_VSMPS3 6
+#define DOMAIN_VRF1 7
+#define DOMAIN_SVA_MMDSP 8
+#define DOMAIN_SVA_PIPE 9
+#define DOMAIN_SIA_MMDSP 10
+#define DOMAIN_SIA_PIPE 11
+#define DOMAIN_SGA 12
+#define DOMAIN_B2R2_MCDE 13
+#define DOMAIN_ESRAM_12 14
+#define DOMAIN_ESRAM_34 15
/* Number of PM domains. */
-#define NR_DOMAINS (DOMAIN_VAPE + 1)
+#define NR_DOMAINS (DOMAIN_ESRAM_34 + 1)
#endif
--
2.54.0
^ permalink raw reply related
* [PATCH 03/11] pmdomain: st: ux500: Implement more power domains
From: Linus Walleij @ 2026-06-18 5:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Mark Brown, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Vinod Koul, Frank Li, Lee Jones
Cc: linux-arm-kernel, devicetree, linux-pm, dri-devel, dmaengine,
Linus Walleij, Linus Walleij
In-Reply-To: <20260618-ux500-power-domains-v7-1-v1-0-eb5e50b1a588@kernel.org>
This starts to implement the power domains that are just skeleton
implementations right now.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pmdomain/st/ste-ux500-pm-domain.c | 125 +++++++++++++++++++++++++++++-
1 file changed, 124 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/st/ste-ux500-pm-domain.c b/drivers/pmdomain/st/ste-ux500-pm-domain.c
index 6896cb4a7b71..723001004690 100644
--- a/drivers/pmdomain/st/ste-ux500-pm-domain.c
+++ b/drivers/pmdomain/st/ste-ux500-pm-domain.c
@@ -41,14 +41,137 @@ static int pd_power_on(struct generic_pm_domain *domain)
return 0;
}
+/*
+ * Apart from these voltage domains there is also VSAFE which is always
+ * on. Vape_esram0_pwr for eSRAM0 is connected to VSAFE.
+ */
static struct generic_pm_domain ux500_pm_domain_vape = {
- .name = "VAPE",
+ /* Vape_pwr */
+ .name = "VAPE", /* 0.95 .. 1.20 V */
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+static struct generic_pm_domain ux500_pm_domain_varm = {
+ .name = "VARM",
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+static struct generic_pm_domain ux500_pm_domain_vmodem = {
+ .name = "VMODEM",
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+static struct generic_pm_domain ux500_pm_domain_vpll = {
+ .name = "VPLL", /* 1.8 V */
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+/*
+ * CHECKME: as these are used directly by peripherals as regulators,
+ * perhaps they should stay in the regulator subsystem?
+ */
+static struct generic_pm_domain ux500_pm_domain_vsmps1 = {
+ .name = "VSMPS1", /* Also called VIO (1.2V) */
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+static struct generic_pm_domain ux500_pm_domain_vsmps2 = {
+ .name = "VSMPS2", /* Also called VIO (1.8V) */
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+static struct generic_pm_domain ux500_pm_domain_vsmps3 = {
+ .name = "VSMPS3",
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+static struct generic_pm_domain ux500_pm_domain_vrf1 = {
+ .name = "VRF1",
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+/* The following are technically children of VAPE */
+static struct generic_pm_domain ux500_pm_domain_sva_mmdsp = {
+ /* Vape_SVA_MMDSP_pwr */
+ .name = "SVA_MMDSP",
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+static struct generic_pm_domain ux500_pm_domain_sva_pipe = {
+ /* Vape_SVA_pwr */
+ .name = "SVA_PIPE",
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+static struct generic_pm_domain ux500_pm_domain_sia_mmdsp = {
+ /* Vape_SIA_MMDSP_pwr */
+ .name = "SIA_MMDSP",
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+static struct generic_pm_domain ux500_pm_domain_sia_pipe = {
+ /* Vape_SIA_pwr */
+ .name = "SIA_PIPE",
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+static struct generic_pm_domain ux500_pm_domain_sga = {
+ /* Vape_SGA_pwr */
+ .name = "SGA",
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+static struct generic_pm_domain ux500_pm_domain_b2r2_mcde = {
+ /* Vape_DSS_pwr DSS (display subsystem) */
+ .name = "B2R2_MCDE",
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+static struct generic_pm_domain ux500_pm_domain_esram_12 = {
+ /* Vape_esram0_pwr, Vape_esram1_pwr */
+ .name = "ESRAM_12",
+ .power_off = pd_power_off,
+ .power_on = pd_power_on,
+};
+
+static struct generic_pm_domain ux500_pm_domain_esram_34 = {
+ /* Vape_esram3_pwr, Vape_esram4_pwr */
+ .name = "ESRAM_34",
.power_off = pd_power_off,
.power_on = pd_power_on,
};
static struct generic_pm_domain *ux500_pm_domains[NR_DOMAINS] = {
[DOMAIN_VAPE] = &ux500_pm_domain_vape,
+ [DOMAIN_VARM] = &ux500_pm_domain_varm,
+ [DOMAIN_VMODEM] = &ux500_pm_domain_vmodem,
+ [DOMAIN_VPLL] = &ux500_pm_domain_vpll,
+ [DOMAIN_VSMPS1] = &ux500_pm_domain_vsmps1,
+ [DOMAIN_VSMPS2] = &ux500_pm_domain_vsmps2,
+ [DOMAIN_VSMPS3] = &ux500_pm_domain_vsmps3,
+ [DOMAIN_VRF1] = &ux500_pm_domain_vrf1,
+ [DOMAIN_SVA_MMDSP] = &ux500_pm_domain_sva_mmdsp,
+ [DOMAIN_SVA_PIPE] = &ux500_pm_domain_sva_pipe,
+ [DOMAIN_SIA_MMDSP] = &ux500_pm_domain_sia_mmdsp,
+ [DOMAIN_SIA_PIPE] = &ux500_pm_domain_sia_pipe,
+ [DOMAIN_SGA] = &ux500_pm_domain_sga,
+ [DOMAIN_B2R2_MCDE] = &ux500_pm_domain_b2r2_mcde,
+ [DOMAIN_ESRAM_12] = &ux500_pm_domain_esram_12,
+ [DOMAIN_ESRAM_34] = &ux500_pm_domain_esram_34,
};
static const struct of_device_id ux500_pm_domain_matches[] = {
--
2.54.0
^ permalink raw reply related
* [PATCH 04/11] ARM: dts: ux500: Rename power domains node
From: Linus Walleij @ 2026-06-18 5:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Mark Brown, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Vinod Koul, Frank Li, Lee Jones
Cc: linux-arm-kernel, devicetree, linux-pm, dri-devel, dmaengine,
Linus Walleij, Linus Walleij
In-Reply-To: <20260618-ux500-power-domains-v7-1-v1-0-eb5e50b1a588@kernel.org>
This matches the naming used in the binding document
Documentation/devicetree/bindings/power/power-domain.yaml
It's most logical to call it a power controller.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/st/ste-dbx5x0.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/st/ste-dbx5x0.dtsi b/arch/arm/boot/dts/st/ste-dbx5x0.dtsi
index 0f87abeddc33..d76a65da7011 100644
--- a/arch/arm/boot/dts/st/ste-dbx5x0.dtsi
+++ b/arch/arm/boot/dts/st/ste-dbx5x0.dtsi
@@ -343,7 +343,7 @@ pmu {
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
};
- pm_domains: pm_domains0 {
+ pm_domains: power-controller {
compatible = "stericsson,ux500-pm-domains";
#power-domain-cells = <1>;
};
--
2.54.0
^ permalink raw reply related
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