* Re: [PATCH v6 0/3] Add Efinix FPGA configuration support
From: Xu Yilun @ 2026-03-30 10:38 UTC (permalink / raw)
To: iansdannapel
Cc: linux-fpga, devicetree, linux-kernel, mdf, yilun.xu, trix, robh,
krzk+dt, conor+dt, neil.armstrong, heiko, marex,
prabhakar.mahadev-lad.rj, dev
In-Reply-To: <20260327114842.1300284-1-iansdannapel@gmail.com>
On Fri, Mar 27, 2026 at 12:48:38PM +0100, iansdannapel@gmail.com wrote:
> From: Ian Dannapel <iansdannapel@gmail.com>
>
> Hi all,
>
> This is v6 of the series adding support for programming Efinix FPGAs
> over SPI using the fpga-mgr subsystem.
Sorry, I'm on vacation and cannot make it in v7.0-rc, though I assume it
should be neat as a v6.
Will try to merge it in v7.1-rc, thanks.
^ permalink raw reply
* [PATCH] media: dt-bindings: media: renesas,fcp: Document RZ/G3L FCPVD IP
From: Biju @ 2026-03-30 11:00 UTC (permalink / raw)
To: Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm
Cc: Biju Das, linux-media, linux-renesas-soc, devicetree,
linux-kernel, Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
The FCPVD block on the RZ/G3L SoC is identical to the one found on the
RZ/G2L SoC. Document RZ/G3L FCPVD IP.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
Documentation/devicetree/bindings/media/renesas,fcp.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.yaml b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
index b5eff6fec8a9..86b176a634e1 100644
--- a/Documentation/devicetree/bindings/media/renesas,fcp.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
@@ -30,6 +30,7 @@ properties:
- renesas,r9a07g043u-fcpvd # RZ/G2UL
- renesas,r9a07g044-fcpvd # RZ/G2{L,LC}
- renesas,r9a07g054-fcpvd # RZ/V2L
+ - renesas,r9a08g046-fcpvd # RZ/G3L
- renesas,r9a09g056-fcpvd # RZ/V2N
- renesas,r9a09g057-fcpvd # RZ/V2H(P)
- const: renesas,fcpv # Generic FCP for VSP fallback
@@ -77,6 +78,7 @@ allOf:
- renesas,r9a07g043u-fcpvd
- renesas,r9a07g044-fcpvd
- renesas,r9a07g054-fcpvd
+ - renesas,r9a08g046-fcpvd
- renesas,r9a09g056-fcpvd
- renesas,r9a09g057-fcpvd
then:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 3/6] arm64: dts: qcom: Add AYN QCS8550 Common
From: Konrad Dybcio @ 2026-03-30 11:00 UTC (permalink / raw)
To: Aaron Kling
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Teguh Sobirin
In-Reply-To: <CALHNRZ_tomry+tJh8g2mCZBM1XQcaA7p1ycK03GH1gPQy3geqg@mail.gmail.com>
On 3/27/26 10:26 PM, Aaron Kling wrote:
> On Tue, Mar 24, 2026 at 7:36 AM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 3/23/26 5:27 PM, Aaron Kling via B4 Relay wrote:
>>> From: Teguh Sobirin <teguh@sobir.in>
>>>
>>> This contains everything common between the AYN QCS8550 devices. It will
>>> be included by device specific dts'.
>>>
>>> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
>>> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>> ---
>>
>> [...]
>>
>>> + sound {
>>> + compatible = "qcom,sm8550-sndcard", "qcom,sm8450-sndcard";
>>> + pinctrl-0 = <&lpi_i2s3_active>;
>>> + pinctrl-names = "default";
>>> +
>>> + model = "AYN-Odin2";
>>
>> Is this enough of a distinction? Do you need to make any changes to the
>> one with a HDMI bridge to get HDMI audio?
>
> After this quesstion, I tried to verify hdmi and am unable to even get
> the connector to come up. The lt8912b driver complains that the
> connector doesn't support edid read. Which per the current connector
> node is correct, none of the devices list a ddc node. I am trying to
> investigate this further, but vendor source release unfortunately
> appears to be missing pieces related to this. And no other current
> qcom device uses this bridge to take a guess at which controller the
> ddc is on.
Go through the I2C buses that are enabled on the vendor kernel and try
inspecting them with toos like i2cdetect
>
> On a related note, I'm not sure hdmi is covered in the audio topology.
Since this is a DSI bridge, I'd imagine it needs a separate connection
to the SoC's sound hardware. We've had similar occurences in the past,
e.g. this on the SM8250 RB5 board (qrb5165-rb5.dts):
https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/Qualcomm/sm8250/HDMI.conf
Maybe +Dmitry could help you out
Konrad
> What I'm using is here [0]. This is in a fork of the topology repo
> with aosp build rules added. Speakers work, headphones out and in
> work. DP works only with the pending q6dsp fixups series, which I
> should probably narrow down and ask for a 6.18 backport for. The ucm
> config [1] I'm basing tests on doesn't handle the built-in mic and I
> haven't been able to figure that out yet, so that's also unknown.
>
> Aaron
>
> [0] https://github.com/LineageOS/android_hardware_qcom_audioreach-topology/blob/ad67f3777b1d4dec5289bc7117f2ec34521be7e6/AYN-Odin2.m4
> [1] https://github.com/AYNTechnologies/alsa-ucm-conf/commit/d33738b93e9560e8d9e08a024cc84c8055bb7eb9
^ permalink raw reply
* Re: [PATCH] arm64: dts: amlogic: t7: khadas-vim4: Remove invalid property
From: Ronald Claveau @ 2026-03-30 11:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
kernel test robot, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <36822ad1-c73d-4903-bd39-091874558f10@kernel.org>
On 3/30/26 12:38 PM, Krzysztof Kozlowski wrote:
> On 30/03/2026 12:21, Ronald Claveau wrote:
>> Fix introduced invalid property for Khadas VIM4 sdcard regulator.
>>
>> arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: regulator-sdcard-3v3 (regulator-fixed): Unevaluated properties are not allowed ('enable-active-low' was unexpected)
>>
>
> Fixes commit?
>
Thanks for your review I will add a Fixes tag like that:
Fixes: 60eff75ac67b ("arm64: dts: amlogic: t7: khadas-vim4: Add power
regulators")
> Why there is no such change in recent next? Was it just merged?
>
Yes it is in next-20260327
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts?h=next-20260327&id=60eff75ac67bbf5445bdbd2842b0109ac591441c
> Best regards,
> Krzysztof
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH v4 3/6] arm64: dts: qcom: Add AYN QCS8550 Common
From: Konrad Dybcio @ 2026-03-30 11:01 UTC (permalink / raw)
To: Aaron Kling, Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Teguh Sobirin
In-Reply-To: <78d7d85e-ecd8-42ca-b59e-b7fbcecf1502@oss.qualcomm.com>
On 3/30/26 1:00 PM, Konrad Dybcio wrote:
> On 3/27/26 10:26 PM, Aaron Kling wrote:
>> On Tue, Mar 24, 2026 at 7:36 AM Konrad Dybcio
>> <konrad.dybcio@oss.qualcomm.com> wrote:
>>>
>>> On 3/23/26 5:27 PM, Aaron Kling via B4 Relay wrote:
>>>> From: Teguh Sobirin <teguh@sobir.in>
>>>>
>>>> This contains everything common between the AYN QCS8550 devices. It will
>>>> be included by device specific dts'.
>>>>
>>>> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
>>>> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
>>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>>> ---
>>>
>>> [...]
>>>
>>>> + sound {
>>>> + compatible = "qcom,sm8550-sndcard", "qcom,sm8450-sndcard";
>>>> + pinctrl-0 = <&lpi_i2s3_active>;
>>>> + pinctrl-names = "default";
>>>> +
>>>> + model = "AYN-Odin2";
>>>
>>> Is this enough of a distinction? Do you need to make any changes to the
>>> one with a HDMI bridge to get HDMI audio?
>>
>> After this quesstion, I tried to verify hdmi and am unable to even get
>> the connector to come up. The lt8912b driver complains that the
>> connector doesn't support edid read. Which per the current connector
>> node is correct, none of the devices list a ddc node. I am trying to
>> investigate this further, but vendor source release unfortunately
>> appears to be missing pieces related to this. And no other current
>> qcom device uses this bridge to take a guess at which controller the
>> ddc is on.
>
> Go through the I2C buses that are enabled on the vendor kernel and try
> inspecting them with toos like i2cdetect
>
>>
>> On a related note, I'm not sure hdmi is covered in the audio topology.
>
> Since this is a DSI bridge, I'd imagine it needs a separate connection
> to the SoC's sound hardware. We've had similar occurences in the past,
> e.g. this on the SM8250 RB5 board (qrb5165-rb5.dts):
>
> https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/Qualcomm/sm8250/HDMI.conf
>
> Maybe +Dmitry could help you out
(mentions work better when you actually add the people you intended to
- fixing that)
>
> Konrad
>
>> What I'm using is here [0]. This is in a fork of the topology repo
>> with aosp build rules added. Speakers work, headphones out and in
>> work. DP works only with the pending q6dsp fixups series, which I
>> should probably narrow down and ask for a 6.18 backport for. The ucm
>> config [1] I'm basing tests on doesn't handle the built-in mic and I
>> haven't been able to figure that out yet, so that's also unknown.
>>
>> Aaron
>>
>> [0] https://github.com/LineageOS/android_hardware_qcom_audioreach-topology/blob/ad67f3777b1d4dec5289bc7117f2ec34521be7e6/AYN-Odin2.m4
>> [1] https://github.com/AYNTechnologies/alsa-ucm-conf/commit/d33738b93e9560e8d9e08a024cc84c8055bb7eb9
^ permalink raw reply
* [PATCH v3 0/2] dt-bindings: power: reset: cortina: Convert to DT schema and rename node
From: Khushal Chitturi @ 2026-03-30 11:01 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
Convert the Cortina Systems Gemini Poweroff Controller bindings to
DT schema and update corresponding dtsi file with new node name
---
Khushal Chitturi (2):
dt-bindings: power: reset: cortina,gemini-power-controller: convert to
DT schema
ARM: dts: gemini: Rename power controller node to poweroff
.../cortina,gemini-power-controller.yaml | 42 +++++++++++++++++++
.../bindings/power/reset/gemini-poweroff.txt | 17 --------
arch/arm/boot/dts/gemini/gemini.dtsi | 2 +-
3 files changed, 43 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
delete mode 100644 Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
--
2.53.0
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: kaanpaali: Add USB support for QRD platform
From: Dmitry Baryshkov @ 2026-03-30 11:01 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Konrad Dybcio, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Ronak Raheja, Jingyi Wang
In-Reply-To: <eacea84c-ce3a-41eb-835c-7da55d130d88@oss.qualcomm.com>
On Sun, Mar 29, 2026 at 11:45:48PM +0530, Krishna Kurapati wrote:
>
>
> On 3/29/2026 11:37 PM, Dmitry Baryshkov wrote:
> > On Sun, Mar 29, 2026 at 11:22:49PM +0530, Krishna Kurapati wrote:
> > > From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
> > >
> > > Enable USB support on Kaanapali QRD variant. Enable USB controller in
> > > device mode till glink node is added.
> >
> > Why can't it be added as a part of this patchset?
> >
>
> Hi Dmitry,
>
> SoCCP changes are not yet acked. Hence I wanted to get the base changes in.
=> commit message or cover letter, please.
>
> Regards,
> Krishna,
>
> > >
> > > Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
> > > Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> > > Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> > > ---
> > > arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 27 ++++++++++++++++++++++
> > > 1 file changed, 27 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
> > > index 6a7eb7f4050a..1929ea273a4f 100644
> > > --- a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
> > > +++ b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
> > > @@ -80,6 +80,11 @@ key-volume-up {
> > > wakeup-source;
> > > };
> > > };
> > > +
> > > + pmih0108_e1_eusb2_repeater {
> > > + vdd18-supply = <&vreg_l15b_1p8>;
> > > + vdd3-supply = <&vreg_l5b_3p1>;
> > > + };
> > > };
> > > &apps_rsc {
> > > @@ -821,3 +826,25 @@ &ufs_mem_phy {
> > > status = "okay";
> > > };
> > > +
> > > +&usb {
> > > + dr_mode = "peripheral";
> > > +
> > > + status = "okay";
> > > +};
> > > +
> > > +&usb_hsphy {
> > > + vdd-supply = <&vreg_l4f_0p8>;
> > > + vdda12-supply = <&vreg_l1d_1p2>;
> > > +
> > > + phys = <&pmih0108_e1_eusb2_repeater>;
> > > +
> > > + status = "okay";
> > > +};
> > > +
> > > +&usb_dp_qmpphy {
> > > + vdda-phy-supply = <&vreg_l1d_1p2>;
> > > + vdda-pll-supply = <&vreg_l4f_0p8>;
> > > +
> > > + status = "okay";
> > > +};
> > > --
> > > 2.34.1
> > >
> >
>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Khushal Chitturi @ 2026-03-30 11:01 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
In-Reply-To: <20260330110135.10316-1-khushalchitturi@gmail.com>
Convert the Cortina Systems Gemini Poweroff Controller bindings to
DT schema.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Changelog:
v2 -> v3:
- Used generic node name "poweroff" instead of "gemini-poweroff".
v1 -> v2:
- Renamed the node from "power-controller" to "gemini-poweroff" to resolve dtschema warnings.
Note:
* This patch series is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../cortina,gemini-power-controller.yaml | 42 +++++++++++++++++++
.../bindings/power/reset/gemini-poweroff.txt | 17 --------
2 files changed, 42 insertions(+), 17 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
delete mode 100644 Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
diff --git a/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
new file mode 100644
index 000000000000..ef5e04f86be1
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/cortina,gemini-power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cortina Systems Gemini Poweroff Controller
+
+maintainers:
+ - Linus Walleij <linusw@kernel.org>
+
+description: |
+ The Gemini power controller is a dedicated IP block in the Cortina Gemini SoC that
+ controls system power-down operations.
+
+properties:
+ compatible:
+ const: cortina,gemini-power-controller
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ poweroff@4b000000 {
+ compatible = "cortina,gemini-power-controller";
+ reg = <0x4b000000 0x100>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt b/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
deleted file mode 100644
index 7fec3e100214..000000000000
--- a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Device-Tree bindings for Cortina Systems Gemini Poweroff
-
-This is a special IP block in the Cortina Gemini SoC that only
-deals with different ways to power the system down.
-
-Required properties:
-- compatible: should be "cortina,gemini-power-controller"
-- reg: should contain the physical memory base and size
-- interrupts: should contain the power management interrupt
-
-Example:
-
-power-controller@4b000000 {
- compatible = "cortina,gemini-power-controller";
- reg = <0x4b000000 0x100>;
- interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
-};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: amlogic: t7: khadas-vim4: Remove invalid property
From: Krzysztof Kozlowski @ 2026-03-30 11:01 UTC (permalink / raw)
To: Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
kernel test robot, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <02927f87-fa91-457d-af2b-a7610ef481e8@aliel.fr>
On 30/03/2026 13:01, Ronald Claveau wrote:
> On 3/30/26 12:38 PM, Krzysztof Kozlowski wrote:
>> On 30/03/2026 12:21, Ronald Claveau wrote:
>>> Fix introduced invalid property for Khadas VIM4 sdcard regulator.
>>>
>>> arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: regulator-sdcard-3v3 (regulator-fixed): Unevaluated properties are not allowed ('enable-active-low' was unexpected)
>>>
>>
>> Fixes commit?
>>
>
> Thanks for your review I will add a Fixes tag like that:
> Fixes: 60eff75ac67b ("arm64: dts: amlogic: t7: khadas-vim4: Add power
> regulators")
>
>> Why there is no such change in recent next? Was it just merged?
>>
>
> Yes it is in next-20260327
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts?h=next-20260327&id=60eff75ac67bbf5445bdbd2842b0109ac591441c
Thanks, With fixes tag added:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 2/2] ARM: dts: gemini: Rename power controller node to poweroff
From: Khushal Chitturi @ 2026-03-30 11:01 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
In-Reply-To: <20260330110135.10316-1-khushalchitturi@gmail.com>
Update the node name for the Cortina Gemini power controller from
power-controller to poweroff since node "power controller" is
reserved for power domain controller.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Changelog:
v2 -> v3:
- Used generic node name "poweroff" instead of "gemini-poweroff".
arch/arm/boot/dts/gemini/gemini.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/gemini/gemini.dtsi b/arch/arm/boot/dts/gemini/gemini.dtsi
index befe322bd7de..910faabf76ef 100644
--- a/arch/arm/boot/dts/gemini/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini/gemini.dtsi
@@ -228,7 +228,7 @@ intcon: interrupt-controller@48000000 {
#interrupt-cells = <2>;
};
- power-controller@4b000000 {
+ poweroff@4b000000 {
compatible = "cortina,gemini-power-controller";
reg = <0x4b000000 0x100>;
interrupts = <26 IRQ_TYPE_EDGE_RISING>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v8 02/10] dt-bindings: power: samsung: add google,gs101-pd
From: Krzysztof Kozlowski @ 2026-03-30 11:03 UTC (permalink / raw)
To: André Draszik
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm
In-Reply-To: <abeff7983dc08c3aeee8b504f34b71b1a2fcdb78.camel@linaro.org>
On 30/03/2026 12:59, André Draszik wrote:
> On Mon, 2026-03-30 at 12:55 +0200, Krzysztof Kozlowski wrote:
>> On 30/03/2026 12:52, André Draszik wrote:
>>>> Your patchset is organized in odd way - first patch for me, then not for
>>>> me, then again two patches for me. Please keep it consistent. Or better,
>>>> decouple since there are no dependencies according to cover letter.
>>>
>>> I'll update the cover letter to describe the dependencies. 4 depends on 2,
>>
>>
>> How 4 (soc) patch depends on 2 (pm domains)? What is exactly the dependency?
>
> 4 updates the soc-level pmu binding of gs101 to have gs101-power-domain
> child-nodes, which are introduced in 2
>
You described what the patch is doing, but that was not my question.
What is the dependency exactly.
This is ping pong, so I finish discussions here, but to be clear -
entire patchset cannot be merged.
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Ulf Hansson @ 2026-03-30 11:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <3bb6b71e-947b-4248-95ba-79852f743c1d@kernel.org>
On Mon, 30 Mar 2026 at 12:17, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 30/03/2026 12:13, Ulf Hansson wrote:
> > On Mon, 30 Mar 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >> On 23/03/2026 12:13, Ulf Hansson wrote:
> >>> Hi Krzysztof,
> >>>
> >>> On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>>
> >>>>
> >>>> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote:
> >>>>> This series adds support for the power domains on Google GS101.
> >>>>>
> >>>>> There are a few differences compared to SoCs already supported by this
> >>>>> driver:
> >>>>> * register access does not work via plain ioremap() / readl() /
> >>>>> writel().
> >>>>> Instead, the regmap created by the PMU driver must be used (which
> >>>>> uses Arm SMCC calls under the hood).
> >>>>> * DTZPC: a call needs to be made before and after power domain off/on,
> >>>>> to inform the EL3 firmware of the request.
> >>>>> * power domains can and are fed by a regulator rail and therefore
> >>>>> regulator control needed be implemented.
> >>>>>
> >>>>> [...]
> >>>>
> >>>> Applied, thanks!
> >>>>
> >>>> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc
> >>>> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba
> >>>> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding
> >>>> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c
> >>>> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
> >>>> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080
> >>>>
> >>>> Best regards,
> >>>
> >>> Usually I pick up the power-domain related changes for the DT bindings
> >>> and host them via an immutable branch called "dt". If needed, SOC
> >>> maintainers can pull it to apply/test the corresponding DTS changes.
> >>>
> >>> That said, I am open to whatever you think is best here. Perhaps it's
> >>> easier if you can drop the DT patches and provide your acks instead or
> >>> if you can share them via an immutable branch for me to pull?
> >>
> >>
> >> I did not pick up any pmdomain binding patches. I picked up only soc and
> >> according to cover letter there are no dependencies between anything here.
> >
> > As I understand it, they are all related and some even depend on each
>
> I raised exactly that questions but no answers.
>
> > other. I think keeping all four DT patches together makes sense.
>
> Why? What is the dependency?
I defer to André to clarify this for us.
>
> >
> > Although, as I said, if you think it's best to funnel them through
> > your tree, please do and then share them via an immutable branch, so I
> > can apply the pmdomain driver changes.
>
> soc must go via my tree, but there is no reason to take the pmdomain
> binding patch. So I did not take.
Yes, they belong to soc/platform, which is common for most
power-domain providers.
To allow us to merge/maintain power-domain provider *driver* changes
separately, we needed a way to manage the corresponding DT bindings.
That's why I am hosting the immutable "dt" branch for these, which
soc/platform maintainers can pull-in when they need it.
Of course, doing it the other way around is also possible. Just let me
know what you prefer.
>
> But anyway, I just noticed that I dropped everything: this introduces
> new warnings which were nowhere addressed or explained. So regardless
> how this should go, please do not apply anything - it's broken and
> author is silent.
Right, I will await your confirmation!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Dmitry Baryshkov @ 2026-03-30 11:15 UTC (permalink / raw)
To: Dikshita Agarwal
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Jonathan Marek,
Ulf Hansson, Rafael J. Wysocki, Bryan O'Donoghue,
Vikash Garodia, Mauro Carvalho Chehab, Stanimir Varbanov,
Abhinav Kumar, Hans Verkuil, Stefan Schmidt, Konrad Dybcio,
Bryan O'Donoghue, Dikshita Agarwal, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-pm, linux-media,
Mauro Carvalho Chehab
In-Reply-To: <5e2635ac-35de-645b-b5e7-235923f844ce@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 10:55:02AM +0530, Dikshita Agarwal wrote:
>
>
> On 2/9/2026 7:02 AM, Dmitry Baryshkov wrote:
> > On SM8250 most of the video clocks are powered by the MMCX domain, while
> > the PLL is powered on by the MX domain. Extend the driver to support
> > scaling both power domains, while keeping compatibility with the
> > existing DTs, which define only the MX domain.
> >
> > Fixes: 79865252acb6 ("media: iris: enable video driver probe of SM8250 SoC")
> > Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > ---
> > drivers/media/platform/qcom/iris/iris_platform_gen1.c | 2 +-
> > drivers/media/platform/qcom/iris/iris_probe.c | 7 +++++++
> > 2 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen1.c b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > index df8e6bf9430e..aa71f7f53ee3 100644
> > --- a/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > +++ b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > @@ -281,7 +281,7 @@ static const struct bw_info sm8250_bw_table_dec[] = {
> >
> > static const char * const sm8250_pmdomain_table[] = { "venus", "vcodec0" };
> >
> > -static const char * const sm8250_opp_pd_table[] = { "mx" };
> > +static const char * const sm8250_opp_pd_table[] = { "mx", "mmcx" };
> >
> > static const struct platform_clk_data sm8250_clk_table[] = {
> > {IRIS_AXI_CLK, "iface" },
> > diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
> > index 7b612ad37e4f..74ec81e3d622 100644
> > --- a/drivers/media/platform/qcom/iris/iris_probe.c
> > +++ b/drivers/media/platform/qcom/iris/iris_probe.c
> > @@ -64,6 +64,13 @@ static int iris_init_power_domains(struct iris_core *core)
> > return ret;
> >
> > ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data, &core->opp_pmdomain_tbl);
> > + /* backwards compatibility for incomplete ABI SM8250 */
> > + if (ret == -ENODEV &&
> > + of_device_is_compatible(core->dev->of_node, "qcom,sm8250-venus")) {
> > + iris_opp_pd_data.num_pd_names--;
> > + ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data,
> > + &core->opp_pmdomain_tbl);
> > + }
> > if (ret < 0)
> > return ret;
> >
> >
>
> Hitting below compilation error on latest kernel
>
> drivers/media/platform/qcom/iris/iris_probe.c: In function
> ‘iris_init_power_domains’:
> drivers/media/platform/qcom/iris/iris_probe.c:71:46: error: decrement of
> read-only member ‘num_pd_names’
> 71 | iris_opp_pd_data.num_pd_names--;
See commit 7ad7f43e568b ("pmdomain: de-constify fields struct
dev_pm_domain_attach_data")
>
> Could you please check and fix.
>
> Thanks,
> Dikshita
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 0/5] SDM670 LPASS LPI pin controller support
From: Konrad Dybcio @ 2026-03-30 11:17 UTC (permalink / raw)
To: Richard Acayan, Bjorn Andersson, Linus Walleij, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Srinivas Kandagatla, linux-arm-msm, linux-gpio, devicetree
In-Reply-To: <acc5dKPef3v4cvbC@rdacayan>
On 3/28/26 3:14 AM, Richard Acayan wrote:
> On Fri, Mar 27, 2026 at 10:10:31PM -0400, Richard Acayan wrote:
>> This adds support for the LPASS LPI pin controller on SDM670, which
>> controls some audio pins (e.g. TDM or PDM busses). The ADSP patches are
>> not sent yet.
>>
>> Dependencies:
>> - SDM670 Basic SoC thermal zones (devicetree nodes are touching)
>> https://lore.kernel.org/r/20260310002037.1863-1-mailingradian@gmail.com
>> - Support for the Pixel 3a XL with the Tianma panel (for reserved GPIOs)
>> https://lore.kernel.org/r/20260310002606.16413-1-mailingradian@gmail.com
>>
>> Changes since v2 (https://lore.kernel.org/r/20260310012446.32226-1-mailingradian@gmail.com):
>> - add minItems and maxItems (1/5)
>> - add review tags (2-5/5)
>
> Uh, it seems I dropped them (pun intended).
Please send a v4 with them re-collected (incl. Krzysztof's new tag
on your dt patch)
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/1] arm64: dts: qcom: hamoa: Fix incomplete Root Port property migration
From: Konrad Dybcio @ 2026-03-30 11:21 UTC (permalink / raw)
To: Ziyue Zhang, andersson, konradybcio, robh, krzk+dt, conor+dt,
jingoohan1, mani, lpieralisi, kwilczynski, bhelgaas, johan+linaro,
vkoul, kishon, neil.armstrong, abel.vesa, kw
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pci, linux-phy,
qiang.yu, quic_krichai, quic_vbadigan
In-Reply-To: <20260330020934.3501247-1-ziyue.zhang@oss.qualcomm.com>
On 3/30/26 4:09 AM, Ziyue Zhang wrote:
> Historically, the Qualcomm PCIe controller node (Host bridge) described
> all Root Port properties, such as PHY, PERST#, and WAKE#. But to provide
> a more accurate hardware description and to support future multi-Root Port
> controllers, these properties were moved to the Root Port node in the
> devicetree bindings.
[...]
> --- a/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
> +++ b/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
> @@ -1033,9 +1033,6 @@ &mdss_dp3_phy {
> };
>
> &pcie4 {
> - perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
> pinctrl-0 = <&pcie4_default>;
> pinctrl-names = "default";
>
> @@ -1050,6 +1047,8 @@ &pcie4_phy {
> };
>
> &pcie4_port0 {
> + reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> wifi@0 {
> compatible = "pci17cb,1107";
nit: This single hunk misses a \n before the subnode, but maybe Bjorn
could fix that up while applying?
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v4 3/6] arm64: dts: qcom: msm8953-flipkart-rimob: Enable display and GPU
From: Konrad Dybcio @ 2026-03-30 11:22 UTC (permalink / raw)
To: cristian_ci, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: dri-devel, devicetree, linux-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260327-rimob-new-features-v4-3-06edff9c4509@protonmail.com>
On 3/27/26 3:30 PM, Cristian Cozzolino via B4 Relay wrote:
> From: Cristian Cozzolino <cristian_ci@protonmail.com>
>
> Add the description for the display panel found on this phone.
> And with this done we can also enable the GPU and set the zap shader
> firmware path.
>
> Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
> ---
[...]
> &rpm_requests {
> regulators {
> compatible = "qcom,rpm-pm8953-regulators";
> @@ -244,6 +310,13 @@ gpio_key_default: gpio-key-default-state {
> drive-strength = <2>;
> bias-pull-up;
> };
> +
> + panel_default: panel-default-state {
> + pins = "gpio61";
> + function = "gpio";
> + drive-strength = <8>;
> + bias-disable;
> + };
Nit: ideally the pin entries would be ordered by the GPIO index,
via:
https://docs.kernel.org/devicetree/bindings/dts-coding-style.html#order-of-nodes
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v1 3/6] arm64: dts: qcom: talos: Add QSPI support
From: Viken Dadhaniya @ 2026-03-30 11:23 UTC (permalink / raw)
To: Konrad Dybcio, Dmitry Baryshkov
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-spi, devicetree, linux-kernel
In-Reply-To: <9d7c5d36-c981-43ed-a08b-3b75c25fad1e@oss.qualcomm.com>
On 3/25/2026 3:02 PM, Konrad Dybcio wrote:
> On 3/24/26 9:51 PM, Dmitry Baryshkov wrote:
>> On Tue, Mar 24, 2026 at 06:43:20PM +0530, Viken Dadhaniya wrote:
>>> The Talos (QCS615) platform includes a QSPI controller used for accessing
>>> external flash storage. Add the QSPI OPP table, TLMM pinmux entries, and
>>> the QSPI controller node to enable support for this hardware.
>>>
>>> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/talos.dtsi | 80 +++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 80 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
>>> index 75716b4a58d6..fd727924b8ca 100644
>>> --- a/arch/arm64/boot/dts/qcom/talos.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/talos.dtsi
>>> @@ -530,6 +530,25 @@ cdsp_smp2p_in: slave-kernel {
>>>
>>> };
>>>
>>> + qspi_opp_table: opp-table-qspi {
>>
>> Why is it not defined inside the QSPI device itself?
>
> The QSPI device has #address-cells = <1>, so we'd get:
>
> Warning (spi_bus_reg): /soc@0/spi@88dc000/opp-table-qspi: missing or empty reg property
>
> Konrad
Yes, I am seeing the same warning when the OPP table is placed inline
under the QSPI node.
Given that opp-table nodes are not addressable bus devices and therefore
do not define a reg property, what would be your preferred way to model
this while keeping the DT warning‑free?
Would placing the OPP table as a sibling of the QSPI node (for example
under the same &soc scope) and referencing it via operating-points-v2 be
acceptable in this case, even though there is only a single QSPI instance?
Thanks for your guidance.
Best regards,
Viken
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Krzysztof Kozlowski @ 2026-03-30 11:24 UTC (permalink / raw)
To: Ulf Hansson
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <CAPDyKFpOPC2stAJ262jdap-=ByY09AeQ0kj6p_9FTGJBx+Tu-Q@mail.gmail.com>
On 30/03/2026 13:12, Ulf Hansson wrote:
>
>>
>>>
>>> Although, as I said, if you think it's best to funnel them through
>>> your tree, please do and then share them via an immutable branch, so I
>>> can apply the pmdomain driver changes.
>>
>> soc must go via my tree, but there is no reason to take the pmdomain
>> binding patch. So I did not take.
>
> Yes, they belong to soc/platform, which is common for most
> power-domain providers.
What does belong to soc/platform? pmdomain changes? No, they do not...
>
> To allow us to merge/maintain power-domain provider *driver* changes
> separately, we needed a way to manage the corresponding DT bindings.
Nothing stops that, there is no dependency. For a week I am saying there
are no dependencies. If there are, please provide any sort of
argument/proof, otherwise there is nothing to do here.
> That's why I am hosting the immutable "dt" branch for these, which
> soc/platform maintainers can pull-in when they need it.
>
> Of course, doing it the other way around is also possible. Just let me
> know what you prefer.
Nothing like that is necessary.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/1] arm64: dts: qcom: hamoa: Fix incomplete Root Port property migration
From: Manivannan Sadhasivam @ 2026-03-30 11:26 UTC (permalink / raw)
To: andersson, Ziyue Zhang
Cc: konradybcio, robh, krzk+dt, conor+dt, jingoohan1, lpieralisi,
kwilczynski, bhelgaas, johan+linaro, vkoul, kishon,
neil.armstrong, abel.vesa, kw, linux-arm-msm, devicetree,
linux-kernel, linux-pci, linux-phy, qiang.yu, quic_krichai,
quic_vbadigan
In-Reply-To: <20260330020934.3501247-1-ziyue.zhang@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 10:09:34AM +0800, Ziyue Zhang wrote:
> Historically, the Qualcomm PCIe controller node (Host bridge) described
> all Root Port properties, such as PHY, PERST#, and WAKE#. But to provide
> a more accurate hardware description and to support future multi-Root Port
> controllers, these properties were moved to the Root Port node in the
> devicetree bindings.
>
> Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> initiated this transition for the Hamoa platform by moving the PHY
> property to the Root Port node in hamoa.dtsi. However, it only updated
> some platform specific DTS files for PERST# and WAKE#, leaving others in
> a "mixed" binding state.
>
> While the PCIe controller driver supports both legacy and Root Port
> bindings, It cannot correctly handle a mix of both. In these cases, the
> driver parses the PHY from the Root Port node, but fails to find the
> PERST# property (which it then assumes is not present, as it is optional).
> Consequently, the controller probe succeeds, but PERST# remains
> uncontrolled, preventing PCIe endpoints from functioning.
>
> So, fix the incomplete migration by moving the PERST# and WAKE# properties
> from the controller node to the Root Port node in all remaining Hamoa
> platform DTS files.
>
> Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
FWIW: Bjorn, this is an -rc candidate.
- Mani
> ---
> .../boot/dts/qcom/x1-asus-zenbook-a14.dtsi | 16 ++++++++-----
> arch/arm64/boot/dts/qcom/x1-crd.dtsi | 24 ++++++++++++-------
> arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi | 14 ++++++-----
> .../boot/dts/qcom/x1-hp-omnibook-x14.dtsi | 14 ++++++-----
> .../boot/dts/qcom/x1-microsoft-denali.dtsi | 8 ++++---
> .../dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 6 ++---
> .../qcom/x1e80100-medion-sprchrgd-14-s1.dts | 14 +++++------
> .../dts/qcom/x1p42100-lenovo-thinkbook-16.dts | 14 ++++++-----
> 8 files changed, 64 insertions(+), 46 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi b/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
> index cd062f844b2d..66d566808f58 100644
> --- a/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
> @@ -1079,9 +1079,6 @@ &mdss_dp3_phy {
> };
>
> &pcie4 {
> - perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
> pinctrl-0 = <&pcie4_default>;
> pinctrl-names = "default";
>
> @@ -1095,10 +1092,12 @@ &pcie4_phy {
> status = "okay";
> };
>
> -&pcie6a {
> - perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +&pcie4_port0 {
> + reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> +};
>
> +&pcie6a {
> vddpe-3v3-supply = <&vreg_nvme>;
>
> pinctrl-0 = <&pcie6a_default>;
> @@ -1114,6 +1113,11 @@ &pcie6a_phy {
> status = "okay";
> };
>
> +&pcie6a_port0 {
> + reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +};
> +
> &pm8550_gpios {
> rtmr0_default: rtmr0-reset-n-active-state {
> pins = "gpio10";
> diff --git a/arch/arm64/boot/dts/qcom/x1-crd.dtsi b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
> index 485dcd946757..a9c5c523575e 100644
> --- a/arch/arm64/boot/dts/qcom/x1-crd.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
> @@ -1248,15 +1248,17 @@ &mdss_dp3_phy {
> };
>
> &pcie4 {
> - perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
> pinctrl-0 = <&pcie4_default>;
> pinctrl-names = "default";
>
> status = "okay";
> };
>
> +&pcie4_port0 {
> + reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> +};
> +
> &pcie4_phy {
> vdda-phy-supply = <&vreg_l3i_0p8>;
> vdda-pll-supply = <&vreg_l3e_1p2>;
> @@ -1265,9 +1267,6 @@ &pcie4_phy {
> };
>
> &pcie5 {
> - perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
> -
> vddpe-3v3-supply = <&vreg_wwan>;
>
> pinctrl-0 = <&pcie5_default>;
> @@ -1283,10 +1282,12 @@ &pcie5_phy {
> status = "okay";
> };
>
> -&pcie6a {
> - perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +&pcie5_port0 {
> + reset-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
> +};
>
> +&pcie6a {
> vddpe-3v3-supply = <&vreg_nvme>;
>
> pinctrl-names = "default";
> @@ -1302,6 +1303,11 @@ &pcie6a_phy {
> status = "okay";
> };
>
> +&pcie6a_port0 {
> + reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +};
> +
> &pm8550_gpios {
> kypd_vol_up_n: kypd-vol-up-n-state {
> pins = "gpio6";
> diff --git a/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi b/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
> index 343844cc62f2..0d9a324cc6cc 100644
> --- a/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
> @@ -1081,9 +1081,6 @@ &mdss_dp3_phy {
> };
>
> &pcie4 {
> - perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
> pinctrl-0 = <&pcie4_default>;
> pinctrl-names = "default";
>
> @@ -1098,6 +1095,9 @@ &pcie4_phy {
> };
>
> &pcie4_port0 {
> + reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> +
> wifi@0 {
> compatible = "pci17cb,1107";
> reg = <0x10000 0x0 0x0 0x0 0x0>;
> @@ -1115,9 +1115,6 @@ wifi@0 {
> };
>
> &pcie6a {
> - perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> -
> vddpe-3v3-supply = <&vreg_nvme>;
>
> pinctrl-0 = <&pcie6a_default>;
> @@ -1126,6 +1123,11 @@ &pcie6a {
> status = "okay";
> };
>
> +&pcie6a_port0 {
> + reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +};
> +
> &pcie6a_phy {
> vdda-phy-supply = <&vreg_l1d_0p8>;
> vdda-pll-supply = <&vreg_l2j_1p2>;
> diff --git a/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi b/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
> index 16437139d336..b773a4976d1b 100644
> --- a/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
> @@ -1065,9 +1065,6 @@ &mdss_dp3_phy {
> };
>
> &pcie4 {
> - perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
> pinctrl-0 = <&pcie4_default>;
> pinctrl-names = "default";
>
> @@ -1082,6 +1079,9 @@ &pcie4_phy {
> };
>
> &pcie4_port0 {
> + reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> +
> wifi@0 {
> compatible = "pci17cb,1107";
> reg = <0x10000 0x0 0x0 0x0 0x0>;
> @@ -1099,9 +1099,6 @@ wifi@0 {
> };
>
> &pcie6a {
> - perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> -
> vddpe-3v3-supply = <&vreg_nvme>;
>
> pinctrl-0 = <&pcie6a_default>;
> @@ -1110,6 +1107,11 @@ &pcie6a {
> status = "okay";
> };
>
> +&pcie6a_port0 {
> + reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +};
> +
> &pcie6a_phy {
> vdda-phy-supply = <&vreg_l1d_0p8>;
> vdda-pll-supply = <&vreg_l2j_1p2>;
> diff --git a/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi b/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
> index 6ab595b6ea30..dd2de1f723b0 100644
> --- a/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
> @@ -964,9 +964,6 @@ wifi@0 {
> };
>
> &pcie6a {
> - perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> -
> vddpe-3v3-supply = <&vreg_nvme>;
>
> pinctrl-0 = <&pcie6a_default>;
> @@ -982,6 +979,11 @@ &pcie6a_phy {
> status = "okay";
> };
>
> +&pcie6a_port0 {
> + reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +};
> +
> &pm8550_gpios {
> rtmr0_default: rtmr0-reset-n-active-state {
> pins = "gpio10";
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
> index bd0e3009fb41..beb1475d7fa0 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
> +++ b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
> @@ -1126,9 +1126,6 @@ &mdss_dp3_phy {
> };
>
> &pcie4 {
> - perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
> pinctrl-0 = <&pcie4_default>;
> pinctrl-names = "default";
>
> @@ -1143,6 +1140,9 @@ &pcie4_phy {
> };
>
> &pcie4_port0 {
> + reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> +
> wifi@0 {
> compatible = "pci17cb,1107";
> reg = <0x10000 0x0 0x0 0x0 0x0>;
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts b/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
> index 763efb9e070d..23a298248a29 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
> +++ b/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
> @@ -1033,9 +1033,6 @@ &mdss_dp3_phy {
> };
>
> &pcie4 {
> - perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
> pinctrl-0 = <&pcie4_default>;
> pinctrl-names = "default";
>
> @@ -1050,6 +1047,8 @@ &pcie4_phy {
> };
>
> &pcie4_port0 {
> + reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> wifi@0 {
> compatible = "pci17cb,1107";
> reg = <0x10000 0x0 0x0 0x0 0x0>;
> @@ -1067,10 +1066,6 @@ wifi@0 {
> };
>
> &pcie6a {
> - perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> -
> - wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> -
> vddpe-3v3-supply = <&vreg_nvme>;
>
> pinctrl-0 = <&pcie6a_default>;
> @@ -1086,6 +1081,11 @@ &pcie6a_phy {
> status = "okay";
> };
>
> +&pcie6a_port0 {
> + reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +};
> +
> &pm8550_gpios {
> rtmr0_default: rtmr0-reset-n-active-state {
> pins = "gpio10";
> diff --git a/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts b/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts
> index ab309d547ed5..500809772097 100644
> --- a/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts
> +++ b/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts
> @@ -1131,9 +1131,6 @@ &mdss_dp3_phy {
> };
>
> &pcie4 {
> - perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
> pinctrl-0 = <&pcie4_default>;
> pinctrl-names = "default";
>
> @@ -1148,6 +1145,9 @@ &pcie4_phy {
> };
>
> &pcie4_port0 {
> + reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> +
> wifi@0 {
> compatible = "pci17cb,1107";
> reg = <0x10000 0x0 0x0 0x0 0x0>;
> @@ -1165,9 +1165,6 @@ wifi@0 {
> };
>
> &pcie6a {
> - perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> - wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> -
> vddpe-3v3-supply = <&vreg_nvme>;
>
> pinctrl-0 = <&pcie6a_default>;
> @@ -1183,6 +1180,11 @@ &pcie6a_phy {
> status = "okay";
> };
>
> +&pcie6a_port0 {
> + reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +};
> +
> &pm8550_pwm {
> status = "okay";
> };
> --
> 2.43.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 3/6] arm64: dts: qcom: Add AYN QCS8550 Common
From: Dmitry Baryshkov @ 2026-03-30 11:32 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Aaron Kling, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel, Teguh Sobirin
In-Reply-To: <78d7d85e-ecd8-42ca-b59e-b7fbcecf1502@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 01:00:55PM +0200, Konrad Dybcio wrote:
> On 3/27/26 10:26 PM, Aaron Kling wrote:
> > On Tue, Mar 24, 2026 at 7:36 AM Konrad Dybcio
> > <konrad.dybcio@oss.qualcomm.com> wrote:
> >>
> >> On 3/23/26 5:27 PM, Aaron Kling via B4 Relay wrote:
> >>> From: Teguh Sobirin <teguh@sobir.in>
> >>>
> >>> This contains everything common between the AYN QCS8550 devices. It will
> >>> be included by device specific dts'.
> >>>
> >>> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> >>> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> >>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> >>> ---
> >>
> >> [...]
> >>
> >>> + sound {
> >>> + compatible = "qcom,sm8550-sndcard", "qcom,sm8450-sndcard";
> >>> + pinctrl-0 = <&lpi_i2s3_active>;
> >>> + pinctrl-names = "default";
> >>> +
> >>> + model = "AYN-Odin2";
> >>
> >> Is this enough of a distinction? Do you need to make any changes to the
> >> one with a HDMI bridge to get HDMI audio?
> >
> > After this quesstion, I tried to verify hdmi and am unable to even get
> > the connector to come up. The lt8912b driver complains that the
> > connector doesn't support edid read.
Looking at the driver, please drop lt8912_bridge_edid_read(),
lt8912_bridge_detect() and lt->bridge.ops assignment. Those bits are
lame and useless.
> Which per the current connector
> > node is correct, none of the devices list a ddc node. I am trying to
> > investigate this further, but vendor source release unfortunately
> > appears to be missing pieces related to this. And no other current
> > qcom device uses this bridge to take a guess at which controller the
> > ddc is on.
>
> Go through the I2C buses that are enabled on the vendor kernel and try
> inspecting them with toos like i2cdetect
I'd second this suggestion. The chip doesn't support EDID reading, so it
is (hopefully) handled via some existing bus. Does downstream handle
EDID / HDMI at all?
>
> >
> > On a related note, I'm not sure hdmi is covered in the audio topology.
>
> Since this is a DSI bridge, I'd imagine it needs a separate connection
> to the SoC's sound hardware. We've had similar occurences in the past,
> e.g. this on the SM8250 RB5 board (qrb5165-rb5.dts):
Yes. Unfortunately, the driver doesn't seem to implement audio support.
I'd suggest pinging Lontium for the information regarding InfoFrame and
audio bits programming.
>
> https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/Qualcomm/sm8250/HDMI.conf
>
> Maybe +Dmitry could help you out
>
> Konrad
>
> > What I'm using is here [0]. This is in a fork of the topology repo
> > with aosp build rules added. Speakers work, headphones out and in
> > work. DP works only with the pending q6dsp fixups series, which I
> > should probably narrow down and ask for a 6.18 backport for. The ucm
> > config [1] I'm basing tests on doesn't handle the built-in mic and I
> > haven't been able to figure that out yet, so that's also unknown.
> >
> > Aaron
> >
> > [0] https://github.com/LineageOS/android_hardware_qcom_audioreach-topology/blob/ad67f3777b1d4dec5289bc7117f2ec34521be7e6/AYN-Odin2.m4
> > [1] https://github.com/AYNTechnologies/alsa-ucm-conf/commit/d33738b93e9560e8d9e08a024cc84c8055bb7eb9
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Konrad Dybcio @ 2026-03-30 11:34 UTC (permalink / raw)
To: Bryan O'Donoghue, Neil Armstrong, Bryan O'Donoghue,
Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Vladimir Zapolskiy, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <0101d8bc-1ae8-475e-bb9e-cc1e16db87ec@kernel.org>
On 3/30/26 11:25 AM, Bryan O'Donoghue wrote:
> On 30/03/2026 10:17, Neil Armstrong wrote:
>> On 3/30/26 11:02, Bryan O'Donoghue wrote:
>>> On 30/03/2026 08:49, Neil Armstrong wrote:
>>>> On 3/27/26 18:42, Bryan O'Donoghue wrote:
>>>>> On 27/03/2026 15:28, Neil Armstrong wrote:
>>>>>>> To be frankly honest you can make an argument for it either way. However my honestly held position is analysing other upstream implementations connecting to the PHY means we can't make the PHY device a drivers/phy device - it would have to be a V4L2 device and then for me the question is why is that even required ?
>>>>>>
>>>>>> This is plain wrong, DT definition is different from software implementation, you can do whatever you want if you describe HW accurately.
>>>>>
>>>>> I'm not sure what point it is you are trying to make here. Are you trying to say drivers/phy is OK with you but you want an endpoint ? If so, please just say so.
>>>>
>>>> I'm against using the "phys = <>" property in the CAMSS to reference the PHYs, a "PHY" in the classic terminology is tied to a single consumer, and if it can be shared to multiple consumer you must model a mux or whatever in the middle.
>>>
>>> The CSIPHY-to-CSID routing is runtime-configurable and is already managed by the media controller framework.
>>
>> This is not compatible with the PHY bindings if you don't have a defined MUX device in the middle, it's wrong. You're hiding the muxing details in the CAMSS blob node.
>>
>>>
>>> DT describes static hardware connections. The dynamic mux is a software concern, not a hardware description concern.
>>
>> DT must describe the possible interconnections between the nodes, if a PHY can be used by multiple hardware components, it must be described.
>
> But right now the CAMSS block is described as a single block. There is no CSID device in the kernel _yet_.
>
> When we break CSID into its own block then fine, lets have a debate about a mux then but right now the "nodes" are CAMSS[MONOLITH] <=> CSIPHY there is no DT CSID device to model this to.
Let's take a step back - since any CSIPHY can feed into any CSID (at runtime),
the resulting nodes would either look like:
// hardcoded, m may != n
csid_n: csid@1000000 {
phys = <&csiphy_m>;
};
or
// determined at runtime
csid_n: csid@1000000 {
phys = <&csiphy_0>,
[...]
<&csiphy_n-1>;
};
or we could store them once, centrally, in the "CAMSS_TOP" node and
pass handles around as necessary:
// camss "catalog/manager" driver/library provides CSIDn with PHYm
camss: camss@10000000 {
phys = <&csiphy_0>,
[...]
<&csiphy_n-1>;
csid_n: csid@1000 {
// no PHY references
};
};
Konrad
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: Dmitry Baryshkov @ 2026-03-30 11:37 UTC (permalink / raw)
To: johannes.goede
Cc: Bryan O'Donoghue, Loic Poulain, vladimir.zapolskiy,
laurent.pinchart, kieran.bingham, robh, krzk+dt, andersson,
konradybcio, linux-media, linux-arm-msm, devicetree, linux-kernel,
mchehab
In-Reply-To: <7fc31426-3157-49c7-a30d-dcd7b181fcc6@oss.qualcomm.com>
On Thu, Mar 26, 2026 at 01:06:59PM +0100, johannes.goede@oss.qualcomm.com wrote:
> Hi Dmitry,
>
> On 24-Mar-26 22:27, Dmitry Baryshkov wrote:
> > On Tue, Mar 24, 2026 at 11:00:21AM +0000, Bryan O'Donoghue wrote:
> >> On 23/03/2026 15:31, Loic Poulain wrote:
>
> <snip>
>
> >>> As far as I understand, CDM could also be implemented in a generic way
> >>> within CAMSS, since other CAMSS blocks make use of CDM as well.
> >>> This is something we should discuss further.
> >> My concern is even conservatively if each module adds another 10 ? writes by
> >> the time we get to denoising, sharpening, lens shade correction, those
> >> writes could easily look more like 100.
> >>
> >> What user-space should submit is well documented data-structures which then
> >> get translated into CDM buffers by the OPE and IFE for the various bits of
> >> the pipeline.
> >
> > I hope here you have accent on the well-documented (ideally some kind of
> > the vendor-independent ABI).
>
> The plan is to use the new extensible generic v4l2 ISP parameters
> API for this:
>
> https://docs.kernel.org/6.19/driver-api/media/v4l2-isp.html
>
> What this does is basically divide the parameter buffer (which
> is just a mmap-able bunch of bytes) into variable sized packets/
> blocks with each block having a small header, with a type field.
>
> And then we can have say CCMv1 type for the CCM on the OPE and
> if with some future hardware the format of the CCM (say different
> fixpoint format) ever changes we can simply define a new CCMv2
> and then the parameter buffer can be filled with different
> versions of different parameter blocks depending on the hw.
>
> And on the kernel side there are helpers to parse this, you
> simply pass a list of the types the current hw supports
> + per type data-callback functions.
>
> And then your CCMv1 or CCMv2 helper will get called with
> the matching parameter-data.
This leads to userspace having to know exact format for each hardware
version, which is not nice. At the very least it should be possible to
accept CCMv1 buffers and covert them to CCMv2 when required.
>
> So this way we can easily add new hw support without needing
> to change the existing API, we can simply extend the list
> of parameter types as needed.
>
> Regards,
>
> Hans
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-03-30 11:41 UTC (permalink / raw)
To: Konrad Dybcio, Neil Armstrong, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Vladimir Zapolskiy, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <6d5ebab6-3c4e-4a1c-9578-6e926cbd96de@oss.qualcomm.com>
On 30/03/2026 12:34, Konrad Dybcio wrote:
> Let's take a step back - since any CSIPHY can feed into any CSID (at runtime),
> the resulting nodes would either look like:
>
> // hardcoded, m may != n
> csid_n: csid@1000000 {
> phys = <&csiphy_m>;
> };
>
Well that would be wrong they can connect to any CSID. We'd be churning
the user-space ABI and imposing an artificial constraint on what the hw
can do.
>
> // determined at runtime
> csid_n: csid@1000000 {
> phys = <&csiphy_0>,
> [...]
> <&csiphy_n-1>;
> };
This I think works well and actually maps to what the hardware can do.
This would be where to talk more about Neil's mux.
>
> or we could store them once, centrally, in the "CAMSS_TOP" node and
> pass handles around as necessary:
>
> // camss "catalog/manager" driver/library provides CSIDn with PHYm
> camss: camss@10000000 {
> phys = <&csiphy_0>,
> [...]
> <&csiphy_n-1>;
>
> csid_n: csid@1000 {
> // no PHY references
> };
> };
That could work too.
Either way I think this is to be hashed out when doing CSID.
---
bod
^ permalink raw reply
* Re: [PATCH v6 2/4] usb: misc: onboard_usb_hub: Add Genesys Logic GL3590 hub support
From: Dmitry Baryshkov @ 2026-03-30 11:43 UTC (permalink / raw)
To: Swati Agarwal
Cc: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Icenowy Zheng, Matthias Kaehlcke, Mike Looijmans,
Pin-yen Lin, Chaoyi Chen, J . Neuschäfer, Jens Glathe,
Bjorn Andersson, Konrad Dybcio, linux-usb, devicetree,
linux-kernel, linux-arm-msm
In-Reply-To: <20260318040644.3591478-3-swati.agarwal@oss.qualcomm.com>
On Wed, Mar 18, 2026 at 09:36:42AM +0530, Swati Agarwal wrote:
> Add support for the GL3590 4 ports USB3.2 hub.
>
> Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
> ---
> drivers/usb/misc/onboard_usb_dev.c | 1 +
> drivers/usb/misc/onboard_usb_dev.h | 8 ++++++++
> 2 files changed, 9 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 3/3] arm64,ppc64le/kdump: pass dm-crypt keys to kdump kernel
From: Rob Herring @ 2026-03-30 11:44 UTC (permalink / raw)
To: Coiby Xu
Cc: kexec, linux-arm-kernel, linuxppc-dev, devicetree,
Arnaud Lefebvre, Baoquan he, Dave Young, Kairui Song, Pingfan Liu,
Andrew Morton, Krzysztof Kozlowski, Thomas Staudt, Sourabh Jain,
Will Deacon, Christophe Leroy (CS GROUP), Catalin Marinas,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Saravana Kannan, open list
In-Reply-To: <20260225060347.718905-4-coxu@redhat.com>
On Wed, Feb 25, 2026 at 12:04 AM Coiby Xu <coxu@redhat.com> wrote:
>
> CONFIG_CRASH_DM_CRYPT has been introduced to support LUKS-encrypted
> device dump target by addressing two challenges [1],
> - Kdump kernel may not be able to decrypt the LUKS partition. For some
> machines, a system administrator may not have a chance to enter the
> password to decrypt the device in kdump initramfs after the 1st kernel
> crashes
>
> - LUKS2 by default use the memory-hard Argon2 key derivation function
> which is quite memory-consuming compared to the limited memory reserved
> for kdump.
>
> To also enable this feature for ARM64 and PowerPC, the missing piece is
> to let the kdump kernel know where to find the dm-crypt keys which are
> randomly stored in memory reserved for kdump. Introduce a new device
> tree property dmcryptkeys [2] as similar to elfcorehdr to pass the
> memory address of the stored info of dm-crypt keys to the kdump kernel.
> Since this property is only needed by the kdump kernel, it won't be
> exposed to user space.
>
> [1] https://lore.kernel.org/all/20250502011246.99238-1-coxu@redhat.com/
> [2] https://github.com/devicetree-org/dt-schema/pull/181
>
> Cc: Arnaud Lefebvre <arnaud.lefebvre@clever-cloud.com>
> Cc: Baoquan he <bhe@redhat.com>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: Kairui Song <ryncsn@gmail.com>
> Cc: Pingfan Liu <kernelfans@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Thomas Staudt <tstaudt@de.ibm.com>
> Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
> arch/arm64/kernel/machine_kexec_file.c | 4 ++++
> arch/powerpc/kexec/elf_64.c | 4 ++++
> drivers/of/fdt.c | 21 +++++++++++++++++++++
> drivers/of/kexec.c | 19 +++++++++++++++++++
> 4 files changed, 48 insertions(+)
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox