* Re: [PATCH v10 0/3] riscv: dts: spacemit: Add PMIC regulators usb pcie
From: Yixun Lan @ 2026-04-09 3:39 UTC (permalink / raw)
To: Han Gao
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Chukun Pan,
devicetree, linux-riscv, spacemit, linux-kernel, Han Gao
In-Reply-To: <cover.1775575436.git.gaohan@iscas.ac.cn>
Hi Han,
On 23:28 Tue 07 Apr , Han Gao wrote:
> Changes in v10:
> - patch 3:
> add vin-supply in pcie_vcc3v3
> reorder vcc5v0_usb30
> remove vpcie3v3-supply form pcie1
> - Link to v9: https://lore.kernel.org/linux-riscv/cover.1775417019.git.gaohan@iscas.ac.cn
You should keep all ChangeLog versions, which easy for people to review
backwards, but this isn't a big problem..
>
> Han Gao (3):
> riscv: dts: spacemit: Enable i2c8 adapter for OrangePi RV2
> riscv: dts: spacemit: Define the P1 PMIC regulators for OrangePi RV2
> riscv: dts: spacemit: Enable USB3.0/PCIe on OrangePi RV2
>
> .../boot/dts/spacemit/k1-orangepi-rv2.dts | 217 ++++++++++++++++++
> 1 file changed, 217 insertions(+)
>
>
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
> prerequisite-patch-id: ef6e9c7b5854d0c08066b72f9a7868db8c2140eb
> prerequisite-patch-id: cfe3800f8c791ec4c63e070af9628e88e0fc31b9
> prerequisite-patch-id: b76493e625ae257c8adcd67874178458420e4d47
> prerequisite-patch-id: 88e01dc92c83bd88ddeb78891d3088209fed8d6b
> prerequisite-patch-id: 60336d10ab8322c70596d0f046b6b5c54bb24b54
> prerequisite-patch-id: 68c4d869548687dc115dd91e2ffb8f4c11482d86
> prerequisite-patch-id: fdadcf964c2cb3406160edb579d99a8d5695f8e6
> prerequisite-patch-id: 73b9e745338b0499b849fa4f7f9508987ab39a59
> prerequisite-patch-id: cd26770c2160c3c31a406bd8a6b01ab666180ae0
> prerequisite-patch-id: e5dfddc32cefae195692da8b80e19adf086e4ad7
> prerequisite-patch-id: 7fd53cbe4977598f26148a4bb1cf692bbdb79a09
> prerequisite-patch-id: 96ebac57bb29619b97fe95422206a685825618e9
> prerequisite-patch-id: 00fac16b52f60383db3140e2885f3f7f8d14dd1a
> prerequisite-patch-id: 3b7a60047b922c48e93599f621cb738856f42354
> prerequisite-patch-id: 275c030b963be05dd1041451f539a130ce614277
> prerequisite-patch-id: 93963424b0871e64276af0e0b2199b52e29b4603
> prerequisite-patch-id: 8383188b1c01ed6280629faaa29c37d699ade241
> prerequisite-patch-id: 5f8126b912b924d63d4a1e0c5eb42d212eb0d369
> prerequisite-patch-id: e80af628a2e0b5f2eeb3cb1b5e7133d08bdd2c4e
> prerequisite-patch-id: 0234a6dca15eb91f98a45a46604ce5b4935048a5
I beliew all dependencies are queued already, and those "prerequisite-patch-id"
are rather hard for people to review (I know it's b4 do this conversion),
I would prefer listing them directly in the cover letter
Anyway, I'm ok with this version, so here
Reviewed-by: Yixun Lan <dlan@kernel.org>
--
Yixun Lan (dlan)
^ permalink raw reply
* Re: [PATCH 02/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable UFS controller
From: Xilin Wu @ 2026-04-09 3:38 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound
In-Reply-To: <bb21b9b3-7432-401a-a0d0-1b1970f27770@oss.qualcomm.com>
On 4/8/2026 4:59 PM, Konrad Dybcio wrote:
> On 4/7/26 5:19 PM, Xilin Wu wrote:
>> Add and enable UFS related nodes for this board.
>>
>> Note that UFS Gear-4 Rate-B is unstable due to board and UFS module design
>> limitations. UFS on this board is stable when working at Gear-4 Rate-A.
>>
>> Signed-off-by: Xilin Wu <sophon@radxa.com>
>> ---
>> .../boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts | 23 ++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
>> index bb5a42b038f1..c961d3ec625f 100644
>> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
>> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
>> @@ -959,6 +959,29 @@ &uart5 {
>> status = "okay";
>> };
>>
>> +&ufs_mem_hc {
>> + reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
>> + vcc-supply = <&vreg_l7b_2p96>;
>> + vcc-max-microamp = <800000>;
>> + vccq-supply = <&vreg_l9b_1p2>;
>> + vccq-max-microamp = <900000>;
>> + vccq2-supply = <&vreg_l9b_1p2>;
>> + vccq2-max-microamp = <1300000>;
>> +
>> + /* Gear-4 Rate-B is unstable due to board */
>> + /* and UFS module design limitations */
>
> /* it's a bit weird to add two single-line */
> /* comments near one another for a single paragraph */
Ack. I'll change the comment to single-line in v2.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Konrad
>
--
Best regards,
Xilin Wu <sophon@radxa.com>
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX91
From: Frank Li @ 2026-04-09 3:30 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Dario Binacchi, Markus Niebel, Maud Spierings, Alexander Stein,
Ernest Van Hoecke, Josua Mayer, Francesco Dolcini, Primoz Fiser
In-Reply-To: <1ed7e2100e3feb74c9f0006d5b88e1bba1ad4339.1775669847.git.stefano.r@variscite.com>
On Wed, Apr 08, 2026 at 07:39:45PM +0200, Stefano Radaelli wrote:
> From: Stefano Radaelli <stefano.r@variscite.com>
>
> Add device tree support for the Variscite VAR-SOM-MX91 system on module.
> This SOM is designed to be used with various carrier boards.
>
> The module includes:
> - NXP i.MX91 MPU processor
> - Up to 2GB of LPDDR4 memory
> - Up to 128GB of eMMC storage memory
> - Integrated 10/100/1000 Mbps Ethernet Transceiver
> - Codec audio WM8904
> - WIFI6 dual-band 802.11ax/ac/a/b/g/n with optional 802.15.4 and Bluetooth
>
> Only SOM-specific peripherals are enabled by default. Carrier board
> specific interfaces are left disabled to be enabled in the respective
> carrier board device trees.
>
> Link: https://variscite.com/system-on-module-som/i-mx-9/i-mx-91/var-som-mx91/
> Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
> ---
> .../boot/dts/freescale/imx91-var-som.dtsi | 456 ++++++++++++++++++
what' difference with imx93-var-som ? Can you reuse it?
Frank
>
^ permalink raw reply
* RE: [PATCH 2/2] PCI: amd-mdb: Add amd,versal2-cpm6-host compatible
From: Musham, Sai Krishna @ 2026-04-09 3:09 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: bhelgaas@google.com, lpieralisi@kernel.org, kw@linux.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
cassel@kernel.org, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Simek, Michal, Gogada, Bharat Kumar, Havalige, Thippeswamy
In-Reply-To: <iruxyxjoaozkt5xigchqnqvik5blbxxy7vubmadtcn5jyjnwzn@lvdnttblbx3f>
[Public]
Hi Krzysztof/Manivannan,
> -----Original Message-----
> From: Manivannan Sadhasivam <mani@kernel.org>
> Sent: Saturday, April 4, 2026 8:46 AM
> To: Musham, Sai Krishna <sai.krishna.musham@amd.com>
> Cc: bhelgaas@google.com; lpieralisi@kernel.org; kw@linux.com;
> robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> cassel@kernel.org; linux-pci@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>;
> Gogada, Bharat Kumar <bharat.kumar.gogada@amd.com>; Havalige,
> Thippeswamy <thippeswamy.havalige@amd.com>
> Subject: Re: [PATCH 2/2] PCI: amd-mdb: Add amd,versal2-cpm6-host
> compatible
>
> On Thu, Apr 02, 2026 at 11:30:06PM +0530, Sai Krishna Musham wrote:
> > Add "amd,versal2-cpm6-host" to the OF match table of the AMD MDB PCIe
> > host controller driver.
> >
> > The Versal2 CPM6 host controller is DesignWare-based and supports
> > PCIe Gen6 operation at up to 64 GT/s per lane. It is currently
> > handled by the same driver and match data (NULL) as the existing
> > MDB host controller, but CPM6 uses a newer IP revision and differs
> > in legacy INTx register offsets.
> >
> > Use a separate compatible to allow CPM6-specific handling once legacy
> > interrupt support is validated.
> >
> > Signed-off-by: Sai Krishna Musham <sai.krishna.musham@amd.com>
> > ---
> > drivers/pci/controller/dwc/pcie-amd-mdb.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-amd-mdb.c
> b/drivers/pci/controller/dwc/pcie-amd-mdb.c
> > index 3c6e837465bb..325bf7aad657 100644
> > --- a/drivers/pci/controller/dwc/pcie-amd-mdb.c
> > +++ b/drivers/pci/controller/dwc/pcie-amd-mdb.c
> > @@ -511,6 +511,9 @@ static const struct of_device_id
> amd_mdb_pcie_of_match[] = {
> > {
> > .compatible = "amd,versal2-mdb-host",
> > },
> > + {
> > + .compatible = "amd,versal2-cpm6-host",
>
> As Krzysztof commented, if the PCIe IP is compatible with an older version,
> 'amd,versal2-mdb-host' in this case, you don't need to add the new
> compatible
> to the driver. Just document the new one with fallback to the old compatible
> in
> the binding and let the driver work with the old compatible.
>
Thanks for the review. CPM6 uses a different DesignWare IP revision and
has differences in legacy interrupt register offsets. I will send a follow-up
patch to address these.
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
Regards,
Sai Krishna
^ permalink raw reply
* Re: [PATCH v1 1/3] dt-bindings: arm: fsl: add Variscite VAR-SOM-MX91 Boards
From: Peng Fan @ 2026-04-09 3:05 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Dario Binacchi, Markus Niebel, Maud Spierings,
Alexander Stein, Ernest Van Hoecke, Josua Mayer,
Francesco Dolcini, Primoz Fiser
In-Reply-To: <86635091cd5db0ecb7f07c5ad9d6f735ec349485.1775669847.git.stefano.r@variscite.com>
On Wed, Apr 08, 2026 at 07:39:44PM +0200, Stefano Radaelli wrote:
>From: Stefano Radaelli <stefano.r@variscite.com>
>
>Add DT compatible strings for Variscite VAR-SOM-MX91 SoM and Symphony
>development carrier Board.
>
>Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* [PATCH v5 1/2] arm64: dts: qcom: talos: Add GPR node, audio services, and MI2S1 TLMM pins
From: Le Qi @ 2026-04-09 3:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, kernel, Le Qi,
Konrad Dybcio
In-Reply-To: <20260409030156.155455-1-le.qi@oss.qualcomm.com>
This patch adds the Generic Pack Router (GPR) node together with
Audio Process Manager (APM) and Proxy Resource Manager (PRM)
audio service nodes to the Talos device tree description.
It also introduces MI2S1 pinctrl states for data0, data1, sck,
and ws lines, grouped into a single entry at the SoC-level DTSI
for better reuse and clarity.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Le Qi <le.qi@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/talos.dtsi | 54 +++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
index ff5afbfce2a4..64121316ffc5 100644
--- a/arch/arm64/boot/dts/qcom/talos.dtsi
+++ b/arch/arm64/boot/dts/qcom/talos.dtsi
@@ -18,6 +18,7 @@
#include <dt-bindings/phy/phy-qcom-qmp.h>
#include <dt-bindings/power/qcom-rpmpd.h>
#include <dt-bindings/power/qcom,rpmhpd.h>
+#include <dt-bindings/soc/qcom,gpr.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
#include <dt-bindings/thermal/thermal.h>
@@ -1610,6 +1611,20 @@ cci_i2c1_default: cci-i2c1-default-state {
bias-pull-up;
};
+ mi2s1_pins: mi2s1-state {
+ pins = "gpio108", "gpio109", "gpio110", "gpio111";
+ function = "mi2s_1";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ mi2s_mclk: mi2s-mclk-state {
+ pins = "gpio122";
+ function = "mclk2";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
qup_i2c1_data_clk: qup-i2c1-data-clk-state {
pins = "gpio4", "gpio5";
function = "qup0";
@@ -5132,6 +5147,45 @@ compute-cb@6 {
dma-coherent;
};
};
+
+ gpr: gpr {
+ compatible = "qcom,gpr";
+ qcom,glink-channels = "adsp_apps";
+ qcom,domain = <GPR_DOMAIN_ID_ADSP>;
+ qcom,intents = <512 20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ q6apm: service@1 {
+ compatible = "qcom,q6apm";
+ reg = <GPR_APM_MODULE_IID>;
+ #sound-dai-cells = <0>;
+ qcom,protection-domain = "avs/audio",
+ "msm/adsp/audio_pd";
+
+ q6apmbedai: bedais {
+ compatible = "qcom,q6apm-lpass-dais";
+ #sound-dai-cells = <1>;
+ };
+
+ q6apmdai: dais {
+ compatible = "qcom,q6apm-dais";
+ iommus = <&apps_smmu 0x1721 0x0>;
+ };
+ };
+
+ q6prm: service@2 {
+ compatible = "qcom,q6prm";
+ reg = <GPR_PRM_MODULE_IID>;
+ qcom,protection-domain = "avs/audio",
+ "msm/adsp/audio_pd";
+
+ q6prmcc: clock-controller {
+ compatible = "qcom,q6prm-lpass-clocks";
+ #clock-cells = <2>;
+ };
+ };
+ };
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v5 2/2] arm64: dts: qcom: talos-evk: Add sound card support with DA7212 codec
From: Le Qi @ 2026-04-09 3:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, kernel, Le Qi,
Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260409030156.155455-1-le.qi@oss.qualcomm.com>
Add the sound card node for QCS615 Talos EVK with DA7212 codec
connected over the Primary MI2S interface. The configuration enables
headphone playback and headset microphone capture, both of which have
been tested to work.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Le Qi <le.qi@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/talos-evk.dts | 56 ++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/talos-evk.dts b/arch/arm64/boot/dts/qcom/talos-evk.dts
index af100e22beee..b7f514fbc7b2 100644
--- a/arch/arm64/boot/dts/qcom/talos-evk.dts
+++ b/arch/arm64/boot/dts/qcom/talos-evk.dts
@@ -5,6 +5,7 @@
/dts-v1/;
#include "talos-evk-som.dtsi"
+#include <dt-bindings/sound/qcom,q6afe.h>
/ {
model = "Qualcomm QCS615 IQ 615 EVK";
@@ -40,6 +41,46 @@ hdmi_con_out: endpoint {
};
};
+ sound {
+ compatible = "qcom,qcs615-sndcard";
+ model = "TALOS-EVK";
+
+ pinctrl-0 = <&mi2s1_pins>, <&mi2s_mclk>;
+ pinctrl-names = "default";
+
+ pri-mi2s-capture-dai-link {
+ link-name = "Primary MI2S Capture";
+
+ codec {
+ sound-dai = <&codec_da7212>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai PRIMARY_MI2S_TX>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+
+ pri-mi2s-playback-dai-link {
+ link-name = "Primary MI2S Playback";
+
+ codec {
+ sound-dai = <&codec_da7212>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai PRIMARY_MI2S_RX>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+ };
+
vreg_v1p8_out: regulator-v1p8-out {
compatible = "regulator-fixed";
regulator-name = "vreg-v1p8-out";
@@ -109,6 +150,21 @@ adv7535_out: endpoint {
};
};
+&i2c5 {
+ status = "okay";
+
+ codec_da7212: codec@1a {
+ compatible = "dlg,da7212";
+ reg = <0x1a>;
+ #sound-dai-cells = <0>;
+ clocks = <&q6prmcc LPASS_CLK_ID_MCLK_2 LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "mclk";
+ VDDA-supply = <&vreg_v1p8_out>;
+ VDDIO-supply = <&vreg_v1p8_out>;
+ VDDMIC-supply = <&vreg_v3p3_out>;
+ };
+};
+
&mdss_dsi0_out {
remote-endpoint = <&adv7535_in>;
data-lanes = <0 1 2 3>;
--
2.34.1
^ permalink raw reply related
* [PATCH v5 0/2] arm64: dts: qcom: QCS615 Talos EVK audio support
From: Le Qi @ 2026-04-09 3:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, kernel, Le Qi
This series adds initial audio support for the QCS615-based Talos EVK
platform. It introduces the GPR (Generic Pack Router) node in the SoC
device tree and enables a sound card node with the DA7212 codec on the
Talos EVK board.
With these changes, playback through headphones and capture from the
headset microphone have been tested and verified to work.
---
Changelog:
v5:
- Moved mclk support to codec since Krystof does not agree to include
it within the DAI node. Link: https://lore.kernel.org/all/5941830f-5892-4e75-bc27-04095b5ca28f@kernel.org/
- v4-link: https://lore.kernel.org/all/20260324060405.3098891-1-le.qi@oss.qualcomm.com/
v4:
- Added mclk support for recording to fix clipping issue.
- v3-link: https://lore.kernel.org/all/20251204083225.1190017-1-le.qi@oss.qualcomm.com/
v3:
- Updated sound card model name to "TALOS-EVK".
- v2-link: https://lore.kernel.org/all/20251125033311.254869-1-le.qi@oss.qualcomm.com/
v2:
- Address Konrad's comment to modify the commit message and
group GPIO pins together into a single entry, moved to the
SoC-level DTSI for reuse.
- v1-link: https://lore.kernel.org/all/20251024023720.3928547-1-le.qi@oss.qualcomm.com/
Le Qi (2):
arm64: dts: qcom: talos: Add GPR node, audio services, and MI2S1 TLMM
pins
arm64: dts: qcom: talos-evk: Add sound card support with DA7212 codec
arch/arm64/boot/dts/qcom/talos-evk.dts | 56 ++++++++++++++++++++++++++
arch/arm64/boot/dts/qcom/talos.dtsi | 54 +++++++++++++++++++++++++
2 files changed, 110 insertions(+)
base-commit: db7efce4ae23ad5e42f5f55428f529ff62b86fab
--
2.34.1
^ permalink raw reply
* Re: [net-next v1 v1 1/5] dt-bindings: net: starfive,jh7110-dwmac: Remove JH8100
From: Minda Chen @ 2026-04-09 2:44 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
devicetree@vger.kernel.org
In-Reply-To: <ad9ee916-6f8a-4cb9-8016-54a02b00c7ab@lunn.ch>
>
> On Wed, Apr 08, 2026 at 04:44:12PM +0800, Minda Chen wrote:
> > Remove JH8100 dt-bindings because do not support it now.
>
> Could you expand on that. If there are devices out in the field, we don't just drop
> support for it because the vendor has something newer.
>
> If the device never made it outside of the vendors lab, then we might consider
> dropping it.
>
> Please explain in detail why this is being dropped.
>
> Andrew
Yes.
We (StarFive) stop developing on JH8100 now, And do NOT release the SoC outside.
Hi Krzysztof
Could you review this series patch 1 -3 which is dt -binding doc changes? I sorry
I have sent you to old e-mail address.
^ permalink raw reply
* RE: [PATCH V11 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Sherry Sun @ 2026-04-09 2:58 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <yijf6mwclpx6n7giucgykxvrm73baicy2urhzns34sxgloli3z@ygose2qrgvuz>
> On Wed, Apr 08, 2026 at 06:34:02AM +0000, Sherry Sun wrote:
>
> [...]
>
> > > > +/**
> > > > + * pci_host_common_parse_port - Parse a single Root Port node
> > > > + * @dev: Device pointer
> > > > + * @bridge: PCI host bridge
> > > > + * @node: Device tree node of the Root Port
> > > > + *
> > > > + * Returns: 0 on success, negative error code on failure */
> > > > +static int pci_host_common_parse_port(struct device *dev,
> > > > + struct pci_host_bridge *bridge,
> > > > + struct device_node *node) {
> > > > + struct pci_host_port *port;
> > > > + struct gpio_desc *reset;
> > > > +
> > > > + reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
> > > > + "reset", GPIOD_ASIS, "PERST#");
> > >
> > > Sorry, I missed this earlier.
> > >
> > > Since PERST# is optional, you cannot reliably detect whether the
> > > Root Port binding intentionally skipped the PERST# GPIO or legacy
> > > binding is used, just by checking for PERST# in Root Port node.
> > >
> > > So this helper should do 3 things:
> > >
> > > 1. If PERST# is found in Root Port node, use it.
> > > 2. If not, check the RC node and if present, return -ENOENT to
> > > fallback to the legacy binding.
> > > 3. If not found in both nodes, assume that the PERST# is not present
> > > in the design, and proceed with parsing Root Port binding further.
> >
> > Hi Mani, understand, does the following code looks ok for above three
> cases?
> >
> > /* Check if PERST# is present in Root Port node */
> > reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
> > "reset", GPIOD_ASIS, "PERST#");
> > if (IS_ERR(reset)) {
> > /* If error is not -ENOENT, it's a real error */
> > if (PTR_ERR(reset) != -ENOENT)
> > return PTR_ERR(reset);
> >
> > /* PERST# not found in Root Port node, check RC node */
> > rc_has_reset = of_property_read_bool(dev->of_node, "reset-gpios") ||
> > of_property_read_bool(dev->of_node, "reset-gpio");
>
> Just:
> if (of_property_read_bool(dev->of_node, "reset-gpios") ||
> of_property_read_bool(dev->of_node, "reset-gpio")) {
> return -ENOENT;
> }
Ok, will do.
>
> > if (rc_has_reset)
> > return -ENOENT;
> >
> > /* No PERST# in either node, assume not present in design */
> > reset = NULL;
> > }
> >
> > port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > if (!port)
> > return -ENOMEM;
> > ...
> >
> > >
> > > But there is one more important limitation here. Right now, this API
> > > only handles PERST#. But if another vendor tries to use it and if
> > > they need other properties such as PHY, clocks etc... those
> > > resources should be fetched optionally only by this helper. But if
> > > the controller has a hard dependency on those resources, the driver will
> fail to operate.
> > >
> > > I don't think we can fix this limitation though and those platforms
> > > should ensure that the resource dependency is correctly modeled in
> > > DT binding and the DTS is validated properly. It'd be good to
> > > mention this in the kernel doc of this API.
> >
> > Ok, I will add a NOTE for this in this API description.
> >
> > >
> > > > + if (IS_ERR(reset))
> > > > + return PTR_ERR(reset);
> > > > +
> > > > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > > > + if (!port)
> > > > + return -ENOMEM;
> > > > +
> > > > + port->reset = reset;
> > > > + INIT_LIST_HEAD(&port->list);
> > > > + list_add_tail(&port->list, &bridge->ports);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +/**
> > > > + * pci_host_common_parse_ports - Parse Root Port nodes from
> > > > +device tree
> > > > + * @dev: Device pointer
> > > > + * @bridge: PCI host bridge
> > > > + *
> > > > + * This function iterates through child nodes of the host bridge
> > > > +and parses
> > > > + * Root Port properties (currently only reset GPIO).
> > > > + *
> > > > + * Returns: 0 on success, -ENOENT if no ports found, other
> > > > +negative error codes
> > > > + * on failure
> > > > + */
> > > > +int pci_host_common_parse_ports(struct device *dev, struct
> > > > +pci_host_bridge *bridge) {
> > > > + int ret = -ENOENT;
> > > > +
> > > > + for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> > > > + if (!of_node_is_type(of_port, "pci"))
> > > > + continue;
> > > > + ret = pci_host_common_parse_port(dev, bridge, of_port);
> > > > + if (ret)
> > > > + return ret;
> > >
> > > As Sashiko flagged, you need to make sure that
> > > devm_add_action_or_reset() is added even during the error path:
> >
> > Yes, it needs to be fixed. We can handle it with the following two methods, I
> am not sure which method is better or more preferable?
> >
> > #1: register cleanup action after first successful port parse and use
> cleanup_registered flag to avoid duplicate register.
> > int ret = -ENOENT;
> > bool cleanup_registered = false;
> >
> > for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> > if (!of_node_is_type(of_port, "pci"))
> > continue;
> > ret = pci_host_common_parse_port(dev, bridge, of_port);
> > if (ret)
> > return ret;
> >
> > /* Register cleanup action after first successful port parse */
> > if (!cleanup_registered) {
> > ret = devm_add_action_or_reset(dev,
> > pci_host_common_delete_ports,
> > &bridge->ports);
>
> Even if you register devm_add_action_or_reset(), it won't be called when
> pci_host_common_parse_port() fails since the legacy fallback will be used.
>
> So you need to manually call pci_host_common_delete_ports() in the error
> path.
Get your point, so seems I should just add the err_cleanup handle path like this, right?
for_each_available_child_of_node_scoped(dev->of_node, of_port) {
if (!of_node_is_type(of_port, "pci"))
continue;
ret = pci_host_common_parse_port(dev, bridge, of_port);
if (ret)
goto err_cleanup;
}
if (ret)
return ret;
return devm_add_action_or_reset(dev, pci_host_common_delete_ports,
&bridge->ports);
err_cleanup:
pci_host_common_delete_ports(&bridge->ports);
return ret;
Best Regards
Sherry
^ permalink raw reply
* Re: [net-next v1 v1 4/5] net: stmmac: starfive: Add JHB100 SGMII interface
From: Minda Chen @ 2026-04-09 2:55 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
devicetree@vger.kernel.org
In-Reply-To: <49407bd8-f20b-46f7-9b98-8c88fc45e0f0@lunn.ch>
>
> > + dwmac->sgmii_rx = devm_clk_get_optional(&pdev->dev, "rx");
> > + if (IS_ERR(dwmac->sgmii_rx))
> > + return dev_err_probe(&pdev->dev, PTR_ERR(dwmac->sgmii_rx),
> > + "error getting sgmii rx clock\n");
> > +
>
> The SGMII clock is optional...
>
Yes. RGMII do not have this clock.
> > /* Generally, the rgmii_tx clock is provided by the internal clock,
> > * which needs to match the corresponding clock frequency according
> > * to different speeds. If the rgmii_tx clock is provided by the
> > * external rgmii_rxin, there is no need to configure the clock
> > * internally, because rgmii_rxin will be adaptively adjusted.
> > */
> > - if (!device_property_read_bool(&pdev->dev, "starfive,tx-use-rgmii-clk"))
> > - plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
> > + if (!device_property_read_bool(&pdev->dev, "starfive,tx-use-rgmii-clk")) {
> > + if (plat_dat->phy_interface == PHY_INTERFACE_MODE_SGMII)
> > + plat_dat->set_clk_tx_rate =
> stmmac_starfive_sgmii_set_clk_rate;
>
> So you probably want to return an error here if it is missing.
>
No. RGMII still using stmmac_set_clk_tx_rate
> Or you might want to look at the compatible, and make the clock mandatory for
> this device.
>
> Andrew
Okay I will check the rx clock whether exist .
^ permalink raw reply
* 回复: [net-next v1 v1 3/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 sgmii rx clk
From: Minda Chen @ 2026-04-09 2:46 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
devicetree@vger.kernel.org
In-Reply-To: <c69cf692-87be-43b5-93ee-38040d5cb1bf@lunn.ch>
>
> > + - description: SGMII RX clock
> >
> > clock-names:
> > - items:
> > - - const: stmmaceth
> > - - const: pclk
> > - - const: ptp_ref
> > - - const: tx
> > - - const: gtx
> > + minItems: 5
> > + maxItems: 6
> > + contains:
> > + enum:
> > + - stmmaceth
> > + - pclk
> > + - ptp_ref
> > + - tx
> > + - gtx
> > + - rx
>
> If this is only used for sgmii, maybe it should have sgmii in the name?
>
> Andrew
Okay. I will change to "sgmii_rx". Thanks
^ permalink raw reply
* [PATCH 4/4] arm64: dts: qcom: sdm845-lg: Enable qcom,snoc-host-cap-skip-quirk
From: Paul Sajna @ 2026-04-09 2:41 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson, Dmitry Baryshkov, David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Paul Sajna
In-Reply-To: <20260408-judyln-followup-v1-0-823467519b59@postmarketos.org>
The WCN3990 firmware for judyln does not respond to the request for
host capabilities. Add the devicetree quirk to skip this request.
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
index 86cf4eb44084..e0c3566761bf 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
@@ -694,5 +694,7 @@ &wifi {
vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
vdd-3.3-ch1-supply = <&vreg_l23a_3p3>;
+ qcom,snoc-host-cap-skip-quirk;
+
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: qcom: sdm845-lg-{judyln, judyp}: Reference memory region in fb
From: Paul Sajna @ 2026-04-09 2:41 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson, Dmitry Baryshkov, David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Paul Sajna, Konrad Dybcio
In-Reply-To: <20260408-judyln-followup-v1-0-823467519b59@postmarketos.org>
To prevent duplicating the framebuffer address and size point out the
existing framebuffer memory region instead of specifying the address
manually.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 3 +--
arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts | 4 ++--
arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts | 4 ++--
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
index 85dc4468b6c4..86cf4eb44084 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
@@ -98,8 +98,7 @@ spss_mem: memory@99000000 {
no-map;
};
- /* Framebuffer region */
- memory@9d400000 {
+ framebuffer_mem: memory@9d400000 {
reg = <0x0 0x9d400000 0x0 0x2400000>;
no-map;
};
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
index adf41aa0146a..349faa123ff1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
@@ -14,9 +14,9 @@ / {
compatible = "lg,judyln", "qcom,sdm845";
chosen {
- framebuffer@9d400000 {
+ framebuffer {
compatible = "simple-framebuffer";
- reg = <0x0 0x9d400000 0x0 (1440 * 3120 * 4)>;
+ memory-region = <&framebuffer_mem>;
width = <1440>;
height = <3120>;
stride = <(1440 * 4)>;
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts b/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts
index d244ebdd17be..44e762f78e95 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts
@@ -14,9 +14,9 @@ / {
compatible = "lg,judyp", "qcom,sdm845";
chosen {
- framebuffer@9d400000 {
+ framebuffer {
compatible = "simple-framebuffer";
- reg = <0x0 0x9d400000 0x0 (1440 * 2880 * 4)>;
+ memory-region = <&framebuffer_mem>;
width = <1440>;
height = <2880>;
stride = <(1440 * 4)>;
--
2.53.0
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: qcom: sdm845-lg-common: Change ipa gsi-loader to 'self', add memory-region
From: Paul Sajna @ 2026-04-09 2:41 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson, Dmitry Baryshkov, David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Paul Sajna, Konrad Dybcio
In-Reply-To: <20260408-judyln-followup-v1-0-823467519b59@postmarketos.org>
The modem firmware for this device doesn't preload the IPA firmware
and requires the OS handles that instead. Set qcom,gsi-loader = "self"
to reflect that.
Ensure the ipa uses the correct memory.
ipa 1e40000.ipa: channel 4 limited to 256 TREs
ipa 1e40000.ipa: IPA driver initialized
ipa 1e40000.ipa: received modem starting event
ipa 1e40000.ipa: received modem running event
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
index 9d82961d527e..85dc4468b6c4 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
@@ -473,7 +473,9 @@ &gpu {
};
&ipa {
- qcom,gsi-loader = "modem";
+ qcom,gsi-loader = "self";
+ memory-region = <&ipa_fw_mem>;
+
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* [PATCH 1/4] arm64: dts: qcom: sdm845-lg-common: Add camera flash
From: Paul Sajna @ 2026-04-09 2:41 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson, Dmitry Baryshkov, David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Paul Sajna, Konrad Dybcio
In-Reply-To: <20260408-judyln-followup-v1-0-823467519b59@postmarketos.org>
Camera doesn't work yet (imx351), but we can use the flash as a flashlight.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
index 71d070619ad7..9d82961d527e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
@@ -496,6 +496,19 @@ &pm8998_resin {
status = "okay";
};
+&pmi8998_flash {
+ status = "okay";
+
+ led-0 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <1>, <2>;
+ led-max-microamp = <100000>;
+ flash-max-microamp = <500000>;
+ flash-max-timeout-us = <500000>;
+ };
+};
+
&pmi8998_lpg {
status = "okay";
--
2.53.0
^ permalink raw reply related
* [PATCH 0/4] arm64: dts: qcom: sdm845-lg: Devicetree followup
From: Paul Sajna @ 2026-04-09 2:41 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson, Dmitry Baryshkov, David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Paul Sajna, Konrad Dybcio
Re-send 3 patches that got dropped from 20260331-judyln-dts-v7-0-87217b15fefb@postmarketos.org
(https://lore.kernel.org/linux-arm-msm/177541802142.2061229.9094394728986735362.b4-ty@kernel.org/)
Re-enable qcom,snoc-host-cap-skip-quirk
To:
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
Paul Sajna (4):
arm64: dts: qcom: sdm845-lg-common: Add camera flash
arm64: dts: qcom: sdm845-lg-common: Change ipa gsi-loader to 'self', add memory-region
arm64: dts: qcom: sdm845-lg-{judyln, judyp}: Reference memory region in fb
arm64: dts: qcom: sdm845-lg: Enable qcom,snoc-host-cap-skip-quirk
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 22 +++++++++++++++++++---
arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts | 4 ++--
arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts | 4 ++--
3 files changed, 23 insertions(+), 7 deletions(-)
---
base-commit: db7efce4ae23ad5e42f5f55428f529ff62b86fab
change-id: 20260408-judyln-followup-e0201f3d27e9
prerequisite-message-id: 20260407-skip-host-cam-qmi-req-v5-0-dfa8a05c6538@ixit.cz
prerequisite-patch-id: ac24dd000a2ecf55cb4da9fbc62e4834530036fd
prerequisite-patch-id: 9c69ab29256c15a0e8ac1c3b9ef64b27661c7815
prerequisite-patch-id: bd62d277785dc0a3bed4beff8d22d7bfd7e491fb
Best regards,
--
Paul Sajna <sajattack@postmarketos.org>
^ permalink raw reply
* Re: Re: [PATCH v1] dt-bindings: usb: Fix EIC7700 USB reset's issue
From: Hang Cao @ 2026-04-09 2:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Conor Dooley
Cc: gregkh, robh, krzk+dt, conor+dt, Thinh.Nguyen, p.zabel,
linux-kernel, linux-usb, devicetree, ningyu, linmin,
pinkesh.vaghela
In-Reply-To: <20260408-designed-broadband-332044a2d1fb@spud>
[-- Attachment #1: Type: text/plain, Size: 2702 bytes --]
Hi, Krzysztof & Conor
No, U-Boot will NOT be affected. Sorry for the misunderstanding due to the
inaccurate commit message.
I will send the next version with the improved commit message below:
The EIC7700 USB requires a USB PHY reset operation; otherwise, the USB will
not work. The reason why the USB driver that was applied can work properly is
that the USB PHY has already been reset in ESWIN's U-Boot.
However, the proper functioning of the USB driver should not be dependent on
the bootloader. Therefore, it is necessary to incorporate the USB PHY reset
signal into the DT bindings.
This patch does not introduce any backward incompatibility since the dts is
not upstream yet. As array of reset operations are used in the driver,
no modifications to the USB controller driver are needed.
Best regards,
Hang
> -----Original Messages-----
> From: "Conor Dooley" <conor@kernel.org>
> Send time:Thursday, 09/04/2026 01:24:34
> To: "Krzysztof Kozlowski" <krzk@kernel.org>
> Cc: caohang@eswincomputing.com, gregkh@linuxfoundation.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, Thinh.Nguyen@synopsys.com, p.zabel@pengutronix.de, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, devicetree@vger.kernel.org, ningyu@eswincomputing.com, linmin@eswincomputing.com, pinkesh.vaghela@einfochips.com
> Subject: Re: [PATCH v1] dt-bindings: usb: Fix EIC7700 USB reset's issue
>
> On Wed, Apr 08, 2026 at 09:48:43AM +0200, Krzysztof Kozlowski wrote:
> > On Tue, Apr 07, 2026 at 02:17:02PM +0800, caohang@eswincomputing.com wrote:
> > > From: Hang Cao <caohang@eswincomputing.com>
> > >
> > > The EIC7700 USB controller requires a USB PHY RESET operation.PHY RESET
> >
> > Missing space after full stop.
> >
> > > operation was missed in the verification version, as it was performed in
> > > ESWIN's U-Boot.
> > >
> > > If a non-ESWIN provided loader is used, this issue will occur, resulting
> > > in USB not work.This patch does not introduce any backward incompatibility
> > > since the dts is not upstream yet.
> >
> > So U-Boot will be affected, no?
>
> Is it even really affected? I don't think there's any bootloader for this
> other than what ESWIN is shipping downstream, outside of people's development
> trees. And any software that expected two resets will work just as badly as
> it always did when a third one is added.
>
> > And even if DTS is not upstreamed, what about all out of tree DTS?
> > This is an already released ABI, so at least explain that driver does
> > not care about resets here and grabs them all.
> >
> > >
> > > Fixes: c640a4239db5 ("dt-bindings: usb: Add ESWIN EIC7700 USB controller")
> >
> >
> > Best regards,
> > Krzysztof
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 235 bytes --]
^ permalink raw reply
* RE: [PATCH V11 04/12] PCI: imx6: Add support for parsing the reset property in new Root Port binding
From: Sherry Sun @ 2026-04-09 2:40 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <t5x45nyn6lw7cofzj2rec5j6z2ml6kve2hvzeeastdrv4hilsu@ujhkmltpp5ky>
> Subject: Re: [PATCH V11 04/12] PCI: imx6: Add support for parsing the reset
> property in new Root Port binding
>
> On Wed, Apr 08, 2026 at 08:34:03AM +0000, Sherry Sun wrote:
> > > On Tue, Apr 07, 2026 at 06:41:46PM +0800, Sherry Sun wrote:
> > > > The current DT binding for pci-imx6 specifies the 'reset-gpios'
> > > > property in the host bridge node. However, the PERST# signal
> > > > logically belongs to individual Root Ports rather than the host bridge
> itself.
> > > > This becomes important when supporting PCIe KeyE connector and PCI
> > > > power control framework for pci-imx6 driver, which requires
> > > > properties to be specified in Root Port nodes.
> > > >
> > > > Add support for parsing 'reset-gpios' from Root Port child nodes
> > > > using the common helper pci_host_common_parse_ports(), and update
> > > > the reset GPIO handling to use the parsed port list from
> > > > bridge->ports. To maintain DT backwards compatibility, fallback to
> > > > the legacy method of parsing the host bridge node if the reset
> > > > property is not present in the Root Port node.
> > > >
> > > > Since now the reset GPIO is obtained with GPIOD_ASIS flag, it may
> > > > be in input mode, using gpiod_direction_output() instead of
> > > > gpiod_set_value_cansleep() to ensure the reset GPIO is properly
> > > > configured as output before setting its value.
> > > >
> > > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > > ---
> > > > drivers/pci/controller/dwc/pci-imx6.c | 75
> > > > +++++++++++++++++++++------
> > > > 1 file changed, 60 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > > index d99da7e42590..dd8f9c0fcec4 100644
> > > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > > @@ -34,6 +34,7 @@
> > > > #include <linux/pm_runtime.h>
> > > >
> > > > #include "../../pci.h"
> > > > +#include "../pci-host-common.h"
> > > > #include "pcie-designware.h"
> > > >
> > > > #define IMX8MQ_GPR_PCIE_REF_USE_PAD BIT(9)
> > > > @@ -152,7 +153,6 @@ struct imx_lut_data {
> > > >
> > > > struct imx_pcie {
> > > > struct dw_pcie *pci;
> > > > - struct gpio_desc *reset_gpiod;
> > > > struct clk_bulk_data *clks;
> > > > int num_clks;
> > > > bool supports_clkreq;
> > > > @@ -1224,6 +1224,32 @@ static void imx_pcie_disable_device(struct
> > > pci_host_bridge *bridge,
> > > > imx_pcie_remove_lut(imx_pcie, pci_dev_id(pdev)); }
> > > >
> > > > +static int imx_pcie_parse_legacy_binding(struct imx_pcie *pcie) {
> > > > + struct device *dev = pcie->pci->dev;
> > > > + struct pci_host_bridge *bridge = pcie->pci->pp.bridge;
> > > > + struct pci_host_port *port;
> > > > + struct gpio_desc *reset;
> > > > +
> > > > + reset = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
> > > > + if (IS_ERR(reset))
> > > > + return PTR_ERR(reset);
> > > > +
> > > > + if (!reset)
> > > > + return 0;
> > > > +
> > > > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > > > + if (!port)
> > > > + return -ENOMEM;
> > > > +
> > > > + port->reset = reset;
> > > > + INIT_LIST_HEAD(&port->list);
> > > > + list_add_tail(&port->list, &bridge->ports);
> > > > +
> > > > + return devm_add_action_or_reset(dev,
> > > pci_host_common_delete_ports,
> > > > + &bridge->ports);
> > > > +}
> > > > +
> > > > static void imx_pcie_vpcie_aux_disable(void *data) {
> > > > struct regulator *vpcie_aux = data; @@ -1233,13 +1259,22 @@
> > > > static void imx_pcie_vpcie_aux_disable(void
> > > > *data)
> > > >
> > > > static void imx_pcie_assert_perst(struct imx_pcie *imx_pcie, bool
> > > > assert) {
> > > > - if (assert) {
> > > > - gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 1);
> > > > - } else {
> > > > - if (imx_pcie->reset_gpiod) {
> > > > - msleep(PCIE_T_PVPERL_MS);
> > > > - gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 0);
> > > > - msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > > > + struct dw_pcie *pci = imx_pcie->pci;
> > > > + struct pci_host_bridge *bridge = pci->pp.bridge;
> > > > + struct pci_host_port *port;
> > > > +
> > > > + if (!bridge)
> > > > + return;
> > > > +
> > > > + list_for_each_entry(port, &bridge->ports, list) {
> > > > + if (assert) {
> > > > + gpiod_direction_output(port->reset, 1);
> > > > + } else {
> > > > + if (port->reset) {
> > > > + msleep(PCIE_T_PVPERL_MS);
> > > > + gpiod_direction_output(port->reset, 0);
> > > > + msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > > > + }
> > >
> > > Sashiko flagged this loop:
> > >
> > > ```
> > > Does this loop multiply the initialization delays?
> > > If a controller has multiple Root Ports, the msleep calls will run
> > > sequentially for each port, linearly increasing the delay. Could we
> > > optimize this by asserting all reset GPIOs, waiting the pre-delay
> > > once, de-asserting all GPIOs, and waiting the post-delay once for the entire
> bus?
> > > ```
> > >
> > > Maybe you should do:
> > >
> > > if (!list_empty(&bridge->ports) && !assert)
> > > msleep(PCIE_T_PVPERL_MS);
> > >
> > > list_for_each_entry(port, &bridge->ports, list) {
> > > ...
> > > gpiod_direction_output(port->reset, 0);
> > > ...
> > > }
> > >
> > > if (!list_empty(&bridge->ports) && !assert)
> > > msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > >
> >
> > Hi Mani, I think the code below looks clearer, is that ok for you?
> >
> > if (assert) {
> > list_for_each_entry(port, &bridge->ports, list)
> > gpiod_direction_output(port->reset, 1);
> > } else {
> > if (list_empty(&bridge->ports))
> > return;
> >
>
> This check should be moved out of the if() condition. Other than this, the
> change looks good.
Ok, will do.
>
> > msleep(PCIE_T_PVPERL_MS);
> > list_for_each_entry(port, &bridge->ports, list)
> > gpiod_direction_output(port->reset, 0);
> > msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > }
> >
> > > And then this:
> > >
> > > ```
> > > Also, since this function is called from imx_pcie_resume_noirq,
> > > which executes with hardware interrupts disabled, does the use of
> > > msleep here trigger a 'sleeping while atomic' bug?
> > > ```
> > >
> > > This is a valid concern. You should use mdelay(). But I'd recommend
> > > switching to IRQ enabled callback, resume() instead. There is no
> > > complelling reason to use resume_noirq() in this driver and adding
> > > delays in noirq() callbacks is not recommended as it may increase the
> overall system resume time.
> > >
> > > I will submit a separate series to convert dw_pcie_resume_noirq()
> > > and its callers to IRQ enabled callbacks since this
> > > dw_pcie_resume_noirq() could potentially cause delay up to 1sec.
> >
> > Yes, this is not a new bug introduced by this patch. I agree we should
> > covert the convert dw_pcie_resume_noirq() and the caller to IRQ
> > enabled callbacks to fix this in a separate patch series.
> > For now, should I leave it as is, or switch to mdelay in this patch?
> >
>
> Just use mdelay() in your patch for now.
Ok, thanks!
Best Regards
Sherry
^ permalink raw reply
* [PATCH] of: unittest: fix use-after-free in of_unittest_changeset()
From: Wentao Liang @ 2026-04-09 2:22 UTC (permalink / raw)
To: robh, saravanak; +Cc: devicetree, linux-kernel, Wentao Liang, stable
The variable 'parent' is assigned the value of 'nchangeset' earlier in the
function, meaning both point to the same struct device_node. The call to
of_node_put(nchangeset) can decrement the reference count to zero and
free the node if there are no other holders. After that, the code still
uses 'parent' to check for the presence of a property and to read a
string property, leading to a use-after-free.
Fix this by moving the of_node_put() call after the last access to
'parent', avoiding the UAF.
Fixes: 1c668ea65506 ("of: unittest: Use of_property_present()")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
drivers/of/unittest.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 2940295843e6..eae7ebdf5130 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -896,8 +896,6 @@ static void __init of_unittest_changeset(void)
unittest(!of_changeset_apply(&chgset), "apply failed\n");
- of_node_put(nchangeset);
-
/* Make sure node names are constructed correctly */
unittest((np = of_find_node_by_path("/testcase-data/changeset/n2/n21")),
"'%pOF' not added\n", n21);
@@ -919,6 +917,7 @@ static void __init of_unittest_changeset(void)
if (!ret)
unittest(strcmp(propstr, "hello") == 0, "original value not in updated property after revert");
+ of_node_put(nchangeset);
of_changeset_destroy(&chgset);
of_node_put(n1);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/5] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add support for glymur Gen5 x8 bifurcation mode
From: Qiang Yu @ 2026-04-09 2:19 UTC (permalink / raw)
To: Rob Herring
Cc: Vinod Koul, Neil Armstrong, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-phy, devicetree, linux-kernel
In-Reply-To: <20260407161311.GA2666255-robh@kernel.org>
On Tue, Apr 07, 2026 at 11:13:11AM -0500, Rob Herring wrote:
> On Mon, Mar 23, 2026 at 12:15:28AM -0700, Qiang Yu wrote:
> > The Glymur SoC has pcie3a and pcie3b PHYs that can operate in two modes:
> >
> > 1. Independent 4-lane mode: Each PHY operates as a separate PCIe Gen5
> > 4-lane interface, compatible with qcom,glymur-qmp-gen5x4-pcie-phy
> > 2. Bifurcation mode (8-lane): pcie3a phy acts as leader and pcie3b phy as
> > follower to form a single 8-lane PCIe Gen5 interface
> >
> > In bifurcation mode, the hardware design requires controlling additional
> > resources beyond the standard pcie3a PHY configuration:
> >
> > - pcie3b's aux_clk (phy_b_aux)
> > - pcie3b's phy_gdsc power domain
> > - pcie3b's bcr/nocsr reset
> >
> > Add qcom,glymur-qmp-gen5x8-pcie-phy compatible string to document this
> > 8-lane bifurcation configuration.
> >
> > The phy_b_aux clock is used as the 6th clock instead of pipediv2,
> > requiring the clock-names enum to be extended to support both
> > [phy_b_aux, pipediv2] options at index 5. This follows the existing
> > pattern used for [rchng, refgen] clocks at index 3.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> > .../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 45 ++++++++++++++++++----
> > 1 file changed, 37 insertions(+), 8 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > index 3a35120a77ec0ceb814a1cdcacff32fef32b4f7b..25717bc9be98824e38f3c27c3299fbd1f2e7e299 100644
> > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > @@ -18,6 +18,7 @@ properties:
> > enum:
> > - qcom,glymur-qmp-gen4x2-pcie-phy
> > - qcom,glymur-qmp-gen5x4-pcie-phy
> > + - qcom,glymur-qmp-gen5x8-pcie-phy
> > - qcom,kaanapali-qmp-gen3x2-pcie-phy
> > - qcom,qcs615-qmp-gen3x1-pcie-phy
> > - qcom,qcs8300-qmp-gen4x2-pcie-phy
> > @@ -68,20 +69,23 @@ properties:
> > - const: ref
> > - enum: [rchng, refgen]
> > - const: pipe
> > - - const: pipediv2
> > + - enum: [phy_b_aux, pipediv2]
> >
> > power-domains:
> > - maxItems: 1
> > + minItems: 1
> > + maxItems: 2
>
> Once there is more than 1, you have to define the order and what each
> one is for.
>
Okay, will add - description for each power-domains.
> >
> > resets:
> > minItems: 1
> > - maxItems: 2
> > + maxItems: 4
> >
> > reset-names:
> > minItems: 1
> > items:
> > - const: phy
> > - const: phy_nocsr
> > + - const: phy_b
> > + - const: phy_b_nocsr
> >
> > vdda-phy-supply: true
> >
> > @@ -183,6 +187,7 @@ allOf:
> > enum:
> > - qcom,glymur-qmp-gen4x2-pcie-phy
> > - qcom,glymur-qmp-gen5x4-pcie-phy
> > + - qcom,glymur-qmp-gen5x8-pcie-phy
> > - qcom,qcs8300-qmp-gen4x2-pcie-phy
> > - qcom,sa8775p-qmp-gen4x2-pcie-phy
> > - qcom,sa8775p-qmp-gen4x4-pcie-phy
> > @@ -201,6 +206,17 @@ allOf:
> > clock-names:
> > minItems: 6
> >
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - qcom,glymur-qmp-gen5x8-pcie-phy
> > + then:
> > + properties:
> > + power-domains:
> > + minItems: 2
>
> else:
> maxItems: 1
>
Will add this.
- Qiang Yu
> > +
> > - if:
> > properties:
> > compatible:
> > @@ -223,11 +239,24 @@ allOf:
> > reset-names:
> > minItems: 2
> > else:
> > - properties:
> > - resets:
> > - maxItems: 1
> > - reset-names:
> > - maxItems: 1
> > + if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - qcom,glymur-qmp-gen5x8-pcie-phy
> > + then:
> > + properties:
> > + resets:
> > + minItems: 4
> > + reset-names:
> > + minItems: 4
> > + else:
> > + properties:
> > + resets:
> > + maxItems: 1
> > + reset-names:
> > + maxItems: 1
> >
> > - if:
> > properties:
> >
> > --
> > 2.34.1
> >
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Liu Ying @ 2026-04-09 2:19 UTC (permalink / raw)
To: Frank Li
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <adYy9xesCKsYWNBg@lizhi-Precision-Tower-5810>
On Wed, Apr 08, 2026 at 06:50:31AM -0400, Frank Li wrote:
> On Wed, Apr 08, 2026 at 04:40:37PM +0800, Liu Ying wrote:
>> On Wed, Apr 08, 2026 at 04:28:40AM -0400, Frank Li wrote:
> ...
>>>>>>>
>>>>>>> Is it possible to appply this overlay file and kd50g21-40nt-a1 overlay file
>>>>>>>
>>>>>>> to imx93-9x9-qsb.dtb, so needn't create dtsi.
>>>>>>
>>>>>> I'm sorry, I don't get your question here.
>>>>>> Anyway, the DT overlays are needed, because the 40-pin EXP/PRI interface on
>>>>>> the i.MX93 9x9 QSB board can not only connect to a DPI panel adapter board
>>>>>> but also to an audio hat[2], and maybe more. The newly introduced .dtsi
>>>>>> file just aims to avoid duplicated code.
>>>>>
>>>>> My means apply two overlay files to dtb
>>>>>
>>>>> imx93-9x9-qsb-tianma-tm050rdh03-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo imx93-9x9-qsb-tianma-tm050rdh03.dtbo
>>
>> This ...
>>
>>>>>
>>>>> In imx93-9x9-qsb-tianma-tm050rdh03.dtbo, only include
>>>>> &{/} {
>>>>> panel {
>>>>> compatible = "tianma,tm050rdh03";
>>>>> enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
>>>>> };
>>>>> };
>>>>
>>>> If an user wants to use imx93-9x9-qsb.dtb and the DT overlay blob
>>>> imx93-9x9-qsb-tianma-tm050rdh03.dtbo to enable the tianma,tm050rdh03
>>>> DPI panel, then it won't work unless the user also apply
>>>> imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo, right?
>>>>
>>>>>
>>>
>>> Yes, imx93-9x9-qsb-tianma-tm050rdh03.dtb already created, which already
>>> applied both overlay file.
>>
>> .... indicates that imx93-9x9-qsb-tianma-tm050rdh03.dtb is generated by
>> applying both imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo and
>> imx93-9x9-qsb-tianma-tm050rdh03.dtbo to imx93-9x9-qsb.dtb.
>> While, imx93-9x9-qsb-tianma-tm050rdh03.dtbo(a DT overlay blob) just contains
>> the panel node, which means that an user __cannot_ enable the tianma,tm050rdh03
>> DPI panel by only applying it to imx93-9x9-qsb.dtb, unless the user also
>> applies imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo. That's why the .dtsi
>> file is needed.
>
> what's problem if we require user do that? Makefile already create finial
> imx93-9x9-qsb-tianma-tm050rdh03.dtb.
The problem is that the user would apply imx93-9x9-qsb-tianma-tm050rdh03.dtbo
to imx93-9x9-qsb.dtb to enable the tianma,tm050rdh03 DPI panel, say in the
U-boot stage with the 'fdt' command, which is fairly a typical usecase, just
like the user would apply imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo to
imx93-9x9-qsb.dtb to enable the ontat,kd50g21-40nt-a1 DPI panel. We cannot
ask the user to additionally apply imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo
to enable the tianma,tm050rdh03 DPI panel, because that's very confusing.
Note that imx93-9x9-qsb-tianma-tm050rdh03.dtb certainly can be used to
enable the tianma,tm050rdh03 DPI panel, but in addition to that,
imx93-9x9-qsb.dtb + imx93-9x9-qsb-tianma-tm050rdh03.dtbo can also be
used to enable the panel.
>
> Any user really apply dtso manaully without use kernel's Makefile?
That's not relevant.
The point is that imx93-9x9-qsb-tianma-tm050rdh03.dtbo would be generated
and applied by the user to imx93-9x9-qsb.dtb to enable the tianma,tm050rdh03
DPI panel.
>
>>
>>>
>>> can the same board be use for imx91 or other evk boards?
>>
>> Yes, both tianma,tm050rdh03 and ontat,kd50g21-40nt-a1 DPI panels can be
>> connected to i.MX91/93 11x11 EVK and 9x9 QSB boards.
>
> Is it possible to use one overlay files for all imx91/imx93 boards?
No, that's impossible, because they use GPIO backlight or PWM backlight,
different GPIOs to enable DPI panels and different GPIO hogs.
>
> Frank
>>
>>>
>>> Frank
>>>
>>>>> Frank
>>>>>>
>>>>>> [2] https://www.nxp.com/design/design-center/development-boards-and-designs/mx93aud-hat-audio-board:MX93AUD-HAT
>>>>>>
>>>>>>>
>>>>>>> Frank
>>>>>>>>
>>>>>>>> ---
>>>>>>>> base-commit: 816f193dd0d95246f208590924dd962b192def78
>>>>>>>> change-id: 20260407-tianma-tm050rdh03-imx93-9x9-qsb-6e4bbbde3d08
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> --
>>>>>>>> Liu Ying <victor.liu@nxp.com>
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Liu Ying
>>>>
>>>> --
>>>> Regards,
>>>> Liu Ying
>>
>> --
>> Regards,
>> Liu Ying
--
Regards,
Liu Ying
^ permalink raw reply
* Re: (subset) [PATCH 0/7] clk: qcom: add support for the clock controllers on Nord platforms
From: Bjorn Andersson @ 2026-04-09 2:07 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Taniya Das, Taniya Das, Richard Cochran, Shawn Guo,
Deepti Jaggi, Bartosz Golaszewski
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, netdev,
Prasanna Tolety
In-Reply-To: <20260403-nord-clks-v1-0-018af14979fd@oss.qualcomm.com>
On Fri, 03 Apr 2026 16:10:48 +0200, Bartosz Golaszewski wrote:
> This documents the gcc, tcsr and rpmhcc support in Nord platforms and
> adds corresponding drivers as well as enables them in arm64 defconfig.
>
>
Applied, thanks!
[1/7] dt-bindings: clock: qcom: Document the Nord SoC TCSR Clock Controller
commit: 31fcf6995e74117fe235a7a07a6e13077070b4a2
[2/7] dt-bindings: clock: qcom-rpmhcc: Add support for Nord SoCs
commit: 8a108047245780ca17667b05a7af600d118ec1d6
[3/7] dt-bindings: clock: qcom: Add Nord Global Clock Controller
commit: 06498d59bb4e10032b1495762a999d640fe4a8dc
[4/7] clk: qcom: Add TCSR clock driver for Nord SoC
commit: 9d13c7bbee5f789738a645df5868b69da5ae3879
[5/7] clk: qcom: rpmh: Add support for Nord rpmh clocks
commit: cf6e6ac63c62cb9f60f981dbaebe591bdbee2f46
[6/7] clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC
commit: a4f780cd5c7aa8c0d2d044ffd153f7a3a13ca81e
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH 01/12] firmware: qcom: scm: Allow QSEECOM for Radxa Dragon Q6A
From: Dmitry Baryshkov @ 2026-04-09 1:54 UTC (permalink / raw)
To: Xilin Wu
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, Judy Hsiao,
linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
linux-sound
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-1-14aca49dde3d@radxa.com>
On Tue, Apr 07, 2026 at 11:19:53PM +0800, Xilin Wu wrote:
> add "radxa,dragon-q6a" as compatible device for QSEECOM
>
> This is required to get access to efivars and uefi boot loader support.
>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
> drivers/firmware/qcom/qcom_scm.c | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] soc: qcom: socinfo: add SoC ID for IPQ9650 family
From: Dmitry Baryshkov @ 2026-04-09 1:53 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260408-ipq9650_soc_ids-v1-2-e76faac33f77@oss.qualcomm.com>
On Wed, Apr 08, 2026 at 03:28:35PM +0530, Kathiravan Thirumoorthy wrote:
> Add SoC IDs for Qualcomm's IPQ9650 family.
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
> drivers/soc/qcom/socinfo.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ 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