* Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
From: Krzysztof Kozlowski @ 2026-06-24 9:41 UTC (permalink / raw)
To: Biju
Cc: Geert Uytterhoeven, Alex Helms, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Magnus Damm,
Biju Das, Brian Masney, linux-renesas-soc, linux-clk, devicetree,
linux-kernel, Prabhakar Mahadev Lad
In-Reply-To: <20260623162039.153291-1-biju.das.jz@bp.renesas.com>
On Tue, Jun 23, 2026 at 05:20:37PM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Alex's email is bouncing. Update the maintainers list with my contact
> details to take over the schema maintenance.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> Ref [1]
> [1] https://lore.kernel.org/all/ajqWevofEJ3fv856@redhat.com/
> ---
> .../devicetree/bindings/clock/renesas,versaclock7.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Please also update MAINTAINERS file.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 07/15] drm/tidss: oldi: Remove define for unused register OLDI_LB_CTRL
From: Swamil Jain @ 2026-06-24 9:41 UTC (permalink / raw)
To: Tomi Valkeinen, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Aradhya Bhatia,
Nishanth Menon, Vignesh Raghavendra, Devarsh Thakkar,
Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <20260529-beagley-ai-display-v3-7-7fefdc5d1adf@ideasonboard.com>
On 5/29/26 14:15, Tomi Valkeinen wrote:
> OLDI_LB_CTRL define is not used, and doesn't seem to exist at least on
> some SoCs. Let's remove the define.
>
> Tested-by: Swamil Jain <s-jain1@ti.com>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
Reviewed-by: Swamil Jain <s-jain1@ti.com>
> drivers/gpu/drm/tidss/tidss_oldi.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_oldi.h b/drivers/gpu/drm/tidss/tidss_oldi.h
> index 8cd535c5ee65..a361e6dbfce3 100644
> --- a/drivers/gpu/drm/tidss/tidss_oldi.h
> +++ b/drivers/gpu/drm/tidss/tidss_oldi.h
> @@ -20,7 +20,6 @@ struct tidss_oldi;
>
> /* Register offsets */
> #define OLDI_PD_CTRL 0x100
> -#define OLDI_LB_CTRL 0x104
>
> /* Power control bits */
> #define OLDI_PWRDOWN_TX(n) BIT(n)
>
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: vendor-prefixes: Add Opto Logic
From: Krzysztof Kozlowski @ 2026-06-24 9:42 UTC (permalink / raw)
To: Leonardo Costa
Cc: laurent.pinchart, neil.armstrong, jesszhan0024, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
nm, vigneshr, kristo, prabhakar.mahadev-lad.rj, thierry.reding,
sam, leonardo.costa, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260623195741.495734-2-leoreis.costa@gmail.com>
On Tue, Jun 23, 2026 at 04:57:37PM -0300, Leonardo Costa wrote:
> From: Leonardo Costa <leonardo.costa@toradex.com>
>
> Add vendor prefix for Opto Logic, a Swiss display solutions provider and
> printing systems manufacturer.
>
> Link: https://optologic.ch/
> Signed-off-by: Leonardo Costa <leonardo.costa@toradex.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: display: panel-lvds: Add compatible for Opto Logic SCX1001511GGC49
From: Krzysztof Kozlowski @ 2026-06-24 9:43 UTC (permalink / raw)
To: Leonardo Costa
Cc: laurent.pinchart, neil.armstrong, jesszhan0024, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
nm, vigneshr, kristo, prabhakar.mahadev-lad.rj, thierry.reding,
sam, leonardo.costa, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260623195741.495734-3-leoreis.costa@gmail.com>
On Tue, Jun 23, 2026 at 04:57:38PM -0300, Leonardo Costa wrote:
> From: Leonardo Costa <leonardo.costa@toradex.com>
>
> The Opto Logic SCX1001511GGC49 is a 10.1" WXGA (1280x800) TFT LCD LVDS
> panel.
>
> Signed-off-by: Leonardo Costa <leonardo.costa@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] dt-bindings: clock: renesas,versaclock7: Update maintainer
From: Biju Das @ 2026-06-24 9:46 UTC (permalink / raw)
To: Krzysztof Kozlowski, biju.das.au
Cc: Geert Uytterhoeven, Alex Helms, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, magnus.damm,
Brian Masney, linux-renesas-soc@vger.kernel.org,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Prabhakar Mahadev Lad
In-Reply-To: <20260624-advanced-pink-dinosaur-ebe720@quoll>
Hi Krzysztof Kozlowski,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: 24 June 2026 10:42
> Subject: Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
>
> On Tue, Jun 23, 2026 at 05:20:37PM +0100, Biju wrote:
> > From: Biju Das <biju.das.jz@bp.renesas.com>
> >
> > Alex's email is bouncing. Update the maintainers list with my contact
> > details to take over the schema maintenance.
> >
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > ---
> > Ref [1]
> > [1] https://lore.kernel.org/all/ajqWevofEJ3fv856@redhat.com/
> > ---
> > .../devicetree/bindings/clock/renesas,versaclock7.yaml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Please also update MAINTAINERS file.
It is taken care in [1]
[1] https://lore.kernel.org/all/CAMuHMdW0-WsZuuc7PoVNC5DBUoY9dP+ULmGTQ76VWMO_SjpbuQ@mail.gmail.com/
Cheers,
Biju
^ permalink raw reply
* [PATCH v2 0/2] Fix traceNoC probe issue on Kaanapali
From: Jie Gan @ 2026-06-24 9:49 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
Patch 1 changes the binding to allow the TraceNoC device accepts
arm,primecell-periphid property.
Patch 2 fixes the deferred probe issue for the TraceNoC device by
adding the arm,primecell-periphid property to bypass the AMBA check.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Changes in v2:
- address the ATID issue reported by Sashiko.
- update binding to accept arm,primecell-periphid property.
- Link to v1: https://lore.kernel.org/r/20260624-fix-tracenoc-probe-issue-v1-1-bcc785198fc5@oss.qualcomm.com
---
Jie Gan (2):
dt-bindings: arm: qcom,coresight-tnoc: allow arm,primecell-periphid
arm64: dts: qcom: kaanapali: fix traceNoC probe issue
Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml | 5 ++++-
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
---
base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
change-id: 20260624-fix-tracenoc-probe-issue-c6429da28df4
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: arm: qcom,coresight-tnoc: allow arm,primecell-periphid
From: Jie Gan @ 2026-06-24 9:49 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260624-fix-tracenoc-probe-issue-v2-0-786520f62f21@oss.qualcomm.com>
The TNOC device is an AMBA primecell and may carry the standard
arm,primecell-periphid property, which is used to supply the
peripheral ID when it cannot be read from the device registers.
Reference primecell.yaml and set additionalProperties to true so the
binding accepts arm,primecell-periphid along with the other common
primecell properties.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
index ef648a15b806..9624fc0adfdc 100644
--- a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
@@ -32,6 +32,9 @@ select:
required:
- compatible
+allOf:
+ - $ref: /schemas/arm/primecell.yaml#
+
properties:
$nodename:
pattern: "^tn(@[0-9a-f]+)$"
@@ -78,7 +81,7 @@ required:
- in-ports
- out-ports
-additionalProperties: false
+additionalProperties: true
examples:
- |
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-24 9:49 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260624-fix-tracenoc-probe-issue-v2-0-786520f62f21@oss.qualcomm.com>
The AMBA bus attempts to read the CID/PID of a device before invoking
its probe function if the arm,primecell-periphid property is absent.
This causes a deferred probe issue for the TraceNoC device, as the
CID/PID cannot be read from the periphid register.
Add the arm,primecell-periphid property to bypass the AMBA bus
check and resolve the probe issue.
Fixes: f73959d86c15 ("arm64: dts: qcom: kaanapali: add coresight nodes")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7aa9653bd456..25820f7c04cd 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -5009,6 +5009,7 @@ tn@111b8000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ arm,primecell-periphid = <0x000f0c00>;
in-ports {
#address-cells = <1>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
From: Krzysztof Kozlowski @ 2026-06-24 9:51 UTC (permalink / raw)
To: Biju Das, biju.das.au
Cc: Geert Uytterhoeven, Alex Helms, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, magnus.damm,
Brian Masney, linux-renesas-soc@vger.kernel.org,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Prabhakar Mahadev Lad
In-Reply-To: <TY3PR01MB11346659E1A238C232E29946686ED2@TY3PR01MB11346.jpnprd01.prod.outlook.com>
On 24/06/2026 11:46, Biju Das wrote:
> Hi Krzysztof Kozlowski,
>
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzk@kernel.org>
>> Sent: 24 June 2026 10:42
>> Subject: Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
>>
>> On Tue, Jun 23, 2026 at 05:20:37PM +0100, Biju wrote:
>>> From: Biju Das <biju.das.jz@bp.renesas.com>
>>>
>>> Alex's email is bouncing. Update the maintainers list with my contact
>>> details to take over the schema maintenance.
>>>
>>> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
>>> ---
>>> Ref [1]
>>> [1] https://lore.kernel.org/all/ajqWevofEJ3fv856@redhat.com/
>>> ---
>>> .../devicetree/bindings/clock/renesas,versaclock7.yaml | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Please also update MAINTAINERS file.
>
> It is taken care in [1]
>
> [1] https://lore.kernel.org/all/CAMuHMdW0-WsZuuc7PoVNC5DBUoY9dP+ULmGTQ76VWMO_SjpbuQ@mail.gmail.com/
Just squash them together.
When you fix such issue like wrong email, fix it everywhere, not just
one-by-one where the maintainers need to poke you to fix in other places
as well. It is generic rule for bugs as well. The wrong email address is
the most obvious example here, because it is also extremely easy. Just
use git grep.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom,coresight-tnoc: allow arm,primecell-periphid
From: sashiko-bot @ 2026-06-24 9:54 UTC (permalink / raw)
To: Jie Gan; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260624-fix-tracenoc-probe-issue-v2-1-786520f62f21@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Setting `additionalProperties: true` completely disables strict schema validation for undefined properties, allowing misspelled or undocumented properties to silently pass.
--
commit 6e8606766f1fd41047be4a5d6a3178b5f3fd67e9
Author: Jie Gan <jie.gan@oss.qualcomm.com>
dt-bindings: arm: qcom,coresight-tnoc: allow arm,primecell-periphid
This commit updates the qcom,coresight-tnoc binding to reference
primecell.yaml. It changes additionalProperties to true to allow
the arm,primecell-periphid property along with other common properties.
> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
[ ... ]
> @@ -78,7 +81,7 @@ required:
> - in-ports
> - out-ports
>
> -additionalProperties: false
> +additionalProperties: true
[Severity: Medium]
Does setting additionalProperties to true completely disable strict schema
validation for this node?
It looks like this change will cause misspelled properties to silently pass
during make dt_binding_check. When adding a $ref in an allOf block, should
unevaluatedProperties: false be used instead? That would allow the inherited
primecell.yaml properties to pass while still rejecting any undefined or
typoed properties.
>
> examples:
> - |
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624-fix-tracenoc-probe-issue-v2-0-786520f62f21@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH 07/12] rtc: rzn1: fix alarm range check truncation on 32-bit systems
From: Lad, Prabhakar @ 2026-06-24 9:53 UTC (permalink / raw)
To: Wolfram Sang
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <ajr1wXCI2U23d1sY@shikoro>
Hi Wolfram,
On Tue, Jun 23, 2026 at 10:08 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
>
>
> > Can you please share the commands you tried, I'll try and replicate it
> > on my side.
>
> Sorry, can't give you the commands, just from my head: I tried to set an
> alarm more than a week in the future, and the alarm was set to the next
> day. But I was in a hurry, maybe I overlooked something, because that
> handling used to work in the past IIRC. I can return to this topic on
> Friday earliest, sadly. Maybe next week only...
>
I ran some tests for cases #1 and #2, and we see an out-of-range
error. By adding a 1-sec leeway when checking the ranges I don't get
the out-of-range error. Let me know what you think (I'll create a
seprate patch for it).
Case #1 reverting this patch:
root@rzn2h-evk:~# date -s "2026-06-24 10:34:00"; hwclock -w;
Wed Jun 24 10:34:00 UTC 2026
root@rzn2h-evk:~#
root@rzn2h-evk:~#
root@rzn2h-evk:~# rtcwake -m no -s 604800;cat /proc/driver/rtc
rtcwake: set rtc wake alarm failed: Numerical result out of range
rtc_time : 10:34:32
rtc_date : 2026-06-24
alrm_time : 10:34:33
alrm_date : 2026-07-01
alarm_IRQ : no
alrm_pending : no
update IRQ enabled : no
periodic IRQ enabled : no
periodic IRQ frequency : 1
max user IRQ frequency : 64
24hr : yes
root@rzn2h-evk:~#
Case #2 with this patch:
root@rzn2h-evk:~# date -s "2026-06-24 10:46:00"; hwclock -w;
Wed Jun 24 10:46:00 UTC 2026
root@rzn2h-evk:~# rtcwake -m no -s 604800;cat /proc/driver/rtc
rtcwake: set rtc wake alarm failed: Numerical result out of range
rtc_time : 10:46:30
rtc_date : 2026-06-24
alrm_time : 10:46:31
alrm_date : 2026-07-01
alarm_IRQ : no
alrm_pending : no
update IRQ enabled : no
periodic IRQ enabled : no
periodic IRQ frequency : 1
max user IRQ frequency : 64
24hr : yes
root@rzn2h-evk:~#
Case #3: Add 1-sec leeway:
root@rzn2h-evk:~# date -s "2026-06-24 10:48:00"; hwclock -w;
Wed Jun 24 10:48:00 UTC 2026
root@rzn2h-evk:~# rtcwake -m no -s 604800;cat /proc/driver/rtc
rtcwake: wakeup using /dev/rtc0 at Wed Jul 1 10:48:50 2026
rtc_time : 10:48:49
rtc_date : 2026-06-24
alrm_time : 10:48:50
alrm_date : 2026-07-01
alarm_IRQ : yes
alrm_pending : no
update IRQ enabled : no
periodic IRQ enabled : no
periodic IRQ frequency : 1
max user IRQ frequency : 64
24hr : yes
root@rzn2h-evk:~#
Changes for case #3:
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index 173526d50d41..8fdb5114a6d8 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -279,7 +279,9 @@ static int rzn1_rtc_set_alarm(struct device *dev,
struct rtc_wkalrm *alrm)
/* We cannot set alarms more than one week ahead */
farest = rtc_tm_to_time64(&tm_now) + rtc->rtcdev->alarm_offset_max;
alarm = rtc_tm_to_time64(tm);
- if (alarm > farest)
+
+ /* Add a 1-second leeway for processing delay */
+ if (alarm > (farest + 1))
return -ERANGE;
/* Convert alarm day into week day */
Cheers,
Prabhakar
^ permalink raw reply related
* RE: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
From: Biju Das @ 2026-06-24 9:59 UTC (permalink / raw)
To: Krzysztof Kozlowski, biju.das.au
Cc: Geert Uytterhoeven, Alex Helms, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, magnus.damm,
Brian Masney, linux-renesas-soc@vger.kernel.org,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Prabhakar Mahadev Lad
In-Reply-To: <77976912-b0b0-4e08-ad9c-5080c4d8adcc@kernel.org>
Hi Krzysztof Kozlowski,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: 24 June 2026 10:52
> Subject: Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
>
> On 24/06/2026 11:46, Biju Das wrote:
> > Hi Krzysztof Kozlowski,
> >
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <krzk@kernel.org>
> >> Sent: 24 June 2026 10:42
> >> Subject: Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update
> >> maintainer
> >>
> >> On Tue, Jun 23, 2026 at 05:20:37PM +0100, Biju wrote:
> >>> From: Biju Das <biju.das.jz@bp.renesas.com>
> >>>
> >>> Alex's email is bouncing. Update the maintainers list with my
> >>> contact details to take over the schema maintenance.
> >>>
> >>> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> >>> ---
> >>> Ref [1]
> >>> [1] https://lore.kernel.org/all/ajqWevofEJ3fv856@redhat.com/
> >>> ---
> >>> .../devicetree/bindings/clock/renesas,versaclock7.yaml | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> Please also update MAINTAINERS file.
> >
> > It is taken care in [1]
> >
> > [1]
> > https://lore.kernel.org/all/CAMuHMdW0-WsZuuc7PoVNC5DBUoY9dP+ULmGTQ76VW
> > MO_SjpbuQ@mail.gmail.com/
>
> Just squash them together.
>
> When you fix such issue like wrong email, fix it everywhere, not just one-by-one where the maintainers
> need to poke you to fix in other places as well. It is generic rule for bugs as well. The wrong email
> address is the most obvious example here, because it is also extremely easy. Just use git grep.
Ok, but both patches were already queued by Geert for 7.3.
The MAINTAINERS file patch is 9 months old patch.
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: leds: backlight: document the SY7758 6-channel High Efficiency LED Driver
From: Daniel Thompson @ 2026-06-24 10:00 UTC (permalink / raw)
To: Neil Armstrong
Cc: Lee Jones, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, dri-devel,
linux-leds, devicetree, linux-kernel, linux-fbdev, KancyJoe,
Krzysztof Kozlowski
In-Reply-To: <20260529-topic-sm8650-ayaneo-pocket-s2-sy7758-v5-1-03aacd49747c@linaro.org>
On Fri, May 29, 2026 at 09:23:08PM +0200, Neil Armstrong wrote:
> Document the Silergy SY7758 6-channel High Efficiency LED Driver
> used for backlight brightness control.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
From: Krzysztof Kozlowski @ 2026-06-24 10:00 UTC (permalink / raw)
To: Biju Das, biju.das.au
Cc: Geert Uytterhoeven, Alex Helms, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, magnus.damm,
Brian Masney, linux-renesas-soc@vger.kernel.org,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Prabhakar Mahadev Lad
In-Reply-To: <TY3PR01MB11346A6077B4F7380078EA3B486ED2@TY3PR01MB11346.jpnprd01.prod.outlook.com>
On 24/06/2026 11:59, Biju Das wrote:
> Hi Krzysztof Kozlowski,
>
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzk@kernel.org>
>> Sent: 24 June 2026 10:52
>> Subject: Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
>>
>> On 24/06/2026 11:46, Biju Das wrote:
>>> Hi Krzysztof Kozlowski,
>>>
>>>> -----Original Message-----
>>>> From: Krzysztof Kozlowski <krzk@kernel.org>
>>>> Sent: 24 June 2026 10:42
>>>> Subject: Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update
>>>> maintainer
>>>>
>>>> On Tue, Jun 23, 2026 at 05:20:37PM +0100, Biju wrote:
>>>>> From: Biju Das <biju.das.jz@bp.renesas.com>
>>>>>
>>>>> Alex's email is bouncing. Update the maintainers list with my
>>>>> contact details to take over the schema maintenance.
>>>>>
>>>>> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
>>>>> ---
>>>>> Ref [1]
>>>>> [1] https://lore.kernel.org/all/ajqWevofEJ3fv856@redhat.com/
>>>>> ---
>>>>> .../devicetree/bindings/clock/renesas,versaclock7.yaml | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> Please also update MAINTAINERS file.
>>>
>>> It is taken care in [1]
>>>
>>> [1]
>>> https://lore.kernel.org/all/CAMuHMdW0-WsZuuc7PoVNC5DBUoY9dP+ULmGTQ76VW
>>> MO_SjpbuQ@mail.gmail.com/
>>
>> Just squash them together.
>>
>> When you fix such issue like wrong email, fix it everywhere, not just one-by-one where the maintainers
>> need to poke you to fix in other places as well. It is generic rule for bugs as well. The wrong email
>> address is the most obvious example here, because it is also extremely easy. Just use git grep.
>
> Ok, but both patches were already queued by Geert for 7.3.
>
> The MAINTAINERS file patch is 9 months old patch.
Hm? How or what exactly is 9 months old? I did `git grep` now and I
still see old email entry in next-20260619
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 2/2] backlight: Add SY7758 6-channel High Efficiency LED Driver support
From: Daniel Thompson @ 2026-06-24 10:00 UTC (permalink / raw)
To: Neil Armstrong
Cc: Lee Jones, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, dri-devel,
linux-leds, devicetree, linux-kernel, linux-fbdev, KancyJoe
In-Reply-To: <20260529-topic-sm8650-ayaneo-pocket-s2-sy7758-v5-2-03aacd49747c@linaro.org>
On Fri, May 29, 2026 at 09:23:09PM +0200, Neil Armstrong wrote:
> From: KancyJoe <kancy2333@outlook.com>
>
> Implement support for the Silergy SY7758 6-channel High Efficiency LED
> Driver used for backlight brightness control in the Ayaneo Pocket S2
> dual-DSI panel.
>
> Signed-off-by: KancyJoe <kancy2333@outlook.com>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: glymur-crd: Move common board nodes to shared DTSI
From: Pankaj Patil @ 2026-06-24 10:02 UTC (permalink / raw)
To: Gopikrishna Garmidi, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, sibi.sankar,
rajendra.nayak
In-Reply-To: <b61ec109-92db-4dc1-ba7d-a5ce79fea08a@oss.qualcomm.com>
On 6/8/2026 3:33 PM, Gopikrishna Garmidi wrote:
>
>
> On 5/19/2026 7:55 PM, Gopikrishna Garmidi wrote:
>> The Glymur and Mahua CRDs use the same board-level hardware for the
>> eDP display panel, MDSS DP3 controller and PHY, USB-C ports (via
>> pmic-glink), USB 0/1/HS/MP controllers, QMP PHYs, eUSB2 repeaters,
>> HID peripherals (touchpad, keyboard, touchscreen) and their dependent
>> regulators and pin control states. This has been verified against
>> both CRD schematics.
>>
>> Move these nodes from glymur-crd.dts to glymur-crd.dtsi to enable code
>> reuse with the Mahua CRD.
>>
>> Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
>> ---
>> Changes in v2:
>> - Rebased on top of next-20260518
>> - Updated subject to include glymur-crd scope prefix
>> - Rewrote commit message to describe the actual shared physical hardware
>> rather than the code-sharing intent; the commonality was verified
>> against Glymur CRD and Mahua CRD schematics
>> - Link to v1: https://lore.kernel.org/r/20260326-glymur-mahua-common-nodes-v1-1-12bb26920ea4@oss.qualcomm.com
>> ---
>> arch/arm64/boot/dts/qcom/glymur-crd.dts | 399 -------------------------------
>> arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 396 ++++++++++++++++++++++++++++++
>> 2 files changed, 396 insertions(+), 399 deletions(-)
>
>
> Hi Krzysztof, Konrad,
>
> This has been waiting for a while now and already has a Reviewed-by from Dmitry. Could you take a look when you get a chance?
>
> Thanks,
> Gopikrishna Garmidi
Krzystof,
We've verified from the schematics the soc gpio and other lines do not change and are pin to pin compatible with glymur,
The only change are the external peripherals connected
Thanks,
Pankaj
Reviewed-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
^ permalink raw reply
* RE: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
From: Biju Das @ 2026-06-24 10:04 UTC (permalink / raw)
To: Krzysztof Kozlowski, biju.das.au
Cc: Geert Uytterhoeven, Alex Helms, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, magnus.damm,
Brian Masney, linux-renesas-soc@vger.kernel.org,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Prabhakar Mahadev Lad
In-Reply-To: <610f349f-b88a-440c-bae2-14199d047d12@kernel.org>
Hi Krzysztof Kozlowski,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: 24 June 2026 11:01
> Subject: Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
>
> On 24/06/2026 11:59, Biju Das wrote:
> > Hi Krzysztof Kozlowski,
> >
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <krzk@kernel.org>
> >> Sent: 24 June 2026 10:52
> >> Subject: Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update
> >> maintainer
> >>
> >> On 24/06/2026 11:46, Biju Das wrote:
> >>> Hi Krzysztof Kozlowski,
> >>>
> >>>> -----Original Message-----
> >>>> From: Krzysztof Kozlowski <krzk@kernel.org>
> >>>> Sent: 24 June 2026 10:42
> >>>> Subject: Re: [PATCH] dt-bindings: clock: renesas,versaclock7:
> >>>> Update maintainer
> >>>>
> >>>> On Tue, Jun 23, 2026 at 05:20:37PM +0100, Biju wrote:
> >>>>> From: Biju Das <biju.das.jz@bp.renesas.com>
> >>>>>
> >>>>> Alex's email is bouncing. Update the maintainers list with my
> >>>>> contact details to take over the schema maintenance.
> >>>>>
> >>>>> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> >>>>> ---
> >>>>> Ref [1]
> >>>>> [1] https://lore.kernel.org/all/ajqWevofEJ3fv856@redhat.com/
> >>>>> ---
> >>>>> .../devicetree/bindings/clock/renesas,versaclock7.yaml | 2 +-
> >>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> Please also update MAINTAINERS file.
> >>>
> >>> It is taken care in [1]
> >>>
> >>> [1]
> >>> https://lore.kernel.org/all/CAMuHMdW0-WsZuuc7PoVNC5DBUoY9dP+ULmGTQ76
> >>> VW
> >>> MO_SjpbuQ@mail.gmail.com/
> >>
> >> Just squash them together.
> >>
> >> When you fix such issue like wrong email, fix it everywhere, not just
> >> one-by-one where the maintainers need to poke you to fix in other
> >> places as well. It is generic rule for bugs as well. The wrong email address is the most obvious
> example here, because it is also extremely easy. Just use git grep.
> >
> > Ok, but both patches were already queued by Geert for 7.3.
> >
> > The MAINTAINERS file patch is 9 months old patch.
>
>
> Hm? How or what exactly is 9 months old? I did `git grep` now and I still see old email entry in next-
> 20260619
Not sure, that patch is posted on Sep 05, 2025
and based on Brian's request Geert queued it.
See below
> On Fri, Sep 05, 2025 at 03:34:38PM +0100, Biju wrote:
> > From: Biju Das <biju.das.jz@bp.renesas.com>
> >
> > Add entries for Renesas versaclock 3 clock driver. While at it
> > add myself as maintainer for versaclock 7 clock driver as Alex's
> > email address bounces.
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH v5 14/14] video: leds: backlight: lm3533: Support getting LED sources from DT
From: Daniel Thompson @ 2026-06-24 10:04 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-15-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:31AM +0300, Svyatoslav Ryhel wrote:
> Add Control Bank to HVLED/LVLED muxing support based on the led-sources
> defined in the device tree.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH 0/4] input: misc: Add an initial driver for haptics inside Qcom PMIH010x PMIC
From: Krzysztof Kozlowski @ 2026-06-24 10:05 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <be2b54a5-ce9d-49a2-80e1-60da874350d9@oss.qualcomm.com>
On 24/06/2026 09:20, Fenglin Wu wrote:
>
> On 6/17/2026 6:42 PM, Krzysztof Kozlowski wrote:
>> On Tue, Jun 16, 2026 at 03:08:23AM -0700, Fenglin Wu wrote:
>>
>> Here - the first sentence - is where you mention merging
>> constraints/strategy/dependencies. Your MFD patch depends on ealier
>> ones.
>>
> Did you mean that these 2 MFD binding changes should be listed as the
> dependency of the MFD patch?
No. Act as maintainer. Clone Linus tree, apply the patch and see if
everything works. My claim is that nothing works and maintainer tree is
broken.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: qcom: glymur: Add label properties to CoreSight devices
From: Jie Gan @ 2026-06-24 10:09 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
Add label properties to TPDM and CTI nodes in the hamoa device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 20b49af7298e..27cc30de940e 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -5770,6 +5770,7 @@ tpdm@1000f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -5834,6 +5835,7 @@ tpdm@1102c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_gcc";
qcom,dsb-msrs-num = <32>;
@@ -5852,6 +5854,7 @@ tpdm@11180000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -5871,6 +5874,7 @@ tpdm@11185000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_dpm_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -5890,6 +5894,7 @@ tpdm@11186000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_dpm_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6010,6 +6015,7 @@ cti@11193000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_cdsp";
};
cti_wpss: cti@111ab000 {
@@ -6018,6 +6024,7 @@ cti_wpss: cti@111ab000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_wpss";
};
tpdm@111d0000 {
@@ -6026,6 +6033,7 @@ tpdm@111d0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qm";
qcom,dsb-msrs-num = <32>;
@@ -6201,6 +6209,7 @@ tpdm@11207000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_mm_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6219,6 +6228,7 @@ tpdm@1120b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_east_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6237,6 +6247,7 @@ tpdm@11213000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_west_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6255,6 +6266,7 @@ tpdm@11219000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_center_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6273,6 +6285,7 @@ tpdm@1121a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc";
qcom,cmb-msrs-num = <32>;
@@ -6291,6 +6304,7 @@ tpdm@1121b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qrng";
qcom,cmb-msrs-num = <32>;
@@ -6309,6 +6323,7 @@ tpdm@1121c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pmu";
qcom,dsb-msrs-num = <32>;
@@ -6327,6 +6342,7 @@ tpdm@1121d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_cx";
qcom,cmb-msrs-num = <32>;
@@ -6345,6 +6361,7 @@ tpdm@1121e000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_mxc";
qcom,cmb-msrs-num = <32>;
@@ -6363,6 +6380,7 @@ tpdm@1121f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_mxa";
qcom,cmb-msrs-num = <32>;
@@ -6381,6 +6399,7 @@ tpdm@11220000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_center_dsb_1";
qcom,dsb-msrs-num = <32>;
@@ -6399,6 +6418,7 @@ tpdm@11224000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_south2_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6417,6 +6437,7 @@ tpdm@11228000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_south_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6435,6 +6456,7 @@ tpdm@11470000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pcie_rscc";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -6478,6 +6500,7 @@ tpdm@11c03000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_4";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6656,6 +6679,7 @@ tpdm@11c09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6675,6 +6699,7 @@ tpdm@11c0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6694,6 +6719,7 @@ tpdm@11c0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6713,6 +6739,7 @@ tpdm@11c0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6732,6 +6759,7 @@ tpdm@11c0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
---
base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
change-id: 20260624-add-label-node-for-glymur-1ba59f479870
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH net] net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
From: Jie Luo @ 2026-06-24 10:16 UTC (permalink / raw)
To: Andrew Lunn
Cc: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Brian Masney, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lei Wei, Suruchi Agarwal, Pavithra R,
linux-kernel, linux-arm-msm, linux-clk, devicetree, netdev,
Kiran Kumar C.S.K, quic_linchen
In-Reply-To: <7095f7ba-bacb-4d03-89cf-ed43882d8213@lunn.ch>
On 6/23/2026 7:31 PM, Andrew Lunn wrote:
> On Tue, Jun 23, 2026 at 05:42:34PM +0800, Jie Luo wrote:
>>
>>
>> On 6/23/2026 4:10 PM, Andrew Lunn wrote:
>>>> Driver is not supported - in terms of how netdev understands supported
>>>> commitment - if maintainer does not care to receive the patches for its
>>>> code, so demote it to "maintained" to reflect true status.
>>>
>>> Maybe "Orphan" would be better, if the listed Maintainer is not doing
>>> any Maintainer work?
>>>
>>> Andrew
>>
>> Hello Andrew, Krzysztof,
>> I will continue to maintain the listed drivers, so their status can
>> remain Supported.
>
> Please understand that being a Maintainer requires that you respond to
> patches and questions about this driver, give Reviewed-by:, ask for
> patches to be changed etc. If you don't respond, ideally with 2 to 3
> days, the driver will be set to Orphaned.
>
> If you want to maintain the Supported status, we can help you set up
> the needed CI system, and get it registered so it reports the results.
>
> Andrew
Thank you Andrew, Krzysztof, for the clarification on what "Supported"
status entails and for the offer to help with CI setup. I would very
much appreciate the community's help in getting the CI system set up
and registered for this driver. In the mean time we will also look at
resources internally within Qualcomm, to understand how to support
testing using kernelCI/netdevCI for IPQ SoC. This will help us test
the driver continuously as well.
I fully understand and accept the maintainer responsibilities for this
driver, and commit to the below:
- Responding to patches and questions in a timely manner.
- Providing review comments and requesting changes where appropriate,
and providing Reviewed-by tags when needed.
I would also like to take a moment to provide an update on our current
efforts for IPQ SoC, if it can be of help. We have already re-started
our efforts for the drivers and are currently actively working to extend
the IPQ drivers to support more functionality and for newer SoC support
for same family. We plan to post these updates to the current drivers
once the review window reopens.
We feel maintaining the "Supported" status is appropriate and reflects
our genuine long-term commitment to IPQ SoC networking drivers in Linux
kernel. We request you to retain the current status for this driver if
acceptable.
Regarding the email ID change, we had attempted to rectify the
MAINTAINERS file a few months ago based on recommendation given
internally (please see below thread), however agree that such an update
in documentation is also required.
https://lore.kernel.org/all/20250903-maintainer_update-v1-1-2183fd2a3c44@oss.qualcomm.com/
^ permalink raw reply
* Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices
From: Krzysztof Kozlowski @ 2026-06-24 10:16 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Vishnu Reddy, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, Vikash Garodia, Robin Murphy, joro, will,
m.szyprowski, iommu, linux-kernel, dikshita.agarwal
In-Reply-To: <20260618151745.GD231643@ziepe.ca>
On 18/06/2026 17:17, Jason Gunthorpe wrote:
> On Thu, Jun 18, 2026 at 01:57:40PM +0200, Krzysztof Kozlowski wrote:
>
>> Same with interrupt-map.
>
>> There are PCIe controller nodes which have interrupt-map and no
>> interrupts property ever uses them.
>
> PCIe is quite a different situation because we expect Linux to
> dynamically create the child nodes based on PCIe discovery, and the
> various maps are all searched based on the PCI BDF based on HW
> properties of real discovered child devices.
>
> Here they created "vpu_bus" and create a bunch of devices for some
> reason, but they are all hard coded in the driver. It is not a dynamic
> discovery, and it is not creating "real" child devices.
Yes, true.
>
>> Because DT person - me - told that creating child device nodes just to
>> configure iommus is abuse of DT. There are no child devices in terms of
>> hardware or firmware. The iommu ranges here are no real hardware.
>
> That doesn't seem to be what Vishnu is saying. Review the earlier two
> emails explaining what the HW issue is here:
>
> https://lore.kernel.org/all/bb59f07e-ca7e-f012-6a4b-0a148350b69c@oss.qualcomm.com/
> https://lore.kernel.org/all/cb37e7cc-4fb0-4c24-8f89-f6f9eb08a107@oss.qualcomm.com/
>
> The VPU HW diagram with different IOVA requirements for different
> stream IDs seems to be an entirely HW based thing: "each context bank
> enforces a different IOVA range"
>
> The original patches just created a 0 based IOVA space per stream and
> justified that by increasing the IOVA address space (make sense). The
> email above now says some of the streams only function with a limited
> range of IOVA because the HW uses the IOVA itself to select the
> streams (insane!)
>
> IOW this entire device is completely mis-designed if it is going to
> easially support the Linux DMA API :( That's all HW mess, which is
> motivating hacks to try to make the Linux DMA API do something usable
> by this device.
>
> Anyhow..
>
> In Linux if you use DT iommus the SW sets things up so every stream
> shares the same translation. If your driver/device doesn't like that
> there is no SW way to opt out of sharing. I think that is the first
> core issue that VPU was struggling with.
>
> If you have one "device" then I would argue the DT should describe all
> its streams using iommus in the normal way. The introduction of
> iommu-map for VPU is only being done because that is a convenient hack
> to allow Linux to unbundle the streams. It would be much harder to
> unbunble the streams directly from the DT iommus property, but that
> would probably be the cleanest, software agnostic, DT modeling.
>
> So, if we are going to do a hack in DT to accomodate Linux, I argue to
> choose explicit child devices so VPU does not need to create a special
> bus, call of_dma_configue, or hack in new DMA API things that only it
> will ever use. Then the explicit children can properly describe how
> the HW decodes IOVA into each streams in the DT (which sounds very
> much like a HW property to me) so that Linux produces IOVA that the HW
> mangling properly routes to the expected stream.
>
> Then the VPU driver just has to assemble itself from many struct
> devices, which I admit is also a troublesome task.
>
>> However, said all this, since I pushed folks to come with the iommu-map
>> approach, I will revoke my disagreement to child device nodes in DT, if
>> you really believe that is the approach. IOW, I will agree to device
>> nodes in DT representing fake hardware-children, just for the sake of
>> Linux driver model limitations.
>
> I would wait for Robin, he knows this better, but I belive this was
> broadly his point in the original email..
Thanks Jason for context and detailed arguments. Robin did not chime in
yet, but from what I understood the DT-child-node approach will be the
way we should go here.
I accept above point of view and I am fine with this, thus Vishnu and
Vikash - please go ahead with DT-child-node solution we had some time ago.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: socfpga: agilex7-gen2: Add initial device tree
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-06-24 10:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: dinguyen@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260624-infallible-diligent-bulldog-bcbab2@quoll>
On 24/6/2026 3:57 pm, Krzysztof Kozlowski wrote:
> On Tue, Jun 23, 2026 at 04:17:16AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
>> +
>> + psci {
>> + compatible = "arm,psci-0.2";
>> + method = "smc";
>> + };
>> +
>> + intc: interrupt-controller@7000000 {
>
> MMIO goes to MMIO, please read writing bindings and submitting patches docs in DT dir.
>
> I think this also fails tests (W=1). If that is true, then review should
> finish here, because instead of using machine to find issues you use
> community.
>
>> + compatible = "arm,gic-v3";
>> + reg = <0x0 0x7000000 0x0 0x10000>,
>> + <0x0 0x7080000 0x0 0x100000>;
>> + ranges;
>> + #interrupt-cells = <3>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + interrupt-controller;
>> + #redistributor-regions = <1>;
>> + redistributor-stride = <0x0 0x40000>;
>> +
>> + its: msi-controller@7040000 {
>> + compatible = "arm,gic-v3-its";
>> + reg = <0x0 0x7040000 0x0 0x20000>;
>> + msi-controller;
>> + #msi-cells = <1>;
>> + };
>> + };
>> +
>> + soc: soc@0 {
>> + compatible = "simple-bus";
>> + ranges = <0 0 0 0xffffffff>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + device_type = "soc";
>> + interrupt-parent = <&intc>;
>> +
>> + smmu: iommu@c100000 {
>> + compatible = "arm,smmu-v3";
>> + reg = <0x0c100000 0x30000>;
>> + interrupts = <GIC_SPI 134 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 129 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 132 IRQ_TYPE_EDGE_RISING>;
>> + interrupt-names = "eventq", "gerror", "priq";
>> + dma-coherent;
>> + #iommu-cells = <1>;
>> + };
>> +
>> + ocram: sram@0 {
>> + compatible = "mmio-sram";
>> + reg = <0x00000000 0x80000>;
>> + ranges = <0 0 0x80000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>
> SoC without any interface, serial or storage or network, is close to
> useless one.
>
> I don't see a point in having it in mainline. Serial is usually ABSOLUTE
> minimum.
>
> Best regards,
> Krzysztof
>
Hi Krzysztof,
Thank you for the review and fast response!
I ran both dt_binding_check and dtbs_check (with CHECK_DTBS=y) locally —
both passed without errors. Could you clarify which specific test you
believe is failing?
Regarding "MMIO goes to MMIO" — are you referring to the GIC
(interrupt-controller@7000000) being placed at the root level instead of
under the soc bus node?
Regarding the serial console — the platform clock driver is not yet
upstream, so the UART depends on clkmgr. Would adding the UART with
clock-frequency be acceptable as an interim solution?
BR,
Nazim
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: glymur: Add label properties to CoreSight devices
From: sashiko-bot @ 2026-06-24 10:18 UTC (permalink / raw)
To: Jie Gan; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260624-add-label-node-for-glymur-v1-1-87576107b999@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message incorrectly references the 'hamoa' device tree instead of 'glymur'.
--
commit 71aa487b99d4969110406291654e33f858011262
Author: Jie Gan <jie.gan@oss.qualcomm.com>
arm64: dts: qcom: glymur: Add label properties to CoreSight devices
This commit adds label properties to TPDM and CTI nodes to provide
human-readable identifiers for each CoreSight device.
> Add label properties to TPDM and CTI nodes in the hamoa device tree to
> provide human-readable identifiers for each CoreSight device. These
> labels allow userspace tools and the CoreSight framework to identify
> devices by name rather than by base address.
[Severity: Medium]
This isn't a bug, but the commit message explicitly states it is modifying
the "hamoa" device tree, while the patch subject and the actual modified
file (arch/arm64/boot/dts/qcom/glymur.dtsi) target "glymur". Could this
reference to "hamoa" be a copy-paste error from a similar patch?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624-add-label-node-for-glymur-v1-1-87576107b999@oss.qualcomm.com?part=1
^ permalink raw reply
* [PATCH 0/2] arm64: Add Axiado AX3005 SoC and EVK support
From: Swark Yang @ 2026-06-24 10:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah
Cc: devicetree, linux-arm-kernel, linux-kernel, Swark Yang
This series adds initial device tree support for the Axiado AX3005 SoC
and its evaluation board (EVK).
The AX3005 uses Cadence-derived UART/I2C/I3C/GPIO and Synopsys
DesignWare SPI IP blocks. These are already described by
existing bindings, so the device tree reuses the "axiado,ax3000-*",
"cdns,*" and "snps,*" compatible strings; only a new SoC/board
level compatible is added.
Patch 1 adds the AX3005 board/SoC compatible strings to the Axiado
platform binding.
Patch 2 adds the AX3005 SoC dtsi, the EVK board dts, and the Makefile
entry. The EVK enables the CPUs, timer, GPIO, UART, I2C, I3C, SPI and
USB controllers.
Validated with:
- make CHECK_DTBS=y axiado/ax3005-evk.dtb
- make dt_binding_check DT_SCHEMA_FILES=axiado.yaml
- boot-tested on the AX3005 EVK (to init CLI via ramfs)
Signed-off-by: Swark Yang <syang@axiado.com>
---
Swark Yang (2):
dt-bindings: arm: axiado: add AX3005 EVK
arm64: dts: axiado: Add initial support for AX3005 SoC and eval board
Documentation/devicetree/bindings/arm/axiado.yaml | 6 +
arch/arm64/boot/dts/axiado/Makefile | 1 +
arch/arm64/boot/dts/axiado/ax3005-evk.dts | 327 +++++++++
arch/arm64/boot/dts/axiado/ax3005.dtsi | 843 ++++++++++++++++++++++
4 files changed, 1177 insertions(+)
---
base-commit: 2b414a95b8f7307d42173ba9e580d6d3e2bcbfce
change-id: 20260617-upstream-axiado-ax3005-upstream-bb09780a2fdf
Best regards,
--
Swark Yang <syang@axiado.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox