* Re: [PATCH v3 1/4] ARM: dts: qcom: msm8960: expressatt: Sort node references and includes
From: David Heidelberg @ 2026-04-11 8:33 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rudraksha Gupta, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <f51ddaf0-a857-4250-ad9e-e50982e8c108@kernel.org>
On 11/04/2026 09:38, Krzysztof Kozlowski wrote:
> On 11/04/2026 06:01, Rudraksha Gupta wrote:
>> On 4/7/26 14:46, David Heidelberg wrote:
>>> On 07/04/2026 23:04, Krzysztof Kozlowski wrote:
>>>> On 07/04/2026 22:39, Rudraksha Gupta wrote:
>>>>> On 4/7/26 12:59, Krzysztof Kozlowski wrote:
>>>>>> On 01/04/2026 22:32, Rudraksha Gupta via B4 Relay wrote:
>>>>>>> From: Rudraksha Gupta <guptarud@gmail.com>
>>>>>>>
>>>>>>> Reorganize the DTS file for consistency with other msm8960 board
>>>>>>> files.
>>>>>>>
>>>>>>> Assisted-by: Claude:claude-opus-4.6
>>>>>>> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
>>>>>>> ---
>>>>>>> .../dts/qcom/qcom-msm8960-samsung-expressatt.dts | 408
>>>>>>> +++++++++++----------
>>>>>>> 1 file changed, 207 insertions(+), 201 deletions(-)
>>>>>>>
>>>>>> Sorry, but no. We are not taking Claude as one determining coding
>>>>>> style.
>>>>>> Are we going to do the work again the moment we come with proper tool?
>>>>>
>>>>> There is no tool currently to auto format DTS, and doesn't seem to be
>>>>> coming for a while:
>>>>>
>>>>> https://www.youtube.com/watch?v=cvoIbTL_ZQA
>>>>>
>>>>>
>>>>> Claude didn't determine the coding style. I did based on sony-huashan,
>>>>> which is already upstream:
>>>>>
>>>>> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/qcom/qcom-msm8960-sony-huashan.dts
>>>>>
>>>>>
>>>>>
>>>>> I just used Claude to do the manual work for me. In v2, I made sure the
>>>>> diff before and after the change was nill. v3 included additional
>>>>> changes requested by Konrad and some comments that I remembered during
>>>>> prior attempts mainlining patch series for this device.
>>>>
>>>> IMO, it is just too risky to let Claude reorganize the nodes, but I
>>>> assume reviewers of your code did run dtx_diff.
>>>
>>> I think it depends on the prompt. Since I’m performing many of the
>>> same tasks repeatedly across multiple sdm845 devices, asking an LLM to
>>> do node-by-node reorganization can be reasonably reviewable (at least
>>> when reviewing incremental progress, not just the final diff).
>>>
>>> I would prefer to do more of the sorting myself, but I find it quite
>>> tedious. The diff tool struggles when similar or identical lines
>>> appear in different nodes, which often results in a messy final diff
>>> (I noticed this in Sajattack’s sdm845 LG patchset).
>>>
>>> This leads me to an idea:
>>>
>>> For these sorting cleanups, perhaps we could introduce a “squash mode”?
>>>
>>> Contributors could submit commits per node, making the reorganization
>>> clearly visible (and ensuring nothing is accidentally lost), and then
>>> the maintainer could squash them into a single commit to avoid
>>> cluttering the git log.
>>>
>>> What do you think?
>>
>> Easiest solution would be to get Claude to make a DTS auto formatter. I
>> estimate it would likely take a couple iterations to get a functional
>> prototype and max a week to get it into a mergable state, if the style
>> is agreed beforehand. Simply provide DTS'es that follow the pattern you
>> like to Claude, then tell Claude that you want to make a Python script
>
> Yeah, and who wants to review the Claude code?
If it's good quality, I would do (depends on the language ofc).
>
> I already have a formatter to review in the pipeline...
Nice!
>
>> to auto format DTS files and make functions for each different common
>> style pattern identified in the DTS'es. I assume it would give a good
>> enough base to work off of. The most painful part will be determining
>> what the correct style for all DTS'es as I'm sure others will have
>> opinions on that.
>>
>
> The biggest problem is that no way maintainers will run untrusted 3rd
> party code, co-contributed by random people with Claude.
Generally, LLMs can be forced/instructed to write human-reviewable code, the
main issue is people usually don't ask for human-readable code.
David
>
>
> Best regards,
> Krzysztof
--
David Heidelberg
^ permalink raw reply
* Re: [PATCH v3 1/4] ARM: dts: qcom: msm8960: expressatt: Sort node references and includes
From: Krzysztof Kozlowski @ 2026-04-11 7:38 UTC (permalink / raw)
To: Rudraksha Gupta, David Heidelberg, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <a0eb87b5-7bb8-4aae-83a1-982d8b4c06f8@gmail.com>
On 11/04/2026 06:01, Rudraksha Gupta wrote:
> On 4/7/26 14:46, David Heidelberg wrote:
>> On 07/04/2026 23:04, Krzysztof Kozlowski wrote:
>>> On 07/04/2026 22:39, Rudraksha Gupta wrote:
>>>> On 4/7/26 12:59, Krzysztof Kozlowski wrote:
>>>>> On 01/04/2026 22:32, Rudraksha Gupta via B4 Relay wrote:
>>>>>> From: Rudraksha Gupta <guptarud@gmail.com>
>>>>>>
>>>>>> Reorganize the DTS file for consistency with other msm8960 board
>>>>>> files.
>>>>>>
>>>>>> Assisted-by: Claude:claude-opus-4.6
>>>>>> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
>>>>>> ---
>>>>>> .../dts/qcom/qcom-msm8960-samsung-expressatt.dts | 408
>>>>>> +++++++++++----------
>>>>>> 1 file changed, 207 insertions(+), 201 deletions(-)
>>>>>>
>>>>> Sorry, but no. We are not taking Claude as one determining coding
>>>>> style.
>>>>> Are we going to do the work again the moment we come with proper tool?
>>>>
>>>> There is no tool currently to auto format DTS, and doesn't seem to be
>>>> coming for a while:
>>>>
>>>> https://www.youtube.com/watch?v=cvoIbTL_ZQA
>>>>
>>>>
>>>> Claude didn't determine the coding style. I did based on sony-huashan,
>>>> which is already upstream:
>>>>
>>>> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/qcom/qcom-msm8960-sony-huashan.dts
>>>>
>>>>
>>>>
>>>> I just used Claude to do the manual work for me. In v2, I made sure the
>>>> diff before and after the change was nill. v3 included additional
>>>> changes requested by Konrad and some comments that I remembered during
>>>> prior attempts mainlining patch series for this device.
>>>
>>> IMO, it is just too risky to let Claude reorganize the nodes, but I
>>> assume reviewers of your code did run dtx_diff.
>>
>> I think it depends on the prompt. Since I’m performing many of the
>> same tasks repeatedly across multiple sdm845 devices, asking an LLM to
>> do node-by-node reorganization can be reasonably reviewable (at least
>> when reviewing incremental progress, not just the final diff).
>>
>> I would prefer to do more of the sorting myself, but I find it quite
>> tedious. The diff tool struggles when similar or identical lines
>> appear in different nodes, which often results in a messy final diff
>> (I noticed this in Sajattack’s sdm845 LG patchset).
>>
>> This leads me to an idea:
>>
>> For these sorting cleanups, perhaps we could introduce a “squash mode”?
>>
>> Contributors could submit commits per node, making the reorganization
>> clearly visible (and ensuring nothing is accidentally lost), and then
>> the maintainer could squash them into a single commit to avoid
>> cluttering the git log.
>>
>> What do you think?
>
> Easiest solution would be to get Claude to make a DTS auto formatter. I
> estimate it would likely take a couple iterations to get a functional
> prototype and max a week to get it into a mergable state, if the style
> is agreed beforehand. Simply provide DTS'es that follow the pattern you
> like to Claude, then tell Claude that you want to make a Python script
Yeah, and who wants to review the Claude code?
I already have a formatter to review in the pipeline...
> to auto format DTS files and make functions for each different common
> style pattern identified in the DTS'es. I assume it would give a good
> enough base to work off of. The most painful part will be determining
> what the correct style for all DTS'es as I'm sure others will have
> opinions on that.
>
The biggest problem is that no way maintainers will run untrusted 3rd
party code, co-contributed by random people with Claude.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/4] ARM: dts: qcom: msm8960: expressatt: Sort node references and includes
From: Krzysztof Kozlowski @ 2026-04-11 7:36 UTC (permalink / raw)
To: David Heidelberg, Rudraksha Gupta, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <eb1eebd2-75c0-4ffe-95e7-9f5d5d02edd1@ixit.cz>
On 07/04/2026 23:46, David Heidelberg wrote:
> On 07/04/2026 23:04, Krzysztof Kozlowski wrote:
>> On 07/04/2026 22:39, Rudraksha Gupta wrote:
>>>
>>> On 4/7/26 12:59, Krzysztof Kozlowski wrote:
>>>> On 01/04/2026 22:32, Rudraksha Gupta via B4 Relay wrote:
>>>>> From: Rudraksha Gupta <guptarud@gmail.com>
>>>>>
>>>>> Reorganize the DTS file for consistency with other msm8960 board files.
>>>>>
>>>>> Assisted-by: Claude:claude-opus-4.6
>>>>> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
>>>>> ---
>>>>> .../dts/qcom/qcom-msm8960-samsung-expressatt.dts | 408 +++++++++++----------
>>>>> 1 file changed, 207 insertions(+), 201 deletions(-)
>>>>>
>>>> Sorry, but no. We are not taking Claude as one determining coding style.
>>>> Are we going to do the work again the moment we come with proper tool?
>>>
>>> There is no tool currently to auto format DTS, and doesn't seem to be
>>> coming for a while:
>>>
>>> https://www.youtube.com/watch?v=cvoIbTL_ZQA
>>>
>>>
>>> Claude didn't determine the coding style. I did based on sony-huashan,
>>> which is already upstream:
>>>
>>> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/qcom/qcom-msm8960-sony-huashan.dts
>>>
>>>
>>> I just used Claude to do the manual work for me. In v2, I made sure the
>>> diff before and after the change was nill. v3 included additional
>>> changes requested by Konrad and some comments that I remembered during
>>> prior attempts mainlining patch series for this device.
>>
>> IMO, it is just too risky to let Claude reorganize the nodes, but I
>> assume reviewers of your code did run dtx_diff.
>
> I think it depends on the prompt. Since I’m performing many of the same tasks
> repeatedly across multiple sdm845 devices, asking an LLM to do node-by-node
> reorganization can be reasonably reviewable (at least when reviewing incremental
> progress, not just the final diff).
>
> I would prefer to do more of the sorting myself, but I find it quite tedious.
> The diff tool struggles when similar or identical lines appear in different
> nodes, which often results in a messy final diff (I noticed this in Sajattack’s
> sdm845 LG patchset).
>
> This leads me to an idea:
>
> For these sorting cleanups, perhaps we could introduce a “squash mode”?
>
> Contributors could submit commits per node, making the reorganization clearly
> visible (and ensuring nothing is accidentally lost), and then the maintainer
> could squash them into a single commit to avoid cluttering the git log.
>
> What do you think?
It would help review on the lists, although the actual solution is to
use deterministic tools. That's why usage of Claude is wrong. It
requires you and us to thoroughly review it. If you did not thoroughly
review that patch, you would be sending microslop.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Guenter Roeck @ 2026-04-11 7:20 UTC (permalink / raw)
To: Akhil R, krzk
Cc: Frank.Li, acpica-devel, alexandre.belloni, conor+dt, devicetree,
ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon, linux-i3c,
linux-kernel, miquel.raynal, p.zabel, rafael, robh, sakari.ailus,
wsa+renesas
In-Reply-To: <20260411053433.49655-1-akhilrajeev@nvidia.com>
On 4/10/26 22:34, Akhil R wrote:
[ ... ]
>>>> And it
>>>> should bring me clear rule what I can or cannot remove from defconfig,
>>>> if in 2 years I come and start pruning it from symbols.
>
> I am still a little confused on what information would likely accept (and
> keep) these configs in the defconfig. Would updating the commit message
> as below work?
>
> "These configs enable the support for SPD5118 within the
> Small-Outline-Compression-Attached Memory Modules (SOCAMM) LPDDR5X found
> in the NVIDIA Vera CPUs. The Vera CPU uses ACPI and is part of platforms
> such as Vera Rubin."
>
It is quite interesting that we argue about SPD5118 which is mandatory in
DDR5 systems. At the same time, CONFIG_IGB_HWMON, CONFIG_SENSORS_MACSMC_HWMON,
CONFIG_SENSORS_RASPBERRYPI_HWMON, and CONFIG_RTC_DRV_DS3232_HWMON _are_
enabled in arm64:defconfig. CONFIG_IGB_HWMON is even built-in.
It is kind of difficult to understand why those are more important than
the temperature sensor on DDR5 modules (or the temperature sensor on DDR4
modules, for that matter).
I don't know what the policy for defconfig is, but just based on that it does
seem to lack consistency.
A separate question is if it is time to enable I3C in default configurations.
I'd think so - more and more chip vendors support it, and presumably they would
not invest in it if there was no demand, but that is just my personal opinion.
Guenter
^ permalink raw reply
* Re: [PATCH 00/35] irqchip/qcom-pdc: Clean up register mapping and DT descriptions
From: Mukesh Ojha @ 2026-04-11 6:55 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, cros-qcom-dts-watchers, linux-arm-msm,
linux-kernel, devicetree
In-Reply-To: <adm1uXe6QRes8DiX@baldur>
On Fri, Apr 10, 2026 at 09:48:25PM -0500, Bjorn Andersson wrote:
> On Sat, Apr 11, 2026 at 12:10:37AM +0530, Mukesh Ojha wrote:
> > The Qualcomm PDC (Power Domain Controller) hardware exposes multiple DRV
> > (Driver) regions, each 0x10000 bytes in size, where each region serves a
> > specific client in the system . Linux only needs access to the APSS DRV
> > region.
> >
> > Despite this, the driver was mapping up to 0x30000 bytes (three DRV
> > regions) via a QCOM_PDC_SIZE clamp introduced as a workaround for old
> > sm8150 DTs that described a too-small register window. Correspondingly,
> > most platform DTS files described the PDC reg as 0x30000 in size, and
> > several also carried a second, entirely unused reg entry pointing at an
> > unrelated register region that the driver never maps.
> >
> > This series cleans all of that up in three logical steps:
> >
> > 1. (patches 2-6):
> >
>
> These patches are for the IRQ subsystem/maintainer.
It's bad on my part that I didn't expect this to be merged in the first
iteration itself, but yes, I could have put PDC register sizing and
related device tree binding and driver changes together with the device
tree as one set. Like in the current patch series, it would be patches
1, 3, and all "Fix PDC reg size..." patches or may be the removing the
2nd register space change as well in one set and pdc driver clean up as
separate ?
>
> > Split __pdc_enable_intr() into two focused per-version helpers
> > to separate the HW < 3.2 bank-based path from the HW >= 3.2 per-pin
> > path. Replace the pdc_version global with a function pointer assigned
> > once at probe time, moving the version check out of the hot path.
> > Tighten the ioremap clamp from QCOM_PDC_SIZE (0x30000) to PDC_DRV_SIZE
> > (0x10000) now that the DT fixes below make the workaround unnecessary.
> > Also add a PDC_VERSION() constructor macro and use FIELD_GET() for bank
> > index extraction to make the bit encoding self-documenting.
> >
> > 2. (patches 1, 7-28):
> >
>
> And these patches are for the Qualcomm SoC/DT tree.
Yes, As I said, I could have done better..
>
> > All 28 platform DTS files that described the PDC reg window as 0x30000
> > are corrected to 0x10000, reflecting the single APSS DRV region that
> > Linux actually maps.
> >
> > 3. (patches 29-35):
> >
>
> Same with these.
>
>
> I don't see any dependencies between the IRQ and DT patches, can they be
> merged independently? Why did you send them together?
For better context, register sizing changes can be sent together
including binding, driver, and DT's as well.
>
> Regards,
> Bjorn
>
> > Seven platform DTS files (kaanapali, lemans, milos, monaco, sc8280xp,
> > sdx75, talos) carried a second reg entry pointing at an unrelated
> > hardware block. The driver only ever calls of_address_to_resource(node,
> > 0, ...) so this second entry was never mapped or accessed. Remove it.
> >
> > The net result is that every PDC node in the tree now describes exactly
> > one register region of exactly 0x10000 bytes — the APSS DRV region that
> > the driver actually uses — and the driver's ioremap clamp matches that
> > reality.
> >
> > Mukesh Ojha (35):
> > dt-bindings: qcom,pdc: Tighten reg to single APSS DRV region
> > irqchip/qcom-pdc: Split __pdc_enable_intr() into per-version helpers
> > irqchip/qcom-pdc: Tighten ioremap clamp to single DRV region size
> > irqchip/qcom-pdc: Replace pdc_version global with a function pointer
> > irqchip/qcom-pdc: Add PDC_VERSION() macro to describe version register
> > fields
> > irqchip/qcom-pdc: Use FIELD_GET() to extract bank index and bit
> > position
> > arm64: dts: qcom: sdm845: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sdm670: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sc7180: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sc7280: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sc8180x: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sm8150: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sc8280xp: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sm8250: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sm8350: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sm8450: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sm8550: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sm8650: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sm4450: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: x1e80100: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sm6350: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sar2130p: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: qcs615: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: qcs8300: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sa8775p: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: sdx75: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: milos: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: qdu1000: Fix PDC reg size to single APSS DRV region
> > arm64: dts: qcom: kaanapali: Drop unused second PDC reg entry
> > arm64: dts: qcom: lemans: Drop unused second PDC reg entry
> > arm64: dts: qcom: milos: Drop unused second PDC reg entry
> > arm64: dts: qcom: monaco: Drop unused second PDC reg entry
> > arm64: dts: qcom: sc8280xp: Drop unused second PDC reg entry
> > arm64: dts: qcom: sdx75: Drop unused second PDC reg entry
> > arm64: dts: qcom: talos: Drop unused second PDC reg entry
> >
> > .../interrupt-controller/qcom,pdc.yaml | 2 +-
> > arch/arm64/boot/dts/qcom/hamoa.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/kaanapali.dtsi | 3 +-
> > arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/lemans.dtsi | 3 +-
> > arch/arm64/boot/dts/qcom/milos.dtsi | 3 +-
> > arch/arm64/boot/dts/qcom/monaco.dtsi | 3 +-
> > arch/arm64/boot/dts/qcom/qdu1000.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/sar2130p.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/sc8180x.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/sdm670.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/sdx75.dtsi | 3 +-
> > arch/arm64/boot/dts/qcom/sm4450.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/sm6350.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/sm8450.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/sm8550.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/sm8650.dtsi | 2 +-
> > arch/arm64/boot/dts/qcom/talos.dtsi | 3 +-
> > drivers/irqchip/qcom-pdc.c | 56 +++++++++++--------
> > 25 files changed, 57 insertions(+), 53 deletions(-)
> >
> > --
> > 2.53.0
> >
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH 04/35] irqchip/qcom-pdc: Replace pdc_version global with a function pointer
From: Mukesh Ojha @ 2026-04-11 6:23 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, cros-qcom-dts-watchers, linux-arm-msm,
linux-kernel, devicetree
In-Reply-To: <adm0X2ybeG5McXVv@baldur>
On Fri, Apr 10, 2026 at 09:43:10PM -0500, Bjorn Andersson wrote:
> On Sat, Apr 11, 2026 at 12:10:41AM +0530, Mukesh Ojha wrote:
> > Now that the two enable paths are separate functions, replace the
> > pdc_version global with a __pdc_enable_intr function pointer. The
> > pointer is assigned once at probe time based on the version register,
> > moving the version comparison out of the interrupt enable/disable hot
> > path entirely.
>
> That's what the patch does, but why?
I thought, it was odd to compare against the version every time during
enable/disable instead of clearing the path to take at probe time itself.
however, I don't have data to prove how hot this path is ?
> >
> > Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > ---
> > drivers/irqchip/qcom-pdc.c | 13 +++----------
> > 1 file changed, 3 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
> > index 21e2b4b884ee..734576cdce0c 100644
> > --- a/drivers/irqchip/qcom-pdc.c
> > +++ b/drivers/irqchip/qcom-pdc.c
> > @@ -51,7 +51,7 @@ static void __iomem *pdc_base;
> > static void __iomem *pdc_prev_base;
> > static struct pdc_pin_region *pdc_region;
> > static int pdc_region_cnt;
> > -static unsigned int pdc_version;
> > +static void (*__pdc_enable_intr)(int pin_out, bool on);
> > static bool pdc_x1e_quirk;
> >
> > static void pdc_base_reg_write(void __iomem *base, int reg, u32 i, u32 val)
> > @@ -123,14 +123,6 @@ static void pdc_enable_intr_cfg(int pin_out, bool on)
> > pdc_reg_write(IRQ_i_CFG, pin_out, enable);
> > }
> >
> > -static void __pdc_enable_intr(int pin_out, bool on)
> > -{
> > - if (pdc_version < PDC_VERSION_3_2)
> > - pdc_enable_intr_bank(pin_out, on);
> > - else
> > - pdc_enable_intr_cfg(pin_out, on);
>
> This style is comfortable to read.
Agree, code readingwise, this looks easier..
>
> > -}
> > -
> > static void pdc_enable_intr(struct irq_data *d, bool on)
> > {
> > unsigned long flags;
> > @@ -400,7 +392,8 @@ static int qcom_pdc_probe(struct platform_device *pdev, struct device_node *pare
> > goto fail;
> > }
> >
> > - pdc_version = pdc_reg_read(PDC_VERSION_REG, 0);
> > + __pdc_enable_intr = (pdc_reg_read(PDC_VERSION_REG, 0) < PDC_VERSION_3_2) ?
> > + pdc_enable_intr_bank : pdc_enable_intr_cfg;
>
> This style is a mess.
>
> Regards,
> Bjorn
>
> >
> > parent_domain = irq_find_host(parent);
> > if (!parent_domain) {
> > --
> > 2.53.0
> >
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH v5 4/5] remoteproc: qcom: pas: Add late attach support for subsystems
From: Jie Gan @ 2026-04-11 6:04 UTC (permalink / raw)
To: Jingyi Wang, Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Luca Weiss, Bartosz Golaszewski, Konrad Dybcio
Cc: aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel,
Gokul Krishna Krishnakumar
In-Reply-To: <20260409-knp-soccp-v5-4-805a492124da@oss.qualcomm.com>
On 4/9/2026 4:52 PM, Jingyi Wang wrote:
> Subsystems can be brought out of reset by entities such as bootloaders.
> As the irq enablement could be later than subsystem bring up, the state
> of subsystem should be checked by reading SMP2P bits and performing ping
> test.
>
> A new qcom_pas_attach() function is introduced. if a crash state is
> detected for the subsystem, rproc_report_crash() is called. If the
> subsystem is ready and the ping is successful, it will be marked as
> "attached". If ready irq is not received, it could be the early boot
> feature is not supported by other entities. In this case, the state will
> be marked as RPROC_OFFLINE so that the PAS driver can load the firmware
> and start the remoteproc.
>
> Co-developed-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
> Signed-off-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
> drivers/remoteproc/qcom_q6v5.c | 69 ++++++++++++++++++++++++++++++++
> drivers/remoteproc/qcom_q6v5.h | 6 +++
> drivers/remoteproc/qcom_q6v5_pas.c | 80 ++++++++++++++++++++++++++++++++++++--
> 3 files changed, 152 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
> index 58d5b85e58cd..52247c17c38a 100644
> --- a/drivers/remoteproc/qcom_q6v5.c
> +++ b/drivers/remoteproc/qcom_q6v5.c
> @@ -20,6 +20,7 @@
>
> #define Q6V5_LOAD_STATE_MSG_LEN 64
> #define Q6V5_PANIC_DELAY_MS 200
> +#define Q6V5_PING_TIMEOUT_MS 500
>
> static int q6v5_load_state_toggle(struct qcom_q6v5 *q6v5, bool enable)
> {
> @@ -234,6 +235,74 @@ unsigned long qcom_q6v5_panic(struct qcom_q6v5 *q6v5)
> }
> EXPORT_SYMBOL_GPL(qcom_q6v5_panic);
>
> +static irqreturn_t q6v5_pong_interrupt(int irq, void *data)
> +{
> + struct qcom_q6v5 *q6v5 = data;
> +
> + complete(&q6v5->ping_done);
> +
> + return IRQ_HANDLED;
> +}
> +
> +int qcom_q6v5_ping_subsystem(struct qcom_q6v5 *q6v5)
> +{
> + int ret;
> + int ping_failed = 0;
> +
> + reinit_completion(&q6v5->ping_done);
> +
> + /* Set master kernel Ping bit */
> + ret = qcom_smem_state_update_bits(q6v5->ping_state,
> + BIT(q6v5->ping_bit), BIT(q6v5->ping_bit));
> + if (ret) {
> + dev_err(q6v5->dev, "Failed to update ping bits\n");
> + return ret;
> + }
> +
> + ret = wait_for_completion_timeout(&q6v5->ping_done, msecs_to_jiffies(Q6V5_PING_TIMEOUT_MS));
> + if (!ret) {
> + ping_failed = -ETIMEDOUT;
> + dev_err(q6v5->dev, "Failed to get back pong\n");
> + }
> +
> + /* Clear ping bit master kernel */
> + ret = qcom_smem_state_update_bits(q6v5->ping_state, BIT(q6v5->ping_bit), 0);
> + if (ret) {
> + dev_err(q6v5->dev, "Failed to clear master kernel bits\n");
> + return ret;
> + }
> +
> + return ping_failed;
> +}
> +EXPORT_SYMBOL_GPL(qcom_q6v5_ping_subsystem);
> +
> +int qcom_q6v5_ping_subsystem_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev)
> +{
> + int ret = -ENODEV;
> +
> + q6v5->ping_state = devm_qcom_smem_state_get(&pdev->dev, "ping", &q6v5->ping_bit);
> + if (IS_ERR(q6v5->ping_state)) {
> + dev_err(&pdev->dev, "Failed to acquire smem state %ld\n",
> + PTR_ERR(q6v5->ping_state));
> + return PTR_ERR(q6v5->ping_state);
> + }
> +
> + init_completion(&q6v5->ping_done);
> +
> + q6v5->pong_irq = platform_get_irq_byname(pdev, "pong");
> + if (q6v5->pong_irq < 0)
> + return q6v5->pong_irq;
> +
> + ret = devm_request_threaded_irq(&pdev->dev, q6v5->pong_irq, NULL,
> + q6v5_pong_interrupt, IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> + "q6v5 pong", q6v5);
> + if (ret)
> + dev_err(&pdev->dev, "Failed to acquire pong IRQ\n");
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(qcom_q6v5_ping_subsystem_init);
> +
> /**
> * qcom_q6v5_init() - initializer of the q6v5 common struct
> * @q6v5: handle to be initialized
> diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
> index 5a859c41896e..5025ffc4dbe8 100644
> --- a/drivers/remoteproc/qcom_q6v5.h
> +++ b/drivers/remoteproc/qcom_q6v5.h
> @@ -17,22 +17,26 @@ struct qcom_q6v5 {
> struct rproc *rproc;
>
> struct qcom_smem_state *state;
> + struct qcom_smem_state *ping_state;
> struct qmp *qmp;
>
> struct icc_path *path;
>
> unsigned stop_bit;
> + unsigned int ping_bit;
>
> int wdog_irq;
> int fatal_irq;
> int ready_irq;
> int handover_irq;
> int stop_irq;
> + int pong_irq;
>
> bool handover_issued;
>
> struct completion start_done;
> struct completion stop_done;
> + struct completion ping_done;
>
> int crash_reason;
>
> @@ -52,5 +56,7 @@ int qcom_q6v5_unprepare(struct qcom_q6v5 *q6v5);
> int qcom_q6v5_request_stop(struct qcom_q6v5 *q6v5, struct qcom_sysmon *sysmon);
> int qcom_q6v5_wait_for_start(struct qcom_q6v5 *q6v5, int timeout);
> unsigned long qcom_q6v5_panic(struct qcom_q6v5 *q6v5);
> +int qcom_q6v5_ping_subsystem(struct qcom_q6v5 *q6v5);
> +int qcom_q6v5_ping_subsystem_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev);
>
> #endif
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index da27d1d3c9da..34b54cf832d0 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -60,6 +60,7 @@ struct qcom_pas_data {
> int region_assign_count;
> bool region_assign_shared;
> int region_assign_vmid;
> + bool early_boot;
> };
>
> struct qcom_pas {
> @@ -423,9 +424,15 @@ static int qcom_pas_stop(struct rproc *rproc)
>
> qcom_pas_unmap_carveout(rproc, pas->mem_phys, pas->mem_size);
>
> - handover = qcom_q6v5_unprepare(&pas->q6v5);
> - if (handover)
> - qcom_pas_handover(&pas->q6v5);
> + /*
> + * qcom_q6v5_prepare is not called in qcom_pas_attach, skip unprepare to
> + * avoid mismatch.
> + */
> + if (pas->rproc->state != RPROC_ATTACHED) {
> + handover = qcom_q6v5_unprepare(&pas->q6v5);
> + if (handover)
> + qcom_pas_handover(&pas->q6v5);
> + }
>
> if (pas->smem_host_id)
> ret = qcom_smem_bust_hwspin_lock_by_host(pas->smem_host_id);
> @@ -510,6 +517,63 @@ static unsigned long qcom_pas_panic(struct rproc *rproc)
> return qcom_q6v5_panic(&pas->q6v5);
> }
>
> +static int qcom_pas_attach(struct rproc *rproc)
> +{
> + int ret;
> + struct qcom_pas *pas = rproc->priv;
> + bool ready_state;
> + bool crash_state;
> +
> + pas->q6v5.running = true;
> + ret = irq_get_irqchip_state(pas->q6v5.fatal_irq,
> + IRQCHIP_STATE_LINE_LEVEL, &crash_state);
> +
> + if (ret)
> + goto disable_running;
> +
> + if (crash_state) {
> + dev_err(pas->dev, "Subsystem has crashed before driver probe\n");
> + rproc_report_crash(rproc, RPROC_FATAL_ERROR);
> + ret = -EINVAL;
> + goto disable_running;
> + }
> +
> + ret = irq_get_irqchip_state(pas->q6v5.ready_irq,
> + IRQCHIP_STATE_LINE_LEVEL, &ready_state);
> +
> + if (ret)
> + goto disable_running;
> +
> + if (unlikely(!ready_state)) {
> + /*
> + * The bootloader may not support early boot, mark the state as
> + * RPROC_OFFLINE so that the PAS driver can load the firmware and
> + * start the remoteproc.
> + */
> + dev_err(pas->dev, "Failed to get subsystem ready interrupt\n");
> + pas->rproc->state = RPROC_OFFLINE;
> + ret = -EINVAL;
> + goto disable_running;
> + }
> +
> + ret = qcom_q6v5_ping_subsystem(&pas->q6v5);
> +
> + if (ret) {
> + dev_err(pas->dev, "Failed to ping subsystem, assuming device crashed\n");
> + rproc_report_crash(rproc, RPROC_FATAL_ERROR);
> + goto disable_running;
> + }
> +
> + pas->q6v5.handover_issued = true;
> +
> + return 0;
> +
> +disable_running:
> + pas->q6v5.running = false;
> +
> + return ret;
> +}
> +
> static const struct rproc_ops qcom_pas_ops = {
> .unprepare = qcom_pas_unprepare,
> .start = qcom_pas_start,
> @@ -518,6 +582,7 @@ static const struct rproc_ops qcom_pas_ops = {
> .parse_fw = qcom_pas_parse_firmware,
> .load = qcom_pas_load,
> .panic = qcom_pas_panic,
> + .attach = qcom_pas_attach,
Possible issue in the future here. The kaanapali_soccp_resource does not
set minidump_id, so this is not triggered today, but it is a latent bug
for any future device that sets both early_boot and minidump_id.
qcom_pas_attach is added to qcom_pas_ops but not to
qcom_pas_minidump_ops. When a device with minidump_id set uses the
minidump ops table, the .attach pointer is NULL. rproc_attach_device()
checks if (rproc->ops->attach) before calling it, so the attach callback
is silently skipped. For a device with early_boot = true and minidump_id
!= 0, the state is set to RPROC_DETACHED in probe, but the attach logic
(crash check, ready check, ping) is never executed, leaving the
subsystem in an inconsistent state.
Thanks,
Jie
> };
>
> static const struct rproc_ops qcom_pas_minidump_ops = {
> @@ -855,6 +920,15 @@ static int qcom_pas_probe(struct platform_device *pdev)
>
> pas->pas_ctx->use_tzmem = rproc->has_iommu;
> pas->dtb_pas_ctx->use_tzmem = rproc->has_iommu;
> +
> + if (desc->early_boot) {
> + ret = qcom_q6v5_ping_subsystem_init(&pas->q6v5, pdev);
> + if (ret)
> + dev_warn(&pdev->dev, "Falling back to firmware load\n");
> + else
> + pas->rproc->state = RPROC_DETACHED;
> + }
> +
> ret = rproc_add(rproc);
> if (ret)
> goto remove_ssr_sysmon;
>
^ permalink raw reply
* Re: [PATCH v2 02/13] ACPICA: Read LVR from the I2C resource descriptor
From: Akhil R @ 2026-04-11 5:41 UTC (permalink / raw)
To: rafael
Cc: acpica-devel, akhilrajeev, alexandre.belloni, conor+dt,
devicetree, ebiggers, frank.li, krzk+dt, lenb, linux-acpi,
linux-hwmon, linux-i3c, linux-kernel, linux, miquel.raynal,
p.zabel, robh, sakari.ailus, wsa+renesas
In-Reply-To: <CAJZ5v0jW9=VtjyjeoEDTm9hrGKP_BYUeuKCxcKoV-VsvM5otiA@mail.gmail.com>
On Fri, 10 Apr 2026 12:59:06 +0200, Rafael J. Wysocki wrote:
> On Fri, Apr 10, 2026 at 6:45 AM Akhil R <akhilrajeev@nvidia.com> wrote:
>>
>> On Thu, 9 Apr 2026 22:04:05 -0400, Frank Li wrote:
>>> On Thu, Apr 09, 2026 at 04:27:32PM +0530, Akhil R wrote:
>>>> ACPI 6.3 specifies byte 8 of I2C Serial Bus Connection descriptor to be
>>>> used for Legacy Virtual Register (LVR) data as specified in the MIPI
>>>> I3C Specification for an I2C device connected to an I3C Host Controller.
>>>> LVR will be read by I3C host controller drivers and it provides details
>>>> about the specific speed and 50ns spike filter capabilities of I2C
>>>> devices.
>>>>
>>>> Update the rsconvert_info to include this field. For I2C devices on an
>>>> I2C bus, this field is Reserved and unused.
>>>>
>>>> This commit is the result of squashing the following:
>>>> ACPICA commit 70082dc8fc847673ac7f4bbb1541776730f0b63e
>>>> ACPICA commit e62e74baf7e08cf059ec82049aeccd565b24d661
>>>> ACPICA commit c404118235108012cad396c834b5aabe2dd1b51a
>>>> ACPICA commit 7650d4a889ea7907060bfce89f4f780ce83e7b28
>>>> ACPICA commit 014fa9f2dbcc6b1bd42a4a4a6f6705d9cf7d460b
>>>
>>> These commit number is not existed at linus official tree. Please remove it.
>>
>> These are commits from ACPI-CA github. The files in the acpica folder is
>> a mirror of that repo. I suppose the commits in this folder are expected
>> to be structured like this. The process is also described here -
>> https://docs.kernel.org/driver-api/acpi/linuxized-acpica.html
>
> While the above is correct overall, it would also be sufficient to use
> Link: tags pointing to those commits.
Ack. I will drop the commit IDs in the next version.
Best Regards,
Akhil
^ permalink raw reply
* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Akhil R @ 2026-04-11 5:34 UTC (permalink / raw)
To: krzk
Cc: Frank.Li, acpica-devel, akhilrajeev, alexandre.belloni, conor+dt,
devicetree, ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon,
linux-i3c, linux-kernel, linux, miquel.raynal, p.zabel, rafael,
robh, sakari.ailus, wsa+renesas
In-Reply-To: <5c751739-5044-4d23-9648-8d46dd0945d1@kernel.org>
On Fri, 10 Apr 2026 11:57:11 +0200, Krzysztof Kozlowski wrote:
> On 10/04/2026 10:37, Akhil R wrote:
>> On Fri, 10 Apr 2026 09:18:48 +0200, Krzysztof Kozlowski wrote:
>>> On 10/04/2026 08:57, Guenter Roeck wrote:
>>>> On 4/9/26 23:39, Krzysztof Kozlowski wrote:
>>>>> On 09/04/2026 12:57, Akhil R wrote:
>>>>>> Add I3C subsystem support, DesignWare I3C master controller, and
>>>>>> SPD5118 hwmon sensor as modules to the defconfig and therefore
>>>>>> enable the support for SPD5118 sensor on SOCAMM found in NVIDIA
>>>>>> Vera platforms.
>>>>>
>>>>> git grep for "Vera" gave me zero results. Are you sure this is an
>>>>> upstream platform? Please point the DTS using this.
>>>>>
>>>>
>>>> I think this is an ACPI based system, or at least that is what Google search
>>>> tells me.
>>>
>>> Thanks. Following Google Vera is either a "CPU" or entire architecture
>>> (at least that's how they call it), so it does not have SPD5118 sensor.
>>
>> SOCAMM is a Memory Module. SPD5118, as it's Kconfig mentions, is a sensor
>> found within such memory modules. I didn't quite get why would you state
>> that the SOCAMM present in Vera architecture (or CPU) does not have
>> SPD5118 in it.
>
> I said that CPU or entire architecture does not have it.
>
> Commit is pretty vague in helping me to figure out the things I asked
> for in last email.
>
>
>>
>> Pasting the below from the Vera Rubin product page [1] -
>> "NVIDIA Vera CPUs add enhanced serviceability with small-outline
>> compression-attached memory modules (SOCAMM) LPDDR5X and in-system tests
>> for the CPU cores."
>>
>> [1]: https://www.nvidia.com/en-us/data-center/technologies/rubin/
>
> So this is for Vera Rubin? For what is this exactly?
SOCAMM is with the Vera CPU. Any Vera based platform would have this module.
Vera Rubin is one such platform.
SPD5118 is within the SOCAMM.
>
>>
>>>
>>>
>>> "Nvidia vera socamm" gives me something about "rubin". It's not me who
>>> should be guessing all this.
>>>
>>> "nvidia vera socamm SPD5118" gives me even less, so justification is flaky.
>>>
>>> To remind, this commit msg should convince why generic kernel for
>>> developers affecting all possible platforms - not end users, because
>>> they always use distro kernels - should enable these configs. And it
>>> should bring me clear rule what I can or cannot remove from defconfig,
>>> if in 2 years I come and start pruning it from symbols.
>>
>> I found little details on what we should be adding in the defconfig. It
>
> Then maybe we should not be adding it to defconfig?
>
> We usually do not make changes which we do not know why we are making
> them. IOW, every commit must be useful for the community and this is
> achieved by either explicit or implicit answer why doing this.
>
> And I gave in the past clear guidelines - this is config for the
> upstream kernel developers to use the upstream hardware and/or for
> distros to understand what is needed to support that upstream hardware
> (although last part in theory, because many distros do variantion of
> allmodconfig, so they don't really care about our defconfig).
>
>> would help if you could share some guidance. Do you mean to say that the
>> defconfig should include only the configs which are necessary in
>> development platforms and not in end-products?
>
> No, the type of product does not matter because upstream supports every
> type of product. Upstream does not say "oh, you run end-product, so we
> don't care about you". But defconfig is not used by endusers and has
> zero meaning to them.
>
> It seems to missed or ignored one more reason I wrote:
>
>>> And it
>>> should bring me clear rule what I can or cannot remove from defconfig,
>>> if in 2 years I come and start pruning it from symbols.
I am still a little confused on what information would likely accept (and
keep) these configs in the defconfig. Would updating the commit message
as below work?
"These configs enable the support for SPD5118 within the
Small-Outline-Compression-Attached Memory Modules (SOCAMM) LPDDR5X found
in the NVIDIA Vera CPUs. The Vera CPU uses ACPI and is part of platforms
such as Vera Rubin."
Regards,
Akhil
^ permalink raw reply
* Re: [PATCH v3 1/4] ARM: dts: qcom: msm8960: expressatt: Sort node references and includes
From: Rudraksha Gupta @ 2026-04-11 4:01 UTC (permalink / raw)
To: David Heidelberg, Krzysztof Kozlowski, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <eb1eebd2-75c0-4ffe-95e7-9f5d5d02edd1@ixit.cz>
On 4/7/26 14:46, David Heidelberg wrote:
> On 07/04/2026 23:04, Krzysztof Kozlowski wrote:
>> On 07/04/2026 22:39, Rudraksha Gupta wrote:
>>> On 4/7/26 12:59, Krzysztof Kozlowski wrote:
>>>> On 01/04/2026 22:32, Rudraksha Gupta via B4 Relay wrote:
>>>>> From: Rudraksha Gupta <guptarud@gmail.com>
>>>>>
>>>>> Reorganize the DTS file for consistency with other msm8960 board
>>>>> files.
>>>>>
>>>>> Assisted-by: Claude:claude-opus-4.6
>>>>> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
>>>>> ---
>>>>> .../dts/qcom/qcom-msm8960-samsung-expressatt.dts | 408
>>>>> +++++++++++----------
>>>>> 1 file changed, 207 insertions(+), 201 deletions(-)
>>>>>
>>>> Sorry, but no. We are not taking Claude as one determining coding
>>>> style.
>>>> Are we going to do the work again the moment we come with proper tool?
>>>
>>> There is no tool currently to auto format DTS, and doesn't seem to be
>>> coming for a while:
>>>
>>> https://www.youtube.com/watch?v=cvoIbTL_ZQA
>>>
>>>
>>> Claude didn't determine the coding style. I did based on sony-huashan,
>>> which is already upstream:
>>>
>>> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/qcom/qcom-msm8960-sony-huashan.dts
>>>
>>>
>>>
>>> I just used Claude to do the manual work for me. In v2, I made sure the
>>> diff before and after the change was nill. v3 included additional
>>> changes requested by Konrad and some comments that I remembered during
>>> prior attempts mainlining patch series for this device.
>>
>> IMO, it is just too risky to let Claude reorganize the nodes, but I
>> assume reviewers of your code did run dtx_diff.
>
> I think it depends on the prompt. Since I’m performing many of the
> same tasks repeatedly across multiple sdm845 devices, asking an LLM to
> do node-by-node reorganization can be reasonably reviewable (at least
> when reviewing incremental progress, not just the final diff).
>
> I would prefer to do more of the sorting myself, but I find it quite
> tedious. The diff tool struggles when similar or identical lines
> appear in different nodes, which often results in a messy final diff
> (I noticed this in Sajattack’s sdm845 LG patchset).
>
> This leads me to an idea:
>
> For these sorting cleanups, perhaps we could introduce a “squash mode”?
>
> Contributors could submit commits per node, making the reorganization
> clearly visible (and ensuring nothing is accidentally lost), and then
> the maintainer could squash them into a single commit to avoid
> cluttering the git log.
>
> What do you think?
Easiest solution would be to get Claude to make a DTS auto formatter. I
estimate it would likely take a couple iterations to get a functional
prototype and max a week to get it into a mergable state, if the style
is agreed beforehand. Simply provide DTS'es that follow the pattern you
like to Claude, then tell Claude that you want to make a Python script
to auto format DTS files and make functions for each different common
style pattern identified in the DTS'es. I assume it would give a good
enough base to work off of. The most painful part will be determining
what the correct style for all DTS'es as I'm sure others will have
opinions on that.
^ permalink raw reply
* Re: [PATCH v5 4/5] remoteproc: qcom: pas: Add late attach support for subsystems
From: Bjorn Andersson @ 2026-04-11 3:04 UTC (permalink / raw)
To: Jingyi Wang
Cc: Mathieu Poirier, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Manivannan Sadhasivam, Luca Weiss, Bartosz Golaszewski,
Konrad Dybcio, aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel,
Gokul Krishna Krishnakumar
In-Reply-To: <20260409-knp-soccp-v5-4-805a492124da@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 01:52:27AM -0700, Jingyi Wang wrote:
[..]
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index da27d1d3c9da..34b54cf832d0 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -60,6 +60,7 @@ struct qcom_pas_data {
> int region_assign_count;
> bool region_assign_shared;
> int region_assign_vmid;
> + bool early_boot;
> };
>
> struct qcom_pas {
> @@ -423,9 +424,15 @@ static int qcom_pas_stop(struct rproc *rproc)
>
> qcom_pas_unmap_carveout(rproc, pas->mem_phys, pas->mem_size);
>
> - handover = qcom_q6v5_unprepare(&pas->q6v5);
> - if (handover)
> - qcom_pas_handover(&pas->q6v5);
> + /*
> + * qcom_q6v5_prepare is not called in qcom_pas_attach, skip unprepare to
> + * avoid mismatch.
Can you confirm that no load_state should be sent to AOSS for SoCCP?
(I.e. from the skipped qcom_q6v5_prepare())
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v5 5/5] remoteproc: qcom_q6v5_pas: Add SoCCP node on Kaanapali
From: Bjorn Andersson @ 2026-04-11 3:01 UTC (permalink / raw)
To: Jingyi Wang
Cc: Mathieu Poirier, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Manivannan Sadhasivam, Luca Weiss, Bartosz Golaszewski,
Konrad Dybcio, aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel,
Dmitry Baryshkov
In-Reply-To: <20260409-knp-soccp-v5-5-805a492124da@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 01:52:28AM -0700, Jingyi Wang wrote:
> The SoC Control Processor (SoCCP) is small RISC-V MCU that controls
> USB Type-C, battery charging and various other functions on Qualcomm SoCs.
> It provides a solution for control-plane processing, reducing per-subsystem
> microcontroller reinvention. Add support for SoCCP PAS loader on Kaanapali
> platform.
>
Very nice commit message.
(Patch looks good as well)
Thank you,
Bjorn
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
> drivers/remoteproc/qcom_q6v5_pas.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index 34b54cf832d0..1c81f22438cc 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -1604,8 +1604,26 @@ static const struct qcom_pas_data sm8750_mpss_resource = {
> .region_assign_vmid = QCOM_SCM_VMID_MSS_MSA,
> };
>
> +static const struct qcom_pas_data kaanapali_soccp_resource = {
> + .crash_reason_smem = 656,
> + .firmware_name = "soccp.mbn",
> + .dtb_firmware_name = "soccp_dtb.mbn",
> + .pas_id = 51,
> + .dtb_pas_id = 0x41,
> + .proxy_pd_names = (char*[]){
> + "cx",
> + "mx",
> + NULL
> + },
> + .ssr_name = "soccp",
> + .sysmon_name = "soccp",
> + .auto_boot = true,
> + .early_boot = true,
> +};
> +
> static const struct of_device_id qcom_pas_of_match[] = {
> { .compatible = "qcom,eliza-adsp-pas", .data = &sm8550_adsp_resource },
> + { .compatible = "qcom,kaanapali-soccp-pas", .data = &kaanapali_soccp_resource },
> { .compatible = "qcom,milos-adsp-pas", .data = &sm8550_adsp_resource },
> { .compatible = "qcom,milos-cdsp-pas", .data = &milos_cdsp_resource },
> { .compatible = "qcom,milos-mpss-pas", .data = &sm8450_mpss_resource },
>
> --
> 2.34.1
>
^ permalink raw reply
* RE: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Peng Fan @ 2026-04-11 3:00 UTC (permalink / raw)
To: Mathieu Poirier, Peng Fan (OSS)
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, linux-remoteproc@vger.kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <adkcugNgyrkHtUML@p14s>
> Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to
> SM CPU/LMM reset vector
>
> On Thu, Apr 09, 2026 at 08:30:54AM +0800, Peng Fan wrote:
> > On Wed, Apr 08, 2026 at 09:46:32AM -0600, Mathieu Poirier wrote:
> > >On Wed, Apr 08, 2026 at 01:30:16AM +0000, Peng Fan wrote:
> > >> > Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass
> bootaddr
> > >> > to SM CPU/LMM reset vector
> > >> >
> > >> [...]
> > >> >
> > >> > >
> > >> > > Aligning the ELF entry point with the hardware reset base on
> > >> > Cortex‑M
> > >> > > systems is possible, but it comes with several risks.
> > >> >
> > >> > I'm not asking to align the ELF entry point with the hardware
> reset base.
> > >> > All I want is to have the correct start address embedded in the
> > >> > ELF file to avoid having to use a mask.
> > >>
> > >> I see, per my understanding:
> > >> FreeRTOS typically exposes __isr_vector, which corresponds to the
> > >> hardware reset / vector table base.
> > >> Zephyr (Cortex‑M) exposes _vector_table, which serves the same
> purpose.
> > >> I am not certain about other RTOSes, but the pattern seems
> consistent:
> > >> the vector table base is already available as a named ELF symbol.
> > >>
> > >> Given that, if the preferred approach is to parse the ELF and
> > >> explicitly retrieve the hardware reset base, I can update the
> implementation accordingly.
> > >> If you prefer to parse the elf file to get the hardware reset base,
> > >> I could update to use them.
> > >>
> > >> Options1: Something as below:
> > >> 1. Include rproc_elf_find_symbol in remoteproc_elf_loader.c 2.
> Use
> > >> below in imx_rproc.c ret = rproc_elf_find_symbol(rproc, fw,
> > >> "__isr_vector", &vector_base); if (ret)
> > >> ret = rproc_elf_find_symbol(rproc, fw, "__vector_table",
> > >> &vector_base);
> > >>
> > >> if (!ret)
> > >> rproc->bootaddr = vector_base
> > >> else
> > >> dev_info(dev, "no __isr_vector or __vector_table\n")
> > >
> > >No
> >
> > If your concern is about rproc->bootaddr, I could introduce
> > imx_rproc->vector_base for i.MX. Please help detail a bit.
> >
> > >
> > >>
> > >> This makes the hardware reset base explicit, avoids masking
> e_entry.
> > >>
> > >> Option 2: User‑provided reset symbol via sysfs As an alternative,
> > >> we could expose a sysfs attribute, e.g. reset_symbol, allowing
> > >> users to specify the symbol name to be used as the reset base:
> > >>
> > >> echo __isr_vector >
> /sys/class/remoteproc/remoteprocX/reset_symbol
> > >>
> > >
> > >Definitely not.
> > >
> > >The definition of e_entry in the specification is clear, i.e "the
> > >address of the entry point from where the process starts executing".
> > >If masking is required because the tool that puts the image together
> > >gets the wrong address, then it should be fixed.
> >
> > The hardware reset base is the address from which the hardware
> fetches
> > the initial stack pointer and program counter values and loads them
> > into the SP and PC registers. In contrast, bootaddr (i.e. e_entry)
> > represents the address at which the CPU starts executing code (the
> PC
> > value after reset). As you pointed out earlier, this distinction is clear.
> >
> > In our case, we need to obtain the hardware reset base and pass that
> > value to the system firmware. However, e_entry should not be set to
> > the hardware reset base. Doing so would introduce the issues I
> > described in [1]. This means we should not modify the Zephyr or
> > FreeRTOS build outputs to make e_entry equal to the hardware reset
> base.
>
>
> As I said earlier, I am _not_ suggesting to make e_entry equal to the
> hardware reset base.
Let me try to restate my understanding more precisely and please
correct me if I am still missing the point.
From your comment:
"
If masking is required because the tool that puts the image together gets the
wrong address, then it should be fixed.
"
I understand this as saying that masking e_entry is not acceptable, because
e_entry already has a clear and correct meaning: it is the execution entry
address, and the kernel should not reinterpret or “fix up” that value.
At the same time, we still need to provide the hardware reset vector base
to the system firmware, and that value is distinct from e_entry.
On i.MX94/5 platforms the reset base is software‑programmable, but that
information is not represented by e_entry, nor is there currently a
separate place in the remoteproc framework to convey a reset‑vector
base independent of the execution entry point.
Given these constraints, I see limited options on the kernel side.
One conservative approach would be to rely on a fixed, platform‑defined
reset base for the affected SoCs. And update RTOS linking script to put
the vector to the location of fixed hardware reset base.
Thanks,
Peng
>
> We are going in circles here.
>
> >
> > Given these constraints, the feasible solutions I can see are either:
> > - option 1 (explicitly retrieving the hardware reset base), or
> > - continuing to use masking.
> >
> > Please suggest.
> >
> > [1]
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> lore
> > .kernel.org%2Fall%2Facs2PAZq2k3zjmDW%40shlinux89%2F&data=0
> 5%7C02%7Cpen
> >
> g.fan%40nxp.com%7C8a5ce35d492b4adb2d3b08de97192cbb%7C686
> ea1d3bc2b4c6fa
> >
> 92cd99c5c301635%7C0%7C0%7C639114331565834960%7CUnknow
> n%7CTWFpbGZsb3d8e
> >
> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI
> kFOIjoiTWF
> >
> pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Pnkirz3BMEuLsJU9
> MHQNon84HIyMX
> > 08x1wCK04dS7VU%3D&reserved=0
> >
> > Thanks,
> > Peng
> >
> > >
> > >> The remoteproc core would then resolve that symbol from the ELF
> and
> > >> set rproc->bootaddr accordingly.
> > >> This provides maximum flexibility but does introduce a new
> > >> user‑visible ABI, so I see it more as an opt‑in or fallback
> mechanism.
> > >>
> > >> Please let me know which approach you prefer, and I will update
> > >> this series accordingly in v3..
> > >>
> > >> Thanks,
> > >> Peng.
> > >>
> > >>
> > >> >
> > >> > > 1, Semantic mismatch (ELF vs. hardware behavior) 2,
> Debuggers
> > >> > > may attempt to set breakpoints or start execution at the entry
> > >> > > symbol
> > >> > >
^ permalink raw reply
* Re: [PATCH v5 4/5] remoteproc: qcom: pas: Add late attach support for subsystems
From: Bjorn Andersson @ 2026-04-11 2:59 UTC (permalink / raw)
To: Jingyi Wang
Cc: Mathieu Poirier, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Manivannan Sadhasivam, Luca Weiss, Bartosz Golaszewski,
Konrad Dybcio, aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel,
Gokul Krishna Krishnakumar
In-Reply-To: <20260409-knp-soccp-v5-4-805a492124da@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 01:52:27AM -0700, Jingyi Wang wrote:
> Subsystems can be brought out of reset by entities such as bootloaders.
> As the irq enablement could be later than subsystem bring up, the state
> of subsystem should be checked by reading SMP2P bits and performing ping
> test.
>
I still don't understand.
Are you saying that devm_request_threaded_irq() will succeed and then
calling irq_get_irqchip_state() will not work? Or are you saying that
SMP2P driver isn't reliable and we're loosing the ready or fatal bits?
In the reply to v4 you replied to me with "it's a downstream feature".
That isn't a reason for performing this extra dance, either downstream
or upstream.
> A new qcom_pas_attach() function is introduced. if a crash state is
> detected for the subsystem, rproc_report_crash() is called. If the
> subsystem is ready and the ping is successful, it will be marked as
> "attached". If ready irq is not received, it could be the early boot
> feature is not supported by other entities. In this case, the state will
> be marked as RPROC_OFFLINE so that the PAS driver can load the firmware
> and start the remoteproc.
>
> Co-developed-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
> Signed-off-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
> drivers/remoteproc/qcom_q6v5.c | 69 ++++++++++++++++++++++++++++++++
> drivers/remoteproc/qcom_q6v5.h | 6 +++
> drivers/remoteproc/qcom_q6v5_pas.c | 80 ++++++++++++++++++++++++++++++++++++--
> 3 files changed, 152 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
> index 58d5b85e58cd..52247c17c38a 100644
> --- a/drivers/remoteproc/qcom_q6v5.c
> +++ b/drivers/remoteproc/qcom_q6v5.c
> @@ -20,6 +20,7 @@
>
> #define Q6V5_LOAD_STATE_MSG_LEN 64
> #define Q6V5_PANIC_DELAY_MS 200
> +#define Q6V5_PING_TIMEOUT_MS 500
Changelog says you removed 5 second timeout, but you only removed 4.5
seconds.
Regards,
Bjorn
>
> static int q6v5_load_state_toggle(struct qcom_q6v5 *q6v5, bool enable)
> {
> @@ -234,6 +235,74 @@ unsigned long qcom_q6v5_panic(struct qcom_q6v5 *q6v5)
> }
> EXPORT_SYMBOL_GPL(qcom_q6v5_panic);
>
> +static irqreturn_t q6v5_pong_interrupt(int irq, void *data)
> +{
> + struct qcom_q6v5 *q6v5 = data;
> +
> + complete(&q6v5->ping_done);
> +
> + return IRQ_HANDLED;
> +}
> +
> +int qcom_q6v5_ping_subsystem(struct qcom_q6v5 *q6v5)
> +{
> + int ret;
> + int ping_failed = 0;
> +
> + reinit_completion(&q6v5->ping_done);
> +
> + /* Set master kernel Ping bit */
> + ret = qcom_smem_state_update_bits(q6v5->ping_state,
> + BIT(q6v5->ping_bit), BIT(q6v5->ping_bit));
> + if (ret) {
> + dev_err(q6v5->dev, "Failed to update ping bits\n");
> + return ret;
> + }
> +
> + ret = wait_for_completion_timeout(&q6v5->ping_done, msecs_to_jiffies(Q6V5_PING_TIMEOUT_MS));
> + if (!ret) {
> + ping_failed = -ETIMEDOUT;
> + dev_err(q6v5->dev, "Failed to get back pong\n");
> + }
> +
> + /* Clear ping bit master kernel */
> + ret = qcom_smem_state_update_bits(q6v5->ping_state, BIT(q6v5->ping_bit), 0);
> + if (ret) {
> + dev_err(q6v5->dev, "Failed to clear master kernel bits\n");
> + return ret;
> + }
> +
> + return ping_failed;
> +}
> +EXPORT_SYMBOL_GPL(qcom_q6v5_ping_subsystem);
> +
> +int qcom_q6v5_ping_subsystem_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev)
> +{
> + int ret = -ENODEV;
> +
> + q6v5->ping_state = devm_qcom_smem_state_get(&pdev->dev, "ping", &q6v5->ping_bit);
> + if (IS_ERR(q6v5->ping_state)) {
> + dev_err(&pdev->dev, "Failed to acquire smem state %ld\n",
> + PTR_ERR(q6v5->ping_state));
> + return PTR_ERR(q6v5->ping_state);
> + }
> +
> + init_completion(&q6v5->ping_done);
> +
> + q6v5->pong_irq = platform_get_irq_byname(pdev, "pong");
> + if (q6v5->pong_irq < 0)
> + return q6v5->pong_irq;
> +
> + ret = devm_request_threaded_irq(&pdev->dev, q6v5->pong_irq, NULL,
> + q6v5_pong_interrupt, IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> + "q6v5 pong", q6v5);
> + if (ret)
> + dev_err(&pdev->dev, "Failed to acquire pong IRQ\n");
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(qcom_q6v5_ping_subsystem_init);
> +
> /**
> * qcom_q6v5_init() - initializer of the q6v5 common struct
> * @q6v5: handle to be initialized
> diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
> index 5a859c41896e..5025ffc4dbe8 100644
> --- a/drivers/remoteproc/qcom_q6v5.h
> +++ b/drivers/remoteproc/qcom_q6v5.h
> @@ -17,22 +17,26 @@ struct qcom_q6v5 {
> struct rproc *rproc;
>
> struct qcom_smem_state *state;
> + struct qcom_smem_state *ping_state;
> struct qmp *qmp;
>
> struct icc_path *path;
>
> unsigned stop_bit;
> + unsigned int ping_bit;
>
> int wdog_irq;
> int fatal_irq;
> int ready_irq;
> int handover_irq;
> int stop_irq;
> + int pong_irq;
>
> bool handover_issued;
>
> struct completion start_done;
> struct completion stop_done;
> + struct completion ping_done;
>
> int crash_reason;
>
> @@ -52,5 +56,7 @@ int qcom_q6v5_unprepare(struct qcom_q6v5 *q6v5);
> int qcom_q6v5_request_stop(struct qcom_q6v5 *q6v5, struct qcom_sysmon *sysmon);
> int qcom_q6v5_wait_for_start(struct qcom_q6v5 *q6v5, int timeout);
> unsigned long qcom_q6v5_panic(struct qcom_q6v5 *q6v5);
> +int qcom_q6v5_ping_subsystem(struct qcom_q6v5 *q6v5);
> +int qcom_q6v5_ping_subsystem_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev);
>
> #endif
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index da27d1d3c9da..34b54cf832d0 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -60,6 +60,7 @@ struct qcom_pas_data {
> int region_assign_count;
> bool region_assign_shared;
> int region_assign_vmid;
> + bool early_boot;
> };
>
> struct qcom_pas {
> @@ -423,9 +424,15 @@ static int qcom_pas_stop(struct rproc *rproc)
>
> qcom_pas_unmap_carveout(rproc, pas->mem_phys, pas->mem_size);
>
> - handover = qcom_q6v5_unprepare(&pas->q6v5);
> - if (handover)
> - qcom_pas_handover(&pas->q6v5);
> + /*
> + * qcom_q6v5_prepare is not called in qcom_pas_attach, skip unprepare to
> + * avoid mismatch.
> + */
> + if (pas->rproc->state != RPROC_ATTACHED) {
> + handover = qcom_q6v5_unprepare(&pas->q6v5);
> + if (handover)
> + qcom_pas_handover(&pas->q6v5);
> + }
>
> if (pas->smem_host_id)
> ret = qcom_smem_bust_hwspin_lock_by_host(pas->smem_host_id);
> @@ -510,6 +517,63 @@ static unsigned long qcom_pas_panic(struct rproc *rproc)
> return qcom_q6v5_panic(&pas->q6v5);
> }
>
> +static int qcom_pas_attach(struct rproc *rproc)
> +{
> + int ret;
> + struct qcom_pas *pas = rproc->priv;
> + bool ready_state;
> + bool crash_state;
> +
> + pas->q6v5.running = true;
> + ret = irq_get_irqchip_state(pas->q6v5.fatal_irq,
> + IRQCHIP_STATE_LINE_LEVEL, &crash_state);
> +
> + if (ret)
> + goto disable_running;
> +
> + if (crash_state) {
> + dev_err(pas->dev, "Subsystem has crashed before driver probe\n");
> + rproc_report_crash(rproc, RPROC_FATAL_ERROR);
> + ret = -EINVAL;
> + goto disable_running;
> + }
> +
> + ret = irq_get_irqchip_state(pas->q6v5.ready_irq,
> + IRQCHIP_STATE_LINE_LEVEL, &ready_state);
> +
> + if (ret)
> + goto disable_running;
> +
> + if (unlikely(!ready_state)) {
> + /*
> + * The bootloader may not support early boot, mark the state as
> + * RPROC_OFFLINE so that the PAS driver can load the firmware and
> + * start the remoteproc.
> + */
> + dev_err(pas->dev, "Failed to get subsystem ready interrupt\n");
> + pas->rproc->state = RPROC_OFFLINE;
> + ret = -EINVAL;
> + goto disable_running;
> + }
> +
> + ret = qcom_q6v5_ping_subsystem(&pas->q6v5);
> +
> + if (ret) {
> + dev_err(pas->dev, "Failed to ping subsystem, assuming device crashed\n");
> + rproc_report_crash(rproc, RPROC_FATAL_ERROR);
> + goto disable_running;
> + }
> +
> + pas->q6v5.handover_issued = true;
> +
> + return 0;
> +
> +disable_running:
> + pas->q6v5.running = false;
> +
> + return ret;
> +}
> +
> static const struct rproc_ops qcom_pas_ops = {
> .unprepare = qcom_pas_unprepare,
> .start = qcom_pas_start,
> @@ -518,6 +582,7 @@ static const struct rproc_ops qcom_pas_ops = {
> .parse_fw = qcom_pas_parse_firmware,
> .load = qcom_pas_load,
> .panic = qcom_pas_panic,
> + .attach = qcom_pas_attach,
> };
>
> static const struct rproc_ops qcom_pas_minidump_ops = {
> @@ -855,6 +920,15 @@ static int qcom_pas_probe(struct platform_device *pdev)
>
> pas->pas_ctx->use_tzmem = rproc->has_iommu;
> pas->dtb_pas_ctx->use_tzmem = rproc->has_iommu;
> +
> + if (desc->early_boot) {
> + ret = qcom_q6v5_ping_subsystem_init(&pas->q6v5, pdev);
> + if (ret)
> + dev_warn(&pdev->dev, "Falling back to firmware load\n");
> + else
> + pas->rproc->state = RPROC_DETACHED;
> + }
> +
> ret = rproc_add(rproc);
> if (ret)
> goto remove_ssr_sysmon;
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v3] Add remoteproc PAS loader for SoCCP on Glymur DT
From: Bjorn Andersson @ 2026-04-11 2:52 UTC (permalink / raw)
To: Ananthu C V
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, Sibi Sankar
In-Reply-To: <20260403-glymur-soccp-v3-1-f0e8d57f11ba@oss.qualcomm.com>
On Fri, Apr 03, 2026 at 04:39:05AM -0700, Ananthu C V wrote:
> From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>
Your commit is lacking both subject prefix and commit message.
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> Co-developed-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> ---
v3? Where is the changelog?
> arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 7 +++++
> arch/arm64/boot/dts/qcom/glymur.dtsi | 47 ++++++++++++++++++++++++++++++++
> 2 files changed, 54 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> index 2852d257ac8c..3fdf8dbbde02 100644
> --- a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> @@ -560,6 +560,13 @@ &pon_resin {
> status = "okay";
> };
>
> +&remoteproc_soccp {
> + firmware-name = "qcom/glymur/soccp.mbn",
> + "qcom/glymur/soccp_dtb.mbn";
> +
> + status = "okay";
> +};
> +
> &tlmm {
> gpio-reserved-ranges = <4 4>, /* EC TZ Secure I3C */
> <10 2>, /* OOB UART */
> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> index f23cf81ddb77..f7f3374a5e08 100644
> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> @@ -2264,6 +2264,53 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
> };
> };
>
> + remoteproc_soccp: remoteproc-soccp@d00000 {
Isn't remoteproc@ sufficient?
> + compatible = "qcom,glymur-soccp-pas", "qcom,kaanapali-soccp-pas";
This binding hasn't been merged, and yet you don't mention that this
can't be merged?
> + reg = <0x0 0x00d00000 0x0 0x200000>;
> +
> + interrupts-extended = <&intc GIC_SPI 167 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 9 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "wdog",
> + "fatal",
> + "ready",
> + "handover",
> + "stop-ack",
> + "pong";
> +
> + clocks = <&rpmhcc RPMH_CXO_CLK>;
> + clock-names = "xo";
> +
> + power-domains = <&rpmhpd RPMHPD_CX>,
> + <&rpmhpd RPMHPD_MX>;
> + power-domain-names = "cx",
> + "mx";
> +
> + memory-region = <&soccp_mem>,
> + <&soccpdtb_mem>;
> +
> + qcom,smem-states = <&soccp_smp2p_out 0>,
> + <&soccp_smp2p_out 8>;
> + qcom,smem-state-names = "stop",
> + "ping";
> +
> + status = "disabled";
> +
> + glink-edge {
> + interrupts-extended = <&ipcc IPCC_MPROC_SOCCP
> + IPCC_MPROC_SIGNAL_GLINK_QMP
> + IRQ_TYPE_EDGE_RISING>;
> + mboxes = <&ipcc IPCC_MPROC_SOCCP
> + IPCC_MPROC_SIGNAL_GLINK_QMP>;
> + qcom,remote-pid = <19>;
> + label = "soccp";
> +
> + };
> + };
> +
> usb_hs_phy: phy@fa0000 {
> compatible = "qcom,glymur-m31-eusb2-phy",
> "qcom,sm8750-m31-eusb2-phy";
>
> ---
> base-commit: bd0f139e5fc11182777b81cefc3893ea508544ec
> change-id: 20260403-glymur-soccp-2ca25f3b30e2
> prerequisite-message-id: <20260326-knp-soccp-dt-v1-0-a60c2ae36e9b@oss.qualcomm.com>
> prerequisite-patch-id: fa390011ee531589a7ad14250d158f497622efbd
> prerequisite-patch-id: 93e7fca58a5c06edefa624ec2b006dd80f4749a8
> prerequisite-patch-id: 99a3b6a7fcd061267b40097ad25f652ebe0a4c7b
Why isn't this list empty?
Regards,
Bjorn
>
> Best regards,
> --
> Ananthu C V <ananthu.cv@oss.qualcomm.com>
>
^ permalink raw reply
* Re: [PATCH 00/35] irqchip/qcom-pdc: Clean up register mapping and DT descriptions
From: Bjorn Andersson @ 2026-04-11 2:48 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, cros-qcom-dts-watchers, linux-arm-msm,
linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-1-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:37AM +0530, Mukesh Ojha wrote:
> The Qualcomm PDC (Power Domain Controller) hardware exposes multiple DRV
> (Driver) regions, each 0x10000 bytes in size, where each region serves a
> specific client in the system . Linux only needs access to the APSS DRV
> region.
>
> Despite this, the driver was mapping up to 0x30000 bytes (three DRV
> regions) via a QCOM_PDC_SIZE clamp introduced as a workaround for old
> sm8150 DTs that described a too-small register window. Correspondingly,
> most platform DTS files described the PDC reg as 0x30000 in size, and
> several also carried a second, entirely unused reg entry pointing at an
> unrelated register region that the driver never maps.
>
> This series cleans all of that up in three logical steps:
>
> 1. (patches 2-6):
>
These patches are for the IRQ subsystem/maintainer.
> Split __pdc_enable_intr() into two focused per-version helpers
> to separate the HW < 3.2 bank-based path from the HW >= 3.2 per-pin
> path. Replace the pdc_version global with a function pointer assigned
> once at probe time, moving the version check out of the hot path.
> Tighten the ioremap clamp from QCOM_PDC_SIZE (0x30000) to PDC_DRV_SIZE
> (0x10000) now that the DT fixes below make the workaround unnecessary.
> Also add a PDC_VERSION() constructor macro and use FIELD_GET() for bank
> index extraction to make the bit encoding self-documenting.
>
> 2. (patches 1, 7-28):
>
And these patches are for the Qualcomm SoC/DT tree.
> All 28 platform DTS files that described the PDC reg window as 0x30000
> are corrected to 0x10000, reflecting the single APSS DRV region that
> Linux actually maps.
>
> 3. (patches 29-35):
>
Same with these.
I don't see any dependencies between the IRQ and DT patches, can they be
merged independently? Why did you send them together?
Regards,
Bjorn
> Seven platform DTS files (kaanapali, lemans, milos, monaco, sc8280xp,
> sdx75, talos) carried a second reg entry pointing at an unrelated
> hardware block. The driver only ever calls of_address_to_resource(node,
> 0, ...) so this second entry was never mapped or accessed. Remove it.
>
> The net result is that every PDC node in the tree now describes exactly
> one register region of exactly 0x10000 bytes — the APSS DRV region that
> the driver actually uses — and the driver's ioremap clamp matches that
> reality.
>
> Mukesh Ojha (35):
> dt-bindings: qcom,pdc: Tighten reg to single APSS DRV region
> irqchip/qcom-pdc: Split __pdc_enable_intr() into per-version helpers
> irqchip/qcom-pdc: Tighten ioremap clamp to single DRV region size
> irqchip/qcom-pdc: Replace pdc_version global with a function pointer
> irqchip/qcom-pdc: Add PDC_VERSION() macro to describe version register
> fields
> irqchip/qcom-pdc: Use FIELD_GET() to extract bank index and bit
> position
> arm64: dts: qcom: sdm845: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sdm670: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sc7180: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sc7280: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sc8180x: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sm8150: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sc8280xp: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sm8250: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sm8350: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sm8450: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sm8550: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sm8650: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sm4450: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: x1e80100: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sm6350: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sar2130p: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: qcs615: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: qcs8300: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sa8775p: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: sdx75: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: milos: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: qdu1000: Fix PDC reg size to single APSS DRV region
> arm64: dts: qcom: kaanapali: Drop unused second PDC reg entry
> arm64: dts: qcom: lemans: Drop unused second PDC reg entry
> arm64: dts: qcom: milos: Drop unused second PDC reg entry
> arm64: dts: qcom: monaco: Drop unused second PDC reg entry
> arm64: dts: qcom: sc8280xp: Drop unused second PDC reg entry
> arm64: dts: qcom: sdx75: Drop unused second PDC reg entry
> arm64: dts: qcom: talos: Drop unused second PDC reg entry
>
> .../interrupt-controller/qcom,pdc.yaml | 2 +-
> arch/arm64/boot/dts/qcom/hamoa.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/kaanapali.dtsi | 3 +-
> arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/lemans.dtsi | 3 +-
> arch/arm64/boot/dts/qcom/milos.dtsi | 3 +-
> arch/arm64/boot/dts/qcom/monaco.dtsi | 3 +-
> arch/arm64/boot/dts/qcom/qdu1000.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sar2130p.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sc8180x.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sdm670.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sdx75.dtsi | 3 +-
> arch/arm64/boot/dts/qcom/sm4450.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sm6350.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sm8450.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sm8550.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sm8650.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/talos.dtsi | 3 +-
> drivers/irqchip/qcom-pdc.c | 56 +++++++++++--------
> 25 files changed, 57 insertions(+), 53 deletions(-)
>
> --
> 2.53.0
>
^ permalink raw reply
* [PATCH v6 3/3] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: dennis @ 2026-04-11 2:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Dennis Gilmore, Michael Riesch,
Mykola Kvach, Jimmy Hon, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260411024743.195385-1-dennis@ausil.us>
From: Dennis Gilmore <dennis@ausil.us>
Add device tree for the Xunlong Orange Pi 5 Pro (RK3588S).
- eMMC module, you can optionally solder a SPI NOR in place and turn
off the eMMC
- PCIe-attached NIC (pcie2x1l1)
- PCIe NVMe slot (pcie2x1l2)
- AP6256 WiFi (BCM43456) via SDIO with mmc-pwrseq
- BCM4345C5 Bluetooth
- es8388 audio
- USB 2.0 and USB 3.0
- Two HDMI ports, the second is connected to the SoC's DP controller
driven by a transparent LT8711UXD bridge that has firmware onboard and
needs no node defined.
Vendors description and links to schematics available:
http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-Pro.html
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../display/rockchip/rockchip,dw-dp.yaml | 7 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 352 ++++++++++++++++++
drivers/gpu/drm/bridge/synopsys/dw-dp.c | 12 +
4 files changed, 372 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
index 6345f0132d43..079a912d97f1 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
@@ -57,6 +57,13 @@ properties:
- const: i2s
- const: spdif
+ hpd-gpios:
+ maxItems: 1
+ description:
+ GPIO used for hot plug detection when the controller's native HPD
+ input is not connected. If not specified, the controller uses its
+ internal HPD detection mechanism.
+
phys:
maxItems: 1
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 4d384f153c13..c99dca2ae9e7 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -214,6 +214,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-odroid-m2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5b.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5-pro.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-cm5-base.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-radxa-cm5-io.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-roc-pc.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
new file mode 100644
index 000000000000..84c83aa69f63
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
@@ -0,0 +1,352 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3588s-orangepi-5.dtsi"
+
+/ {
+ model = "Xunlong Orange Pi 5 Pro";
+ compatible = "xunlong,orangepi-5-pro", "rockchip,rk3588s";
+
+ aliases {
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc;
+ mmc2 = &sdio;
+ };
+
+ dp-con {
+ compatible = "dp-connector";
+
+ port {
+ dp_con_in: endpoint {
+ remote-endpoint = <&dp0_out_con>;
+ };
+ };
+ };
+
+ analog-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_detect>;
+ simple-audio-card,bitclock-master = <&masterdai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&masterdai>;
+ simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "rockchip,es8388";
+ simple-audio-card,routing =
+ "Headphones", "LOUT1",
+ "Headphones", "ROUT1",
+ "LINPUT1", "Microphone Jack",
+ "RINPUT1", "Microphone Jack",
+ "LINPUT2", "Onboard Microphone",
+ "RINPUT2", "Onboard Microphone";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Onboard Microphone",
+ "Headphone", "Headphones";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s2_2ch>;
+ };
+
+ masterdai: simple-audio-card,codec {
+ sound-dai = <&es8388>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ led-0 {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm15 0 1000000 0>;
+ };
+
+ led-1 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_ACTIVITY;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm3 0 1000000 0>;
+ };
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ #cooling-cells = <2>;
+ cooling-levels = <0 50 100 150 200 255>;
+ fan-supply = <&vcc5v0_sys>;
+ pwms = <&pwm2 0 20000000 0>;
+ };
+
+ vcc3v3_dp: regulator-vcc3v3-dp {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "vcc3v3_dp";
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ vcc3v3_phy1: regulator-vcc3v3-phy1 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
+ regulator-boot-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "vcc3v3_phy1";
+ startup-delay-us = <50000>;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ vcc5v0_otg: regulator-vcc5v0-otg {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_otg_en>;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ regulator-name = "vcc5v0_otg";
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&hym8563>;
+ clock-names = "ext_clock";
+ post-power-on-delay-ms = <200>;
+ reset-gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_LOW>;
+ };
+
+ typea_con: usb-a-connector {
+ compatible = "usb-a-connector";
+ data-role = "host";
+ label = "USB3 Type-A";
+ power-role = "source";
+ vbus-supply = <&vcc5v0_otg>;
+ };
+};
+
+&dp0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp0m0_pins>;
+ status = "okay";
+};
+
+&dp0_in {
+ dp0_in_vp1: endpoint {
+ remote-endpoint = <&vp1_out_dp0>;
+ };
+};
+
+&dp0_out {
+ dp0_out_con: endpoint {
+ remote-endpoint = <&dp_con_in>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1m4_xfer>;
+ status = "okay";
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3m0_xfer>;
+ status = "okay";
+
+ es8388: audio-codec@11 {
+ compatible = "everest,es8388", "everest,es8328";
+ reg = <0x11>;
+ #sound-dai-cells = <0>;
+ AVDD-supply = <&vcc_3v3_s0>;
+ DVDD-supply = <&vcc_1v8_s0>;
+ HPVDD-supply = <&vcc_3v3_s0>;
+ PVDD-supply = <&vcc_3v3_s0>;
+ assigned-clock-rates = <12288000>;
+ assigned-clocks = <&cru I2S2_2CH_MCLKOUT>;
+ clocks = <&cru I2S2_2CH_MCLKOUT>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s2m1_mclk>;
+ };
+};
+
+&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4m3_xfer>;
+ status = "okay";
+};
+
+&i2s2_2ch {
+ pinctrl-0 = <&i2s2m1_lrck &i2s2m1_sclk
+ &i2s2m1_sdi &i2s2m1_sdo>;
+ status = "okay";
+};
+
+&package_thermal {
+ polling-delay = <1000>;
+
+ cooling-maps {
+ map0 {
+ trip = <&package_fan0>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map1 {
+ trip = <&package_fan1>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ package_fan0: package-fan0 {
+ hysteresis = <2000>;
+ temperature = <55000>;
+ type = "active";
+ };
+
+ package_fan1: package-fan1 {
+ hysteresis = <2000>;
+ temperature = <65000>;
+ type = "active";
+ };
+ };
+};
+
+/* NVMe */
+&pcie2x1l1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie30x1m1_1_clkreqn &pcie30x1m1_1_waken>;
+ reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+ supports-clkreq;
+ vpcie3v3-supply = <&vcc_3v3_s3>;
+ status = "okay";
+};
+
+/* NIC */
+&pcie2x1l2 {
+ reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc3v3_phy1>;
+ status = "okay";
+};
+
+&pinctrl {
+ bluetooth {
+ bt_wake_gpio: bt-wake-pin {
+ rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_host_irq: bt-wake-host-irq {
+ rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ usb {
+ vcc5v0_otg_en: vcc5v0-otg-en {
+ rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wlan {
+ wifi_host_wake_irq: wifi-host-wake-irq {
+ rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+};
+
+&pwm15 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm15m2_pins>;
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm2m1_pins>;
+ status = "okay";
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm3m2_pins>;
+ status = "okay";
+};
+
+&sdhci {
+ status = "okay";
+};
+
+&sdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ max-frequency = <150000000>;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ no-mmc;
+ no-sd;
+ non-removable;
+ sd-uhs-sdr104;
+ status = "okay";
+
+ ap6256: wifi@1 {
+ compatible = "brcm,bcm43456-fmac", "brcm,bcm4329-fmac";
+ reg = <1>;
+ interrupt-names = "host-wake";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA0 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_host_wake_irq>;
+ };
+};
+
+&uart9 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart9m2_xfer &uart9m2_ctsn &uart9m2_rtsn>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm4345c5";
+ clocks = <&hym8563>;
+ clock-names = "lpo";
+ device-wakeup-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+ interrupt-names = "host-wakeup";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PC5 IRQ_TYPE_LEVEL_HIGH>;
+ max-speed = <1500000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_wake_host_irq &bt_wake_gpio>;
+ shutdown-gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
+ vbat-supply = <&vcc_3v3_s3>;
+ vddio-supply = <&vcc_1v8_s3>;
+ };
+};
+
+&usb_host0_xhci {
+ dr_mode = "host";
+};
+
+&usbdp_phy0 {
+ rockchip,dp-lane-mux = <0 1>;
+};
+
+&vp1 {
+ vp1_out_dp0: endpoint@a {
+ reg = <ROCKCHIP_VOP2_EP_DP0>;
+ remote-endpoint = <&dp0_in_vp1>;
+ };
+};
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
index fd23ca2834b0..b58f57b69b22 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
@@ -8,6 +8,7 @@
*/
#include <linux/bitfield.h>
#include <linux/clk.h>
+#include <linux/gpio/consumer.h>
#include <linux/iopoll.h>
#include <linux/irq.h>
#include <linux/media-bus-format.h>
@@ -330,6 +331,8 @@ struct dw_dp {
u8 pixel_mode;
DECLARE_BITMAP(sdp_reg_bank, SDP_REG_BANK_SIZE);
+
+ struct gpio_desc *hpd_gpiod;
};
enum {
@@ -481,6 +484,9 @@ static bool dw_dp_hpd_detect(struct dw_dp *dp)
{
u32 value;
+ if (dp->hpd_gpiod)
+ return gpiod_get_value_cansleep(dp->hpd_gpiod);
+
regmap_read(dp->regmap, DW_DP_HPD_STATUS, &value);
return FIELD_GET(HPD_STATE, value) == DW_DP_HPD_STATE_PLUG;
@@ -2002,6 +2008,12 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
return ERR_CAST(dp->regmap);
}
+ dp->hpd_gpiod = devm_gpiod_get_optional(dev, "hpd", GPIOD_IN);
+ if (IS_ERR(dp->hpd_gpiod)) {
+ dev_err_probe(dev, PTR_ERR(dp->hpd_gpiod), "failed to get hpd GPIO\n");
+ return ERR_CAST(dp->hpd_gpiod);
+ }
+
dp->phy = devm_of_phy_get(dev, dev->of_node, NULL);
if (IS_ERR(dp->phy)) {
dev_err_probe(dev, PTR_ERR(dp->phy), "failed to get phy\n");
--
2.53.0
^ permalink raw reply related
* [PATCH v6 2/3] arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for Pro
From: dennis @ 2026-04-11 2:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Dennis Gilmore, Michael Riesch,
Mykola Kvach, Jimmy Hon, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260411024743.195385-1-dennis@ausil.us>
From: Dennis Gilmore <dennis@ausil.us>
The Orange Pi 5 Pro uses the same SoC and base as the Orange Pi 5 and
Orange Pi 5B but has had sound, USB, and leds wired up differently. The
boards also use gmac for ethernet where the Pro has a PCIe attached NIC.
I have not changed the definitions from what was in rk3588s-orangepi-5.dtsi
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 192 +++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 198 +-----------------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
4 files changed, 209 insertions(+), 189 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
new file mode 100644
index 000000000000..b04dd667605d
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
@@ -0,0 +1,192 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device tree definitions shared by the Orange Pi 5 and Orange Pi 5B
+ * but not the Orange Pi 5 Pro.
+ */
+
+#include <dt-bindings/usb/pd.h>
+#include "rk3588s-orangepi-5.dtsi"
+
+/ {
+ aliases {
+ ethernet0 = &gmac1;
+ };
+
+ analog-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_detect>;
+ simple-audio-card,name = "rockchip,es8388";
+ simple-audio-card,bitclock-master = <&masterdai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&masterdai>;
+ simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,routing =
+ "Headphones", "LOUT1",
+ "Headphones", "ROUT1",
+ "LINPUT1", "Microphone Jack",
+ "RINPUT1", "Microphone Jack",
+ "LINPUT2", "Onboard Microphone",
+ "RINPUT2", "Onboard Microphone";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Onboard Microphone",
+ "Headphone", "Headphones";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s1_8ch>;
+ };
+
+ masterdai: simple-audio-card,codec {
+ sound-dai = <&es8388>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ led {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm0 0 25000 0>;
+ };
+ };
+};
+
+&gmac1 {
+ clock_in_out = "output";
+ phy-handle = <&rgmii_phy1>;
+ phy-mode = "rgmii-rxid";
+ pinctrl-0 = <&gmac1_miim
+ &gmac1_tx_bus2
+ &gmac1_rx_bus2
+ &gmac1_rgmii_clk
+ &gmac1_rgmii_bus>;
+ pinctrl-names = "default";
+ tx_delay = <0x42>;
+ status = "okay";
+};
+
+&i2c6 {
+ es8388: audio-codec@10 {
+ compatible = "everest,es8388", "everest,es8328";
+ reg = <0x10>;
+ clocks = <&cru I2S1_8CH_MCLKOUT>;
+ AVDD-supply = <&vcc_3v3_s0>;
+ DVDD-supply = <&vcc_1v8_s0>;
+ HPVDD-supply = <&vcc_3v3_s0>;
+ PVDD-supply = <&vcc_3v3_s0>;
+ assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
+ assigned-clock-rates = <12288000>;
+ #sound-dai-cells = <0>;
+ };
+
+ usbc0: usb-typec@22 {
+ compatible = "fcs,fusb302";
+ reg = <0x22>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usbc0_int>;
+ vbus-supply = <&vbus_typec>;
+ status = "okay";
+
+ usb_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ op-sink-microwatt = <1000000>;
+ power-role = "dual";
+ sink-pdos =
+ <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
+ source-pdos =
+ <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "source";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usbc0_hs: endpoint {
+ remote-endpoint = <&usb_host0_xhci_drd_sw>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ usbc0_ss: endpoint {
+ remote-endpoint = <&usbdp_phy0_typec_ss>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ usbc0_sbu: endpoint {
+ remote-endpoint = <&usbdp_phy0_typec_sbu>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&i2s1_8ch {
+ rockchip,i2s-tx-route = <3 2 1 0>;
+ rockchip,i2s-rx-route = <1 3 2 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s1m0_sclk
+ &i2s1m0_mclk
+ &i2s1m0_lrck
+ &i2s1m0_sdi1
+ &i2s1m0_sdo3>;
+ status = "okay";
+};
+
+&pwm0 {
+ pinctrl-0 = <&pwm0m2_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usb_host0_xhci {
+ dr_mode = "otg";
+ usb-role-switch;
+
+ port {
+ usb_host0_xhci_drd_sw: endpoint {
+ remote-endpoint = <&usbc0_hs>;
+ };
+ };
+};
+
+&usb_host2_xhci {
+ status = "okay";
+};
+
+&usbdp_phy0 {
+ mode-switch;
+ orientation-switch;
+ sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
+ sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usbdp_phy0_typec_ss: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&usbc0_ss>;
+ };
+
+ usbdp_phy0_typec_sbu: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&usbc0_sbu>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
index 83b9b6645a1e..d76bdf1b5e90 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
@@ -2,12 +2,16 @@
/dts-v1/;
-#include "rk3588s-orangepi-5.dtsi"
+#include "rk3588s-orangepi-5-5b.dtsi"
/ {
model = "Xunlong Orange Pi 5";
compatible = "xunlong,orangepi-5", "rockchip,rk3588s";
+ aliases {
+ mmc0 = &sdmmc;
+ };
+
vcc3v3_pcie20: regulator-vcc3v3-pcie20 {
compatible = "regulator-fixed";
enable-active-high;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
index dafad29f9854..5c154cc6c62a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
@@ -3,19 +3,13 @@
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/leds/common.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
#include <dt-bindings/pinctrl/rockchip.h>
#include <dt-bindings/soc/rockchip,vop2.h>
-#include <dt-bindings/usb/pd.h>
#include "rk3588s.dtsi"
/ {
- aliases {
- ethernet0 = &gmac1;
- mmc0 = &sdmmc;
- };
-
chosen {
stdout-path = "serial2:1500000n8";
};
@@ -34,38 +28,6 @@ button-recovery {
};
};
- analog-sound {
- compatible = "simple-audio-card";
- pinctrl-names = "default";
- pinctrl-0 = <&hp_detect>;
- simple-audio-card,name = "rockchip,es8388";
- simple-audio-card,bitclock-master = <&masterdai>;
- simple-audio-card,format = "i2s";
- simple-audio-card,frame-master = <&masterdai>;
- simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
- simple-audio-card,mclk-fs = <256>;
- simple-audio-card,routing =
- "Headphones", "LOUT1",
- "Headphones", "ROUT1",
- "LINPUT1", "Microphone Jack",
- "RINPUT1", "Microphone Jack",
- "LINPUT2", "Onboard Microphone",
- "RINPUT2", "Onboard Microphone";
- simple-audio-card,widgets =
- "Microphone", "Microphone Jack",
- "Microphone", "Onboard Microphone",
- "Headphone", "Headphones";
-
- simple-audio-card,cpu {
- sound-dai = <&i2s1_8ch>;
- };
-
- masterdai: simple-audio-card,codec {
- sound-dai = <&es8388>;
- system-clock-frequency = <12288000>;
- };
- };
-
hdmi0-con {
compatible = "hdmi-connector";
type = "a";
@@ -77,18 +39,6 @@ hdmi0_con_in: endpoint {
};
};
- pwm-leds {
- compatible = "pwm-leds";
-
- led {
- color = <LED_COLOR_ID_GREEN>;
- function = LED_FUNCTION_STATUS;
- linux,default-trigger = "heartbeat";
- max-brightness = <255>;
- pwms = <&pwm0 0 25000 0>;
- };
- };
-
vbus_typec: regulator-vbus-typec {
compatible = "regulator-fixed";
enable-active-high;
@@ -101,15 +51,6 @@ vbus_typec: regulator-vbus-typec {
vin-supply = <&vcc5v0_sys>;
};
- vcc5v0_sys: regulator-vcc5v0-sys {
- compatible = "regulator-fixed";
- regulator-name = "vcc5v0_sys";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- };
-
vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
compatible = "regulator-fixed";
gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_LOW>;
@@ -119,6 +60,15 @@ vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
regulator-max-microvolt = <3300000>;
vin-supply = <&vcc_3v3_s3>;
};
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
};
&combphy0_ps {
@@ -161,20 +111,6 @@ &cpu_l3 {
cpu-supply = <&vdd_cpu_lit_s0>;
};
-&gmac1 {
- clock_in_out = "output";
- phy-handle = <&rgmii_phy1>;
- phy-mode = "rgmii-rxid";
- pinctrl-0 = <&gmac1_miim
- &gmac1_tx_bus2
- &gmac1_rx_bus2
- &gmac1_rgmii_clk
- &gmac1_rgmii_bus>;
- pinctrl-names = "default";
- tx_delay = <0x42>;
- status = "okay";
-};
-
&gpu {
mali-supply = <&vdd_gpu_s0>;
status = "okay";
@@ -270,69 +206,6 @@ &i2c6 {
pinctrl-0 = <&i2c6m3_xfer>;
status = "okay";
- es8388: audio-codec@10 {
- compatible = "everest,es8388", "everest,es8328";
- reg = <0x10>;
- clocks = <&cru I2S1_8CH_MCLKOUT>;
- AVDD-supply = <&vcc_3v3_s0>;
- DVDD-supply = <&vcc_1v8_s0>;
- HPVDD-supply = <&vcc_3v3_s0>;
- PVDD-supply = <&vcc_3v3_s0>;
- assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
- assigned-clock-rates = <12288000>;
- #sound-dai-cells = <0>;
- };
-
- usbc0: usb-typec@22 {
- compatible = "fcs,fusb302";
- reg = <0x22>;
- interrupt-parent = <&gpio0>;
- interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&usbc0_int>;
- vbus-supply = <&vbus_typec>;
- status = "okay";
-
- usb_con: connector {
- compatible = "usb-c-connector";
- label = "USB-C";
- data-role = "dual";
- op-sink-microwatt = <1000000>;
- power-role = "dual";
- sink-pdos =
- <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
- source-pdos =
- <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
- try-power-role = "source";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- usbc0_hs: endpoint {
- remote-endpoint = <&usb_host0_xhci_drd_sw>;
- };
- };
-
- port@1 {
- reg = <1>;
- usbc0_ss: endpoint {
- remote-endpoint = <&usbdp_phy0_typec_ss>;
- };
- };
-
- port@2 {
- reg = <2>;
- usbc0_sbu: endpoint {
- remote-endpoint = <&usbdp_phy0_typec_sbu>;
- };
- };
- };
- };
- };
-
hym8563: rtc@51 {
compatible = "haoyu,hym8563";
reg = <0x51>;
@@ -346,18 +219,6 @@ hym8563: rtc@51 {
};
};
-&i2s1_8ch {
- rockchip,i2s-tx-route = <3 2 1 0>;
- rockchip,i2s-rx-route = <1 3 2 0>;
- pinctrl-names = "default";
- pinctrl-0 = <&i2s1m0_sclk
- &i2s1m0_mclk
- &i2s1m0_lrck
- &i2s1m0_sdi1
- &i2s1m0_sdo3>;
- status = "okay";
-};
-
&i2s5_8ch {
status = "okay";
};
@@ -404,12 +265,6 @@ typec5v_pwren: typec5v-pwren {
};
};
-&pwm0 {
- pinctrl-0 = <&pwm0m2_pins>;
- pinctrl-names = "default";
- status = "okay";
-};
-
&rknn_core_0 {
npu-supply = <&vdd_npu_s0>;
sram-supply = <&vdd_npu_s0>;
@@ -841,26 +696,7 @@ &uart2 {
};
&usbdp_phy0 {
- mode-switch;
- orientation-switch;
- sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
- sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
status = "okay";
-
- port {
- #address-cells = <1>;
- #size-cells = <0>;
-
- usbdp_phy0_typec_ss: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&usbc0_ss>;
- };
-
- usbdp_phy0_typec_sbu: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&usbc0_sbu>;
- };
- };
};
&usb_host0_ehci {
@@ -872,15 +708,7 @@ &usb_host0_ohci {
};
&usb_host0_xhci {
- dr_mode = "otg";
- usb-role-switch;
status = "okay";
-
- port {
- usb_host0_xhci_drd_sw: endpoint {
- remote-endpoint = <&usbc0_hs>;
- };
- };
};
&usb_host1_ehci {
@@ -891,7 +719,7 @@ &usb_host1_ohci {
status = "okay";
};
-&usb_host2_xhci {
+&vop {
status = "okay";
};
@@ -899,10 +727,6 @@ &vop_mmu {
status = "okay";
};
-&vop {
- status = "okay";
-};
-
&vp0 {
vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
reg = <ROCKCHIP_VOP2_EP_HDMI0>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
index d21ec320d295..8af174777809 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
@@ -2,7 +2,7 @@
/dts-v1/;
-#include "rk3588s-orangepi-5.dtsi"
+#include "rk3588s-orangepi-5-5b.dtsi"
/ {
model = "Xunlong Orange Pi 5B";
--
2.53.0
^ permalink raw reply related
* [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
From: dennis @ 2026-04-11 2:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Dennis Gilmore, Michael Riesch,
Mykola Kvach, Jimmy Hon, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260411024743.195385-1-dennis@ausil.us>
From: Dennis Gilmore <dennis@ausil.us>
Add compatible string for the Orange Pi 5 Pro.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index ae77ded9fe47..3c6b83a84463 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -1320,6 +1320,7 @@ properties:
items:
- enum:
- xunlong,orangepi-5
+ - xunlong,orangepi-5-pro
- xunlong,orangepi-5b
- const: rockchip,rk3588s
--
2.53.0
^ permalink raw reply related
* [PATCH v6 0/3] Add support for Orange Pi 5 Pro
From: dennis @ 2026-04-11 2:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Dennis Gilmore, Michael Riesch,
Mykola Kvach, Jimmy Hon, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
From: Dennis Gilmore <dennis@ausil.us>
This series adds initial support for Orange Pi 5 Pro. The PCIe attached network
driver(dwmac-motorcomm) was just added.
The series was tested against Linux 7.0-rc7
Please take a look.
Thank you,
Dennis Gilmore
Changes in v6:
- Move the shared configs for the Orange Pi 5 and Orange Pi 5b from each
devices dts to a shared rk3588s-orangepi-5-5b.dtsi to avoid duplication
- Remove empty ports subnodeis from typea_con
- Move i2s2m1_mclk pinctrl from &i2s2 to the es8388 codec node
- Add dp-con, dp0_out, dp0_in, and vp1 nodes, plus the vcc3v3_dp regulator
in order to get the second HDMI port working via its transparent
LT8711UXD DP to HDMI bridge
- link to v5 https://lore.kernel.org/linux-devicetree/20260401010707.2584962-1-dennis@ausil.us/
Changes in v5:
- define a connector node for Type-A port, and list the regulator as its VBUS supply explicitly.
- Requires https://lore.kernel.org/all/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net/
- link to v4 https://lore.kernel.org/linux-devicetree/20260310031002.3921234-1-dennis@ausil.us/
Changes in v4:
- rename vcc3v3_pcie20 copied from rk3588s-orangepi-5.dts to vcc3v3_phy1 to match the schematic
- use vcc_3v3_s3 as the supply not vcc5v0_sys for PCIe
- remove the definition for vcc3v3_pcie_m2 as it does not really exist
as a regulator
- link to v3 https://lore.kernel.org/linux-devicetree/20260306024634.239614-1-dennis@ausil.us/
Changes in v3:
- moved leds from gpio-leds to pwm-leds
- remove disable-wp from sdio
- rename vcc3v3_pcie_eth regulator to vcc3v3_pcie_m2 to reflect the
purppose
- actually clean up the delete lines and comments missed in v2
- link to v2 https://lore.kernel.org/linux-devicetree/20260304025521.210377-1-dennis@ausil.us/
Changes in v2:
- moved items not shared by orangepi 5/5b/5 Pro from dtsi to 5 and 5b
dts files
- removed all the comments and deleted properties from 5 Pro dts
- Link to v1 https://lore.kernel.org/linux-devicetree/20260228205418.2944620-1-dennis@ausil.us/
Dennis Gilmore (3):
dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for
Pro
arm64: dts: rockchip: Add Orange Pi 5 Pro board support
.../devicetree/bindings/arm/rockchip.yaml | 1 +
.../display/rockchip/rockchip,dw-dp.yaml | 7 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 192 ++++++++++
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 352 ++++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 198 +---------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
drivers/gpu/drm/bridge/synopsys/dw-dp.c | 12 +
9 files changed, 582 insertions(+), 189 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
--
2.53.0
^ permalink raw reply
* Re: [PATCH 04/35] irqchip/qcom-pdc: Replace pdc_version global with a function pointer
From: Bjorn Andersson @ 2026-04-11 2:43 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, cros-qcom-dts-watchers, linux-arm-msm,
linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-5-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:41AM +0530, Mukesh Ojha wrote:
> Now that the two enable paths are separate functions, replace the
> pdc_version global with a __pdc_enable_intr function pointer. The
> pointer is assigned once at probe time based on the version register,
> moving the version comparison out of the interrupt enable/disable hot
> path entirely.
That's what the patch does, but why?
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/irqchip/qcom-pdc.c | 13 +++----------
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
> index 21e2b4b884ee..734576cdce0c 100644
> --- a/drivers/irqchip/qcom-pdc.c
> +++ b/drivers/irqchip/qcom-pdc.c
> @@ -51,7 +51,7 @@ static void __iomem *pdc_base;
> static void __iomem *pdc_prev_base;
> static struct pdc_pin_region *pdc_region;
> static int pdc_region_cnt;
> -static unsigned int pdc_version;
> +static void (*__pdc_enable_intr)(int pin_out, bool on);
> static bool pdc_x1e_quirk;
>
> static void pdc_base_reg_write(void __iomem *base, int reg, u32 i, u32 val)
> @@ -123,14 +123,6 @@ static void pdc_enable_intr_cfg(int pin_out, bool on)
> pdc_reg_write(IRQ_i_CFG, pin_out, enable);
> }
>
> -static void __pdc_enable_intr(int pin_out, bool on)
> -{
> - if (pdc_version < PDC_VERSION_3_2)
> - pdc_enable_intr_bank(pin_out, on);
> - else
> - pdc_enable_intr_cfg(pin_out, on);
This style is comfortable to read.
> -}
> -
> static void pdc_enable_intr(struct irq_data *d, bool on)
> {
> unsigned long flags;
> @@ -400,7 +392,8 @@ static int qcom_pdc_probe(struct platform_device *pdev, struct device_node *pare
> goto fail;
> }
>
> - pdc_version = pdc_reg_read(PDC_VERSION_REG, 0);
> + __pdc_enable_intr = (pdc_reg_read(PDC_VERSION_REG, 0) < PDC_VERSION_3_2) ?
> + pdc_enable_intr_bank : pdc_enable_intr_cfg;
This style is a mess.
Regards,
Bjorn
>
> parent_domain = irq_find_host(parent);
> if (!parent_domain) {
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v4 2/3] thermal: spacemit: k1: Add thermal sensor support
From: Shuwei Wu @ 2026-04-11 1:56 UTC (permalink / raw)
To: Jie Gan, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: linux-pm, devicetree, linux-riscv, spacemit, linux-kernel,
Anand Moon, Troy Mitchell, Yao Zi, Vincent Legoll, Gong Shuai
In-Reply-To: <38088fd6-1db6-4591-b489-33b52f727549@oss.qualcomm.com>
On Fri Apr 10, 2026 at 4:25 PM CST, Jie Gan wrote:
>
>
> On 4/10/2026 11:31 AM, Shuwei Wu wrote:
>> The thermal sensor on K1 supports monitoring five temperature zones.
>> The driver registers these sensors with the thermal framework
>> and supports standard operations:
>> - Reading temperature (millidegree Celsius)
>> - Setting high/low thresholds for interrupts
>>
>> Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
>> Reviewed-by: Anand Moon <linux.amoon@gmail.com>
>> Tested-by: Anand Moon <linux.amoon@gmail.com>
>> Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
>> Reviewed-by: Yao Zi <me@ziyao.cc>
>> Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
>> Tested-by: Gong Shuai <gsh517025@gmail.com>
>>
>> ---
>> Changes in v4:
>> - Add 'depends on THERMAL_OF' in drivers/thermal/spacemit/Kconfig
>>
>> Changes in v3:
>> - Align multi-line assignments as suggested by reviewer
>> - Remove unnecessary variable definitions
>>
>> Changes in v2:
>> - Rename k1_thermal.c to k1_tsensor.c for better hardware alignment
>> - Move driver to drivers/thermal/spacemit/
>> - Add Kconfig/Makefile for spacemit and update top-level build files
>> - Refactor names, style, code alignment, and comments
>> - Simplify probe and error handling
>> ---
>> drivers/thermal/Kconfig | 2 +
>> drivers/thermal/Makefile | 1 +
>> drivers/thermal/spacemit/Kconfig | 19 +++
>> drivers/thermal/spacemit/Makefile | 3 +
>> drivers/thermal/spacemit/k1_tsensor.c | 281 ++++++++++++++++++++++++++++++++++
>> 5 files changed, 306 insertions(+)
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index b10080d61860..1c4a5cd5a23e 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -472,6 +472,8 @@ endmenu
>>
>> source "drivers/thermal/renesas/Kconfig"
>>
>> +source "drivers/thermal/spacemit/Kconfig"
>> +
>> source "drivers/thermal/tegra/Kconfig"
>>
>> config GENERIC_ADC_THERMAL
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index bb21e7ea7fc6..3b249195c088 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -65,6 +65,7 @@ obj-y += mediatek/
>> obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
>> obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
>> obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
>> +obj-y += spacemit/
>> obj-$(CONFIG_SPRD_THERMAL) += sprd_thermal.o
>> obj-$(CONFIG_KHADAS_MCU_FAN_THERMAL) += khadas_mcu_fan.o
>> obj-$(CONFIG_LOONGSON2_THERMAL) += loongson2_thermal.o
>> diff --git a/drivers/thermal/spacemit/Kconfig b/drivers/thermal/spacemit/Kconfig
>> new file mode 100644
>> index 000000000000..de7b5ece5af2
>> --- /dev/null
>> +++ b/drivers/thermal/spacemit/Kconfig
>> @@ -0,0 +1,19 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +menu "SpacemiT thermal drivers"
>> +depends on ARCH_SPACEMIT || COMPILE_TEST
>> +
>> +config SPACEMIT_K1_TSENSOR
>> + tristate "SpacemiT K1 thermal sensor driver"
>> + depends on THERMAL_OF
>> + help
>> + This driver provides support for the thermal sensor
>> + integrated in the SpacemiT K1 SoC.
>> +
>> + The thermal sensor monitors temperatures for five thermal zones:
>> + soc, package, gpu, cluster0, and cluster1. It supports reporting
>> + temperature values and handling high/low threshold interrupts.
>> +
>> + Say Y here if you want to enable thermal monitoring on SpacemiT K1.
>> + If compiled as a module, it will be called k1_tsensor.
>> +
>> +endmenu
>> diff --git a/drivers/thermal/spacemit/Makefile b/drivers/thermal/spacemit/Makefile
>> new file mode 100644
>> index 000000000000..82b30741e4ec
>> --- /dev/null
>> +++ b/drivers/thermal/spacemit/Makefile
>> @@ -0,0 +1,3 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +
>> +obj-$(CONFIG_SPACEMIT_K1_TSENSOR) += k1_tsensor.o
>> diff --git a/drivers/thermal/spacemit/k1_tsensor.c b/drivers/thermal/spacemit/k1_tsensor.c
>> new file mode 100644
>> index 000000000000..b742739e9019
>> --- /dev/null
>> +++ b/drivers/thermal/spacemit/k1_tsensor.c
>> @@ -0,0 +1,281 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Thermal sensor driver for SpacemiT K1 SoC
>> + *
>> + * Copyright (C) 2026 Shuwei Wu <shuwei.wu@mailbox.org>
>> + */
>> +#include <linux/bitfield.h>
>> +#include <linux/clk.h>
>> +#include <linux/err.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/reset.h>
>> +#include <linux/slab.h>
>> +#include <linux/thermal.h>
>> +
>> +#include "../thermal_hwmon.h"
>> +
>> +#define K1_TSENSOR_PCTRL_REG 0x00
>> +#define K1_TSENSOR_PCTRL_ENABLE BIT(0)
>> +#define K1_TSENSOR_PCTRL_TEMP_MODE BIT(3)
>> +#define K1_TSENSOR_PCTRL_RAW_SEL BIT(7)
>> +
>> +#define K1_TSENSOR_PCTRL_CTUNE GENMASK(11, 8)
>> +#define K1_TSENSOR_PCTRL_SW_CTRL GENMASK(21, 18)
>> +#define K1_TSENSOR_PCTRL_HW_AUTO_MODE BIT(23)
>> +
>> +#define K1_TSENSOR_EN_REG 0x08
>> +#define K1_TSENSOR_EN_ALL GENMASK(MAX_SENSOR_NUMBER - 1, 0)
>> +
>> +#define K1_TSENSOR_TIME_REG 0x0C
>> +#define K1_TSENSOR_TIME_WAIT_REF_CNT GENMASK(3, 0)
>> +#define K1_TSENSOR_TIME_ADC_CNT_RST GENMASK(7, 4)
>> +#define K1_TSENSOR_TIME_FILTER_PERIOD GENMASK(21, 20)
>> +#define K1_TSENSOR_TIME_MASK GENMASK(23, 0)
>> +
>> +#define K1_TSENSOR_INT_CLR_REG 0x10
>> +#define K1_TSENSOR_INT_EN_REG 0x14
>> +#define K1_TSENSOR_INT_STA_REG 0x18
>> +
>> +#define K1_TSENSOR_INT_EN_MASK BIT(0)
>> +#define K1_TSENSOR_INT_MASK(x) (GENMASK(2, 1) << ((x) * 2))
>> +
>> +#define K1_TSENSOR_DATA_BASE_REG 0x20
>> +#define K1_TSENSOR_DATA_REG(x) (K1_TSENSOR_DATA_BASE_REG + ((x) / 2) * 4)
>> +#define K1_TSENSOR_DATA_LOW_MASK GENMASK(15, 0)
>> +#define K1_TSENSOR_DATA_HIGH_MASK GENMASK(31, 16)
>> +
>> +#define K1_TSENSOR_THRSH_BASE_REG 0x40
>> +#define K1_TSENSOR_THRSH_REG(x) (K1_TSENSOR_THRSH_BASE_REG + ((x) * 4))
>> +#define K1_TSENSOR_THRSH_LOW_MASK GENMASK(15, 0)
>> +#define K1_TSENSOR_THRSH_HIGH_MASK GENMASK(31, 16)
>> +
>> +#define MAX_SENSOR_NUMBER 5
>> +
>> +/* Hardware offset value required for temperature calculation */
>> +#define TEMPERATURE_OFFSET 278
>> +
>> +struct k1_tsensor_channel {
>> + struct k1_tsensor *ts;
>> + struct thermal_zone_device *tzd;
>> + int id;
>> +};
>> +
>> +struct k1_tsensor {
>> + void __iomem *base;
>> + struct k1_tsensor_channel ch[MAX_SENSOR_NUMBER];
>> +};
>> +
>> +static void k1_tsensor_init(struct k1_tsensor *ts)
>> +{
>> + u32 val;
>> +
>> + /* Disable all the interrupts */
>> + writel(0xffffffff, ts->base + K1_TSENSOR_INT_EN_REG);
>> +
>> + /* Configure ADC sampling time and filter period */
>> + val = readl(ts->base + K1_TSENSOR_TIME_REG);
>> + val &= ~K1_TSENSOR_TIME_MASK;
>> + val |= K1_TSENSOR_TIME_FILTER_PERIOD |
>> + K1_TSENSOR_TIME_ADC_CNT_RST |
>> + K1_TSENSOR_TIME_WAIT_REF_CNT;
>> + writel(val, ts->base + K1_TSENSOR_TIME_REG);
>> +
>> + /*
>> + * Enable all sensors' auto mode, enable dither control,
>> + * consecutive mode, and power up sensor.
>> + */
>> + val = readl(ts->base + K1_TSENSOR_PCTRL_REG);
>> + val &= ~K1_TSENSOR_PCTRL_SW_CTRL;
>> + val &= ~K1_TSENSOR_PCTRL_CTUNE;
>> + val |= K1_TSENSOR_PCTRL_RAW_SEL |
>> + K1_TSENSOR_PCTRL_TEMP_MODE |
>> + K1_TSENSOR_PCTRL_HW_AUTO_MODE |
>> + K1_TSENSOR_PCTRL_ENABLE;
>> + writel(val, ts->base + K1_TSENSOR_PCTRL_REG);
>> +
>> + /* Enable thermal interrupt */
>> + val = readl(ts->base + K1_TSENSOR_INT_EN_REG);
>> + val |= K1_TSENSOR_INT_EN_MASK;
>> + writel(val, ts->base + K1_TSENSOR_INT_EN_REG);
>> +
>> + /* Enable each sensor */
>> + val = readl(ts->base + K1_TSENSOR_EN_REG);
>> + val |= K1_TSENSOR_EN_ALL;
>> + writel(val, ts->base + K1_TSENSOR_EN_REG);
>> +}
>> +
>> +static void k1_tsensor_enable_irq(struct k1_tsensor_channel *ch)
>> +{
>> + struct k1_tsensor *ts = ch->ts;
>> + u32 val;
>> +
>> + val = readl(ts->base + K1_TSENSOR_INT_CLR_REG);
>> + val |= K1_TSENSOR_INT_MASK(ch->id);
>> + writel(val, ts->base + K1_TSENSOR_INT_CLR_REG);
>> +
>> + val = readl(ts->base + K1_TSENSOR_INT_EN_REG);
>> + val &= ~K1_TSENSOR_INT_MASK(ch->id);
>> + writel(val, ts->base + K1_TSENSOR_INT_EN_REG);
>> +}
>> +
>> +/*
>> + * The conversion formula used is:
>> + * T(m°C) = (((raw_value & mask) >> shift) - TEMPERATURE_OFFSET) * 1000
>> + */
>> +static int k1_tsensor_get_temp(struct thermal_zone_device *tz, int *temp)
>> +{
>> + struct k1_tsensor_channel *ch = thermal_zone_device_priv(tz);
>> + struct k1_tsensor *ts = ch->ts;
>> + u32 val;
>> +
>> + val = readl(ts->base + K1_TSENSOR_DATA_REG(ch->id));
>> + if (ch->id % 2)
>> + *temp = FIELD_GET(K1_TSENSOR_DATA_HIGH_MASK, val);
>> + else
>> + *temp = FIELD_GET(K1_TSENSOR_DATA_LOW_MASK, val);
>> +
>> + *temp -= TEMPERATURE_OFFSET;
>> + *temp *= 1000;
>> +
>> + return 0;
>> +}
>> +
>> +/*
>> + * For each sensor, the hardware threshold register is 32 bits:
>> + * - Lower 16 bits [15:0] configure the low threshold temperature.
>> + * - Upper 16 bits [31:16] configure the high threshold temperature.
>> + */
>> +static int k1_tsensor_set_trips(struct thermal_zone_device *tz, int low, int high)
>> +{
>> + struct k1_tsensor_channel *ch = thermal_zone_device_priv(tz);
>> + struct k1_tsensor *ts = ch->ts;
>> + u32 val;
>> +
>> + if (low >= high)
>> + return -EINVAL;
>> +
>> + if (low < 0)
>> + low = 0;
>> +
>> + high = high / 1000 + TEMPERATURE_OFFSET;
>
> Consider passes high = INT_MAX here:
>
> high = INT/1000 + TEMPERATURE_OFFSET == 2147761;
>
>> + low = low / 1000 + TEMPERATURE_OFFSET;
>> +
>> + val = readl(ts->base + K1_TSENSOR_THRSH_REG(ch->id));
>> + val &= ~K1_TSENSOR_THRSH_HIGH_MASK;
>> + val |= FIELD_PREP(K1_TSENSOR_THRSH_HIGH_MASK, high);
>
> K1_TSENSOR_THRSH_HIGH_MASK is a 16-bit MASK:
> FIELD_PREP(K1_TSENSOR_THRSH_HIGH_MASK, 2147761); <- overflow happened
>
> the maximum value here will be changed to 50609 from 65536.
>
> We should add a check here and limit the 'high' value here to avoid
> overflow:
>
> if (high > (int)((0xFFFF - TEMPERATURE_OFFSET) * 1000))
> high = (0Xffff - TEMPERATURE_OFFSET) * 1000;
>
> high = high / 1000 + TEMPERATURE_OFFSET;
>
> ...
Got it. I'll add a check to handle the overflow.
>
>> +
>> + val &= ~K1_TSENSOR_THRSH_LOW_MASK;
>> + val |= FIELD_PREP(K1_TSENSOR_THRSH_LOW_MASK, low);
>> + writel(val, ts->base + K1_TSENSOR_THRSH_REG(ch->id));
>> +
>> + return 0;
>> +}
>> +
>> +static const struct thermal_zone_device_ops k1_tsensor_ops = {
>> + .get_temp = k1_tsensor_get_temp,
>> + .set_trips = k1_tsensor_set_trips,
>> +};
>> +
>> +static irqreturn_t k1_tsensor_irq_thread(int irq, void *data)
>> +{
>> + struct k1_tsensor *ts = (struct k1_tsensor *)data;
>> + int mask, status, i;
>> +
>> + status = readl(ts->base + K1_TSENSOR_INT_STA_REG);
>> +
>> + for (i = 0; i < MAX_SENSOR_NUMBER; i++) {
>> + if (status & K1_TSENSOR_INT_MASK(i)) {
>> + mask = readl(ts->base + K1_TSENSOR_INT_CLR_REG);
>> + mask |= K1_TSENSOR_INT_MASK(i);
>> + writel(mask, ts->base + K1_TSENSOR_INT_CLR_REG);
>> + thermal_zone_device_update(ts->ch[i].tzd, THERMAL_EVENT_UNSPECIFIED);
>> + }
>> + }
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static int k1_tsensor_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct k1_tsensor *ts;
>> + struct reset_control *reset;
>> + struct clk *clk;
>> + int i, irq, ret;
>> +
>> + ts = devm_kzalloc(dev, sizeof(*ts), GFP_KERNEL);
>> + if (!ts)
>> + return -ENOMEM;
>> +
>> + ts->base = devm_platform_ioremap_resource(pdev, 0);
>> + if (IS_ERR(ts->base))
>> + return dev_err_probe(dev, PTR_ERR(ts->base), "Failed to get reg\n");
>> +
>> + reset = devm_reset_control_get_exclusive_deasserted(dev, NULL);
>> + if (IS_ERR(reset))
>> + return dev_err_probe(dev, PTR_ERR(reset), "Failed to get/deassert reset control\n");
>> +
>> + clk = devm_clk_get_enabled(dev, "core");
>> + if (IS_ERR(clk))
>> + return dev_err_probe(dev, PTR_ERR(clk), "Failed to get core clock\n");
>> +
>> + clk = devm_clk_get_enabled(dev, "bus");
>> + if (IS_ERR(clk))
>> + return dev_err_probe(dev, PTR_ERR(clk), "Failed to get bus clock\n");
>> +
>> + k1_tsensor_init(ts);
>> +
>> + for (i = 0; i < MAX_SENSOR_NUMBER; ++i) {
>> + ts->ch[i].id = i;
>> + ts->ch[i].ts = ts;
>> + ts->ch[i].tzd = devm_thermal_of_zone_register(dev, i, ts->ch + i, &k1_tsensor_ops);
>> + if (IS_ERR(ts->ch[i].tzd))
>> + return PTR_ERR(ts->ch[i].tzd);
>> +
>> + /* Attach sysfs hwmon attributes for userspace monitoring */
>> + ret = devm_thermal_add_hwmon_sysfs(dev, ts->ch[i].tzd);
>> + if (ret)
>> + dev_warn(dev, "Failed to add hwmon sysfs attributes\n");
>> +
>> + k1_tsensor_enable_irq(ts->ch + i);
>
> should call after the devm_request_threaded_irq succeeds;
I'll reorder this in v5.
Thanks for catching that.
>
> Thanks,
> Jie
>
>> + }
>> +
>> + irq = platform_get_irq(pdev, 0);
>> + if (irq < 0)
>> + return irq;
>> +
>> + ret = devm_request_threaded_irq(dev, irq, NULL,
>> + k1_tsensor_irq_thread,
>> + IRQF_ONESHOT, "k1_tsensor", ts);
>> + if (ret < 0)
>> + return ret;
>> +
>> + platform_set_drvdata(pdev, ts);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id k1_tsensor_dt_ids[] = {
>> + { .compatible = "spacemit,k1-tsensor" },
>> + { /* sentinel */ }
>> +};
>> +
>> +MODULE_DEVICE_TABLE(of, k1_tsensor_dt_ids);
>> +
>> +static struct platform_driver k1_tsensor_driver = {
>> + .driver = {
>> + .name = "k1_tsensor",
>> + .of_match_table = k1_tsensor_dt_ids,
>> + },
>> + .probe = k1_tsensor_probe,
>> +};
>> +module_platform_driver(k1_tsensor_driver);
>> +
>> +MODULE_DESCRIPTION("SpacemiT K1 Thermal Sensor Driver");
>> +MODULE_AUTHOR("Shuwei Wu <shuwei.wu@mailbox.org>");
>> +MODULE_LICENSE("GPL");
>>
--
Best regards,
Shuwei Wu
^ permalink raw reply
* Re: [PATCH] riscv: dts: tenstorrent: Add PMU node to blackhole for Linux perf support
From: Drew Fustini @ 2026-04-11 1:38 UTC (permalink / raw)
To: Anirudh Srinivasan
Cc: Drew Fustini, Joel Stanley, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, linux-riscv, devicetree, linux-kernel,
Michael Neuling
In-Reply-To: <20260409-blackhole_pmu-v1-1-01a34bf46a1c@oss.tenstorrent.com>
On Thu, Apr 09, 2026 at 09:49:59PM -0500, Anirudh Srinivasan wrote:
> From: Michael Neuling <mikey@neuling.org>
>
> Add a riscv,pmu device tree node with SBI PMU event mappings for the
> SiFive X280 hardware performance counters. This enables OpenSBI to
> expose the SBI PMU extension, allowing Linux perf to use the 4
> programmable counters (mhpmcounter3-6) across 3 event classes:
> instruction commit, microarchitectural, and memory system events.
>
> Event encodings are derived from the SiFive Tenstorrent X280 MC Manual
> (21G3.04.00) Table 13, section 3.10.5.
>
> Assisted-by: Claude:claude-opus-4-6[1m]
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> Signed-off-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
> ---
> Added a dependency of [1] to b4 so that checkpatch doesn't complain
> about the Assisted-by tag
>
> [1] https://lore.kernel.org/all/20260311152039.254244-1-sashal@kernel.org/
> ---
> arch/riscv/boot/dts/tenstorrent/blackhole.dtsi | 48 ++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
Reviewed-by: Drew Fustini <fustini@kernel.org>
If there are no objections, then I will apply it to
tenstorrent-dt-for-next.
Thanks,
Drew
^ permalink raw reply
* Re: [PATCH v4 1/3] dt-bindings: thermal: Add SpacemiT K1 thermal sensor
From: Shuwei Wu @ 2026-04-11 1:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yixun Lan,
Philipp Zabel, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, linux-pm, devicetree, linux-riscv, spacemit,
linux-kernel, Krzysztof Kozlowski, Vincent Legoll, Gong Shuai
In-Reply-To: <20260410-inescapable-glossy-cobra-da4bf4@quoll>
On Fri Apr 10, 2026 at 3:22 PM CST, Krzysztof Kozlowski wrote:
> On Fri, Apr 10, 2026 at 11:31:36AM +0800, Shuwei Wu wrote:
>> Document the SpacemiT K1 Thermal Sensor, which supports
>> monitoring temperatures for five zones: soc, package, gpu, cluster0,
>> and cluster1.
>>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>> Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
>> Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
>> Tested-by: Gong Shuai <gsh517025@gmail.com>
>
> No, not possible. Otherwise explain me how your device tested a YAML
> file.
>
> Drop all of such tags.
Sorry for the noise. I will drop it.
Thanks for pointing out.
>
> Best regards,
> Krzysztof
--
Best regards,
Shuwei Wu
^ permalink raw reply
* [PATCH v2 3/3] pmdomain: arm_scmi: add support for domain hierarchies
From: Kevin Hilman (TI) @ 2026-04-10 23:44 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: Geert Uytterhoeven, linux-pm, devicetree, linux-kernel, arm-scmi,
linux-arm-kernel
In-Reply-To: <20260410-topic-lpm-pmdomain-child-ids-v2-0-83396e4b5f8b@baylibre.com>
After primary SCMI pmdomain is created, use new of_genpd helper which
checks for child domain mappings defined in power-domains-child-ids.
Also remove any child domain mappings when SCMI domain is removed.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
drivers/pmdomain/arm/scmi_pm_domain.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/arm/scmi_pm_domain.c b/drivers/pmdomain/arm/scmi_pm_domain.c
index b5e2ffd5ea64..6d33b3d62ef3 100644
--- a/drivers/pmdomain/arm/scmi_pm_domain.c
+++ b/drivers/pmdomain/arm/scmi_pm_domain.c
@@ -114,6 +114,14 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
dev_set_drvdata(dev, scmi_pd_data);
+ /*
+ * Parse (optional) power-domains-child-ids property to
+ * establish parent-child relationships
+ */
+ ret = of_genpd_add_child_ids(np, scmi_pd_data);
+ if (ret < 0 && ret != -ENOENT)
+ dev_err(dev, "Failed to add child domain hierarchy: %d\n", ret);
+
return 0;
err_rm_genpds:
for (i = num_domains - 1; i >= 0; i--)
@@ -129,9 +137,13 @@ static void scmi_pm_domain_remove(struct scmi_device *sdev)
struct device *dev = &sdev->dev;
struct device_node *np = dev->of_node;
+ scmi_pd_data = dev_get_drvdata(dev);
+
+ /* Remove any parent-child relationships established at probe time */
+ of_genpd_remove_child_ids(np, scmi_pd_data);
+
of_genpd_del_provider(np);
- scmi_pd_data = dev_get_drvdata(dev);
for (i = 0; i < scmi_pd_data->num_domains; i++) {
if (!scmi_pd_data->domains[i])
continue;
--
2.51.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox