* Re: [PATCH] firmware: arm_scmi: Fix OOB in scmi_power_name_get()
From: Geert Uytterhoeven @ 2026-05-22 7:56 UTC (permalink / raw)
To: Sudeep Holla; +Cc: Cristian Marussi, arm-scmi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260521-loutish-lurking-koel-229bd9@sudeepholla>
Hi Sudeep,
On Thu, 21 May 2026 at 18:26, Sudeep Holla <sudeep.holla@kernel.org> wrote:
> On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote:
> > scmi_power_name_get() does not validate the domain number passed by the
> > external caller, which may lead to an out-of-bounds access.
> >
> > Fix this by returning "unknown" for invalid domains, like
> > scmi_reset_name_get() does.
> >
> > Fixes: 76a6550990e296a7 ("firmware: arm_scmi: add initial support for power protocol")
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > drivers/firmware/arm_scmi/power.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/arm_scmi/power.c b/drivers/firmware/arm_scmi/power.c
> > index 3aa84ceb6d2bab68..4a7215e02dec035d 100644
> > --- a/drivers/firmware/arm_scmi/power.c
> > +++ b/drivers/firmware/arm_scmi/power.c
> > @@ -204,8 +204,12 @@ scmi_power_name_get(const struct scmi_protocol_handle *ph,
> > u32 domain)
> > {
> > struct scmi_power_info *pi = ph->get_priv(ph);
> > - struct power_dom_info *dom = pi->dom_info + domain;
> > + struct power_dom_info *dom;
> > +
> > + if (domain >= pi->num_domains)
> > + return "unknown";
>
> The only user of this function must not call it for domain >= pi->num_domains.
> However, I am thinking if it is bit inconsistent within SCMI core now. I like
> the way pinmux/ctl handles this as I don't like the alternative for this
> (i.e. ERRPTR(-EINVAL or something)). Worst case if this ever causes issue
> we can change the signature of the scmi_{power,reset}_name_get to follow
> something like pinmux and update the users. Thoughts ? Happy to apply this
> for now.
You mean returning an int error code using return statements, and
returning the objects using passed function pointers?
Depends on the number of returned objects: if it's just one (e.g. a
name or info pointer), then the valid pointer/error pointer idiom is
very common in Linux.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 03/10] dt-bindings: clock: Add Amlogic A9 peripherals clock controller
From: Jian Hu @ 2026-05-22 7:49 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Jerome Brunet, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-kernel, linux-clk,
devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <20260515-augmented-cyber-puffin-4db20f@quoll>
On 5/15/2026 4:10 PM, Krzysztof Kozlowski wrote:
> [ EXTERNAL EMAIL ]
>
> On Mon, May 11, 2026 at 08:47:25PM +0800, Jian Hu wrote:
>> Add the peripherals clock controller dt-bindings for the Amlogic A9
>> SoC family.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> ---
>> .../clock/amlogic,a9-peripherals-clkc.yaml | 150 +++++++++
>> .../clock/amlogic,a9-peripherals-clkc.h | 352 +++++++++++++++++++++
>> 2 files changed, 502 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a9-peripherals-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a9-peripherals-clkc.yaml
>> new file mode 100644
>> index 000000000000..97e2c44d8630
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/amlogic,a9-peripherals-clkc.yaml
>> @@ -0,0 +1,150 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (C) 2026 Amlogic, Inc. All rights reserved
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/clock/amlogic,a9-peripherals-clkc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Amlogic A9 Series Peripherals Clock Controller
>> +
>> +maintainers:
>> + - Neil Armstrong <neil.armstrong@linaro.org>
>> + - Jerome Brunet <jbrunet@baylibre.com>
>> + - Jian Hu <jian.hu@amlogic.com>
>> + - Xianwei Zhao <xianwei.zhao@amlogic.com>
>> +
>> +properties:
>> + compatible:
>> + const: amlogic,a9-peripherals-clkc
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + '#clock-cells':
>> + const: 1
>> +
>> + clocks:
>> + minItems: 20
> I don't think so. How they could be optional in silicon? How does
> exactly work from silicon point of view?
These are internal clocks from unimplemented analog blocks, and these
clocks will be added
in the future. Marking them as optional is indeed incorrect.
Only the last external clock is actually optional.
I will fix it in the next version.
>> + items:
>> + - description: input oscillator
>> + - description: input fclk div 2
>> + - description: input fclk div 3
>> + - description: input fclk div 4
>> + - description: input fclk div 5
>> + - description: input fclk div 7
>> + - description: input fclk div 2p5
>> + - description: input sys clk
>> + - description: input gp1 pll
>> + - description: input gp2 pll
>> + - description: input sys pll div 16
>> + - description: input cpu clk div 16
>> + - description: input a78 clk div 16
>> + - description: input dsu clk div 16
>> + - description: input rtc clk
>> + - description: input gp0 pll
>> + - description: input hifi0 pll
>> + - description: input hifi1 pll
>> + - description: input mclk0 pll
>> + - description: input mclk1 pll
>> + - description: input video1 pll (optional)
>> + - description: input video2 pll (optional)
>> + - description: input hdmi out2 clk (optional)
>> + - description: input hdmi pixel clk (optional)
>> + - description: input pixel0 pll (optional)
>> + - description: input pixel1 pll (optional)
>> + - description: input usb2 drd clk (optional)
>> + - description: external input rmii oscillator (optional)
>> +
>> + clock-names:
>> + minItems: 20
>> + items:
>> + - const: xtal
>> + - const: fdiv2
>> + - const: fdiv3
>> + - const: fdiv4
>> + - const: fdiv5
>> + - const: fdiv7
>> + - const: fdiv2p5
>> + - const: sys
>> + - const: gp1
>> + - const: gp2
>> + - const: sysplldiv16
>> + - const: cpudiv16
>> + - const: a78div16
>> + - const: dsudiv16
>> + - const: rtc
>> + - const: gp0
>> + - const: hifi0
>> + - const: hifi1
>> + - const: mclk0
>> + - const: mclk1
>> + - const: vid1
>> + - const: vid2
>> + - const: hdmiout2
>> + - const: hdmipix
>> + - const: pix0
>> + - const: pix1
>> + - const: u2drd
>> + - const: ext_rmii
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - '#clock-cells'
>> + - clocks
>> + - clock-names
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + apb4 {
> Same comments as other patches. Do not come with your own style, but
> adjust to mainline. Do you see this anywhere?
>
> git grep apb4 -- Documentation/devicetree/bindings/clock/
>
> So why coming with something COMPLETELY different?
>
> Best regards,
> Krzysztof
Thanks for pointing this out. You are correct that there is no precedent
for "apb4"
in the mainline clock bindings. I should not have invented a new naming
scheme here.
I will rename this to use the standard "soc" naming that is consistent
with all other
similar bindings in the kernel tree.
Furthermore, I will search the kernel to see if it exists when naming.
This will be fixed in the next revision.
^ permalink raw reply
* [PATCH 2/2] gpio: mxc: use BIT() macro
From: Alexander Stein @ 2026-05-22 7:01 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: Alexander Stein, linux-gpio, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260522070118.800671-1-alexander.stein@ew.tq-group.com>
Do not open-code the BIT() macro.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
drivers/gpio/gpio-mxc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 12f11a6c96653..7e2690d92df6f 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -330,13 +330,13 @@ static int gpio_set_wake_irq(struct irq_data *d, u32 enable)
ret = enable_irq_wake(port->irq_high);
else
ret = enable_irq_wake(port->irq);
- port->wakeup_pads |= (1 << gpio_idx);
+ port->wakeup_pads |= BIT(gpio_idx);
} else {
if (port->irq_high && (gpio_idx >= 16))
ret = disable_irq_wake(port->irq_high);
else
ret = disable_irq_wake(port->irq);
- port->wakeup_pads &= ~(1 << gpio_idx);
+ port->wakeup_pads &= ~BIT(gpio_idx);
}
return ret;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v1 13/15] dt-bindings: display: panel-lvds: Add dual-channel LVDS support
From: Francesco Dolcini @ 2026-05-22 7:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vitor Soares, Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding, Sam Ravnborg, Vitor Soares, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260522-vehement-kangaroo-of-penetration-de8d99@quoll>
On Fri, May 22, 2026 at 08:55:12AM +0200, Krzysztof Kozlowski wrote:
> On Thu, May 21, 2026 at 04:00:49PM +0100, Vitor Soares wrote:
> > From: Vitor Soares <vitor.soares@toradex.com>
> > Assisted-by: Claude:claude-sonnet-4.6
>
> Using assisted by is not permission to send us unreviewed code.
It was reviewed (by myself before Vitor did send the series). It is a
plain old mistake, unfortunately we cannot blame Claude for it.
Francesco
^ permalink raw reply
* Re: [PATCH] arm64: mm: call pagetable dtor when freeing hot-removed page tables
From: Catalin Marinas @ 2026-05-22 7:32 UTC (permalink / raw)
To: Andrew Morton
Cc: Alistair Popple, linux-arm-kernel, linux-kernel, linux-mm, will,
david
In-Reply-To: <ahACfQ6kCfONqz5h@arm.com>
On Fri, May 22, 2026 at 08:15:09AM +0100, Catalin Marinas wrote:
> On Thu, May 21, 2026 at 03:31:30PM -0700, Andrew Morton wrote:
> > On Thu, 21 May 2026 13:27:30 +1000 Alistair Popple <apopple@nvidia.com> wrote:
> > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > > index 8e1d80a7033e..0c24fe650e95 100644
> > > --- a/arch/arm64/mm/mmu.c
> > > +++ b/arch/arm64/mm/mmu.c
> > > @@ -1422,6 +1422,7 @@ static void free_hotplug_page_range(struct page *page, size_t size,
> > >
> > > static void free_hotplug_pgtable_page(struct page *page)
> > > {
> > > + pagetable_dtor(page_ptdesc(page));
> > > free_hotplug_page_range(page, PAGE_SIZE, NULL);
> > > }
> >
> > I'd of course prefer that arm maintainers handle this. But
> > 5e8eb9aeeda3 came via myself so convention kinda-dictates that I get to
> > fix it.
>
> That's fine but Sashiko has some points:
>
> https://sashiko.dev/#/patchset/20260521032730.2104017-1-apopple@nvidia.com
The other Sashiko find looks like a false positive. vmemmap_*_populate()
do not allocate the page table from altmap, only the page pointed at by
the vmemmap pte.
--
Catalin
^ permalink raw reply
* [PATCH] wifi: mt76: mt7996: remove redundant pdev->bus check in probe
From: Lorenzo Bianconi @ 2026-05-22 7:24 UTC (permalink / raw)
To: Felix Fietkau, Ryder Lee, Shayne Chen, Sean Wang,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Dan Carpenter, linux-wireless, linux-arm-kernel, linux-mediatek,
Lorenzo Bianconi
Drop the unnecessary pdev->bus NULL check in mt7996_pci_probe() since
the pointer is already dereferenced earlier in mt76_pci_disable_aspm(),
making the check dead code. Silences the related Smatch warning.
Fixes: 377aa17d2aed ("wifi: mt76: mt7996: Add NPU offload support to MT7996 driver")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7996/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/pci.c b/drivers/net/wireless/mediatek/mt76/mt7996/pci.c
index 12523ddba630..b7d9193e042f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/pci.c
@@ -141,7 +141,7 @@ static int mt7996_pci_probe(struct pci_dev *pdev,
dev->hif2 = hif2;
mt76_npu_init(mdev, pci_resource_start(pdev, 0),
- pdev->bus && pci_domain_nr(pdev->bus) ? 3 : 2);
+ pci_domain_nr(pdev->bus) ? 3 : 2);
ret = mt7996_mmio_wed_init(dev, pdev, false, &irq);
if (ret < 0)
---
base-commit: e9aeddfe98ebccd3761ac7dd316af4fb5de1c28a
change-id: 20260522-mt7996-pdev-bus-fix-0ea1302f0d68
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH] ARM: rockchip: keep reset control around
From: Heiko Stuebner @ 2026-05-22 7:20 UTC (permalink / raw)
To: Heiko Stuebner
Cc: linux-arm-kernel, linux-rockchip, Philipp Zabel, Steven Price,
Bartosz Golaszewski
In-Reply-To: <20260521210915.2331176-1-heiko@sntech.de>
Am Donnerstag, 21. Mai 2026, 23:09:15 Mitteleuropäische Sommerzeit schrieb Heiko Stuebner:
> Do not put the reset control, retain exclusive control over it.
> After turning on a CPU, the corresponding reset line must stay
> deasserted.
>
> This also avoids calling reset_control_put() before workqueues
> are operational.
>
> Fixes: 78ebbff6d1a0 ("reset: handle removing supplier before consumers")
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> Tested-by: Steven Price <steven.price@arm.com>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> arch/arm/mach-rockchip/platsmp.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c
> index f432d22bfed8..f659d894bfae 100644
> --- a/arch/arm/mach-rockchip/platsmp.c
> +++ b/arch/arm/mach-rockchip/platsmp.c
> @@ -34,6 +34,7 @@ static int ncores;
>
> static struct regmap *pmu;
> static int has_pmu = true;
> +static struct reset_control *cpu_rstc[4];
After sleeping on that, this should be cpu_rstc[5];
Coretx-A9 SoCs need to enable the SCU power-domain which thankfully
sits at index 4 of the power-domain register.
So while we (already) expect no reset control for that, we need at least
make sure, it's not reading into undefined memory and thus need that
empty field in the array.
Heiko
>
> static int pmu_power_domain_is_on(int pd)
> {
> @@ -64,9 +65,11 @@ static struct reset_control *rockchip_get_core_reset(int cpu)
> static int pmu_set_power_domain(int pd, bool on)
> {
> u32 val = (on) ? 0 : BIT(pd);
> - struct reset_control *rstc = rockchip_get_core_reset(pd);
> + struct reset_control *rstc;
> int ret;
>
> + rstc = pd < ARRAY_SIZE(cpu_rstc) ? cpu_rstc[pd] : ERR_PTR(-EINVAL);
> +
> if (IS_ERR(rstc) && read_cpuid_part() != ARM_CPU_PART_CORTEX_A9) {
> pr_err("%s: could not get reset control for core %d\n",
> __func__, pd);
> @@ -100,11 +103,8 @@ static int pmu_set_power_domain(int pd, bool on)
> }
> }
>
> - if (!IS_ERR(rstc)) {
> - if (on)
> - reset_control_deassert(rstc);
> - reset_control_put(rstc);
> - }
> + if (!IS_ERR(rstc) && on)
> + reset_control_deassert(rstc);
>
> return 0;
> }
> @@ -312,6 +312,10 @@ static void __init rockchip_smp_prepare_cpus(unsigned int max_cpus)
> ncores = ((l2ctlr >> 24) & 0x3) + 1;
> }
>
> + /* Collect cpu core reset control for each core */
> + for (i = 0; i < ncores; i++)
> + cpu_rstc[i] = rockchip_get_core_reset(i);
> +
> /* Make sure that all cores except the first are really off */
> for (i = 1; i < ncores; i++)
> pmu_set_power_domain(0 + i, false);
>
^ permalink raw reply
* Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered down
From: Mukesh Savaliya @ 2026-05-22 7:20 UTC (permalink / raw)
To: Carlos Song (OSS), o.rempel@pengutronix.de, kernel@pengutronix.de,
andi.shyti@kernel.org, Frank Li, s.hauer@pengutronix.de,
festevam@gmail.com, Carlos Song, Bough Chen
Cc: linux-i2c@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <AM0PR04MB68026A6412B8F844D1324B92E80E2@AM0PR04MB6802.eurprd04.prod.outlook.com>
Thanks Carlos !
On 5/21/2026 8:19 PM, Carlos Song (OSS) wrote:
>
>
>> -----Original Message-----
>> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
>> Sent: Thursday, May 21, 2026 8:40 PM
>> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>; Mukesh Savaliya
>> <mukesh.savaliya@oss.qualcomm.com>; o.rempel@pengutronix.de;
>> kernel@pengutronix.de; andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
>> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
>> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
>> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
>> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
>> stable@vger.kernel.org
>> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered
>> down
>>
>>
>>
>> On 5/21/2026 5:32 PM, Carlos Song (OSS) wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
>>>> Sent: Thursday, May 21, 2026 7:14 PM
>>>> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>; Mukesh Savaliya
>>>> <mukesh.savaliya@oss.qualcomm.com>; o.rempel@pengutronix.de;
>>>> kernel@pengutronix.de; andi.shyti@kernel.org; Frank Li
>>>> <frank.li@nxp.com>; s.hauer@pengutronix.de; festevam@gmail.com;
>>>> Carlos Song <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
>>>> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
>>>> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
>>>> stable@vger.kernel.org
>>>> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is
>>>> powered down
>>>>
>>>>
>>>> On 5/21/2026 4:21 PM, Carlos Song (OSS) wrote:
>>>>
>>>> [...]
>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
>>>>>>>> Sent: Thursday, May 21, 2026 3:40 PM
>>>>>>>> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>;
>>>>>>>> o.rempel@pengutronix.de; kernel@pengutronix.de;
>>>>>>>> andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
>>>>>>>> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
>>>>>>>> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
>>>>>>>> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
>>>>>>>> linux-arm-kernel@lists.infradead.org;
>>>>>>>> linux-kernel@vger.kernel.org; stable@vger.kernel.org
>>>>>>>> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware
>>>>>>>> is powered down
>>>>>>>>
>>>>>>>> Hi Carlos,
>>>>>>>>
>>>>>>>> On 5/20/2026 3:45 PM, Carlos Song (OSS) wrote:
>>>>>>>>> From: Carlos Song <carlos.song@nxp.com>
>>>>>>>>>
>>>>>>>>> Mark the I2C adapter as suspended during system suspend to block
>>>>>>>>> further transfers, and resume it on system resume. This prevents
>>>>>>>>> potential hangs when the hardware is powered down but clients
>>>>>>>>> still attempt
>>>>>>>> I2C transfers.
>>>>>>>>>
>>>>>> what was the reason of this hang ? I was thinking you don't have
>>>>>> interrupts working when client requested transfer but adapter was
>>>>>> suspended. Please correct me if wrong.
>>>>>>
>>>>>> And it would be good to mention the actual problem and why/how it
>>>> occurred.
>>>>>>>> Code changes looks fine to me but have comment on commit log.
>>>>>>>>
>>>>>>>> It seems, you are adding support of _noirq() callbacks to allow
>>>>>>>> transfers during suspend/resume noirq phase of PM.
>>>>>>>>
>>>>>>>> Would it make sense if you can write "Replace system PM callbacks
>>>>>>>> with noirq PM callbacks" OR "Allow transfers during _noirq phase
>>>>>>>> of the PM ops" instead of "mark I2C adapter when hardware is
>>>>>>>> powered
>>>>>> down" ?
>>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Thank you for your comments!
>>>>>>>
>>>>>>> But this patch is added is not for support noirq PM callback or
>>>>>>> transfer in noirq
>>>>>> phase.
>>>>>>>
>>>>>> Okay, may be actual problem description can help me.
>>>>>>> In fact, this fix is to mark the I2C adapter as suspended during
>>>>>>> system noirq suspend to block further transfers, and resume it on
>>>>>>> system noirq resume. This is to prohibit I2C device calling the
>>>>>>> I2C controller after the system noirq suspend and before noirq
>>>>>>> resume, because at
>>>>>> this time the I2C instance is powered off or the clock is disabled
>>>>>> ... So I want to keep current commit. How do you think?
>>>>>> completely Makes sense. Please help add how this problem occurred
>>>>>> and
>>>> why ?
>>>>>> So the change/fix will be good to understand against it.
>>>>>
>>>>> Hi,
>>>>>
>>>>> In some I.MX platform, some I2C devices will keep a work queue all
>>>>> time, the work queue will trigger I2C xfer every once in a while,
>>>>> but the work
>>>> queue shouldn't be free in system suspend.
>>>>>
>>>>
>>>> work queue has transfers queued even if system is suspended ? IMO,
>>>> the client i2c devices should not let system go to suspend.
>>>>
>>>
>>> Hi Mukesh,
>>>
>>> Thank you for the detailed discussion.
>>>
>>> Yes, I totally agree that I2C client drivers should ideally stop
>>> issuing transfers when the system is suspending.
>>>
>>> However, in practice there are many different I2C clients, and not all
>>> of them strictly adhere to this requirement. Some clients may still
>>> trigger transfers through workqueues or deferred contexts during the
>>> suspend/resume window.
>>>
>>> Therefore, adding this protection at the I2C controller side helps to
>>> avoid unexpected accesses when the hardware resources are unavailable,
>>> making the system more robust.
>>>
>>
>> Agreed !
>>
>>>>> Within a very short time window, possibly from noirq_suspend to the
>>>>> system actually being suspended, or possibly from the system
>>>>> starting to resume to before noirq_resume, this work queue will
>>>>> trigger an I2C transfer, and at this time the I2C controller's clk
>>>>> and pinctrl have not yet been restored, reading and
>>>>
>>>> Right, this kind of explains the problem to me. I think you are
>>>> trying to serve i2c transfers when your resources(clk, pinctrl) are
>>>> not turned ON and also interrupt remains disabled. And that's why you
>>>> need to add
>>>> _noir() PM callbacks supports along with IRQF_NO_SUSPEND |
>>>> IRQF_EARLY_RESUME flags.
>>>>
>>>>> writing I2C registers causes the system to hang. This patch make all
>>>>> I2C operations are performed in a safe hardware state.
>>>>>
>>>>> Is it better if I add these comment to patch commit log?
>>>>>>>
>>>> if my latest comments makes sense against the issue, you may write
>>>> accordingly. if i am wrong, then your explanation makes sense. Cause
>>>> of the hang needs to be clearly mention int the commit log in your next
>> patch.
>>>>
>>>
>>> Based on our discussion, I have updated the commit log as below:
>>>
>>> On some i.MX platforms, certain I2C client drivers keep a periodic
>>> workqueue which continues to trigger I2C transfers.
>>>
>>> During system suspend/resume, there exists a time window between:
>>> - noirq_suspend and full suspend
>>> - resume start and noirq_resume
>>
>> - noirq_resume and resume start [Just opposite ?]
>>
>
> Sorry, the expression is ambiguous.
>
> I will update the commit log to:
>
> During system suspend/resume, there exists a time window between:
> - suspend_noirq and the system entering suspend
> - the system starting to resume and resume_noirq
>
> Does this look good to you?
Yes, looks good.
>
>>>
>>> In this window, the I2C controller resources such as clock and pinctrl
>>> may already be disabled or not yet restored.
>>>
>>> If a workqueue triggers an I2C transfer in this period, the driver
>>> attempts to access I2C registers while the hardware resources are
>>> unavailable, which may lead to system hang.
>>>
>>> Mark the I2C adapter as suspended during noirq suspend and block new
>>> transfers until resume, ensuring that I2C transfers are only issued
>>> when hardware resources are available.
>>>
>>> Does this look good to you?
>>>
>> Looks good, Thanks !
>>
>>>>>>
>>>>>
>>>
>
^ permalink raw reply
* [PATCH v2 2/2] spi: aspeed: Replace VLA parameter with flat pointer in calibration helper
From: Chin-Ting Kuo @ 2026-05-22 7:16 UTC (permalink / raw)
To: clg, broonie, joel, andrew, linux-aspeed, openbmc, linux-spi,
linux-arm-kernel, linux-kernel, david.laight.linux, BMC-SW
Cc: kernel test robot
In-Reply-To: <20260522071621.102507-1-chin-ting_kuo@aspeedtech.com>
aspeed_spi_ast2600_optimized_timing() declared its buffer argument as a
variable-length array parameter (u8 buf[rows][cols]), which causes a
sparse warning. Replace the VLA parameter with a plain u8 * and compute
the 2-D index manually. The corresponding call site is also updated.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605180441.uD3toFRJ-lkp@intel.com/
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index 808659a1f460..027caa2eeb5c 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -1467,8 +1467,7 @@ static int aspeed_spi_do_calibration(struct aspeed_spi_chip *chip)
* must contains the highest number of consecutive "pass"
* results and not span across multiple rows.
*/
-static u32 aspeed_spi_ast2600_optimized_timing(u32 rows, u32 cols,
- u8 buf[rows][cols])
+static u32 aspeed_spi_ast2600_optimized_timing(u32 rows, u32 cols, u8 *buf)
{
int r = 0, c = 0;
int max = 0;
@@ -1478,7 +1477,7 @@ static u32 aspeed_spi_ast2600_optimized_timing(u32 rows, u32 cols,
for (j = 0; j < cols;) {
int k = j;
- while (k < cols && buf[i][k])
+ while (k < cols && buf[(i * cols) + k])
k++;
if (k - j > max) {
@@ -1541,7 +1540,7 @@ static int aspeed_spi_ast2600_calibrate(struct aspeed_spi_chip *chip, u32 hdiv,
}
}
- calib_point = aspeed_spi_ast2600_optimized_timing(6, 17, calib_res);
+ calib_point = aspeed_spi_ast2600_optimized_timing(6, 17, &calib_res[0][0]);
/* No good setting for this frequency */
if (calib_point == 0)
return -1;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/2] spi: aspeed: Fix missing __iomem annotation in output transfer path
From: Chin-Ting Kuo @ 2026-05-22 7:16 UTC (permalink / raw)
To: clg, broonie, joel, andrew, linux-aspeed, openbmc, linux-spi,
linux-arm-kernel, linux-kernel, david.laight.linux, BMC-SW
Cc: kernel test robot
In-Reply-To: <20260522071621.102507-1-chin-ting_kuo@aspeedtech.com>
The dst parameter of aspeed_spi_user_transfer_tx() is an MMIO address
obtained from chip->ahb_base, but it was typed as void * instead of
void __iomem *. This caused a sparse warning report. Fix the
parameter type to void __iomem * and drop the now-unnecessary
cast at the call site.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605180441.uD3toFRJ-lkp@intel.com/
Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
---
drivers/spi/spi-aspeed-smc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index c21323e07d3c..808659a1f460 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -891,7 +891,7 @@ static int aspeed_spi_user_unprepare_msg(struct spi_controller *ctlr,
static void aspeed_spi_user_transfer_tx(struct aspeed_spi *aspi,
struct spi_device *spi,
const u8 *tx_buf, u8 *rx_buf,
- void *dst, u32 len)
+ void __iomem *dst, u32 len)
{
const struct aspeed_spi_data *data = aspi->data;
bool full_duplex_transfer = data->full_duplex && tx_buf == rx_buf;
@@ -936,7 +936,7 @@ static int aspeed_spi_user_transfer(struct spi_controller *ctlr,
aspeed_spi_set_io_mode(chip, CTRL_IO_QUAD_DATA);
aspeed_spi_user_transfer_tx(aspi, spi, tx_buf, rx_buf,
- (void *)ahb_base, xfer->len);
+ ahb_base, xfer->len);
}
if (rx_buf && rx_buf != tx_buf) {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] spi: aspeed: Fix __iomem annotation and VLA parameter
From: Chin-Ting Kuo @ 2026-05-22 7:16 UTC (permalink / raw)
To: clg, broonie, joel, andrew, linux-aspeed, openbmc, linux-spi,
linux-arm-kernel, linux-kernel, david.laight.linux, BMC-SW
This series fixes two sparse warnings reported by the kernel test robot.
The first patch fixes missing __iomem annotation on an MMIO pointer
parameter, which also caused a redundant cast at the call site.
A VLA function parameter warning is also fixed in this patch series.
Changes in v2:
- Add parentheses to row-major index for clarity.
Chin-Ting Kuo (2):
spi: aspeed: Fix missing __iomem annotation in output transfer path
spi: aspeed: Replace VLA parameter with flat pointer in calibration
helper
drivers/spi/spi-aspeed-smc.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH] arm64: mm: call pagetable dtor when freeing hot-removed page tables
From: Catalin Marinas @ 2026-05-22 7:15 UTC (permalink / raw)
To: Andrew Morton
Cc: Alistair Popple, linux-arm-kernel, linux-kernel, linux-mm, will,
david
In-Reply-To: <20260521153130.d7d5cd060f7522f894252333@linux-foundation.org>
On Thu, May 21, 2026 at 03:31:30PM -0700, Andrew Morton wrote:
> On Thu, 21 May 2026 13:27:30 +1000 Alistair Popple <apopple@nvidia.com> wrote:
> > Since 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in
> > __create_pgd_mapping()") page-table allocation on ARM64 always
> > calls pagetable_{pte,pmd,pud,p4d}_ctor(). This sets the page_type
> > to PGTY_table, increments NR_PAGETABLE and possible allocates a PTL.
> > However the matching pagetable_dtor() calls were never added.
> >
> > With DEBUG_VM enabled on kernel versions prior to v6.17 without
> > 2dfcd1608f3a9 ("mm/page_alloc: let page freeing clear any set page
> > type") this leads to the following warning when freeing these pages due
> > to page->page_type sharing page->_mapcount:
> >
> > BUG: Bad page state in process ... pfn:284fbb
> > page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x284fbb
> > flags: 0x17fffc000000000(node=0|zone=2|lastcpupid=0x1ffff)
> > page_type: f2(table)
> > page dumped because: nonzero mapcount
> > Call trace:
> > bad_page+0x13c/0x160
> > __free_frozen_pages+0x6cc/0x860
> > ___free_pages+0xf4/0x180
> > free_pages+0x54/0x80
> > free_hotplug_page_range.part.0+0x58/0x90
> > free_empty_tables+0x438/0x500
> > __remove_pgd_mapping.constprop.0+0x60/0xa8
> > arch_remove_memory+0x48/0x80
> > try_remove_memory+0x158/0x1d8
> > offline_and_remove_memory+0x138/0x180
> >
> > It can also lead to leaking the ptl allocation if ALLOC_SPLIT_PTLOCKS
> > is defined and incorrect NR_PAGETABLE stats. Fix this by calling
> > pagetable_dtor() in free_hotplug_pgtable_page() prior to freeing the
> > page to undo the effects of calling pagetable_*_ctor().
> >
> > Fixes: 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in __create_pgd_mapping()")
>
> 6.16+, so I assume we want cc:stable here.
>
> > arch/arm64/mm/mmu.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 8e1d80a7033e..0c24fe650e95 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -1422,6 +1422,7 @@ static void free_hotplug_page_range(struct page *page, size_t size,
> >
> > static void free_hotplug_pgtable_page(struct page *page)
> > {
> > + pagetable_dtor(page_ptdesc(page));
> > free_hotplug_page_range(page, PAGE_SIZE, NULL);
> > }
>
> I'd of course prefer that arm maintainers handle this. But
> 5e8eb9aeeda3 came via myself so convention kinda-dictates that I get to
> fix it.
That's fine but Sashiko has some points:
https://sashiko.dev/#/patchset/20260521032730.2104017-1-apopple@nvidia.com
The __remove_pgd_mapping() path is fine but we also have the
vmemmap_free() path where the constructor was never called.
We could pass around a bool dtor argument but I wonder whether we could
just check it's a pgtable page:
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 4c8959153ac4..9d42cbddce27 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1441,6 +1441,9 @@ static void free_hotplug_page_range(struct page *page, size_t size,
static void free_hotplug_pgtable_page(struct page *page)
{
+ if (folio_test_pgtable(page_folio(page)))
+ pagetable_dtor(page_ptdesc(page));
+
free_hotplug_page_range(page, PAGE_SIZE, NULL);
}
--
Catalin
^ permalink raw reply related
* Re: [PATCH] ARM: zte: clean up zx297520v3 doc. warnings
From: Stefan Dösinger @ 2026-05-22 7:09 UTC (permalink / raw)
To: linux-kernel, Randy Dunlap
Cc: Randy Dunlap, Linus Walleij, Krzysztof Kozlowski,
linux-arm-kernel, Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260521191458.177046-1-rdunlap@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 470 bytes --]
Hi,
Am Donnerstag, 21. Mai 2026, 22:14:57 Ostafrikanische Zeit schrieben Sie:
> Fix multiple documentation build warnings.
> Improve punctuation and formatting of the rendered output.
>
> Documentation/arch/arm/zte/zx297520v3.rst:66: WARNING: Title underline too
> short. 3. Building for built-in U-Boot
I am sorry for the mess. I'll look into doc building before I send clock
documentation...
Reviewed-by: Stefan Dösinger <stefandoesinger@gmail.com>
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* [PATCH v2] net: stmmac: fix RX DMA leak on TX alloc failure
From: Abid Ali via B4 Relay @ 2026-05-22 7:09 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel, Abid Ali
From: Abid Ali <dev.taqnialabs@gmail.com>
Free RX DMA resources when alloc_dma_tx_desc_resources() fails in
alloc_dma_desc_resources().
Signed-off-by: Abid Ali <dev.taqnialabs@gmail.com>
---
Changes in v2:
- Restructured return path based on feedback.
- Link to v1: https://lore.kernel.org/r/20260425-stmmac-rx-desc-cleanup-v1-1-1a18a704c422@gmail.com
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 13d3cac05..240453daa 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2370,6 +2370,8 @@ static int alloc_dma_desc_resources(struct stmmac_priv *priv,
return ret;
ret = alloc_dma_tx_desc_resources(priv, dma_conf);
+ if (ret)
+ free_dma_rx_desc_resources(priv, dma_conf);
return ret;
}
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260425-stmmac-rx-desc-cleanup-440f05845492
Best regards,
--
Abid Ali <dev.taqnialabs@gmail.com>
^ permalink raw reply related
* [PATCH 1/2] gpio: mxc: fix irq_high handling
From: Alexander Stein @ 2026-05-22 7:01 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: Alexander Stein, linux-gpio, imx, linux-arm-kernel, linux-kernel
If port->irq_high is -1 (fsl,imx21-gpio compatible) and gpio_idx is >= 16
enable_irq_wake() is called with -1 which is wrong.
Fixes: 5f6d1998adeb ("gpio: mxc: release the parent IRQ in runtime suspend")
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
I don't have hardware to test. I just noticed this by code review.
drivers/gpio/gpio-mxc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 647b6f4861b74..12f11a6c96653 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -469,7 +469,7 @@ static int mxc_gpio_probe(struct platform_device *pdev)
* the handler is needed only once, but doing it for every port
* is more robust and easier.
*/
- port->irq_high = -1;
+ port->irq_high = 0;
port->mx_irq_handler = mx2_gpio_irq_handler;
} else
port->mx_irq_handler = mx3_gpio_irq_handler;
--
2.43.0
^ permalink raw reply related
* [PATCH] media: rockchip: rkcif: Fix error handling for media_entity_remote_source_pad_unique()
From: Chen Ni @ 2026-05-22 6:55 UTC (permalink / raw)
To: mehdi.djait, michael.riesch
Cc: mchehab, heiko, hverkuil+cisco, gerald.loacker, bryan.odonoghue,
linux-media, linux-arm-kernel, linux-rockchip, linux-kernel,
Chen Ni
The media_entity_remote_source_pad_unique() function returns an error
pointer on failure, not NULL. Fix the check to use IS_ERR() and return
PTR_ERR() to correctly handle allocation failures.
Fixes: 501802e2ad51 ("media: rockchip: rkcif: add abstraction for dma blocks")
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
---
drivers/media/platform/rockchip/rkcif/rkcif-stream.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/rockchip/rkcif/rkcif-stream.c b/drivers/media/platform/rockchip/rkcif/rkcif-stream.c
index 3130d420ad55..542aa877919d 100644
--- a/drivers/media/platform/rockchip/rkcif/rkcif-stream.c
+++ b/drivers/media/platform/rockchip/rkcif/rkcif-stream.c
@@ -466,7 +466,7 @@ static int rkcif_stream_link_validate(struct media_link *link)
struct rkcif_stream *stream = to_rkcif_stream(vdev);
int ret = -EINVAL;
- if (!media_entity_remote_source_pad_unique(link->sink->entity))
+ if (IS_ERR(media_entity_remote_source_pad_unique(link->sink->entity)))
return -ENOTCONN;
sd = media_entity_to_v4l2_subdev(link->source->entity);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v1 13/15] dt-bindings: display: panel-lvds: Add dual-channel LVDS support
From: Krzysztof Kozlowski @ 2026-05-22 6:55 UTC (permalink / raw)
To: Vitor Soares
Cc: Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding, Sam Ravnborg, Vitor Soares, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260521150038.103538-30-ivitro@gmail.com>
On Thu, May 21, 2026 at 04:00:49PM +0100, Vitor Soares wrote:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> The panel-lvds binding only supports single-channel panels.
On purpose, no?
> Extend it to support dual-channel LVDS panels by referencing the
> lvds-dual-ports schema when a ports container is present.
You now changed existing panels to dual channel.
>
> Assisted-by: Claude:claude-sonnet-4.6
Using assisted by is not permission to send us unreviewed code.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] net: stmmac: mmc: Remove duplicate mmc_rx crc
From: Abid Ali @ 2026-05-22 6:54 UTC (permalink / raw)
To: andrew
Cc: alexandre.torgue, andrew+netdev, davem, dev.taqnialabs, edumazet,
kuba, linux-arm-kernel, linux-kernel, linux-stm32,
mcoquelin.stm32, netdev, pabeni
In-Reply-To: <2d702678-5b2b-451e-b692-228efcbbefc4@lunn.ch>
On Thu, May 21, 2026 at 20:44:53 +0200, Andrew Lunn wrote:
> Thanks for the updated commit message.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Much appreciated.
Should I send a v3 with the Reviewed-by trailer added ?
- Abid
^ permalink raw reply
* Re: [RESEND v3 1/3] KVM: arm64: Reset page order in pKVM hyp_pool
From: Fuad Tabba @ 2026-05-22 6:53 UTC (permalink / raw)
To: Vincent Donnefort
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, linux-arm-kernel, kvmarm, kernel-team,
qperret, Sashiko
In-Reply-To: <20260521143626.1005660-2-vdonnefort@google.com>
On Thu, 21 May 2026 at 15:36, Vincent Donnefort <vdonnefort@google.com> wrote:
>
> When a VM fails to initialise after its stage-2 hyp_pool has been
> initialised, that stage-2 must be torn down entirely. This requires
> resetting both the refcount and the order of its pages back to 0.
>
> Currently, reclaim_pgtable_pages() implicitly resets the page order by
> allocating the entire pool with order-0 granularity. However, in the VM
> initialisation error path, the addresses of the donated memory (the PGD)
> are already known, making it unnecessary to iterate over all pages in
> the pool.
>
> Since the vmemmap page order is a hyp_pool-specific field, leaving a
> non-zero order on hyp_pool destruction is harmless until another pool
> attempts to admit the page. Instead of resetting this field during
> destruction, reset it during pool initialization in hyp_pool_init().
>
> For 'external' pages, we can't trust the order either as they bypass
> hyp_pool_init(). Since we never coalesce them, enforce order-0 to ensure
> safe insertion into the pool.
>
> This leaves no vmemmap order users outside of hyp_pool.
>
> Fixes: 256b4668cd89 ("KVM: arm64: Introduce separate hypercalls for pKVM VM reservation and initialization")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index 25f04629014e..fa447d400b71 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> @@ -217,7 +217,6 @@ static void *guest_s2_zalloc_page(void *mc)
> memset(addr, 0, PAGE_SIZE);
> p = hyp_virt_to_page(addr);
> p->refcount = 1;
> - p->order = 0;
>
> return addr;
> }
> @@ -322,7 +321,6 @@ void reclaim_pgtable_pages(struct pkvm_hyp_vm *vm, struct kvm_hyp_memcache *mc)
> while (addr) {
> page = hyp_virt_to_page(addr);
> page->refcount = 0;
> - page->order = 0;
> push_hyp_memcache(mc, addr, hyp_virt_to_phys);
> WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(addr), 1));
> addr = hyp_alloc_pages(&vm->pool, 0);
> diff --git a/arch/arm64/kvm/hyp/nvhe/page_alloc.c b/arch/arm64/kvm/hyp/nvhe/page_alloc.c
> index a1eb27a1a747..57f86aa0f82f 100644
> --- a/arch/arm64/kvm/hyp/nvhe/page_alloc.c
> +++ b/arch/arm64/kvm/hyp/nvhe/page_alloc.c
> @@ -94,13 +94,22 @@ static void __hyp_attach_page(struct hyp_pool *pool,
> struct hyp_page *p)
> {
> phys_addr_t phys = hyp_page_to_phys(p);
> - u8 order = p->order;
> struct hyp_page *buddy;
> + bool coalesce = true;
> + u8 order = p->order;
>
> - memset(hyp_page_to_virt(p), 0, PAGE_SIZE << p->order);
> + /*
> + * 'external' pages are never coalesced and their ->order field
> + * untrusted as they bypass hyp_pool_init(). Enforce order-0.
> + */
> + if (phys < pool->range_start || phys >= pool->range_end) {
> + order = 0;
> + coalesce = false;
> + }
> +
> + memset(hyp_page_to_virt(p), 0, PAGE_SIZE << order);
>
> - /* Skip coalescing for 'external' pages being freed into the pool. */
> - if (phys < pool->range_start || phys >= pool->range_end)
> + if (!coalesce)
> goto insert;
>
> /*
> @@ -237,8 +246,10 @@ int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned int nr_pages,
>
> /* Init the vmemmap portion */
> p = hyp_phys_to_page(phys);
> - for (i = 0; i < nr_pages; i++)
> + for (i = 0; i < nr_pages; i++) {
> hyp_set_page_refcounted(&p[i]);
> + p[i].order = 0;
> + }
>
> /* Attach the unused pages to the buddy tree */
> for (i = reserved_pages; i < nr_pages; i++)
> --
> 2.54.0.746.g67dd491aae-goog
>
^ permalink raw reply
* Re: [PATCH v1 14/15] dt-bindings: display: panel-lvds: Add LG LP156WF1
From: Krzysztof Kozlowski @ 2026-05-22 6:53 UTC (permalink / raw)
To: Vitor Soares
Cc: Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding, Sam Ravnborg, Vitor Soares, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260521150038.103538-31-ivitro@gmail.com>
On Thu, May 21, 2026 at 04:00:50PM +0100, Vitor Soares wrote:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> Add the compatible string for the LG LP156WF1 15.6" FHD (1920x1080)
> dual-channel TFT LCD LVDS panel.
>
> Assisted-by: Claude:claude-sonnet-4.6
Really - oneliner for trivial binding needs AI tools to help writing it?
> Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
> ---
> Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 01/10] dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock for RK3588
From: Damon Ding @ 2026-05-22 6:29 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260522-demonic-shaggy-wasp-a3f261@quoll>
Hi Krzysztof,
On 5/22/2026 2:11 PM, Krzysztof Kozlowski wrote:
> On Thu, May 21, 2026 at 04:08:26PM +0800, Damon Ding wrote:
>> RK3588 eDP controller requires HCLK_VO1 to access the VO1 GRF
>> registers and enable the video datapath.
>>
>> Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
>> phandle reference, which allowed the eDP to work without explicitly
>> managing the hclk_vo1 clock. However, this is not safe or explicit.
>>
>> To make the clock dependency explicit, enforce per-SoC clock-names
>> requirements:
>> - RK3288: 2 clocks (dp, pclk)
>> - RK3399: 3 clocks (dp, pclk, grf)
>> - RK3588: 3 clocks (dp, pclk, hclk)
>>
>> Do not reuse the 'grf' clock name for RK3588 because it represents
>> a different clock with distinct control logic:
>> - The 'grf' clock is only for GRF register access and is toggled
>> dynamically during register access.
>> - The 'hclk' clock controls both GRF access and video datapath
>> gating, and must remain enabled during probe.
>>
>> Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>>
>> ---
>>
>> Changes in v4:
>> - Modify the commit msg.
>>
>> Changes in v5:
>> - Enforce the correct third clock name on a per-compatible basis.
>> - Modify the commit msg simultaneously.
>>
>> Changes in v6:
>> - Expand more detail commit msg about using hclk instead of grf clock.
>> ---
>> .../rockchip/rockchip,analogix-dp.yaml | 37 +++++++++++++++++--
>> 1 file changed, 33 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> index d99b23b88cc5..8001c1facf98 100644
>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>> @@ -23,10 +23,7 @@ properties:
>>
>> clock-names:
>> minItems: 2
>> - items:
>> - - const: dp
>> - - const: pclk
>> - - const: grf
>> + maxItems: 3
>>
>> power-domains:
>> maxItems: 1
>> @@ -60,6 +57,33 @@ required:
>> allOf:
>> - $ref: /schemas/display/bridge/analogix,dp.yaml#
>>
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - rockchip,rk3288-dp
>> + then:
>> + properties:
>> + clock-names:
>> + items:
>> + - const: dp
>> + - const: pclk
>
> Why aren't there constraints for clocks? They always must come together.
>
> Please open any other binding and look how it is done there.
>
>
Yes, as Conor's suggestion, the right way is to keep all valid clock
names at the top level, and use only minItems/maxItems in allOf to
differentiate clocks and clock-names of platforms.
I will update this in next version.
Best regards,
Damon
^ permalink raw reply
* Re: [PATCH] irqchip/exynos-combiner: remove useless spinlock
From: Sebastian Andrzej Siewior @ 2026-05-22 6:27 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-arm-kernel, linux-samsung-soc, linux-rt-devel,
Thomas Gleixner, Krzysztof Kozlowski, Alim Akhtar, Clark Williams,
Steven Rostedt
In-Reply-To: <20260522061012.2687122-1-m.szyprowski@samsung.com>
On 2026-05-22 08:10:12 [+0200], Marek Szyprowski wrote:
> irq_controller_lock doesn't protect anything, it must be some leftover
> from early development or copy/paste. Remove it completely.
>
> Suggested-by: Thomas Gleixner <tglx@kernel.org>
> Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Link: https://lore.kernel.org/all/20260520220422.3522908-1-m.szyprowski@samsung.com/
> Fixes: 96031b31a4b3 ("irqchip/exynos-combiner: Switch to raw_spinlock")
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
There is a bit of reserch in 20260521090453.bbUZ00tS@linutronix.de why
it is a leftover.
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Sebastian
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: clock: Add Amlogic A9 PLL clock controller
From: Jian Hu @ 2026-05-22 6:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Jerome Brunet, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-kernel, linux-clk,
devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <20260515-subtle-sepia-tuatara-cfee3d@quoll>
Hi Krzysztof,
Thanks for your review.
On 5/15/2026 4:09 PM, Krzysztof Kozlowski wrote:
> [ EXTERNAL EMAIL ]
>
> On Mon, May 11, 2026 at 08:47:24PM +0800, Jian Hu wrote:
>> Add the PLL clock controller dt-bindings for the Amlogic A9 SoC family.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> ---
>> .../bindings/clock/amlogic,a9-pll-clkc.yaml | 110 +++++++++++++++++++++
>> include/dt-bindings/clock/amlogic,a9-pll-clkc.h | 55 +++++++++++
>> 2 files changed, 165 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
>> new file mode 100644
>> index 000000000000..4ee6013ba1a1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
>> @@ -0,0 +1,110 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (C) 2026 Amlogic, Inc. All rights reserved
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/clock/amlogic,a9-pll-clkc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Amlogic A9 Series PLL Clock Controller
>> +
>> +maintainers:
>> + - Neil Armstrong <neil.armstrong@linaro.org>
>> + - Jerome Brunet <jbrunet@baylibre.com>
>> + - Jian Hu <jian.hu@amlogic.com>
>> + - Xianwei Zhao <xianwei.zhao@amlogic.com>
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - amlogic,a9-gp0-pll
>> + - amlogic,a9-hifi0-pll
>> + - amlogic,a9-hifi1-pll
>> + - amlogic,a9-mclk0-pll
>> + - amlogic,a9-mclk1-pll
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + '#clock-cells':
>> + const: 1
>> +
>> + clocks:
>> + items:
>> + - description: pll input oscillator gate
>> + - description: fixed input clock source for mclk_sel_0
>> + - description: u3p2pll input clock source for mclk_sel_0 (optional)
> Second clock is also optional. Drop "(optional)" comment, just
> confusing.
GP0 has only one parent clock, while MCLK has three.
The second and third parent entries of GP0 are vacant,
so they need to be marked optional.
I will add the optional property for the second clock in the next revision.
>> + minItems: 1
>> +
>> + clock-names:
>> + items:
>> + - const: in0
>> + - const: in1
>> + - const: in2
> Pretty pointless names, drop property.
Ok, I will drop them.
clock-names:
- items:
- - const: in0
- - const: in1
- - const: in2
minItems: 1
>> + minItems: 1
>> +
>> +required:
>> + - compatible
>> + - '#clock-cells'
>> + - reg
>> + - clocks
>> + - clock-names
>> +
>> +allOf:
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - amlogic,a9-mclk0-pll
>> + - amlogic,a9-mclk1-pll
>> +
>> + then:
>> + properties:
>> + clocks:
>> + maxItems: 3
> No, minItems instead. maxItems is already 3, so what is the point of
> redefining it?
Ok, I will use minItems instead.
>> +
>> + clock-names:
>> + maxItems: 3
>> +
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - amlogic,a9-gp0-pll
>> + - amlogic,a9-hifi0-pll
>> + - amlogic,a9-hifi1-pll
>> +
>> + then:
>> + properties:
>> + clocks:
>> + maxItems: 1
>> +
>> + clock-names:
>> + maxItems: 1
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + apb4 {
> soc
Ok, I will rename it to soc.
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + clock-controller@8200 {
>> + compatible = "amlogic,a9-gp0-pll";
>> + reg = <0x0 0x8200 0x0 0x20>;
>> + #clock-cells = <1>;
>> + clocks = <&scmi_clk 0>;
>> + clock-names = "in0";
>> + };
>> +
>> + clock-controller@8330 {
>> + compatible = "amlogic,a9-mclk0-pll";
>> + reg = <0x0 0x8330 0x0 0x14>;
>> + #clock-cells = <1>;
>> + clocks = <&scmi_clk 4>,
>> + <&scmi_clk 8>;
>> + clock-names = "in0", "in1";
> One example is enough, you have exactly the same properties.
Ok, I will drop the second clock node.
>
> Best regards,
> Krzysztof
>
Best regards,
Jian
^ permalink raw reply
* RE: [PATCH 1/2] PCI: host-generic: Simplify return value handling in pci_host_common_parse_port(s)
From: Sherry Sun @ 2026-05-22 6:20 UTC (permalink / raw)
To: Hongxing Zhu, Sherry Sun (OSS), l.stach@pengutronix.de, Frank Li,
bhelgaas@google.com, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, robh@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
will@kernel.org
Cc: imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <GV2PR04MB12019D8D1854A947AA7DDE1208C0F2@GV2PR04MB12019.eurprd04.prod.outlook.com>
> > Subject: [PATCH 1/2] PCI: host-generic: Simplify return value handling
> > in
> > pci_host_common_parse_port(s)
> >
> > From: Sherry Sun <sherry.sun@nxp.com>
> >
> > The pci_host_common_parse_port() shouldn't check the RC-level binding.
> > That's a policy decision that belongs to the caller, not this common helper.
> >
> > Simplify pci_host_common_parse_port() to only parses properties from
> > the Root
> "to only parses"/s/"to only parse"
>
> > Port(and its children) without checking the RC node. Also change
> Missing space after "Port".
>
> > pci_host_common_parse_ports() to return 0 when no ports are found,
> > since it is not an error.
> >
> > So now both functions won't return failure for "property not found" or
> > "port not found", they purely returns 0 on success and a negative
> > error code on real
> returns/s/return
Thanks, will fix these issues.
Best Regards
Sherry Sun
>
> Best Regards
> Richard Zhu
>
> > failures.
> >
> > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > ---
> > drivers/pci/controller/pci-host-common.c | 29
> > ++++--------------------
> > 1 file changed, 5 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pci-host-common.c
> > b/drivers/pci/controller/pci- host-common.c index
> > 67455caaf9e6..7ce5a939e3d9 100644
> > --- a/drivers/pci/controller/pci-host-common.c
> > +++ b/drivers/pci/controller/pci-host-common.c
> > @@ -108,8 +108,7 @@ static int pci_host_common_parse_perst(struct
> > device *dev,
> > * dependencies and the driver may fail to operate if required resources
> > * are missing.
> > *
> > - * Return: 0 on success, -ENODEV if PERST# found in RC node (legacy
> > binding
> > - * should be used), Other negative error codes on failure.
> > + * Return: 0 on success, negative error codes on failure.
> > */
> > static int pci_host_common_parse_port(struct device *dev,
> > struct pci_host_bridge *bridge, @@ -
> 128,22
> > +127,6 @@ static int pci_host_common_parse_port(struct device *dev,
> > if (ret)
> > return ret;
> >
> > - /*
> > - * 1. PERST# found in RP or its child nodes - list is not empty,
> > - * continue
> > - *
> > - * 2. PERST# not found in RP/children, but found in RC node -
> > - * return -ENODEV to fallback legacy binding
> > - *
> > - * 3. PERST# not found anywhere - list is empty, continue (optional
> > - * PERST#)
> > - */
> > - if (list_empty(&port->perst)) {
> > - if (of_property_present(dev->of_node, "reset-gpios") ||
> > - of_property_present(dev->of_node, "reset-gpio"))
> > - return -ENODEV;
> > - }
> > -
> > INIT_LIST_HEAD(&port->list);
> > list_add_tail(&port->list, &bridge->ports);
> >
> > @@ -158,13 +141,11 @@ static int pci_host_common_parse_port(struct
> > device *dev,
> > * Iterate through child nodes of the host bridge and parse Root Port
> > * properties (currently only reset GPIOs).
> > *
> > - * Return: 0 on success, -ENODEV if no ports found or PERST# found in
> > RC
> > - * node (legacy binding should be used), Other negative error codes
> > on
> > - * failure.
> > + * Return: 0 on success, negative error codes on failure.
> > */
> > int pci_host_common_parse_ports(struct device *dev, struct
> > pci_host_bridge
> > *bridge) {
> > - int ret = -ENODEV;
> > + int ret = 0;
> >
> > for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> > if (!of_node_is_type(of_port, "pci")) @@ -174,8 +155,8 @@
> int
> > pci_host_common_parse_ports(struct device *dev, struct pci_host_bridge
> *brid
> > goto err_cleanup;
> > }
> >
> > - if (ret)
> > - return ret;
> > + if (list_empty(&bridge->ports))
> > + return 0;
> >
> > return devm_add_action_or_reset(dev,
> pci_host_common_delete_ports,
> > &bridge->ports);
> > --
> > 2.37.1
^ permalink raw reply
* Re: [PATCH v6 01/10] dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock for RK3588
From: Krzysztof Kozlowski @ 2026-05-22 6:11 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260521080835.1362416-2-damon.ding@rock-chips.com>
On Thu, May 21, 2026 at 04:08:26PM +0800, Damon Ding wrote:
> RK3588 eDP controller requires HCLK_VO1 to access the VO1 GRF
> registers and enable the video datapath.
>
> Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
> phandle reference, which allowed the eDP to work without explicitly
> managing the hclk_vo1 clock. However, this is not safe or explicit.
>
> To make the clock dependency explicit, enforce per-SoC clock-names
> requirements:
> - RK3288: 2 clocks (dp, pclk)
> - RK3399: 3 clocks (dp, pclk, grf)
> - RK3588: 3 clocks (dp, pclk, hclk)
>
> Do not reuse the 'grf' clock name for RK3588 because it represents
> a different clock with distinct control logic:
> - The 'grf' clock is only for GRF register access and is toggled
> dynamically during register access.
> - The 'hclk' clock controls both GRF access and video datapath
> gating, and must remain enabled during probe.
>
> Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>
> ---
>
> Changes in v4:
> - Modify the commit msg.
>
> Changes in v5:
> - Enforce the correct third clock name on a per-compatible basis.
> - Modify the commit msg simultaneously.
>
> Changes in v6:
> - Expand more detail commit msg about using hclk instead of grf clock.
> ---
> .../rockchip/rockchip,analogix-dp.yaml | 37 +++++++++++++++++--
> 1 file changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> index d99b23b88cc5..8001c1facf98 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> @@ -23,10 +23,7 @@ properties:
>
> clock-names:
> minItems: 2
> - items:
> - - const: dp
> - - const: pclk
> - - const: grf
> + maxItems: 3
>
> power-domains:
> maxItems: 1
> @@ -60,6 +57,33 @@ required:
> allOf:
> - $ref: /schemas/display/bridge/analogix,dp.yaml#
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - rockchip,rk3288-dp
> + then:
> + properties:
> + clock-names:
> + items:
> + - const: dp
> + - const: pclk
Why aren't there constraints for clocks? They always must come together.
Please open any other binding and look how it is done there.
Best regards,
Krzysztof
^ 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