* Re: [PATCH] dt-bindings: mailbox: qcom-ipcc: Document Nord IPCC
From: Manivannan Sadhasivam @ 2026-04-20 8:16 UTC (permalink / raw)
To: Shawn Guo
Cc: Jassi Brar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260420040141.1247612-1-shengchao.guo@oss.qualcomm.com>
On Mon, Apr 20, 2026 at 12:01:41PM +0800, Shawn Guo wrote:
> From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>
> Document Inter-Processor Communication Controller on Qualcomm Nord SoC
> with a fallback on qcom,ipcc.
>
> Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> index f5c584cf2146..0a86230a2b18 100644
> --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> @@ -28,6 +28,7 @@ properties:
> - qcom,glymur-ipcc
> - qcom,kaanapali-ipcc
> - qcom,milos-ipcc
> + - qcom,nord-ipcc
What is the difference between this and the existing 'sa8775p' compatible? Are
they both representing the same SoC series?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] dt-bindings: mailbox: qcom-ipcc: Document Nord IPCC
From: Konrad Dybcio @ 2026-04-20 8:18 UTC (permalink / raw)
To: Manivannan Sadhasivam, Shawn Guo
Cc: Jassi Brar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <rqjdh72kncyjfkpfo5ymd3uvyy5bzrqzpomdbggobk2spcfpwg@irlwojm3eme7>
On 4/20/26 10:16 AM, Manivannan Sadhasivam wrote:
> On Mon, Apr 20, 2026 at 12:01:41PM +0800, Shawn Guo wrote:
>> From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>>
>> Document Inter-Processor Communication Controller on Qualcomm Nord SoC
>> with a fallback on qcom,ipcc.
>>
>> Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
>> ---
>> Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
>> index f5c584cf2146..0a86230a2b18 100644
>> --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
>> +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
>> @@ -28,6 +28,7 @@ properties:
>> - qcom,glymur-ipcc
>> - qcom,kaanapali-ipcc
>> - qcom,milos-ipcc
>> + - qcom,nord-ipcc
>
> What is the difference between this and the existing 'sa8775p' compatible? Are
> they both representing the same SoC series?
Nord is a gen newer
Konrad
^ permalink raw reply
* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Andy Shevchenko @ 2026-04-20 8:21 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Svyatoslav Ryhel, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap,
linux-iio, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419172216.3cf10e51@jic23-huawei>
On Sun, Apr 19, 2026 at 05:22:16PM +0100, Jonathan Cameron wrote:
> On Sun, 19 Apr 2026 16:41:24 +0300
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > нд, 19 квіт. 2026 р. о 16:33 Jonathan Cameron <jic23@kernel.org> пише:
> > > On Sun, 19 Apr 2026 11:31:24 +0300
> > > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
...
> > > There is the obvious point of ABI compatibility raised as well, but given
> > > we don't seem to be getting much push back on that maybe that's not a significant
> > > concern.
> >
> > I did not found any ABI in the Documentation/ABI regarding this sensor
> > using grep,
The code is what is in use, it has an ABI. The question if it's in use or not.
> > maybe you are more familiar?
> Doesn't matter if it's documented explicitly (many older drivers are not).
> The question is whether anyone has supported parts and userspace code that
> makes use of the sysfs files this driver provides.
>
> Their userspace will be broken by dropping it. The lack of upstream users
> makes this less critical but it can be argued it's still a possible regression.
Usual recommendation is to google, and check Debian code search engine.
I randomly chose a couple of sysfs nodes and only kernel code refers to them.
So, at least there is a good sign that it likely not in use. But one has
to perform more checks (all attributes, more sources of information) and
summarise that in the commit message.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: Document Nord QMP UFS PHY
From: Krzysztof Kozlowski @ 2026-04-20 8:21 UTC (permalink / raw)
To: Shawn Guo, Vinod Koul
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Dmitry Baryshkov, Bartosz Golaszewski, Deepti Jaggi, linux-phy,
devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20260420074942.1250414-1-shengchao.guo@oss.qualcomm.com>
On 20/04/2026 09:49, Shawn Guo wrote:
> Add compatible for QMP UFS PHY on Qualcomm Nord SoC with a fallback
> on qcom,sm8650-qmp-ufs-phy.
>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
> index 9616c736b6d4..cc3457d6aa3b 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
> @@ -36,6 +36,10 @@ properties:
> - enum:
> - qcom,kaanapali-qmp-ufs-phy
> - const: qcom,sm8750-qmp-ufs-phy
> + - items:
> + - enum:
> + - qcom,nord-qmp-ufs-phy
> + - const: qcom,sm8650-qmp-ufs-phy
You do not need new entry, especially placed in incorrect order. Sort it
and then you will see that you just duplicated it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] mailbox: qcom-cpucp: Add support for Nord CPUCP mailbox controller
From: Konrad Dybcio @ 2026-04-20 8:22 UTC (permalink / raw)
To: Shawn Guo, Jassi Brar
Cc: Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260420034932.1247344-3-shengchao.guo@oss.qualcomm.com>
On 4/20/26 5:49 AM, Shawn Guo wrote:
> From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>
> The Nord SoC CPUCP mailbox supports 16 IPC channels, compared to 3 on
> x1e80100. The existing driver hardcodes the channel count via a
> compile-time constant (APSS_CPUCP_IPC_CHAN_SUPPORTED), making it
> impossible to support hardware with a different number of channels.
>
> Introduce a qcom_cpucp_mbox_data per-hardware configuration struct that
> carries the channel count, and retrieve it via of_device_get_match_data()
> at probe time. Switch the channel array from a fixed-size member to a
> dynamically allocated buffer sized from the hardware data. Update the
> x1e80100 entry to supply its own data struct, and add a new Nord entry
> with num_chans = 16.
>
> Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
[...]
> /**
> * struct qcom_cpucp_mbox - Holder for the mailbox driver
> - * @chans: The mailbox channel
> + * @chans: The mailbox channels (dynamically allocated)
I don't think this line is a valuable change
The rest of the patch looks good
Konrad
^ permalink raw reply
* Re: [PATCH 0/2] Add CPUCP mailbox support for Qualcomm Nord SoC
From: Konrad Dybcio @ 2026-04-20 8:23 UTC (permalink / raw)
To: Shawn Guo, Jassi Brar
Cc: Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260420034932.1247344-1-shengchao.guo@oss.qualcomm.com>
On 4/20/26 5:49 AM, Shawn Guo wrote:
> This series adds CPUCP mailbox controller support for Qualcomm Nord SoC.
>
> The Nord CPUCP mailbox is functionally identical to the existing x1e80100
> implementation, except it exposes 16 IPC channels instead of 3. Patch 1
> adds the Nord compatible string to the DT binding. Patch 2 refactors
> the channel count from a hardcoded compile-time constant into
> a per-hardware configuration struct populated via the device tree
> match data.
What are these channels used for?
Konrad
^ permalink raw reply
* Re: [PATCH] dt-bindings: mailbox: qcom-ipcc: Document Nord IPCC
From: Manivannan Sadhasivam @ 2026-04-20 8:23 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Shawn Guo, Jassi Brar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Dmitry Baryshkov,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, linux-kernel,
devicetree
In-Reply-To: <1b40b1a0-983c-4eca-bdc8-6a64cf76197d@oss.qualcomm.com>
On Mon, Apr 20, 2026 at 10:18:52AM +0200, Konrad Dybcio wrote:
> On 4/20/26 10:16 AM, Manivannan Sadhasivam wrote:
> > On Mon, Apr 20, 2026 at 12:01:41PM +0800, Shawn Guo wrote:
> >> From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> >>
> >> Document Inter-Processor Communication Controller on Qualcomm Nord SoC
> >> with a fallback on qcom,ipcc.
> >>
> >> Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> >> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> >> ---
> >> Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> >> index f5c584cf2146..0a86230a2b18 100644
> >> --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> >> +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> >> @@ -28,6 +28,7 @@ properties:
> >> - qcom,glymur-ipcc
> >> - qcom,kaanapali-ipcc
> >> - qcom,milos-ipcc
> >> + - qcom,nord-ipcc
> >
> > What is the difference between this and the existing 'sa8775p' compatible? Are
> > they both representing the same SoC series?
>
> Nord is a gen newer
>
Okay. This should've been present in the commit message to make it clear.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] dt-bindings: mailbox: qcom-ipcc: Document Nord IPCC
From: Krzysztof Kozlowski @ 2026-04-20 8:24 UTC (permalink / raw)
To: Konrad Dybcio, Manivannan Sadhasivam, Shawn Guo
Cc: Jassi Brar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <1b40b1a0-983c-4eca-bdc8-6a64cf76197d@oss.qualcomm.com>
On 20/04/2026 10:18, Konrad Dybcio wrote:
> On 4/20/26 10:16 AM, Manivannan Sadhasivam wrote:
>> On Mon, Apr 20, 2026 at 12:01:41PM +0800, Shawn Guo wrote:
>>> From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>>>
>>> Document Inter-Processor Communication Controller on Qualcomm Nord SoC
>>> with a fallback on qcom,ipcc.
>>>
>>> Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>>> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
>>> ---
>>> Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
>>> index f5c584cf2146..0a86230a2b18 100644
>>> --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
>>> +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
>>> @@ -28,6 +28,7 @@ properties:
>>> - qcom,glymur-ipcc
>>> - qcom,kaanapali-ipcc
>>> - qcom,milos-ipcc
>>> + - qcom,nord-ipcc
>>
>> What is the difference between this and the existing 'sa8775p' compatible? Are
>> they both representing the same SoC series?
>
> Nord is a gen newer
This should be explained somewhere, e.g. in board/soc bindings or SoC ID
bindings. None of these are posted, so most of the patches being posted
could receive that comment - what is the difference and why commit msg
explains nothing.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH V13 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Sherry Sun @ 2026-04-20 8:24 UTC (permalink / raw)
To: mani@kernel.org, Bjorn Helgaas
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <viggqsxczf5d5hok4qpqhknalwb46xapsgdxbbgbqhruhyn2hn@wtck4yajmuw7>
> On Fri, Apr 17, 2026 at 02:55:33PM -0500, Bjorn Helgaas wrote:
> > On Fri, Apr 17, 2026 at 03:17:16AM +0000, Sherry Sun wrote:
> > > > On Thu, Apr 16, 2026 at 07:14:12PM +0800, Sherry Sun wrote:
> > > > > Introduce generic helper functions to parse Root Port device
> > > > > tree nodes and extract common properties like reset GPIOs. This
> > > > > allows multiple PCI host controller drivers to share the same
> > > > > parsing logic.
> > > > >
> > > > > Define struct pci_host_port to hold common Root Port properties
> > > > > (currently only reset GPIO descriptor) and add
> > > > > pci_host_common_parse_ports() to parse Root Port nodes from
> > > > > device tree.
> > > >
> > > > Are the Root Port and the RC the only possible places for 'reset'
> > > > GPIO descriptions in DT? I think PERST# routing is outside the
> > > > PCIe spec, so it seems like a system could provide a PERST# GPIO
> > > > routed to any Switch Upstream Port or Endpoint (I assume a PERST#
> > > > connected to a switch would apply to both the upstream port and
> > > > the downstream ports).
> > >
> > > Thanks for the feedback. You're right that PERST# routing could
> > > theoretically be connected to any device in the hierarchy. However,
> > > for this patch series, I've focused on the most common use case in
> > > practice: use Root Port level PERST# instead of the legacy Root
> > > Complex level PERST#.
> > >
> > > Root Port level PERST# - This is the primary target, where each Root
> > > Port has individual control over devices connected to it. RC level
> > > PERST# - Legacy binding support, where a single GPIO controls all
> > > ports.
> > >
> > > We can extend this framework later if real hardware emerges that
> > > needs Switch or EP-level PERST# control. I can add a comment
> > > documenting this limitation if needed.
> > >
> > > BTW, Mani and Rob had some great discussions in dt-schema about
> > > PERST# and WAKE# sideband signals settings.
> >
> > > You can check here:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > thub.com%2Fdevicetree-org%2Fdt-
> schema%2Fissues%2F168&data=05%7C02%7C
> > >
> sherry.sun%40nxp.com%7C232644f8bbe64279f77908de9ea20b09%7C686ea1
> d3bc
> > >
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C639122615977862858%7CUnknown
> %7CTWFp
> > >
> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> MiIs
> > >
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=r7szCLCsGFN2
> 1ULZ
> > > ibH7Ga%2FH0e6VyIdqznKCJ6yIGM4%3D&reserved=0
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > thub.com%2Fdevicetree-org%2Fdt-
> schema%2Fpull%2F126&data=05%7C02%7Csh
> > >
> erry.sun%40nxp.com%7C232644f8bbe64279f77908de9ea20b09%7C686ea1d
> 3bc2b
> > >
> 4c6fa92cd99c5c301635%7C0%7C0%7C639122615977892044%7CUnknown%7
> CTWFpbG
> > >
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> sIk
> > >
> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=o3RIy1SfvTGfkX
> 9rm8
> > > dNH2or5SZ7v5bYF%2Fl1XGaf8aA%3D&reserved=0
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > thub.com%2Fdevicetree-org%2Fdt-
> schema%2Fpull%2F170&data=05%7C02%7Csh
> > >
> erry.sun%40nxp.com%7C232644f8bbe64279f77908de9ea20b09%7C686ea1d
> 3bc2b
> > >
> 4c6fa92cd99c5c301635%7C0%7C0%7C639122615977910169%7CUnknown%7
> CTWFpbG
> > >
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> sIk
> > >
> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d8SBGcqKcjYe1i
> iqs9
> > > %2F%2Bg1o%2FbECHYtnEULg7hTXyKmY%3D&reserved=0
> >
> > The upshot of all those conversations is that WAKE# and PERST# can be
> > routed to arbitrary devices independent of the PCI topology.
> >
> > I think extending host-generic to look for 'reset' in Root Port nodes
> > is the right thing. My concern is more about where we store it. This
> > patch saves it in a new "pci_host_port" struct, but someday we'll want
> > a place to save the PERST# GPIOs for several slots behind a switch.
> > Then we'll have two different ways to save the same information.
> >
>
> Even if there are PERST# GPIOs from the host, connected to downstream
> ports of a PCIe switch, they could be stored in the Root Port's (pci_host_port)
> struct as a list of PERST#. This is what pcie-qcom driver does.
>
> It is too clumsy to handle PERST# individually for each device. We tried it
> before with pwrctrl, but it always ended up biting us on who gets to control
> the PERST#. We can't let pwrctrl handle PERST# for a switch port and host
> controller driver handle it for RP. And we cannot let pwrctrl handle PERST# for
> all ports, because, host controller drivers also need to control them for RC
> initialization.
>
> That's why it was decided to handle PERST# for all ports in the host controller
> drivers. So following that pattern, this helper could also be extended to parse
> the PERST# from all ports defined in DT and store them in the same Root Port
> struct.
>
> It should be trivial to implement this logic in the current helper. @Sherry:
> Could you please implement this logic?
Hi Mani, do you mean the similar logic in this patch?
https://lore.kernel.org/all/20251216-pci-pwrctrl-rework-v2-1-745a563b9be6@oss.qualcomm.com/
If yes, of cause I can do this for current helper functions in pci-host-common.c.
Best Regards
Sherry
^ permalink raw reply
* Re: [PATCH] dt-bindings: crypto: qcom,inline-crypto-engine: Document Nord ICE
From: Krzysztof Kozlowski @ 2026-04-20 8:27 UTC (permalink / raw)
To: Shawn Guo, Herbert Xu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-crypto, devicetree, linux-arm-msm,
linux-kernel
In-Reply-To: <20260420073301.1250197-1-shengchao.guo@oss.qualcomm.com>
On 20/04/2026 09:33, Shawn Guo wrote:
> Add compatible for Inline Crypto Engine (ICE) on Qualcomm Nord SoC
> witha fallback on qcom,inline-crypto-engine.
Don't explain what the diff is doing. Explain why. Why do you use fallback?
What is Nord? It's nowhere explained. First posting was 1.5 months ago
and it did not provide any explanation. I don't see any information
being posted in the series sent now.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: sc8280xp: add several missing pdc map entries
From: Konrad Dybcio @ 2026-04-20 8:32 UTC (permalink / raw)
To: Pengyu Luo, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260419173251.1180026-1-mitltlatltl@gmail.com>
On 4/19/26 7:32 PM, Pengyu Luo wrote:
> pdc 215, 256, 257 are missing, but we can find tlmm pin 103, 84, 90
> are mapped to them respectively, so add the map entries from pdc to
> gic. These entries are reversed from .data section of qcgpio.sys
>
> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
The below change on top will fully align it with the data in the docs
(no functional change)
(yes that's a removal of one irq mapping)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index 761f229e8f47..23e80c765384 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -5310,7 +5310,7 @@ pdc: interrupt-controller@b220000 {
<66 438 3>,
<69 86 1>,
<70 520 54>,
- <124 609 28>,
+ <124 609 27>,
<159 638 1>,
<160 720 8>,
<168 801 1>,
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: dts: qcom: sc8280xp: gaokun3: correct EC interrupt pin
From: Konrad Dybcio @ 2026-04-20 8:33 UTC (permalink / raw)
To: Pengyu Luo, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260419173251.1180026-2-mitltlatltl@gmail.com>
On 4/19/26 7:32 PM, Pengyu Luo wrote:
> Unlike other sc8280xp platforms, on this platform, in dsdt, gpio 0x2c0
> is not mapped to gpio107, it is gpio103, so fix it. I found this until
> I did a trigger track, irq is regularly triggerd every several
> millisecs. In the past, since here gpio107 was low forever, ec irq
> would keep to be triggered and polling the event every several
> millisecs.
>
> About how to get the map, please check openbsd driver for it
> https://github.com/openbsd/src/blob/master/sys/dev/acpi/qcgpio.c
>
> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Arnd Bergmann @ 2026-04-20 8:33 UTC (permalink / raw)
To: Andy Shevchenko, Jonathan Cameron
Cc: Svyatoslav Ryhel, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <aeXh7j410AxESy4U@ashevche-desk.local>
On Mon, Apr 20, 2026, at 10:21, Andy Shevchenko wrote:
> On Sun, Apr 19, 2026 at 05:22:16PM +0100, Jonathan Cameron wrote:
>> On Sun, 19 Apr 2026 16:41:24 +0300 Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>> > нд, 19 квіт. 2026 р. о 16:33 Jonathan Cameron <jic23@kernel.org> пише:
>>
>> Their userspace will be broken by dropping it. The lack of upstream users
>> makes this less critical but it can be argued it's still a possible regression.
>
> Usual recommendation is to google, and check Debian code search engine.
> I randomly chose a couple of sysfs nodes and only kernel code refers to them.
> So, at least there is a good sign that it likely not in use. But one has
> to perform more checks (all attributes, more sources of information) and
> summarise that in the commit message.
I think in this case it's sufficient to point out that there is no
devicetree support in the driver, and no pre-DT board file ever
declared a platform_device with apds990x_platform_data in mainline
kernels. The ambient light sensor drivers in drivers/misc/ were
all added in before the change from boardfile to DT, and from custom
ABI to drivers/iio.
Arnd
^ permalink raw reply
* Re: [PATCH] dt-bindings: qcom: geni-se-qup: Add compatible for Nord SoC
From: Rob Herring (Arm) @ 2026-04-20 8:33 UTC (permalink / raw)
To: Shawn Guo
Cc: Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, linux-serial,
devicetree, linux-arm-msm, Deepti Jaggi, linux-kernel,
Praveen Talari, Bjorn Andersson, Dmitry Baryshkov,
Bartosz Golaszewski
In-Reply-To: <20260420064401.1248833-1-shengchao.guo@oss.qualcomm.com>
On Mon, 20 Apr 2026 14:44:01 +0800, Shawn Guo wrote:
> From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>
> Add compatibles for GENI Serial Engine QUP Wrapper Controller on Nord SoC
> with fallback on SA8255P compatibles.
>
> Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> .../soc/qcom/qcom,sa8255p-geni-se-qup.yaml | 20 +++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml:77:13: [warning] wrong indentation: expected 14 but found 12 (indentation)
./Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml:80:13: [warning] wrong indentation: expected 14 but found 12 (indentation)
./Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml:83:13: [warning] wrong indentation: expected 14 but found 12 (indentation)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260420064401.1248833-1-shengchao.guo@oss.qualcomm.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH] dt-bindings: crypto: qcom,inline-crypto-engine: Document Nord ICE
From: Shawn Guo @ 2026-04-20 8:39 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov,
Bartosz Golaszewski, Deepti Jaggi, linux-crypto, devicetree,
linux-arm-msm, linux-kernel
In-Reply-To: <dd5ee12e-1aac-494f-a8f8-74e236ecb47c@kernel.org>
On Mon, Apr 20, 2026 at 10:27:56AM +0200, Krzysztof Kozlowski wrote:
> On 20/04/2026 09:33, Shawn Guo wrote:
> > Add compatible for Inline Crypto Engine (ICE) on Qualcomm Nord SoC
> > witha fallback on qcom,inline-crypto-engine.
>
> Don't explain what the diff is doing. Explain why. Why do you use fallback?
>
> What is Nord? It's nowhere explained. First posting was 1.5 months ago
> and it did not provide any explanation. I don't see any information
> being posted in the series sent now.
I'm still checking internally to see how we can get the best socinfo
patch describing Nord which is a SoC family covering both SA8997P and
IQ10 variant. Hopefully I will get it soon.
Shawn
^ permalink raw reply
* [PATCH] dts: riscv: spacemit: k3: only keep spacemit,k1-i2c
From: Sandie Cao @ 2026-04-20 8:39 UTC (permalink / raw)
To: Yixun Lan, Troy Mitchell
Cc: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, spacemit, linux-riscv,
devicetree, linux-kernel, Sandie Cao, kernel test robot
Fix dtcheck issue: compatible:0: 'spacemit,k1-i2c' was expected
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/r/202604140259.eKDaxKua-lkp@intel.com/
Signed-off-by: Sandie Cao <sandie.cao@deepcomputing.io>
---
arch/riscv/boot/dts/spacemit/k3.dtsi | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
index 815debd16409..9a3d2e8cdfe8 100644
--- a/arch/riscv/boot/dts/spacemit/k3.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
@@ -556,7 +556,7 @@ gmac2_axi_setup: stmmac-axi-config {
};
i2c0: i2c@d4010800 {
- compatible = "spacemit,k3-i2c", "spacemit,k1-i2c";
+ compatible = "spacemit,k1-i2c";
reg = <0x0 0xd4010800 0x0 0x38>;
#address-cells = <1>;
#size-cells = <0>;
@@ -570,7 +570,7 @@ i2c0: i2c@d4010800 {
};
i2c1: i2c@d4011000 {
- compatible = "spacemit,k3-i2c", "spacemit,k1-i2c";
+ compatible = "spacemit,k1-i2c";
reg = <0x0 0xd4011000 0x0 0x38>;
#address-cells = <1>;
#size-cells = <0>;
@@ -584,7 +584,7 @@ i2c1: i2c@d4011000 {
};
i2c2: i2c@d4012000 {
- compatible = "spacemit,k3-i2c", "spacemit,k1-i2c";
+ compatible = "spacemit,k1-i2c";
reg = <0x0 0xd4012000 0x0 0x38>;
#address-cells = <1>;
#size-cells = <0>;
@@ -598,7 +598,7 @@ i2c2: i2c@d4012000 {
};
i2c4: i2c@d4012800 {
- compatible = "spacemit,k3-i2c", "spacemit,k1-i2c";
+ compatible = "spacemit,k1-i2c";
reg = <0x0 0xd4012800 0x0 0x38>;
#address-cells = <1>;
#size-cells = <0>;
@@ -612,7 +612,7 @@ i2c4: i2c@d4012800 {
};
i2c5: i2c@d4013800 {
- compatible = "spacemit,k3-i2c", "spacemit,k1-i2c";
+ compatible = "spacemit,k1-i2c";
reg = <0x0 0xd4013800 0x0 0x38>;
#address-cells = <1>;
#size-cells = <0>;
@@ -752,7 +752,7 @@ uart9: serial@d4017800 {
};
i2c6: i2c@d4018800 {
- compatible = "spacemit,k3-i2c", "spacemit,k1-i2c";
+ compatible = "spacemit,k1-i2c";
reg = <0x0 0xd4018800 0x0 0x38>;
#address-cells = <1>;
#size-cells = <0>;
@@ -784,7 +784,7 @@ gpio: gpio@d4019000 {
};
i2c8: i2c@d401d800 {
- compatible = "spacemit,k3-i2c", "spacemit,k1-i2c";
+ compatible = "spacemit,k1-i2c";
reg = <0x0 0xd401d800 0x0 0x38>;
#address-cells = <1>;
#size-cells = <0>;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Andy Shevchenko @ 2026-04-20 8:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jonathan Cameron, Svyatoslav Ryhel, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan, Greg Kroah-Hartman, Randy Dunlap,
linux-iio, devicetree, linux-kernel, linux-doc
In-Reply-To: <68c671b4-6754-49df-9fdb-2b3382033fb3@app.fastmail.com>
On Mon, Apr 20, 2026 at 10:33:22AM +0200, Arnd Bergmann wrote:
> On Mon, Apr 20, 2026, at 10:21, Andy Shevchenko wrote:
> > On Sun, Apr 19, 2026 at 05:22:16PM +0100, Jonathan Cameron wrote:
> >> On Sun, 19 Apr 2026 16:41:24 +0300 Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >> > нд, 19 квіт. 2026 р. о 16:33 Jonathan Cameron <jic23@kernel.org> пише:
>
> >> Their userspace will be broken by dropping it. The lack of upstream users
> >> makes this less critical but it can be argued it's still a possible regression.
> >
> > Usual recommendation is to google, and check Debian code search engine.
> > I randomly chose a couple of sysfs nodes and only kernel code refers to them.
> > So, at least there is a good sign that it likely not in use. But one has
> > to perform more checks (all attributes, more sources of information) and
> > summarise that in the commit message.
>
> I think in this case it's sufficient to point out that there is no
> devicetree support in the driver, and no pre-DT board file ever
> declared a platform_device with apds990x_platform_data in mainline
> kernels. The ambient light sensor drivers in drivers/misc/ were
> all added in before the change from boardfile to DT, and from custom
> ABI to drivers/iio.
Works for me. I am all for removing old and legacy (especially non-FW node
compatible) code.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] dts: riscv: spacemit: k3: only keep spacemit,k1-i2c
From: Krzysztof Kozlowski @ 2026-04-20 8:43 UTC (permalink / raw)
To: Sandie Cao, Yixun Lan, Troy Mitchell
Cc: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, spacemit, linux-riscv,
devicetree, linux-kernel, kernel test robot
In-Reply-To: <20260420083931.1427703-1-sandie.cao@deepcomputing.io>
On 20/04/2026 10:39, Sandie Cao wrote:
> Fix dtcheck issue: compatible:0: 'spacemit,k1-i2c' was expected
Missing space after main commit msg.
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/r/202604140259.eKDaxKua-lkp@intel.com/
>
There is no space between tags.
Anyway, explain WHY K3 device does not use K3 compatible. It is clearly
violating writing-bindings.
Plus, I don't think this report is correct. You just send us something
close to random fix of random warning, without even opening the files
and understanding what is there. spacemit,k3-i2c MUST be used with K1.
Please read the binding.
NAK
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dts: riscv: spacemit: k3: only keep spacemit,k1-i2c
From: Krzysztof Kozlowski @ 2026-04-20 8:44 UTC (permalink / raw)
To: Sandie Cao, Yixun Lan, Troy Mitchell
Cc: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, spacemit, linux-riscv,
devicetree, linux-kernel, kernel test robot
In-Reply-To: <dfa3f1a7-f4c6-4655-94c0-326f88db3896@kernel.org>
On 20/04/2026 10:43, Krzysztof Kozlowski wrote:
> On 20/04/2026 10:39, Sandie Cao wrote:
>> Fix dtcheck issue: compatible:0: 'spacemit,k1-i2c' was expected
>
> Missing space after main commit msg.
>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Closes: https://lore.kernel.org/r/202604140259.eKDaxKua-lkp@intel.com/
>>
Also, the file reported in above warning DOES NOT EXIST (I checked
next-20260414).
Please do not send reported-by bug reports for things which do not exist.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: amlogic: t7: khadas-vim4: Enable Bluetooth
From: Neil Armstrong @ 2026-04-20 8:47 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel
In-Reply-To: <20260416-add-bluetooth-t7-vim4-v2-3-9a57098fd055@aliel.fr>
On 4/16/26 10:54, Ronald Claveau wrote:
> Enable UART C on the Khadas VIM4 board and attach the BCM43438
> compatible Bluetooth controller to it. The node configures the RTS/CTS
> hardware flow control, the associated pinmux, the power supplies (vddao_3v3
> and vddao_1v8), the 32 kHz LPO clock shared with the wifi32k fixed
> clock, and the GPIO lines used for host wakeup, device wakeup and
> shutdown.
>
> Remove clocks and clock-names for UART A, as they are defined in DTSI.
This should be a separate patch.
Neil
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 21 +++++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> index 69d6118ba57e7..8ea7ae609fbd5 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> @@ -250,6 +250,23 @@ &sd_emmc_c {
>
> &uart_a {
> status = "okay";
> - clocks = <&xtal>, <&xtal>, <&xtal>;
> - clock-names = "xtal", "pclk", "baud";
> +};
> +
> +&uart_c {
> + status = "okay";
> + pinctrl-0 = <&uart_c_pins>;
> + pinctrl-names = "default";
> + uart-has-rtscts;
> +
> + bluetooth {
> + compatible = "brcm,bcm43438-bt";
> + shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
> + host-wakeup-gpios = <&gpio GPIOX_18 GPIO_ACTIVE_HIGH>;
> + device-wakeup-gpios = <&gpio GPIOX_19 GPIO_ACTIVE_HIGH>;
> + max-speed = <3000000>;
> + clocks = <&wifi32k>;
> + clock-names = "lpo";
> + vbat-supply = <&vddao_3v3>;
> + vddio-supply = <&vddao_1v8>;
> + };
> };
>
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: amlogic: t7: Add UART controllers nodes
From: Neil Armstrong @ 2026-04-20 8:47 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel
In-Reply-To: <20260416-add-bluetooth-t7-vim4-v2-2-9a57098fd055@aliel.fr>
On 4/16/26 10:54, Ronald Claveau wrote:
> Add device tree nodes for UART B through F (serial@7a000 to
> serial@82000), completing the UART controller description for the T7
> SoC. Each node includes the peripheral clock.
>
> While at it, move the uart_a node to its correct position in the
> bus address order (0x78000) to comply with the DT requirement that
> nodes be sorted by their reg address. Complete the
> uart_a node with its peripheral clock (CLKID_SYS_UART_A) and the
> associated clock-names, matching the vendor default clock assignment,
> consistent with the other UART nodes.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 61 +++++++++++++++++++++++++----
> 1 file changed, 54 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 4a55d9641bc9b..81c26b1e3e7a4 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -577,13 +577,6 @@ gpio_intc: interrupt-controller@4080 {
> <10 11 12 13 14 15 16 17 18 19 20 21>;
> };
>
> - uart_a: serial@78000 {
> - compatible = "amlogic,t7-uart", "amlogic,meson-s4-uart";
> - reg = <0x0 0x78000 0x0 0x18>;
> - interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
> - status = "disabled";
> - };
> -
> gp0: clock-controller@8080 {
> compatible = "amlogic,t7-gp0-pll";
> reg = <0x0 0x8080 0x0 0x20>;
> @@ -713,6 +706,60 @@ pwm_ao_cd: pwm@60000 {
> status = "disabled";
> };
>
> + uart_a: serial@78000 {
> + compatible = "amlogic,t7-uart", "amlogic,meson-s4-uart";
> + reg = <0x0 0x78000 0x0 0x18>;
> + interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&xtal>, <&clkc_periphs CLKID_SYS_UART_A>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> + status = "disabled";
> + };
> +
> + uart_b: serial@7a000 {
> + compatible = "amlogic,t7-uart", "amlogic,meson-s4-uart";
> + reg = <0x0 0x7a000 0x0 0x18>;
> + interrupts = <GIC_SPI 169 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&xtal>, <&clkc_periphs CLKID_SYS_UART_B>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> + status = "disabled";
> + };
> +
> + uart_c: serial@7c000 {
> + compatible = "amlogic,t7-uart", "amlogic,meson-s4-uart";
> + reg = <0x0 0x7c000 0x0 0x18>;
> + interrupts = <GIC_SPI 170 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&xtal>, <&clkc_periphs CLKID_SYS_UART_C>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> + status = "disabled";
> + };
> +
> + uart_d: serial@7e000 {
> + compatible = "amlogic,t7-uart", "amlogic,meson-s4-uart";
> + reg = <0x0 0x7e000 0x0 0x18>;
> + interrupts = <GIC_SPI 171 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&xtal>, <&clkc_periphs CLKID_SYS_UART_D>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> + status = "disabled";
> + };
> +
> + uart_e: serial@80000 {
> + compatible = "amlogic,t7-uart", "amlogic,meson-s4-uart";
> + reg = <0x0 0x80000 0x0 0x18>;
> + interrupts = <GIC_SPI 172 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&xtal>, <&clkc_periphs CLKID_SYS_UART_E>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> + status = "disabled";
> + };
> +
> + uart_f: serial@82000 {
> + compatible = "amlogic,t7-uart", "amlogic,meson-s4-uart";
> + reg = <0x0 0x82000 0x0 0x18>;
> + interrupts = <GIC_SPI 173 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&xtal>, <&clkc_periphs CLKID_SYS_UART_F>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> + status = "disabled";
> + };
> +
> sd_emmc_a: mmc@88000 {
> compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> reg = <0x0 0x88000 0x0 0x800>;
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: amlogic: t7: Add uart_c pinctrl pins group
From: Neil Armstrong @ 2026-04-20 8:47 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel
In-Reply-To: <20260416-add-bluetooth-t7-vim4-v2-1-9a57098fd055@aliel.fr>
On 4/16/26 10:54, Ronald Claveau wrote:
> Add the pin multiplexing configuration for UART C (TX, RX, CTS, RTS)
> in the T7 SoC pinctrl node, required to route the UART C signals
> through the correct pads before enabling the controller.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 7fe72c94ed623..4a55d9641bc9b 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -553,6 +553,18 @@ mux {
> bias-pull-up;
> };
> };
> +
> + uart_c_pins: uart-c {
> + mux {
> + groups = "uart_c_tx",
> + "uart_c_rx",
> + "uart_c_cts",
> + "uart_c_rts";
> + bias-pull-up;
> + output-high;
> + function = "uart_c";
> + };
> + };
> };
>
> gpio_intc: interrupt-controller@4080 {
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v2 2/4] soc: amlogic: clk-measure: Add A1 and T7 support
From: Neil Armstrong @ 2026-04-20 8:49 UTC (permalink / raw)
To: jian.hu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260415-clkmsr_a1_t7-v2-2-02b6314427e6@amlogic.com>
On 4/15/26 10:33, Jian Hu via B4 Relay wrote:
> From: Jian Hu <jian.hu@amlogic.com>
>
> Add support for the A1 and T7 SoC family in amlogic clk measure.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> ---
> drivers/soc/amlogic/meson-clk-measure.c | 272 ++++++++++++++++++++++++++++++++
> 1 file changed, 272 insertions(+)
>
> diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
> index d862e30a244e..8c4f3cc8c8ab 100644
> --- a/drivers/soc/amlogic/meson-clk-measure.c
> +++ b/drivers/soc/amlogic/meson-clk-measure.c
> @@ -787,6 +787,258 @@ static const struct meson_msr_id clk_msr_s4[] = {
>
> };
>
> +static const struct meson_msr_id clk_msr_a1[] = {
> + CLK_MSR_ID(0, "tdmout_b_sclk"),
> + CLK_MSR_ID(1, "tdmout_a_sclk"),
> + CLK_MSR_ID(2, "tdmin_lb_sclk"),
> + CLK_MSR_ID(3, "tdmin_b_sclk"),
> + CLK_MSR_ID(4, "tdmin_a_sclk"),
> + CLK_MSR_ID(5, "vad"),
> + CLK_MSR_ID(6, "resamplea"),
> + CLK_MSR_ID(7, "pdm_sysclk"),
> + CLK_MSR_ID(8, "pdm_dclk"),
> + CLK_MSR_ID(9, "locker_out"),
> + CLK_MSR_ID(10, "locker_in"),
> + CLK_MSR_ID(11, "spdifin"),
> + CLK_MSR_ID(12, "tdmin_vad"),
> + CLK_MSR_ID(13, "au_adc"),
> + CLK_MSR_ID(14, "au_dac"),
> + CLK_MSR_ID(16, "spicc_a"),
> + CLK_MSR_ID(17, "spifc"),
> + CLK_MSR_ID(18, "sd_emmc_a"),
> + CLK_MSR_ID(19, "dmcx4"),
> + CLK_MSR_ID(20, "dmc"),
> + CLK_MSR_ID(21, "psram"),
> + CLK_MSR_ID(22, "cecb"),
> + CLK_MSR_ID(23, "ceca"),
> + CLK_MSR_ID(24, "ts"),
> + CLK_MSR_ID(25, "pwm_f"),
> + CLK_MSR_ID(26, "pwm_e"),
> + CLK_MSR_ID(27, "pwm_d"),
> + CLK_MSR_ID(28, "pwm_c"),
> + CLK_MSR_ID(29, "pwm_b"),
> + CLK_MSR_ID(30, "pwm_a"),
> + CLK_MSR_ID(31, "saradc"),
> + CLK_MSR_ID(32, "usb_bus"),
> + CLK_MSR_ID(33, "dsp_b"),
> + CLK_MSR_ID(34, "dsp_a"),
> + CLK_MSR_ID(35, "axi"),
> + CLK_MSR_ID(36, "sys"),
> + CLK_MSR_ID(40, "rng_ring_osc0"),
> + CLK_MSR_ID(41, "rng_ring_osc1"),
> + CLK_MSR_ID(42, "rng_ring_osc2"),
> + CLK_MSR_ID(43, "rng_ring_osc3"),
> + CLK_MSR_ID(44, "dds_out"),
> + CLK_MSR_ID(45, "cpu_clk_div16"),
> + CLK_MSR_ID(46, "gpio_msr"),
> + CLK_MSR_ID(50, "osc_ring_cpu0"),
> + CLK_MSR_ID(51, "osc_ring_cpu1"),
> + CLK_MSR_ID(54, "osc_ring_top0"),
> + CLK_MSR_ID(55, "osc_ring_top1"),
> + CLK_MSR_ID(56, "osc_ring_ddr"),
> + CLK_MSR_ID(57, "osc_ring_dmc"),
> + CLK_MSR_ID(58, "osc_ring_dspa"),
> + CLK_MSR_ID(59, "osc_ring_dspb"),
> + CLK_MSR_ID(60, "osc_ring_rama"),
> + CLK_MSR_ID(61, "osc_ring_ramb"),
> +};
> +
> +static const struct meson_msr_id clk_msr_t7[] = {
> + CLK_MSR_ID(0, "sys"),
> + CLK_MSR_ID(1, "axi"),
> + CLK_MSR_ID(2, "rtc"),
> + CLK_MSR_ID(3, "dspa"),
> + CLK_MSR_ID(4, "dspb"),
> + CLK_MSR_ID(5, "mali"),
> + CLK_MSR_ID(6, "sys_cpu_clk_div16"),
> + CLK_MSR_ID(7, "ceca"),
> + CLK_MSR_ID(8, "cecb"),
> + CLK_MSR_ID(10, "fclk_div5"),
> + CLK_MSR_ID(11, "mpll0"),
> + CLK_MSR_ID(12, "mpll1"),
> + CLK_MSR_ID(13, "mpll2"),
> + CLK_MSR_ID(14, "mpll3"),
> + CLK_MSR_ID(15, "mpll_50m"),
> + CLK_MSR_ID(16, "pcie_inp"),
> + CLK_MSR_ID(17, "pcie_inn"),
> + CLK_MSR_ID(18, "mpll_test_out"),
> + CLK_MSR_ID(19, "hifi_pll"),
> + CLK_MSR_ID(20, "gp0_pll"),
> + CLK_MSR_ID(21, "gp1_pll"),
> + CLK_MSR_ID(22, "eth_mppll_50m"),
> + CLK_MSR_ID(23, "sys_pll_div16"),
> + CLK_MSR_ID(24, "ddr_dpll_pt"),
> + CLK_MSR_ID(25, "earcrx_pll"),
> + CLK_MSR_ID(26, "paie1_clk_inp"),
> + CLK_MSR_ID(27, "paie1_clk_inn"),
> + CLK_MSR_ID(28, "amlgdc"),
> + CLK_MSR_ID(29, "gdc"),
> + CLK_MSR_ID(30, "mod_eth_phy_ref"),
> + CLK_MSR_ID(31, "mod_eth_tx"),
> + CLK_MSR_ID(32, "eth_clk125Mhz"),
> + CLK_MSR_ID(33, "eth_clk_rmii"),
> + CLK_MSR_ID(34, "co_clkin_to_mac"),
> + CLK_MSR_ID(35, "mod_eth_rx_clk_rmii"),
> + CLK_MSR_ID(36, "co_rx"),
> + CLK_MSR_ID(37, "co_tx"),
> + CLK_MSR_ID(38, "eth_phy_rxclk"),
> + CLK_MSR_ID(39, "eth_phy_plltxclk"),
> + CLK_MSR_ID(40, "ephy_test"),
> + CLK_MSR_ID(41, "dsi_b_meas"),
> + CLK_MSR_ID(42, "hdmirx_apl"),
> + CLK_MSR_ID(43, "hdmirx_tmds"),
> + CLK_MSR_ID(44, "hdmirx_cable"),
> + CLK_MSR_ID(45, "hdmirx_apll_clk_audio"),
> + CLK_MSR_ID(46, "hdmirx_5m"),
> + CLK_MSR_ID(47, "hdmirx_2m"),
> + CLK_MSR_ID(48, "hdmirx_cfg"),
> + CLK_MSR_ID(49, "hdmirx_hdcp2x_eclk"),
> + CLK_MSR_ID(50, "vid_pll0_div"),
> + CLK_MSR_ID(51, "hdmi_vid_pll"),
> + CLK_MSR_ID(54, "vdac_clk"),
> + CLK_MSR_ID(55, "vpu_clk_buf"),
> + CLK_MSR_ID(56, "mod_tcon_clko"),
> + CLK_MSR_ID(57, "lcd_an_clk_ph2"),
> + CLK_MSR_ID(58, "lcd_an_clk_ph3"),
> + CLK_MSR_ID(59, "hdmi_tx_pixel"),
> + CLK_MSR_ID(60, "vdin_meas"),
> + CLK_MSR_ID(61, "vpu_clk"),
> + CLK_MSR_ID(62, "vpu_clkb"),
> + CLK_MSR_ID(63, "vpu_clkb_tmp"),
> + CLK_MSR_ID(64, "vpu_clkc"),
> + CLK_MSR_ID(65, "vid_lock"),
> + CLK_MSR_ID(66, "vapbclk"),
> + CLK_MSR_ID(67, "ge2d"),
> + CLK_MSR_ID(68, "aud_pll"),
> + CLK_MSR_ID(69, "aud_sck"),
> + CLK_MSR_ID(70, "dsi_a_meas"),
> + CLK_MSR_ID(72, "mipi_csi_phy"),
> + CLK_MSR_ID(73, "mipi_isp"),
> + CLK_MSR_ID(76, "hdmitx_tmds"),
> + CLK_MSR_ID(77, "hdmitx_sys"),
> + CLK_MSR_ID(78, "hdmitx_fe"),
> + CLK_MSR_ID(80, "hdmitx_prif"),
> + CLK_MSR_ID(81, "hdmitx_200m"),
> + CLK_MSR_ID(82, "hdmitx_aud"),
> + CLK_MSR_ID(83, "hdmitx_pnx"),
> + CLK_MSR_ID(84, "spicc5"),
> + CLK_MSR_ID(85, "spicc4"),
> + CLK_MSR_ID(86, "spicc3"),
> + CLK_MSR_ID(87, "spicc2"),
> + CLK_MSR_ID(93, "vdec"),
> + CLK_MSR_ID(94, "wave521_aclk"),
> + CLK_MSR_ID(95, "wave521_cclk"),
> + CLK_MSR_ID(96, "wave521_bclk"),
> + CLK_MSR_ID(97, "hcodec"),
> + CLK_MSR_ID(98, "hevcb"),
> + CLK_MSR_ID(99, "hevcf"),
> + CLK_MSR_ID(100, "hdmi_aud_pll"),
> + CLK_MSR_ID(101, "hdmi_acr_ref"),
> + CLK_MSR_ID(102, "hdmi_meter"),
> + CLK_MSR_ID(103, "hdmi_vid"),
> + CLK_MSR_ID(104, "hdmi_aud"),
> + CLK_MSR_ID(105, "hdmi_dsd"),
> + CLK_MSR_ID(108, "dsi1_phy"),
> + CLK_MSR_ID(109, "dsi0_phy"),
> + CLK_MSR_ID(110, "smartcard"),
> + CLK_MSR_ID(111, "sar_adc"),
> + CLK_MSR_ID(113, "sd_emmc_c"),
> + CLK_MSR_ID(114, "sd_emmc_b"),
> + CLK_MSR_ID(115, "sd_emmc_a"),
> + CLK_MSR_ID(116, "gpio_msr"),
> + CLK_MSR_ID(117, "spicc1"),
> + CLK_MSR_ID(118, "spicc0"),
> + CLK_MSR_ID(119, "anakin"),
> + CLK_MSR_ID(121, "ts_clk(temp sensor)"),
> + CLK_MSR_ID(122, "ts_a73"),
> + CLK_MSR_ID(123, "ts_a53"),
> + CLK_MSR_ID(124, "ts_nna"),
> + CLK_MSR_ID(130, "audio_vad"),
> + CLK_MSR_ID(131, "acodec_dac_clk_x128"),
> + CLK_MSR_ID(132, "audio_locker_in"),
> + CLK_MSR_ID(133, "audio_locker_out"),
> + CLK_MSR_ID(134, "audio_tdmout_c_sclk"),
> + CLK_MSR_ID(135, "audio_tdmout_b_sclk"),
> + CLK_MSR_ID(136, "audio_tdmout_a_sclk"),
> + CLK_MSR_ID(137, "audio_tdmin_lb_sclk"),
> + CLK_MSR_ID(138, "audio_tdmin_c_sclk"),
> + CLK_MSR_ID(139, "audio_tdmin_b_sclk"),
> + CLK_MSR_ID(140, "audio_tdmin_a_sclk"),
> + CLK_MSR_ID(141, "audio_resamplea"),
> + CLK_MSR_ID(142, "audio_pdm_sysclk"),
> + CLK_MSR_ID(143, "audio_spdifoutb_mst"),
> + CLK_MSR_ID(144, "audio_spdifout_mst"),
> + CLK_MSR_ID(145, "audio_spdifin_mst"),
> + CLK_MSR_ID(146, "audio_pdm_dclk"),
> + CLK_MSR_ID(147, "audio_resampleb"),
> + CLK_MSR_ID(148, "earcrx_pll_dmac"),
> + CLK_MSR_ID(156, "pwm_ao_h"),
> + CLK_MSR_ID(157, "pwm_ao_g"),
> + CLK_MSR_ID(158, "pwm_ao_f"),
> + CLK_MSR_ID(159, "pwm_ao_e"),
> + CLK_MSR_ID(160, "pwm_ao_d"),
> + CLK_MSR_ID(161, "pwm_ao_c"),
> + CLK_MSR_ID(162, "pwm_ao_b"),
> + CLK_MSR_ID(163, "pwm_ao_a"),
> + CLK_MSR_ID(164, "pwm_f"),
> + CLK_MSR_ID(165, "pwm_e"),
> + CLK_MSR_ID(166, "pwm_d"),
> + CLK_MSR_ID(167, "pwm_c"),
> + CLK_MSR_ID(168, "pwm_b"),
> + CLK_MSR_ID(169, "pwm_a"),
> + CLK_MSR_ID(170, "aclkm"),
> + CLK_MSR_ID(171, "mclk_pll"),
> + CLK_MSR_ID(172, "a73_sys_pll_div16"),
> + CLK_MSR_ID(173, "a73_cpu_clk_div16"),
> + CLK_MSR_ID(176, "rng_ring_0"),
> + CLK_MSR_ID(177, "rng_ring_1"),
> + CLK_MSR_ID(178, "rng_ring_2"),
> + CLK_MSR_ID(179, "rng_ring_3"),
> + CLK_MSR_ID(180, "am_ring_out0"),
> + CLK_MSR_ID(181, "am_ring_out1"),
> + CLK_MSR_ID(182, "am_ring_out2"),
> + CLK_MSR_ID(183, "am_ring_out3"),
> + CLK_MSR_ID(184, "am_ring_out4"),
> + CLK_MSR_ID(185, "am_ring_out5"),
> + CLK_MSR_ID(186, "am_ring_out6"),
> + CLK_MSR_ID(187, "am_ring_out7"),
> + CLK_MSR_ID(188, "am_ring_out8"),
> + CLK_MSR_ID(189, "am_ring_out9"),
> + CLK_MSR_ID(190, "am_ring_out10"),
> + CLK_MSR_ID(191, "am_ring_out11"),
> + CLK_MSR_ID(192, "am_ring_out12"),
> + CLK_MSR_ID(193, "am_ring_out13"),
> + CLK_MSR_ID(194, "am_ring_out14"),
> + CLK_MSR_ID(195, "am_ring_out15"),
> + CLK_MSR_ID(196, "am_ring_out16"),
> + CLK_MSR_ID(197, "am_ring_out17"),
> + CLK_MSR_ID(198, "am_ring_out18"),
> + CLK_MSR_ID(199, "am_ring_out19"),
> + CLK_MSR_ID(200, "mipi_csi_phy0"),
> + CLK_MSR_ID(201, "mipi_csi_phy1"),
> + CLK_MSR_ID(202, "mipi_csi_phy2"),
> + CLK_MSR_ID(203, "mipi_csi_phy3"),
> + CLK_MSR_ID(204, "vid_pll1_div"),
> + CLK_MSR_ID(205, "vid_pll2_div"),
> + CLK_MSR_ID(206, "am_ring_out20"),
> + CLK_MSR_ID(207, "am_ring_out21"),
> + CLK_MSR_ID(208, "am_ring_out22"),
> + CLK_MSR_ID(209, "am_ring_out23"),
> + CLK_MSR_ID(210, "am_ring_out24"),
> + CLK_MSR_ID(211, "am_ring_out25"),
> + CLK_MSR_ID(212, "am_ring_out26"),
> + CLK_MSR_ID(213, "am_ring_out27"),
> + CLK_MSR_ID(214, "am_ring_out28"),
> + CLK_MSR_ID(215, "am_ring_out29"),
> + CLK_MSR_ID(216, "am_ring_out30"),
> + CLK_MSR_ID(217, "am_ring_out31"),
> + CLK_MSR_ID(218, "am_ring_out32"),
> + CLK_MSR_ID(219, "enc0_if"),
> + CLK_MSR_ID(220, "enc2"),
> + CLK_MSR_ID(221, "enc1"),
> + CLK_MSR_ID(222, "enc0")
> +};
> +
> static int meson_measure_id(struct meson_msr_id *clk_msr_id,
> unsigned int duration)
> {
> @@ -1026,6 +1278,18 @@ static const struct meson_msr_data clk_msr_s4_data = {
> .reg = &msr_reg_offset_v2,
> };
>
> +static const struct meson_msr_data clk_msr_a1_data = {
> + .msr_table = (void *)clk_msr_a1,
> + .msr_count = ARRAY_SIZE(clk_msr_a1),
> + .reg = &msr_reg_offset_v2,
> +};
> +
> +static const struct meson_msr_data clk_msr_t7_data = {
> + .msr_table = (void *)clk_msr_t7,
> + .msr_count = ARRAY_SIZE(clk_msr_t7),
> + .reg = &msr_reg_offset_v2,
> +};
> +
> static const struct of_device_id meson_msr_match_table[] = {
> {
> .compatible = "amlogic,meson-gx-clk-measure",
> @@ -1059,6 +1323,14 @@ static const struct of_device_id meson_msr_match_table[] = {
> .compatible = "amlogic,s4-clk-measure",
> .data = &clk_msr_s4_data,
> },
> + {
> + .compatible = "amlogic,a1-clk-measure",
> + .data = &clk_msr_a1_data,
> + },
> + {
> + .compatible = "amlogic,t7-clk-measure",
> + .data = &clk_msr_t7_data,
> + },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, meson_msr_match_table);
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH] dts: riscv: spacemit: k3: only keep spacemit,k1-i2c
From: Troy Mitchell @ 2026-04-20 8:50 UTC (permalink / raw)
To: Krzysztof Kozlowski, Sandie Cao, Yixun Lan, Troy Mitchell
Cc: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, spacemit, linux-riscv,
devicetree, linux-kernel, kernel test robot
In-Reply-To: <87ef529e-b591-49f5-9fc9-3099672e2f0f@kernel.org>
On Mon Apr 20, 2026 at 4:44 PM CST, Krzysztof Kozlowski wrote:
> On 20/04/2026 10:43, Krzysztof Kozlowski wrote:
>> On 20/04/2026 10:39, Sandie Cao wrote:
>>> Fix dtcheck issue: compatible:0: 'spacemit,k1-i2c' was expected
>>
>> Missing space after main commit msg.
>>
>>> Reported-by: kernel test robot <lkp@intel.com>
>>> Closes: https://lore.kernel.org/r/202604140259.eKDaxKua-lkp@intel.com/
>>>
>
> Also, the file reported in above warning DOES NOT EXIST (I checked
> next-20260414).
In Documentation/devicetree/bindings/pinctrl/spacemit,k1-pinctrl.yaml:
properties:
compatible:
enum:
- spacemit,k1-pinctrl
- spacemit,k3-pinctrl
So there's no reason to use k1-i2c. As far as I can tell, while they are the same IP,
there are subtle differences between them.
- Troy
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: amlogic: t7: Add clk measure support
From: Neil Armstrong @ 2026-04-20 8:52 UTC (permalink / raw)
To: Jian Hu, Ronald Claveau
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
In-Reply-To: <64cde9f6-4f28-4ba7-8362-aac28887ff22@amlogic.com>
On 4/20/26 05:25, Jian Hu wrote:
> Hi Ronald,
>
>
> Thanks for your review.
>
> On 4/17/2026 5:48 PM, Ronald Claveau wrote:
>> [ EXTERNAL EMAIL ]
>>
>> Hello Jian,
>>
>> On 4/15/26 10:33 AM, Jian Hu via B4 Relay wrote:
>>> From: Jian Hu <jian.hu@amlogic.com>
>>>
>>> Add the clock measure device to the T7 SoC family.
>>>
>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>> ---
>>> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>>> index 7fe72c94ed62..cec2ea74850d 100644
>>> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>>> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>>> @@ -701,6 +701,11 @@ pwm_ao_cd: pwm@60000 {
>>> status = "disabled";
>>> };
>>>
>>> + clock-measurer@48000 {
>>> + compatible = "amlogic,t7-clk-measure";
>>> + reg = <0x0 0x48000 0x0 0x1c>;
>>> + };
>>> +
>> Can you please order by reg, it should be between pwm_ao_gh and pwm_ab.
>> Thank you.
>
>
> According to the "Order of Nodes" chapter in Documentation/devicetree/bindings/dts-coding-style.rst,
>
> nodes of the same type should be grouped together, and this takes higher priority.
>
> So I have placed the clock-measure node after all PWM nodes to avoid splitting the PWM group.
This is not something we ever followed in the past, and I don't think it makes sens here.
"""
Alternatively for some subarchitectures, nodes of the same type can be
grouped together, e.g. all I2C controllers one after another even if this
breaks unit address ordering.
"""
This doesn't apply here, so order strictly by address.
Neil
>
>
> Best regards,
>
> Jian
>
^ 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