* [PATCH] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: Document Nord QMP UFS PHY
From: Shawn Guo @ 2026-04-20 7:49 UTC (permalink / raw)
To: 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, Shawn Guo
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
- enum:
- qcom,milos-qmp-ufs-phy
- qcom,msm8996-qmp-ufs-phy
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 1/5] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add support for glymur Gen5 x8 bifurcation mode
From: Qiang Yu @ 2026-04-20 7:23 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260417-awesome-tacky-coot-e59a30@quoll>
On Fri, Apr 17, 2026 at 11:18:08AM +0200, Krzysztof Kozlowski wrote:
> On Wed, Apr 15, 2026 at 07:58:13PM -0700, Qiang Yu wrote:
> > On Wed, Apr 15, 2026 at 09:50:28AM +0200, Krzysztof Kozlowski wrote:
> > > On Sun, Apr 12, 2026 at 11:25:56PM -0700, Qiang Yu wrote:
> > > > The Glymur SoC has pcie3a and pcie3b PHYs that can operate in two modes:
> > > >
> > > > 1. Independent 4-lane mode: Each PHY operates as a separate PCIe Gen5
> > > > 4-lane interface, compatible with qcom,glymur-qmp-gen5x4-pcie-phy
> > > > 2. Bifurcation mode (8-lane): pcie3a phy acts as leader and pcie3b phy as
> > > > follower to form a single 8-lane PCIe Gen5 interface
> > > >
> > > > In bifurcation mode, the hardware design requires controlling additional
> > > > resources beyond the standard pcie3a PHY configuration:
> > > >
> > > > - pcie3b's aux_clk (phy_b_aux)
> > > > - pcie3b's phy_gdsc power domain
> > > > - pcie3b's bcr/nocsr reset
> > > >
> > > > Add qcom,glymur-qmp-gen5x8-pcie-phy compatible string to document this
> > > > 8-lane bifurcation configuration.
> > >
> > > Do you describe PCI3A or PCI3B or something combined PCI3?
> >
> > I describe a single x8 PHY with resources from both the pcie3a and pcie3b
> > PHY blocks for x8 operation.
> >
> > >
> > > >
> > > > The phy_b_aux clock is used as the 6th clock instead of pipediv2,
> > > > requiring the clock-names enum to be extended to support both
> > > > [phy_b_aux, pipediv2] options at index 5. This follows the existing
> > > > pattern used for [rchng, refgen] clocks at index 3.
> > > >
> > > > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > > ---
> > > > .../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 53 ++++++++++++++++++----
> > > > 1 file changed, 45 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > index 3a35120a77ec0ceb814a1cdcacff32fef32b4f7b..14eba5d705b1956c1bb00cc8c95171ed6488299b 100644
> > > > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > @@ -18,6 +18,7 @@ properties:
> > > > enum:
> > > > - qcom,glymur-qmp-gen4x2-pcie-phy
> > > > - qcom,glymur-qmp-gen5x4-pcie-phy
> > > > + - qcom,glymur-qmp-gen5x8-pcie-phy
> > >
> > > That's the same device as 5x4, no? One device, one compatible and this
> > > suggests you will have three PCI phys in the DT - two 5x4 and one 5x8?
> > >
> >
> > It is not the same as the 5x4 PHY. In DT, we model three PHY nodes:
> > phy_3a (1x4), phy_3b (1x4), and a separate phy_1x8 node for x8 mode.
>
> OK, that's what I wanted to hear. And that's what should not be done,
>
> You should not have a separate node for the same hardware. First, DTC
> will give you a W=1 warning, although warning itself should be moved to
> W=2.
>
> Second, the warning tells important story - same hardware is described
> twice.
>
> You only need phy_3a and phy_3b, so only two in total.
We can keep only phy_3a and phy_3b, but still add new compatible
qcom,glymur-qmp-gen5x8-pcie-phy in binding, right?
For boards that support pcie3a(1x4) + pcie3b(1x4), DTS would be:
pcie3a_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
pcie3b_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
For boards that support 1x8, we would override pcie3a_phy with:
pcie3a_phy { compatible = "qcom,glymur-qmp-gen5x8-pcie-phy"; /* additional resources */ };
pcie3b_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
This still uses only two PHY nodes and DTC will not report warning.
- Qiang Yu
>
> phy_3a could have resources of phy_3b OR could have a phandle to
> companion (follower) phy to fetch resources from it. I don't know yet
> which choice is better, though.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine
From: Harshal Dev @ 2026-04-20 8:05 UTC (permalink / raw)
To: johannes.goede, Konrad Dybcio, Thara Gopinath, Herbert Xu,
David S. Miller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov
Cc: Neeraj Soni, Kuldeep Singh, Abel Vesa, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Bartosz Golaszewski,
Udit Tiwari
In-Reply-To: <cf8ba27f-2c9e-4c13-8c28-4e1e22e22479@oss.qualcomm.com>
+Udit, +Bartoz
Hello Hans,
On 4/17/2026 8:00 PM, johannes.goede@oss.qualcomm.com wrote:
> Hi,
>
> On 17-Apr-26 15:38, Harshal Dev wrote:
>>
>>
>> On 4/17/2026 4:36 PM, Konrad Dybcio wrote:
>>> On 4/17/26 11:22 AM, Harshal Dev wrote:
>>>> Hi,
>>>>
>>>> On 4/16/2026 7:10 PM, Konrad Dybcio wrote:
>>>>> On 4/16/26 3:07 PM, Harshal Dev wrote:
>>>>>> On Glymur, there is a crypto engine IP block similar to the ones found on
>>>>>> SM8x50 platforms.
>>>>>>
>>>>>> Describe the crypto engine and its BAM.
>>>>>>
>>>>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>>>>> ---
>>>>>> arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>>>>>> 1 file changed, 26 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>>> index f23cf81ddb77..e8c796f2c572 100644
>>>>>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>>> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>>>>>> status = "disabled";
>>>>>> };
>>>>>>
>>>>>> + cryptobam: dma-controller@1dc4000 {
>>>>>> + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>>>>>> + reg = <0x0 0x01dc4000 0x0 0x28000>;
>>>>>> + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + #dma-cells = <1>;
>>>>>> + iommus = <&apps_smmu 0x480 0x0>,
>>>>>> + <&apps_smmu 0x481 0x0>;
>>>>>
>>>>> It seems like these aren't the right SIDs on this platform.. Have you
>>>>> tested this patch on hw?
>>>>
>>>> Thanks a lot for catching this Konrad. The correct SID pairs are <0x80 0x0> and <0x81 0x0>.
>>>> (I hope I don't need to pad them?)
>>>
>>> No, you don't
>>
>> Ack.
>>
>>>
>>>>
>>>> Unfortunately, I could only validate driver probe on my limited ramdisk environment:
>>>>
>>>> [ 4.583802] qcrypto 1dfa000.crypto: Crypto device found, version 5.9.1
>>>>
>>>> I was waiting for Wenjia to run the full crypto user-space test suite once. I'll update the
>>>> SIDs and wait for a Tested-by from him.
>>>
>>> Thanks
>>>
>>> I think you should be able to get some life out of the crypto engine
>>> via CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y (which btw +Hans
>>> mentioned reports a failure on Hamoa)
>>
>> Sure, I'll try this, could you also point me to the bug report?
>
> No bug report yet, I was asking around internally who I should
> talk to about his.
>
> I'm seeing 7.0-rc# QCE crypto selftest failures on a Lenovo ThinkPad
> T14s gen 6 (Hamoa x1e78100):
>
> [ 1.357020] alg: skcipher: xts-aes-qce setkey failed on test vector 0; expected_error=0, actual_error=-126, flags=0x1
> [ 1.369951] alg: skcipher: ctr-aes-qce encryption test failed (wrong output IV) on test vector 4, cfg="in-place (one sglist)"
> [ 1.443143] alg: aead: rfc4309-ccm-aes-qce decryption failed on test vector 1; expected_error=0, actual_error=-6, cfg="misaligned splits crossing pages, inplace"
>
> This is with manually compiled 7.0-rc# using Fedora's default kernel
> config which includes: CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y
> with the latter being hidden behind CONFIG_EXPERT for some reason.
>
> This is a regression compared to 6.19.y where CONFIG_CRYPTO_SELFTESTS=y
> is also enabled by Fedora and it works fine.
Our Crypto Engine enablement for Hamoa (x1e80100) was merged as part of the 7.0 kernel
https://lore.kernel.org/all/a9a6b840-5a4f-4d27-8b34-da82657e5c9d@app.fastmail.com/
I did not run the CRYPTO_SELF_TESTS for these, so I am not sure if they were passing
for 7.0 with the Crypto Engine enablement changes. I also do not know if we have been
running the self-tests for other Qualcomm targets which have support for the Crypto Engine.
Maybe Bartoz can help answer this, since he has been involved from the beginning.
But it is worthwhile to check if something else introduced this regression or simply
the enablement of Crypto Engine on Hamoa. If you have a manually compiled 7.0-rc build
could you perhaps check reproduction after reverting this commit?
7d1974ce80fc386834e5667b0f579c2c766c4faa ("arm64: dts: qcom: x1e80100: Add crypto engine")
>
> I've not looked further into this yet, other then a message to fellow
> OSTT team arm64-laptop users asking for tips / whom to report this to.
>
> I would be happy to send create a kernel.bugzilla.org bug-report
> about this to, or report to email somewhere, or ...
>
> Please let met know where you want a bug-report to be filed and
> also what information to add on top of the above info ?
>
> E.g. these failures trigger a WARN() and thus log a backtrace,
> do you want those backtraces and if yes I presume I should run
> them through addr2line ?
>
Please send an email to me, Neeraj, Udit and Bartoz for a separate discussion on this.
Please provide information which can help us reproduce this on our setup, and
also the the dmesg and backtrace logs which you are mentioning here apart from any
other information which you feel is relevant.
Thank you very much for your efforts on this!
Regards,
Harshal
> Regards,
>
> Hans
>
>
^ permalink raw reply
* 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
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