* [PATCH v3 0/3] riscv: dts: spacemit: Add PMIC regulators usb pcie
From: Han Gao @ 2026-03-29 17:05 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan
Cc: devicetree, linux-riscv, spacemit, linux-kernel, Han Gao, Han Gao
Changes in v3:
- Merge patch 2 into 3
- Fix
Rename regulator-name from USB30_HUB to USB_HUB_EN
Drop regulator-usb3-vbus-5v
Drop reset-gpios from usb hub nodes
Fix reg_dc_in regulator-name from "dc_in_12v" to "dc_in_5v"
- Link to v2: https://lore.kernel.org/linux-riscv/20260310161853.3900605-1-gaohan@iscas.ac.cn/
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 | 222 ++++++++++++++++++
1 file changed, 222 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
--
2.47.3
^ permalink raw reply
* [PATCH v3 3/3] riscv: dts: spacemit: Enable USB3.0/PCIe on OrangePi RV2
From: Han Gao @ 2026-03-29 17:05 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan
Cc: devicetree, linux-riscv, spacemit, linux-kernel, Han Gao, Han Gao
In-Reply-To: <cover.1774803532.git.gaohan@iscas.ac.cn>
Enable the DWC3 USB 3.0 controller and its associated usbphy2 on the
OrangePi RV2 board.
The board utilizes a Genesys Logic GL3523 hub, which requires one
separate power supplies for hub itself.
Define a 3.3v fixed voltage regulator to be used by PCIe on OPi RV2.
Define PCIe and PHY-related Device Tree nodes for the OPi RV2.
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
---
.../boot/dts/spacemit/k1-orangepi-rv2.dts | 79 +++++++++++++++++++
1 file changed, 79 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
index 1b1b27bc95d8..a53cd2e037ef 100644
--- a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
@@ -23,6 +23,15 @@ chosen {
stdout-path = "serial0";
};
+ pcie_vcc_3v3: regulator-pcie-vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "PCIE_VCC3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio K1_GPIO(116) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
reg_dc_in: regulator-vcc-in-5v {
compatible = "regulator-fixed";
regulator-name = "dc_in_5v";
@@ -42,6 +51,15 @@ reg_vcc_4v: regulator-vcc-4v {
vin-supply = <®_dc_in>;
};
+ usb3_hub_5v: regulator-usb3-hub-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "USB_HUB_EN";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio K1_GPIO(123) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
leds {
compatible = "gpio-leds";
@@ -54,6 +72,10 @@ led1 {
};
};
+&combo_phy {
+ status = "okay";
+};
+
ð0 {
phy-handle = <&rgmii0>;
phy-mode = "rgmii-id";
@@ -230,8 +252,65 @@ dldo7 {
};
};
+&pcie1_phy {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie1_3_cfg>;
+ status = "okay";
+};
+
+&pcie1_port {
+ phys = <&pcie1_phy>;
+ vpcie3v3-supply = <&pcie_vcc_3v3>;
+};
+
+&pcie1 {
+ vpcie3v3-supply = <&pcie_vcc_3v3>;
+ status = "okay";
+};
+
+&pcie2_phy {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie2_4_cfg>;
+ status = "okay";
+};
+
+&pcie2_port {
+ phys = <&pcie2_phy>;
+ vpcie3v3-supply = <&pcie_vcc_3v3>;
+};
+
+&pcie2 {
+ vpcie3v3-supply = <&pcie_vcc_3v3>;
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_2_cfg>;
status = "okay";
};
+
+&usbphy2 {
+ status = "okay";
+};
+
+&usb_dwc3 {
+ dr_mode = "host";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ hub_2_0: hub@1 {
+ compatible = "usb5e3,610";
+ reg = <0x1>;
+ vdd-supply = <&usb3_hub_5v>;
+ peer-hub = <&hub_3_0>;
+ };
+
+ hub_3_0: hub@2 {
+ compatible = "usb5e3,620";
+ reg = <0x2>;
+ vdd-supply = <&usb3_hub_5v>;
+ peer-hub = <&hub_2_0>;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v3 2/3] riscv: dts: spacemit: Define the P1 PMIC regulators for OrangePi RV2
From: Han Gao @ 2026-03-29 17:05 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan
Cc: devicetree, linux-riscv, spacemit, linux-kernel, Han Gao, Han Gao
In-Reply-To: <cover.1774803532.git.gaohan@iscas.ac.cn>
Define the DC power input and the 4v power as fixed regulator supplies.
Define the SpacemiT P1 PMIC voltage regulators and their constraints.
The power management hardware design on the OrangePi RV2 is identical to
the Banana Pi BPI-F3, so the DT Nodes were taken from k1-bananapi-f3.dts.
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
---
.../boot/dts/spacemit/k1-orangepi-rv2.dts | 137 ++++++++++++++++++
1 file changed, 137 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
index 93880ba7bdfe..1b1b27bc95d8 100644
--- a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
@@ -23,6 +23,25 @@ chosen {
stdout-path = "serial0";
};
+ reg_dc_in: regulator-vcc-in-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_in_5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_vcc_4v: regulator-vcc-4v {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_4v";
+ regulator-min-microvolt = <4000000>;
+ regulator-max-microvolt = <4000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ vin-supply = <®_dc_in>;
+ };
+
leds {
compatible = "gpio-leds";
@@ -91,6 +110,124 @@ &i2c8 {
pinctrl-0 = <&i2c8_cfg>;
pinctrl-names = "default";
status = "okay";
+
+ pmic@41 {
+ compatible = "spacemit,p1";
+ reg = <0x41>;
+ interrupts = <64>;
+ vin1-supply = <®_vcc_4v>;
+ vin2-supply = <®_vcc_4v>;
+ vin3-supply = <®_vcc_4v>;
+ vin4-supply = <®_vcc_4v>;
+ vin5-supply = <®_vcc_4v>;
+ vin6-supply = <®_vcc_4v>;
+ aldoin-supply = <®_vcc_4v>;
+ dldoin1-supply = <&buck5>;
+ dldoin2-supply = <&buck5>;
+
+ regulators {
+ buck1 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3450000>;
+ regulator-ramp-delay = <5000>;
+ regulator-always-on;
+ };
+
+ buck2 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3450000>;
+ regulator-ramp-delay = <5000>;
+ regulator-always-on;
+ };
+
+ buck3_1v8: buck3 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-ramp-delay = <5000>;
+ regulator-always-on;
+ };
+
+ buck4 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-ramp-delay = <5000>;
+ regulator-always-on;
+ };
+
+ buck5: buck5 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3450000>;
+ regulator-ramp-delay = <5000>;
+ regulator-always-on;
+ };
+
+ buck6 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3450000>;
+ regulator-ramp-delay = <5000>;
+ regulator-always-on;
+ };
+
+ aldo1 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ };
+
+ aldo2 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ };
+
+ aldo3 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ };
+
+ aldo4 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ };
+
+ dldo1 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ };
+
+ dldo2 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ };
+
+ dldo3 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ };
+
+ dldo4 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-always-on;
+ };
+
+ dldo5 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ };
+
+ dldo6 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-always-on;
+ };
+
+ dldo7 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ };
+ };
+ };
};
&uart0 {
--
2.47.3
^ permalink raw reply related
* [PATCH v3 1/3] riscv: dts: spacemit: Enable i2c8 adapter for OrangePi RV2
From: Han Gao @ 2026-03-29 17:05 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan
Cc: devicetree, linux-riscv, spacemit, linux-kernel, Han Gao, Han Gao
In-Reply-To: <cover.1774803532.git.gaohan@iscas.ac.cn>
The adapter is used to access the SpacemiT P1 PMIC present in this board.
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
---
arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
index 7b7331cb3c72..93880ba7bdfe 100644
--- a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
@@ -87,6 +87,12 @@ &pdma {
status = "okay";
};
+&i2c8 {
+ pinctrl-0 = <&i2c8_cfg>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_2_cfg>;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v13 3/6] iommu: Add verisilicon IOMMU driver
From: Benjamin Gaignard @ 2026-03-29 17:01 UTC (permalink / raw)
To: Will Deacon
Cc: joro, robin.murphy, robh, krzk+dt, conor+dt, heiko,
nicolas.dufresne, p.zabel, mchehab, iommu, devicetree,
linux-kernel, linux-arm-kernel, linux-rockchip, linux-media
In-Reply-To: <acQPEEd0hQrghGbw@willie-the-truck>
Le 25/03/2026 à 17:36, Will Deacon a écrit :
> On Tue, Mar 24, 2026 at 05:28:44PM +0100, Benjamin Gaignard wrote:
>> Le 24/03/2026 à 16:46, Will Deacon a écrit :
>>> On Mon, Feb 16, 2026 at 10:51:35AM +0100, Benjamin Gaignard wrote:
>>>> The Verisilicon IOMMU hardware block can be found in combination
>>>> with Verisilicon hardware video codecs (encoders or decoders) on
>>>> different SoCs.
>>>> Enable it will allow us to use non contiguous memory allocators
>>>> for Verisilicon video codecs.
>>>> If both decoder and this iommu driver are compiled has modules
>>>> there is undefined symboles issues so this iommu driver could
>>>> only be compiled has built-in.
>>>>
>>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
>>>> ---
>>>> MAINTAINERS | 8 +
>>>> drivers/iommu/Kconfig | 11 +
>>>> drivers/iommu/Makefile | 1 +
>>>> drivers/iommu/vsi-iommu.c | 794 ++++++++++++++++++++++++++++++++++++++
>>>> include/linux/vsi-iommu.h | 21 +
>>>> 5 files changed, 835 insertions(+)
>>>> create mode 100644 drivers/iommu/vsi-iommu.c
>>>> create mode 100644 include/linux/vsi-iommu.h
>>> [...]
>>>
>>>> +static size_t vsi_iommu_unmap(struct iommu_domain *domain, unsigned long _iova,
>>>> + size_t size, size_t count, struct iommu_iotlb_gather *gather)
>>>> +{
>>>> + struct vsi_iommu_domain *vsi_domain = to_vsi_domain(domain);
>>>> + dma_addr_t pte_dma, iova = (dma_addr_t)_iova;
>>>> + unsigned long flags;
>>>> + phys_addr_t pt_phys;
>>>> + u32 dte;
>>>> + u32 *pte_addr;
>>>> + size_t unmap_size = 0;
>>>> +
>>>> + spin_lock_irqsave(&vsi_domain->lock, flags);
>>>> +
>>>> + dte = vsi_domain->dt[vsi_iova_dte_index(iova)];
>>>> + /* Just return 0 if iova is unmapped */
>>>> + if (!vsi_dte_is_pt_valid(dte))
>>>> + goto unlock;
>>>> +
>>>> + pt_phys = vsi_dte_pt_address(dte);
>>>> + pte_addr = (u32 *)phys_to_virt(pt_phys) + vsi_iova_pte_index(iova);
>>>> + pte_dma = pt_phys + vsi_iova_pte_index(iova) * sizeof(u32);
>>>> + unmap_size = vsi_iommu_unmap_iova(vsi_domain, pte_addr, pte_dma, size);
>>>> +
>>>> +unlock:
>>>> + spin_unlock_irqrestore(&vsi_domain->lock, flags);
>>>> +
>>>> + return unmap_size;
>>>> +}
>>> I still think you need TLB invalidation here.
>>>
>>> I looked at the downstream code that you linked to and it litters the
>>> invalidation in the callers via mpp_iommu_flush_tlb(), which tend to
>>> invalidate _before_ starting an operation. That's very likely buggy and
>>> certainly not something we want upstream.
>>>
>>> The unmap routine should do the invalidation so that, when it returns,
>>> the pages really are unmapped from the device (assuming strict mode).
>>>
>>> I know you said that you tried to add invalidation here and it "didn't
>>> work", but that's not something I can really help you with.
>> I know you expect the hardware to work like that but that isn't not the
>> case.
> The hardware appears to have a register to invalidate the entire TLB.
> We can use that if there's nothing else.
VSI_MMU_BIT_FLUSH ? it discards everything.
Is there an api to call it when all buffers have been unmapped ?
>
>> I spend quite long to try to found hidden bit(s) or an other way to do like
>> you want but I can't find any solution.
> Then we can invalidate the entire TLB.
>
>> As you mention the downstream code suggest that the iommu can't invalidate
>> TLB in unmap routine so I don't see how to progress.
> The downstream code is a tangled mess; I don't think it suggests anything
> about what the IOMMU hardware is capable of.
If you have an other source to tell the hardware capabilities, I will be
more than happy to read it and fix the driver.
Benjamin
>
>> Maybe we should just admit that is how the hardware work.
> No.
>
> The upstream kernel isn't a dumping ground for vendor crap. The hardware
> has TLB invalidation functionality and so we should use it. If we don't,
> then we're not giving the IOMMU API what it expects and any callers
> outside of the video codecs will be landed with problems when unmap
> doesn't work as expected.
>
>> This v13 has fixed the documentation so I don't plan to spend more time on this driver.
> That's a shame, I'm really not asking for much.
>
> Will
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: msm8996: add blsp2_spi4 node
From: Dmitry Baryshkov @ 2026-03-29 16:46 UTC (permalink / raw)
To: Christopher Obbard
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <CACr-zFDv9mqZMOfHq+LjktA0DUVrTTw7-2oSxmu3U05ss2CQNg@mail.gmail.com>
On Sun, Mar 29, 2026 at 05:35:23PM +0100, Christopher Obbard wrote:
> Hi Dmitry,
>
> Thanks for the review.
>
> On Sun, 29 Mar 2026 at 17:03, Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > On Sun, Mar 29, 2026 at 02:19:15PM +0100, Christopher Obbard wrote:
> > > Add the BLSP2 SPI4 controller node together with its default and sleep
> > > pinctrl states.
> > >
> > > Signed-off-by: Christopher Obbard <christopher.obbard@linaro.org>
> > > ---
> > > arch/arm64/boot/dts/qcom/msm8996.dtsi | 41 +++++++++++++++++++++++++++++++++++
> > > 1 file changed, 41 insertions(+)
> > >
> > > @@ -3417,6 +3441,23 @@ blsp2_i2c3: i2c@75b7000 {
> > > status = "disabled";
> > > };
> > >
> > > + blsp2_spi4: spi@75b9000 {
> >
> > This should be coming after i2c@75b9000 (which needs to be renamed to
> > i2c4, btw)
>
> I will move the node in the next revision.
> I will also add a separate commit to rename i2c@75b9000 from
> blsp2_i2c5 to blsp2_i2c4. I assume the pinctrls also need to be
> renamed to i2c4?
> Also, do you know of any other nodes which need to be renamed while I am there?
Hmm, after checking. For whatever reason, the nodes are off-by-one.
Sorry, I didn't notice it from the beginning. So, instead this should be
blsp2_spi5.
>
>
> > > + compatible = "qcom,spi-qup-v2.2.1";
> > > + reg = <0x075b9000 0x600>,
> > > + <0x07584000 0x2b000>;
> >
> > This wasn't tested against the bindings.
>
> Oops - I will solve this in the next revision.
>
>
> Cheers!
>
> Chris
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/1] dt-bindings: connector: Add role‑switch provider phandle
From: Dmitry Baryshkov @ 2026-03-29 16:42 UTC (permalink / raw)
To: Elson Serrao
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heikki Krogerus,
Bjorn Andersson, Konrad Dybcio, Wesley Cheng, devicetree,
linux-kernel, linux-arm-msm
In-Reply-To: <a25ecdb4-1140-41e7-8007-8aadbe5c207c@oss.qualcomm.com>
On Thu, Mar 26, 2026 at 11:50:26AM -0700, Elson Serrao wrote:
>
>
> On 3/25/2026 6:57 PM, Dmitry Baryshkov wrote:
> > On Thu, 26 Mar 2026 at 03:49, Elson Serrao
> > <elson.serrao@oss.qualcomm.com> wrote:
> >>
>
> [...]
>
> >>>
> >>> Previously we didn't have such an issue for the usb-role-switch,
> >>> because there always have been a direct link between the USB connector
> >>> (be it gpio-usb-b-connector or usb-c-connector) and the USB controller
> >>> (implementing usb-role-switch). As with the EUD this is no longer a
> >>> case, my suggestion would be to follow prior art and let EUD receive,
> >>> interpret and resend usb-role-switch events.
> >>>
> >>
> >> In this topology, the EUD hardware spans more than one independent
> >> role-switch relationship, as a single EUD node is the direct neighbor of
> >> multiple connectors. This introduces additional considerations around
> >> role-switch discovery.
> >>
> >> One practical consideration if the EUD registers multiple role-switch
> >> instances is that fwnode_usb_role_switch_get() ( which relies on
> >> class_find_device_by_fwnode API), assumes a unique firmware node per
> >> role-switch instance. If multiple role-switch instances are registered
> >> against the same firmware node (the EUD fwnode), the lookup will return
> >> only the first registered instance, making it difficult for a connector to
> >> reliably bind to its intended role-switch provider.
> >>
> >> Supporting multiple role-switch instances in this model would therefore
> >> require extending the lookup mechanism to allow additional disambiguation
> >> (for example, associating role-switch instances with connector context).
> >>
> >> I want to make sure I clearly understand the intended modeling and whether
> >> these USB role-switch framework implications are considered acceptable.
> >
> > As far as I can see, you can register two usb-role-switches, one per
> > the EUD path. then the connector will still be able to discover
> > correct switch by following the chain from the connector. On the other
> > hand, the EUD driver can use fwnode_usb_role_switch_get() passing the
> > path's fwnode and find the next role-switch connected to the each of
> > the EUD ports / paths.
> >
>
> My earlier questions were primarily around a flattened ports representation.
> I agree that modeling each EUD path as a distinct child node with its own
> firmware node addresses those concerns cleanly.
>
> For context, the existing EUD binding [1] models a single controller ↔
> connector relationship using a flat top-level ports block. An earlier
> attempt [2] to reinterpret that top-level structure to represent
> multiple paths ran into DT ABI concerns, as it changed the meaning of
> existing bindings.
>
> Based on your example, my understanding is that the intended direction is
> to keep the existing top-level `ports` semantics unchanged for backward
> compatibility, and model multi-path hardware using explicit child nodes,
> each representing one controller ↔ connector relationship and registering
> a separate usb-role-switch instance.
I'd say, it is a good idea. This matches the port / ports case, where we
don't create ports node if we know that there will be only ports@0 node.
Likewise you can have only one OF graph if there is only one path (for
backwards compatibility) and add subnodes if there is more than one.
>
> Please let me know if this matches the intended direction.
>
> For the purposes of the usb‑role‑switch discussion, the other feedback in
> [2] around PHY handling is orthogonal and will be addressed in a follow‑up
> revision.
>
> Thanks,
> Elson
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml?h=v7.0-rc5
> [2] https://lore.kernel.org/all/20260126233830.2193816-2-elson.serrao@oss.qualcomm.com/
>
> > Here I am assuming that EUD device structured in a way like:
> >
> > eud {
> > compatible = "qcom,eud";
> >
> > path@0 {
> > ports {
> > port@0 {
> > endpoint {
> > remote-endpoint = <&usb_con_0_hs>;
> > };
> > };
> > port@1 {
> > endpoint {
> > remote-endpoint = <&usb0_hs>;
> > };
> > };
> > };
> > };
> >
> > path@1 {
> > ports {
> > port@0 {
> > endpoint {
> > remote-endpoint = <&usb_con_1_hs>;
> > };
> > };
> > port@1 {
> > endpoint {
> > remote-endpoint = <&usb1_hs>;
> > };
> > };
> > };
> > };
> >
> > };
> >
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 0/1] dt-bindings: connector: Add role‑switch provider phandle
From: Dmitry Baryshkov @ 2026-03-29 16:39 UTC (permalink / raw)
To: Elson Serrao
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heikki Krogerus,
Bjorn Andersson, Konrad Dybcio, Wesley Cheng, devicetree,
linux-kernel, linux-arm-msm
In-Reply-To: <28c9c2b5-feeb-49ae-9d4c-51ac571ad8a1@oss.qualcomm.com>
On Wed, Mar 25, 2026 at 06:44:35PM -0700, Elson Serrao wrote:
>
>
> On 3/24/2026 10:46 AM, Dmitry Baryshkov wrote:
> > Hello,
> >
> > On Tue, 24 Mar 2026 at 19:29, Elson Serrao
> > <elson.serrao@oss.qualcomm.com> wrote:
> >>
> >> Hi all,
> >>
> >> This patch proposes a generic Devicetree mechanism for a USB connector to
> >> reference the USB role‑switch provider when there is an intermediate,
> >> block between the connector and the controller in the OF graph.
> >
> > Please, don't describe what the patch or the change does, see
> > Documentation/processes/submitting-patches.rst.
> >
> >>
> >> Problem
> >> =======
> >> OF‑graph links are strictly point‑to‑point via remote-endpoint, so a
> >> consumer can only discover its immediate neighbor in the graph. When an
> >> intermediate node sits between the USB connector and the controller, the
> >> connector cannot identify the controller (the role‑switch provider) from
> >> the graph alone.
> >
> > DT is a hardware description. Here you are trying to describe the
> > software behaviour. Please don't mix those.
> >
> > [skipped diagrams]
> >
> >>
> >> From the OF‑graph structure alone, Conn‑0 cannot determine that
> >> USBCtrl‑0 (and not USBCtrl‑1) is the correct role‑switch provider.
> >>
> >> Proposal
> >> ========
> >> Add an optional consumer→provider phandle on the connector:
> >>
> >> usb-role-switch = <&controller>;
> >
> > An alternative proposal: let EUD register as a role-switch and then
> > retranslate usb-role-switch events. This is how it is handled by the
> > Type-C-related objects (muxes and orientation switches).
> >
>
> Hi Dmitry,
>
> Thank you for the review and suggestions.
>
> To better understand the intended model: are you proposing that the EUD
> register a separate usb‑role‑switch instance per connector → controller
> relationship, or a single role‑switch instance representing the EUD as a
> whole?
>
> I understand the analogy with Type‑C muxes and orientation switches, which
> are typically modeled on a per‑connector basis. In contrast, the EUD hardware
> block spans multiple connectors and controllers and can carry traffic from
> multiple independent USB connections concurrently.
> For example:
> - Connector0 operating in host mode (connected to Controller0)
> - Connector1 operating in device mode (connected to Controller1)
> - Both active at the same time
>
> In such a scenario, a single role‑switch instance representing both
> connectors appears ambiguous, as different roles may be active
> simultaneously on different ports.
>
> Registering multiple role‑switch instances—one per connector/controller
> pair—would avoid that ambiguity. However, this would imply a single EUD
> device registering multiple role‑switch instances associated with the same
> firmware node. As the USB role‑switch framework currently assumes a 1:1
> relationship between a firmware node and its role‑switch instance, this
> would likely require non‑trivial changes to USB role switch framework on
> how role‑switch instances are represented and managed.
It assumes 1:1 between some fwnode and the role-switch. But nothing
implies that it is the device node. It is the parent of the
corresponding OF graph. If EUD has two graphs, then each graph can have
its own usb-role-switch.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: msm8996: add blsp2_spi4 node
From: Christopher Obbard @ 2026-03-29 16:35 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <grmuh7b5phy6clv7izgq43yjtfxaulw3h6tqjenux35r5o3qnk@6q7nlgczigdx>
Hi Dmitry,
Thanks for the review.
On Sun, 29 Mar 2026 at 17:03, Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> On Sun, Mar 29, 2026 at 02:19:15PM +0100, Christopher Obbard wrote:
> > Add the BLSP2 SPI4 controller node together with its default and sleep
> > pinctrl states.
> >
> > Signed-off-by: Christopher Obbard <christopher.obbard@linaro.org>
> > ---
> > arch/arm64/boot/dts/qcom/msm8996.dtsi | 41 +++++++++++++++++++++++++++++++++++
> > 1 file changed, 41 insertions(+)
> >
> > @@ -3417,6 +3441,23 @@ blsp2_i2c3: i2c@75b7000 {
> > status = "disabled";
> > };
> >
> > + blsp2_spi4: spi@75b9000 {
>
> This should be coming after i2c@75b9000 (which needs to be renamed to
> i2c4, btw)
I will move the node in the next revision.
I will also add a separate commit to rename i2c@75b9000 from
blsp2_i2c5 to blsp2_i2c4. I assume the pinctrls also need to be
renamed to i2c4?
Also, do you know of any other nodes which need to be renamed while I am there?
> > + compatible = "qcom,spi-qup-v2.2.1";
> > + reg = <0x075b9000 0x600>,
> > + <0x07584000 0x2b000>;
>
> This wasn't tested against the bindings.
Oops - I will solve this in the next revision.
Cheers!
Chris
^ permalink raw reply
* [PATCH v3 06/24] dt-bindings: firmware: arm,scmi: Add support for telemetry protocol
From: Cristian Marussi @ 2026-03-29 16:33 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, arm-scmi, linux-fsdevel,
linux-doc
Cc: sudeep.holla, james.quinlan, f.fainelli, vincent.guittot,
etienne.carriere, peng.fan, michal.simek, dan.carpenter, d-gole,
jonathan.cameron, elif.topuz, lukasz.luba, philip.radford,
brauner, souvik.chakravarty, Cristian Marussi, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260329163337.637393-1-cristian.marussi@arm.com>
Add new SCMI v4.0 Telemetry protocol bindings definitions.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
Cc: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: devicetree@vger.kernel.org
---
Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index be817fd9cc34..e936ae7c0fb9 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -298,6 +298,14 @@ properties:
reg:
const: 0x19
+ protocol@1B:
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ const: 0x1B
+
patternProperties:
'-pins$':
type: object
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] dt-bindings: perf: marvell: Document CN20K DDR PMU
From: Rob Herring (Arm) @ 2026-03-29 16:31 UTC (permalink / raw)
To: Geetha sowjanya
Cc: krzk+dt, mark.rutland, linux-kernel, will, linux-perf-users,
linux-arm-kernel, devicetree
In-Reply-To: <20260329152439.10573-2-gakula@marvell.com>
On Sun, 29 Mar 2026 20:54:38 +0530, Geetha sowjanya wrote:
> Add a devicetree binding for the Marvell CN20K DDR performance
> monitor block, including the marvell,cn20k-ddr-pmu compatible
> string and the required MMIO reg region.
>
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
> ---
>
> Changes in v1:
> - Added a description field to the binding.
> - Simplified the compatible property using 'const' instead of 'items/enum'.
> - Updated the example node name to include a unit-address matching the reg base.
>
> .../bindings/perf/marvell-cn20k-ddr.yaml | 39 +++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml:35:1: [error] syntax error: found character '\t' that cannot start any token (syntax)
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml: ignoring, error parsing file
./Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml:35:1: found character '\t' that cannot start any token
make[2]: *** Deleting file 'Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.example.dts'
Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml:35:1: found character '\t' that cannot start any token
make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.example.dts] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1614: dt_binding_check] Error 2
make: *** [Makefile:248: __sub-make] Error 2
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260329152439.10573-2-gakula@marvell.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v4 3/3] arm64: dts: qcom: sdm845-xiaomi-beryllium: Enable ath10k host-cap skip quirk
From: Dmitry Baryshkov @ 2026-03-29 16:27 UTC (permalink / raw)
To: david
Cc: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio, Paul Sajna,
Amit Pundir, linux-wireless, devicetree, ath10k, linux-kernel,
linux-arm-msm, phone-devel
In-Reply-To: <20260325-skip-host-cam-qmi-req-v4-3-bc08538487aa@ixit.cz>
On Wed, Mar 25, 2026 at 06:57:17PM +0100, David Heidelberg via B4 Relay wrote:
> From: Amit Pundir <amit.pundir@linaro.org>
>
> The Wi-Fi firmware used on Xiaomi Poco F1 (beryllium) phone doesn't
> support the host-capability QMI request, so add a quirk to skip it on
> this device.
>
> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-common.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 2/3] ath10k: Add device-tree quirk to skip host cap QMI requests
From: Dmitry Baryshkov @ 2026-03-29 16:26 UTC (permalink / raw)
To: david
Cc: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio, Paul Sajna,
Amit Pundir, linux-wireless, devicetree, ath10k, linux-kernel,
linux-arm-msm, phone-devel
In-Reply-To: <20260325-skip-host-cam-qmi-req-v4-2-bc08538487aa@ixit.cz>
On Wed, Mar 25, 2026 at 06:57:16PM +0100, David Heidelberg via B4 Relay wrote:
> From: Amit Pundir <amit.pundir@linaro.org>
>
> Some firmware versions do not support the host capability QMI request.
> Since this request occurs before firmware-N.bin and board-M.bin are
> loaded, the quirk cannot be expressed in the firmware itself.
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Jeff, to my knowledge this is the best approach that we have to solve
the issue on those devices.
>
> The root cause is unclear, but there appears to be a generation of
> firmware that lacks host capability support.
>
> Without this quirk, ath10k_qmi_host_cap_send_sync() returns
> QMI_ERR_MALFORMED_MSG_V01 before loading the firmware. This error is not
> fatal - Wi-Fi services still come up successfully if the request is simply
> skipped.
>
> Add a device-tree quirk to skip the host capability QMI request on devices
> whose firmware does not support it.
>
> For example, firmware build
> "QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1"
> on Xiaomi Poco F1 phone requires this quirk.
>
> Suggested-by: Bjorn Andersson <andersson@kernel.org>
> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> drivers/net/wireless/ath/ath10k/qmi.c | 13 ++++++++++---
> drivers/net/wireless/ath/ath10k/snoc.c | 3 +++
> drivers/net/wireless/ath/ath10k/snoc.h | 1 +
> 3 files changed, 14 insertions(+), 3 deletions(-)
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 3/6] arm64: dts: qcom: msm8953-flipkart-rimob: Enable display and GPU
From: cristian_ci @ 2026-03-29 16:19 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
dri-devel, devicetree, linux-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <s6kyh5wyamcxyd7xsbu5wrrpndpdb5xhxapmxze2qgblng5eiq@hl36nzg2lldg>
On Sunday, March 29th, 2026 at 17:51, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> On Sun, Mar 29, 2026 at 03:26:48PM +0000, cristian_ci wrote:
> > On Sunday, March 29th, 2026 at 12:12, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > > On Sat, Mar 28, 2026 at 05:30:53PM +0000, cristian_ci wrote:
> > > > On Friday, March 27th, 2026 at 23:57, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> > > >
> > > > > On Fri, Mar 27, 2026 at 03:30:49PM +0100, 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>
> > > > > > ---
> > > > > > .../arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts | 73 ++++++++++++++++++++++
> > > > > > 1 file changed, 73 insertions(+)
> > > > > >
> > > > >
> > > > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > > >
> > > > I wonder if I should, instead, edit the compatible property by adding a
> > > > second string (for the fallback), like this:
> > > >
> > > > compatible = "flipkart,rimob-panel-nt35532-cs", "novatek,nt35532";
> > > >
> > > > and, therefore, add "novatek,nt35532" string also to (patch 1/6)'s
> > > > bindings example. Let me know what you think.
> > >
> > > What would it mean? I think we usually don't include the IC into the
> > > compat list for the panel, but feel free to prove me wrong.
> >
> > I've noticed use of that in this [1] patch series but I don't know why IC
> > string is used there (in the example) if the specific panel string (the
> > first one) is already defined in the panel driver.
> >
> > [1] https://lore.kernel.org/linux-arm-msm/20251001135914.13754-2-caojunjie650@gmail.com/
>
> That's why I wrote "usually". In the end we also have several
> (unfortunately) panel devices which use IC for compat string, etc.
Ok, thanks for the reply.
Best Regards,
Cristian.
> --
> With best wishes
> Dmitry
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: msm8996: fix indentation in sdhc2 node
From: Dmitry Baryshkov @ 2026-03-29 16:06 UTC (permalink / raw)
To: Christopher Obbard
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260329-wip-obbardc-msm8996-whitespace-v1-1-ba3a278f043c@linaro.org>
On Sun, Mar 29, 2026 at 02:12:26PM +0100, Christopher Obbard wrote:
> Drop stray leading whitespace from sdhc2 node.
>
> No functional change.
>
> Signed-off-by: Christopher Obbard <christopher.obbard@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: msm8996: add blsp2_spi4 node
From: Dmitry Baryshkov @ 2026-03-29 16:03 UTC (permalink / raw)
To: Christopher Obbard
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260329-wip-obbardc-msm8996-blsp2_spi4-v1-1-5d9270235e92@linaro.org>
On Sun, Mar 29, 2026 at 02:19:15PM +0100, Christopher Obbard wrote:
> Add the BLSP2 SPI4 controller node together with its default and sleep
> pinctrl states.
>
> Signed-off-by: Christopher Obbard <christopher.obbard@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 41 +++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> @@ -3417,6 +3441,23 @@ blsp2_i2c3: i2c@75b7000 {
> status = "disabled";
> };
>
> + blsp2_spi4: spi@75b9000 {
This should be coming after i2c@75b9000 (which needs to be renamed to
i2c4, btw)
> + compatible = "qcom,spi-qup-v2.2.1";
> + reg = <0x075b9000 0x600>,
> + <0x07584000 0x2b000>;
This wasn't tested against the bindings.
> + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 239 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&gcc GCC_BLSP2_QUP5_SPI_APPS_CLK>,
> + <&gcc GCC_BLSP2_AHB_CLK>;
> + clock-names = "core", "iface";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&blsp2_spi4_default>;
> + pinctrl-1 = <&blsp2_spi4_sleep>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> blsp2_i2c5: i2c@75b9000 {
> compatible = "qcom,i2c-qup-v2.2.1";
> reg = <0x75b9000 0x1000>;
>
> ---
> base-commit: 54f966f63b379d0c62bb044b7903319776443a4a
> change-id: 20260329-wip-obbardc-msm8996-blsp2_spi4-7892454c504c
>
> Best regards,
> --
> Christopher Obbard <christopher.obbard@linaro.org>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 3/6] arm64: dts: qcom: msm8953-flipkart-rimob: Enable display and GPU
From: Dmitry Baryshkov @ 2026-03-29 15:51 UTC (permalink / raw)
To: cristian_ci
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
dri-devel, devicetree, linux-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <VRCUEe2qHZa0a8HzVvhoRtAZyXO8pBU_l96B6U1kL5EFVSJyQBfYeKDvqPit-qpPRtIjUbtl7TH0JegJ7LXvctAxgyo50K6rTC5hwNjuV5k=@protonmail.com>
On Sun, Mar 29, 2026 at 03:26:48PM +0000, cristian_ci wrote:
> On Sunday, March 29th, 2026 at 12:12, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> > On Sat, Mar 28, 2026 at 05:30:53PM +0000, cristian_ci wrote:
> > > On Friday, March 27th, 2026 at 23:57, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> > >
> > > > On Fri, Mar 27, 2026 at 03:30:49PM +0100, 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>
> > > > > ---
> > > > > .../arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts | 73 ++++++++++++++++++++++
> > > > > 1 file changed, 73 insertions(+)
> > > > >
> > > >
> > > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > >
> > > I wonder if I should, instead, edit the compatible property by adding a
> > > second string (for the fallback), like this:
> > >
> > > compatible = "flipkart,rimob-panel-nt35532-cs", "novatek,nt35532";
> > >
> > > and, therefore, add "novatek,nt35532" string also to (patch 1/6)'s
> > > bindings example. Let me know what you think.
> >
> > What would it mean? I think we usually don't include the IC into the
> > compat list for the panel, but feel free to prove me wrong.
>
> I've noticed use of that in this [1] patch series but I don't know why IC
> string is used there (in the example) if the specific panel string (the
> first one) is already defined in the panel driver.
>
> [1] https://lore.kernel.org/linux-arm-msm/20251001135914.13754-2-caojunjie650@gmail.com/
That's why I wrote "usually". In the end we also have several
(unfortunately) panel devices which use IC for compat string, etc.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v8 0/6] mfd: Add support for NXP MC33978/MC34978 MSDI
From: Guenter Roeck @ 2026-03-29 15:34 UTC (permalink / raw)
To: Oleksij Rempel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Peter Rosin, Linus Walleij
Cc: kernel, linux-kernel, devicetree, linux-hwmon, linux-gpio,
David Jander
In-Reply-To: <20260329090601.532477-1-o.rempel@pengutronix.de>
Hi Oleksij,
On 3/29/26 02:05, Oleksij Rempel wrote:
> changes v7:
> - drop gpiolib irq fix and make pinctrl more robust against NULL point
> dereference.
>
> This series adds support for the NXP MC33978/MC34978 Multiple Switch Detection
> Interface (MSDI) via the MFD framework.
>
> Architecture overview:
> * mfd: Core driver handling 2-frame pipelined SPI, regulator sequencing, and
> linear irq_domain. Harvests status bits from SPI MISO MSB.
> * pinctrl: Exposes 22 physical switch inputs as standard GPIOs. Proxies IRQs to
> the MFD domain.
> * hwmon: Exposes thermal limits, VBATP/VDDQ voltage boundaries, and dynamic
> fault alarms.
> * mux: Controls the 24-to-1 AMUX routing analog signals (switch voltages,
> temperature, VBATP) to an external ADC.
>
> Initial pinctrl implementation by David Jander, reworked into this MFD
> architecture.
>
I Acked the hwmon driver, but Sashiko is still not happy with several of the other
patches in the series:
https://sashiko.dev/#/patchset/20260329090601.532477-1-o.rempel%40pengutronix.de
If the remaining issues are false positives, please let Roman and/or me know.
Thanks,
Guenter
^ permalink raw reply
* [PATCH net-next v3 3/3] net: pse-pd: add LED trigger support via notification path
From: Carlo Szelinsky @ 2026-03-29 15:31 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-leds, Carlo Szelinsky, kernel test robot
In-Reply-To: <20260329153124.2823980-1-github@szelinsky.de>
Add per-PI "delivering" and "enabled" LED triggers to the PSE core
subsystem. LED state is updated from the shared pse_handle_events()
function whenever the IRQ or poll path detects a state change, as well
as from the regulator enable/disable paths so that host-initiated
admin state changes via ethtool are immediately reflected.
Both C33 and PoDL power status and admin state are checked so that LED
triggers work for both controller types.
Trigger names use dev_name(dev) (e.g. "pse-1-003c:port0:delivering")
to ensure uniqueness when multiple PSE controllers are present on the
same system.
Initial LED state is queried at registration time so already-active
ports are reflected immediately without waiting for a hardware event.
LED trigger registration is performed before adding the controller to
the global list, avoiding a race where an IRQ or poll event could
invoke pse_led_update() on a partially initialized trigger.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603251254.o5PqMBRU-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202603251250.cuMCk5Yv-lkp@intel.com/
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
---
drivers/net/pse-pd/pse_core.c | 134 +++++++++++++++++++++++++++++++++-
include/linux/pse-pd/pse.h | 22 ++++++
2 files changed, 154 insertions(+), 2 deletions(-)
diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 23783bf2edf4..dd0895ca07ad 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -12,9 +12,10 @@
#include <linux/phy.h>
#include <linux/pse-pd/pse.h>
#include <linux/regulator/driver.h>
+#include <linux/leds.h>
+#include <linux/workqueue.h>
#include <linux/regulator/machine.h>
#include <linux/rtnetlink.h>
-#include <linux/workqueue.h>
#include <net/net_trackers.h>
#define PSE_PW_D_LIMIT INT_MAX
@@ -670,6 +671,111 @@ static int _pse_pi_delivery_power_sw_pw_ctrl(struct pse_controller_dev *pcdev,
return 0;
}
+#if IS_ENABLED(CONFIG_LEDS_TRIGGERS)
+/**
+ * pse_led_update - Update LED triggers for a PI based on current state
+ * @pcdev: PSE controller device
+ * @id: PI index
+ *
+ * Queries the current power status and admin state of the PI and
+ * fires LED trigger events on state changes. Called from the
+ * notification path and the regulator enable/disable paths.
+ *
+ * Must be called with pcdev->lock held.
+ */
+static void pse_led_update(struct pse_controller_dev *pcdev, int id)
+{
+ struct pse_pi_led_triggers *trigs;
+ struct pse_pw_status pw_status = {};
+ struct pse_admin_state admin_state = {};
+ bool delivering, enabled;
+
+ if (!pcdev->pi_led_trigs)
+ return;
+
+ trigs = &pcdev->pi_led_trigs[id];
+ if (!trigs->delivering.name)
+ return;
+
+ if (pcdev->ops->pi_get_pw_status(pcdev, id, &pw_status))
+ return;
+ if (pcdev->ops->pi_get_admin_state(pcdev, id, &admin_state))
+ return;
+
+ delivering = pw_status.c33_pw_status ==
+ ETHTOOL_C33_PSE_PW_D_STATUS_DELIVERING ||
+ pw_status.podl_pw_status ==
+ ETHTOOL_PODL_PSE_PW_D_STATUS_DELIVERING;
+ enabled = admin_state.c33_admin_state ==
+ ETHTOOL_C33_PSE_ADMIN_STATE_ENABLED ||
+ admin_state.podl_admin_state ==
+ ETHTOOL_PODL_PSE_ADMIN_STATE_ENABLED;
+
+ if (trigs->last_delivering != delivering) {
+ trigs->last_delivering = delivering;
+ led_trigger_event(&trigs->delivering,
+ delivering ? LED_FULL : LED_OFF);
+ }
+
+ if (trigs->last_enabled != enabled) {
+ trigs->last_enabled = enabled;
+ led_trigger_event(&trigs->enabled,
+ enabled ? LED_FULL : LED_OFF);
+ }
+}
+
+static int pse_led_triggers_register(struct pse_controller_dev *pcdev)
+{
+ struct device *dev = pcdev->dev;
+ const char *dev_id;
+ int i, ret;
+
+ dev_id = dev_name(dev);
+
+ pcdev->pi_led_trigs = devm_kcalloc(dev, pcdev->nr_lines,
+ sizeof(*pcdev->pi_led_trigs),
+ GFP_KERNEL);
+ if (!pcdev->pi_led_trigs)
+ return -ENOMEM;
+
+ for (i = 0; i < pcdev->nr_lines; i++) {
+ struct pse_pi_led_triggers *trigs = &pcdev->pi_led_trigs[i];
+
+ /* Skip PIs not described in device tree */
+ if (!pcdev->no_of_pse_pi && !pcdev->pi[i].np)
+ continue;
+
+ trigs->delivering.name = devm_kasprintf(dev, GFP_KERNEL,
+ "pse-%s:port%d:delivering",
+ dev_id, i);
+ if (!trigs->delivering.name)
+ return -ENOMEM;
+
+ ret = devm_led_trigger_register(dev, &trigs->delivering);
+ if (ret)
+ return ret;
+
+ trigs->enabled.name = devm_kasprintf(dev, GFP_KERNEL,
+ "pse-%s:port%d:enabled",
+ dev_id, i);
+ if (!trigs->enabled.name)
+ return -ENOMEM;
+
+ ret = devm_led_trigger_register(dev, &trigs->enabled);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+#else
+static inline void pse_led_update(struct pse_controller_dev *pcdev, int id) {}
+static int pse_led_triggers_register(struct pse_controller_dev *pcdev)
+{
+ return 0;
+}
+#endif /* CONFIG_LEDS_TRIGGERS */
+
static int pse_pi_enable(struct regulator_dev *rdev)
{
struct pse_controller_dev *pcdev = rdev_get_drvdata(rdev);
@@ -695,6 +801,7 @@ static int pse_pi_enable(struct regulator_dev *rdev)
pcdev->pi[id].admin_state_enabled = 1;
ret = 0;
}
+ pse_led_update(pcdev, id);
mutex_unlock(&pcdev->lock);
return ret;
}
@@ -702,6 +809,7 @@ static int pse_pi_enable(struct regulator_dev *rdev)
ret = ops->pi_enable(pcdev, id);
if (!ret)
pcdev->pi[id].admin_state_enabled = 1;
+ pse_led_update(pcdev, id);
mutex_unlock(&pcdev->lock);
return ret;
@@ -719,6 +827,7 @@ static int pse_pi_disable(struct regulator_dev *rdev)
ret = _pse_pi_disable(pcdev, id);
if (!ret)
pi->admin_state_enabled = 0;
+ pse_led_update(pcdev, id);
mutex_unlock(&pcdev->lock);
return 0;
@@ -1108,6 +1217,20 @@ int pse_controller_register(struct pse_controller_dev *pcdev)
if (ret)
return ret;
+ ret = pse_led_triggers_register(pcdev);
+ if (ret) {
+ dev_warn(pcdev->dev, "Failed to register LED triggers: %d\n",
+ ret);
+ }
+
+ /* Query initial LED state for all PIs so already-active ports
+ * are reflected immediately without waiting for a hardware event.
+ */
+ for (i = 0; i < pcdev->nr_lines; i++) {
+ if (pcdev->no_of_pse_pi || pcdev->pi[i].np)
+ pse_led_update(pcdev, i);
+ }
+
mutex_lock(&pse_list_mutex);
list_add(&pcdev->list, &pse_controller_list);
mutex_unlock(&pse_list_mutex);
@@ -1265,7 +1388,14 @@ static void pse_handle_events(struct pse_controller_dev *pcdev,
struct pse_ntf ntf = {};
int ret;
- /* Do nothing PI not described */
+ /* Update LEDs for described PIs regardless of consumer state.
+ * LED triggers are registered at controller init, before any
+ * PHY claims a PSE control, so rdev may still be NULL here.
+ */
+ if (pcdev->no_of_pse_pi || pcdev->pi[i].np)
+ pse_led_update(pcdev, i);
+
+ /* Skip regulator/netlink path for PIs without consumers */
if (!pcdev->pi[i].rdev)
continue;
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index 44d5d10e239d..0058636a6299 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -10,6 +10,7 @@
#include <linux/kfifo.h>
#include <uapi/linux/ethtool.h>
#include <uapi/linux/ethtool_netlink_generated.h>
+#include <linux/leds.h>
#include <linux/regulator/driver.h>
/* Maximum current in uA according to IEEE 802.3-2022 Table 145-1 */
@@ -266,6 +267,23 @@ struct pse_pi {
int pw_allocated_mW;
};
+#if IS_ENABLED(CONFIG_LEDS_TRIGGERS)
+/**
+ * struct pse_pi_led_triggers - LED trigger state for a PSE PI
+ *
+ * @delivering: LED trigger for power delivering state
+ * @enabled: LED trigger for admin enabled state
+ * @last_delivering: cached delivering state for change detection
+ * @last_enabled: cached enabled state for change detection
+ */
+struct pse_pi_led_triggers {
+ struct led_trigger delivering;
+ struct led_trigger enabled;
+ bool last_delivering;
+ bool last_enabled;
+};
+#endif
+
/**
* struct pse_ntf - PSE notification element
*
@@ -303,6 +321,7 @@ struct pse_ntf {
* @ntf_work: workqueue for PSE notification management
* @ntf_fifo: PSE notifications FIFO
* @ntf_fifo_lock: protect @ntf_fifo writer
+ * @pi_led_trigs: per-PI LED trigger state array
*/
struct pse_controller_dev {
const struct pse_controller_ops *ops;
@@ -327,6 +346,9 @@ struct pse_controller_dev {
struct work_struct ntf_work;
DECLARE_KFIFO_PTR(ntf_fifo, struct pse_ntf);
spinlock_t ntf_fifo_lock; /* Protect @ntf_fifo writer */
+#if IS_ENABLED(CONFIG_LEDS_TRIGGERS)
+ struct pse_pi_led_triggers *pi_led_trigs;
+#endif
};
/**
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v3 2/3] net: pse-pd: add devm_pse_poll_helper()
From: Carlo Szelinsky @ 2026-03-29 15:31 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-leds, Carlo Szelinsky
In-Reply-To: <20260329153124.2823980-1-github@szelinsky.de>
Extract the common event handling loop from pse_isr() into a shared
pse_handle_events() function, and add a generic poll-based alternative
to the IRQ path for PSE controllers that lack interrupt support or
have IRQ lines not wired on the board.
The new devm_pse_poll_helper() function sets up a delayed work that
periodically calls the driver's map_event callback to detect state
changes, feeding events into the existing ntf_fifo / pse_send_ntf_worker
notification pipeline. This reuses the same pse_irq_desc interface as
the IRQ path — the driver provides a map_event callback that populates
per-PI notification arrays.
The poll worker uses system_freezable_wq to avoid running during system
suspend when the underlying hardware (e.g. I2C bus) may be inaccessible.
Work cancellation on teardown is handled via devm_add_action_or_reset()
to ensure the delayed work is cancelled before poll_notifs is freed
by devres, avoiding a use-after-free when devm_pse_poll_helper() is
called after devm_pse_controller_register() (devres LIFO ordering).
The poll interval is configurable via the DT property "poll-interval-ms"
and defaults to 500ms, balancing responsiveness against I2C bus load.
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
---
drivers/net/pse-pd/pse_core.c | 166 ++++++++++++++++++++++++++++------
include/linux/pse-pd/pse.h | 12 +++
2 files changed, 148 insertions(+), 30 deletions(-)
diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 3beaaaeec9e1..23783bf2edf4 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -14,10 +14,18 @@
#include <linux/regulator/driver.h>
#include <linux/regulator/machine.h>
#include <linux/rtnetlink.h>
+#include <linux/workqueue.h>
#include <net/net_trackers.h>
#define PSE_PW_D_LIMIT INT_MAX
+/*
+ * Default poll interval for controllers without IRQ support.
+ * 500ms provides a reasonable trade-off between responsiveness
+ * (event detection, PD detection) and I2C bus utilization.
+ */
+#define PSE_DEFAULT_POLL_INTERVAL_MS 500
+
static DEFINE_MUTEX(pse_list_mutex);
static LIST_HEAD(pse_controller_list);
static DEFINE_XARRAY_ALLOC(pse_pw_d_map);
@@ -1238,66 +1246,103 @@ static int pse_set_config_isr(struct pse_controller_dev *pcdev, int id,
}
/**
- * pse_isr - IRQ handler for PSE
- * @irq: irq number
- * @data: pointer to user interrupt structure
+ * pse_handle_events - Process PSE events for all PIs
+ * @pcdev: a pointer to the PSE controller device
+ * @notifs: per-PI notification array
+ * @notifs_mask: bitmask of PIs with events
*
- * Return: irqreturn_t - status of IRQ
+ * Common event handling shared between IRQ and poll paths.
+ * Caller must hold pcdev->lock.
*/
-static irqreturn_t pse_isr(int irq, void *data)
+static void pse_handle_events(struct pse_controller_dev *pcdev,
+ unsigned long *notifs,
+ unsigned long notifs_mask)
{
- struct pse_controller_dev *pcdev;
- unsigned long notifs_mask = 0;
- struct pse_irq_desc *desc;
- struct pse_irq *h = data;
- int ret, i;
-
- desc = &h->desc;
- pcdev = h->pcdev;
-
- /* Clear notifs mask */
- memset(h->notifs, 0, pcdev->nr_lines * sizeof(*h->notifs));
- mutex_lock(&pcdev->lock);
- ret = desc->map_event(irq, pcdev, h->notifs, ¬ifs_mask);
- if (ret || !notifs_mask) {
- mutex_unlock(&pcdev->lock);
- return IRQ_NONE;
- }
+ int i;
for_each_set_bit(i, ¬ifs_mask, pcdev->nr_lines) {
- unsigned long notifs, rnotifs;
+ unsigned long pi_notifs, rnotifs;
struct pse_ntf ntf = {};
+ int ret;
/* Do nothing PI not described */
if (!pcdev->pi[i].rdev)
continue;
- notifs = h->notifs[i];
+ pi_notifs = notifs[i];
if (pse_pw_d_is_sw_pw_control(pcdev, pcdev->pi[i].pw_d)) {
- ret = pse_set_config_isr(pcdev, i, notifs);
+ ret = pse_set_config_isr(pcdev, i, pi_notifs);
if (ret)
- notifs |= ETHTOOL_PSE_EVENT_SW_PW_CONTROL_ERROR;
+ pi_notifs |= ETHTOOL_PSE_EVENT_SW_PW_CONTROL_ERROR;
}
- dev_dbg(h->pcdev->dev,
- "Sending PSE notification EVT 0x%lx\n", notifs);
+ dev_dbg(pcdev->dev,
+ "Sending PSE notification EVT 0x%lx\n", pi_notifs);
- ntf.notifs = notifs;
+ ntf.notifs = pi_notifs;
ntf.id = i;
kfifo_in_spinlocked(&pcdev->ntf_fifo, &ntf, 1,
&pcdev->ntf_fifo_lock);
schedule_work(&pcdev->ntf_work);
- rnotifs = pse_to_regulator_notifs(notifs);
+ rnotifs = pse_to_regulator_notifs(pi_notifs);
regulator_notifier_call_chain(pcdev->pi[i].rdev, rnotifs,
NULL);
}
+}
+
+/**
+ * pse_isr - IRQ handler for PSE
+ * @irq: irq number
+ * @data: pointer to user interrupt structure
+ *
+ * Return: irqreturn_t - status of IRQ
+ */
+static irqreturn_t pse_isr(int irq, void *data)
+{
+ struct pse_controller_dev *pcdev;
+ unsigned long notifs_mask = 0;
+ struct pse_irq *h = data;
+ int ret;
+ pcdev = h->pcdev;
+
+ /* Clear notifs mask */
+ memset(h->notifs, 0, pcdev->nr_lines * sizeof(*h->notifs));
+ mutex_lock(&pcdev->lock);
+ ret = h->desc.map_event(irq, pcdev, h->notifs, ¬ifs_mask);
+ if (ret || !notifs_mask) {
+ mutex_unlock(&pcdev->lock);
+ return IRQ_NONE;
+ }
+
+ pse_handle_events(pcdev, h->notifs, notifs_mask);
mutex_unlock(&pcdev->lock);
return IRQ_HANDLED;
}
+static void pse_poll_worker(struct work_struct *work)
+{
+ struct pse_controller_dev *pcdev =
+ container_of(work, struct pse_controller_dev,
+ poll_work.work);
+ unsigned long notifs_mask = 0;
+ int ret;
+
+ memset(pcdev->poll_notifs, 0,
+ pcdev->nr_lines * sizeof(*pcdev->poll_notifs));
+ mutex_lock(&pcdev->lock);
+ ret = pcdev->poll_desc.map_event(0, pcdev, pcdev->poll_notifs,
+ ¬ifs_mask);
+ if (!ret && notifs_mask)
+ pse_handle_events(pcdev, pcdev->poll_notifs, notifs_mask);
+ mutex_unlock(&pcdev->lock);
+
+ queue_delayed_work(system_freezable_wq, &pcdev->poll_work,
+ msecs_to_jiffies(pcdev->poll_interval_ms));
+}
+
/**
* devm_pse_irq_helper - Register IRQ based PSE event notifier
* @pcdev: a pointer to the PSE
@@ -1351,6 +1396,67 @@ int devm_pse_irq_helper(struct pse_controller_dev *pcdev, int irq,
}
EXPORT_SYMBOL_GPL(devm_pse_irq_helper);
+static void pse_poll_cancel(void *data)
+{
+ struct pse_controller_dev *pcdev = data;
+
+ cancel_delayed_work_sync(&pcdev->poll_work);
+}
+
+/**
+ * devm_pse_poll_helper - Register poll-based PSE event notifier
+ * @pcdev: a pointer to the PSE controller device
+ * @d: PSE event description (uses same pse_irq_desc as IRQ path)
+ *
+ * For PSE controllers without IRQ support or with IRQ not wired. Sets
+ * up a delayed work that periodically calls the driver's map_event
+ * callback to detect state changes, feeding events into the standard
+ * notification pipeline.
+ *
+ * The poll worker uses system_freezable_wq to ensure it does not run
+ * during system suspend while the hardware may be inaccessible.
+ *
+ * Return: 0 on success and errno on failure
+ */
+int devm_pse_poll_helper(struct pse_controller_dev *pcdev,
+ const struct pse_irq_desc *d)
+{
+ struct device *dev = pcdev->dev;
+ int ret;
+
+ if (!d || !d->map_event || !d->name)
+ return -EINVAL;
+
+ pcdev->poll_desc = *d;
+ pcdev->poll_notifs = devm_kcalloc(dev, pcdev->nr_lines,
+ sizeof(*pcdev->poll_notifs),
+ GFP_KERNEL);
+ if (!pcdev->poll_notifs)
+ return -ENOMEM;
+
+ of_property_read_u32(dev->of_node, "poll-interval-ms",
+ &pcdev->poll_interval_ms);
+ if (!pcdev->poll_interval_ms)
+ pcdev->poll_interval_ms = PSE_DEFAULT_POLL_INTERVAL_MS;
+
+ INIT_DELAYED_WORK(&pcdev->poll_work, pse_poll_worker);
+ pcdev->polling = true;
+
+ /* Register devm action to cancel poll work before poll_notifs is
+ * freed by devres. This ensures correct teardown ordering since
+ * devm_pse_poll_helper() is called after devm_pse_controller_register().
+ */
+ ret = devm_add_action_or_reset(dev, pse_poll_cancel, pcdev);
+ if (ret)
+ return ret;
+
+ queue_delayed_work(system_freezable_wq, &pcdev->poll_work,
+ msecs_to_jiffies(pcdev->poll_interval_ms));
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(devm_pse_poll_helper);
+
/* PSE control section */
static void __pse_control_release(struct kref *kref)
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index 4e5696cfade7..44d5d10e239d 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -292,6 +292,11 @@ struct pse_ntf {
* @pi: table of PSE PIs described in this controller device
* @no_of_pse_pi: flag set if the pse_pis devicetree node is not used
* @irq: PSE interrupt
+ * @polling: flag indicating poll-based event detection is active
+ * @poll_interval_ms: poll interval in milliseconds
+ * @poll_work: delayed work for poll-based event detection
+ * @poll_desc: copy of the driver's event descriptor for polling
+ * @poll_notifs: per-PI notification scratch space for poll worker
* @pis_prio_max: Maximum value allowed for the PSE PIs priority
* @supp_budget_eval_strategies: budget evaluation strategies supported
* by the PSE
@@ -312,6 +317,11 @@ struct pse_controller_dev {
struct pse_pi *pi;
bool no_of_pse_pi;
int irq;
+ bool polling;
+ unsigned int poll_interval_ms;
+ struct delayed_work poll_work;
+ struct pse_irq_desc poll_desc;
+ unsigned long *poll_notifs;
unsigned int pis_prio_max;
u32 supp_budget_eval_strategies;
struct work_struct ntf_work;
@@ -345,6 +355,8 @@ int devm_pse_controller_register(struct device *dev,
struct pse_controller_dev *pcdev);
int devm_pse_irq_helper(struct pse_controller_dev *pcdev, int irq,
int irq_flags, const struct pse_irq_desc *d);
+int devm_pse_poll_helper(struct pse_controller_dev *pcdev,
+ const struct pse_irq_desc *d);
struct pse_control *of_pse_control_get(struct device_node *node,
struct phy_device *phydev);
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v3 1/3] dt-bindings: net: pse-pd: add poll-interval-ms property
From: Carlo Szelinsky @ 2026-03-29 15:31 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-leds, Carlo Szelinsky
In-Reply-To: <20260329153124.2823980-1-github@szelinsky.de>
Add the optional poll-interval-ms property for PSE controllers that
use poll-based event detection instead of interrupts. Defaults to
500ms if not specified.
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
---
.../devicetree/bindings/net/pse-pd/pse-controller.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml b/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
index cd09560e0aea..329d020f054c 100644
--- a/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
+++ b/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
@@ -27,6 +27,14 @@ properties:
subnode. This property is deprecated, please use pse-pis instead.
enum: [0, 1]
+ poll-interval-ms:
+ description:
+ Polling interval in milliseconds for PSE controllers using
+ poll-based event detection instead of interrupts. Used when the
+ controller lacks IRQ support or the IRQ line is not wired.
+ default: 500
+ minimum: 50
+
pse-pis:
type: object
description:
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v3 0/3] net: pse-pd: add poll path and LED trigger support
From: Carlo Szelinsky @ 2026-03-29 15:31 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-leds, Carlo Szelinsky
Big thanks to Kory, Oleksij and Krzysztof for all the helpful feedback
on v2 — really appreciate the time you put into reviewing this.
I learned a lot!
This series adds poll-based event detection and LED trigger support
to the PSE core subsystem.
Patches 1-2 introduce the poll path independently of LED support,
so it can be tested in isolation on boards with and without IRQ
configured.
Patch 3 adds LED triggers that hook into the shared event handling
path introduced by patch 2.
Note: pse_handle_events() and the existing pse_isr() pass notifs_mask
as a single unsigned long, which limits the bitmask to BITS_PER_LONG
PI lines. This is a pre-existing constraint in the IRQ path and is
sufficient for all current PSE controllers (max 48 ports vs 64-bit
unsigned long), but may need to be converted to DECLARE_BITMAP() if
future hardware exceeds this limit.
Changes since v2:
- Based on net-next/main, added net-next subject prefix
- Added --base tree information
- Added CC for devicetree list and DT maintainers
- Collected Reviewed-by from Kory Maincent on patch 1/3
- Fixed build error when CONFIG_LEDS_TRIGGERS is disabled:
moved LED registration before list_add(), removing the
pcdev->pi_led_trigs = NULL assignment on conditionally
compiled struct member (reported by kernel test robot)
- Fixed use-after-free on device unbind: poll work is now
cancelled via devm_add_action_or_reset() to ensure correct
devres teardown ordering (poll_work cancelled before
poll_notifs is freed)
- Used system_freezable_wq for poll worker to prevent hardware
access during system suspend
- Added PoDL power status and admin state checks to LED triggers
so they work for both C33 and PoDL controller types
- Used dev_name(dev) for LED trigger names to ensure uniqueness
across multiple PSE controllers (of_node->name can be generic)
- Added initial LED state query at registration so already-active
ports are reflected immediately
- Added pse_led_update() calls in regulator enable/disable paths
so ethtool admin state changes are reflected in LEDs
- Moved LED trigger registration before list_add() to prevent
race where IRQ/poll could invoke pse_led_update() on partially
initialized triggers
Changes since v1:
- Split single patch into 3 separate patches
- Extracted pse_handle_events() and devm_pse_poll_helper() as a
standalone poll path (patches 1-2), testable without LED code
- Added DT binding for poll-interval-ms as a separate patch
- Renamed led-poll-interval-ms to poll-interval-ms for generic use
- Fire LED triggers from the notification path rather than a
separate poll loop
Tested on Realtek RTL9303 with HS104 PoE chip, poll path only
(without IRQ configured). Verified PD connect/disconnect notifications
and LED trigger state changes.
Link: https://lore.kernel.org/all/20260323201225.1836561-1-github@szelinsky.de/
Link: https://lore.kernel.org/all/20260314235916.2391678-1-github@szelinsky.de/
Carlo Szelinsky (3):
dt-bindings: net: pse-pd: add poll-interval-ms property
net: pse-pd: add devm_pse_poll_helper()
net: pse-pd: add LED trigger support via notification path
.../bindings/net/pse-pd/pse-controller.yaml | 8 +
drivers/net/pse-pd/pse_core.c | 298 ++++++++++++++++--
include/linux/pse-pd/pse.h | 34 ++
3 files changed, 309 insertions(+), 31 deletions(-)
base-commit: ced629dc8e5c51ff2b5d847adeeb1035cd655d58
--
2.43.0
^ permalink raw reply
* Re: [PATCH v8 5/6] hwmon: add NXP MC33978/MC34978 driver
From: Guenter Roeck @ 2026-03-29 15:31 UTC (permalink / raw)
To: Oleksij Rempel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Peter Rosin, Linus Walleij
Cc: kernel, linux-kernel, devicetree, linux-hwmon, linux-gpio,
David Jander
In-Reply-To: <20260329090601.532477-6-o.rempel@pengutronix.de>
On 3/29/26 02:06, Oleksij Rempel wrote:
> Add hardware monitoring support for the NXP MC33978/MC34978 Multiple
> Switch Detection Interface (MSDI).
>
> The hardware utilizes a clear-on-read FAULT register, but physical
> faults remain asserted as long as the underlying condition exists. This
> asserts a global FAULT_STAT bit on the SPI bus. To handle this without
> trapping the CPU in an interrupt storm, this driver implements the
> following architecture:
> - Requests a rising-edge nested IRQ (IRQF_TRIGGER_RISING) from the MFD
> core to catch the initial 0 -> 1 transition of the global fault state.
> - Caches hwmon-specific alarm bits and calculates state edges (XOR) to
> isolate alarm transitions from system integrity faults.
> - Implements a 1Hz delayed workqueue that polls the hardware as long as
> any alarm is active. This compensates for the edge-triggered IRQ by
> discovering secondary faults that occur without a rising edge, and
> detecting when the hardware clears.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Acked-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* Re: [PATCH v4 3/6] arm64: dts: qcom: msm8953-flipkart-rimob: Enable display and GPU
From: cristian_ci @ 2026-03-29 15:26 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
dri-devel, devicetree, linux-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <o2sbqzcix74u46g74sil2c3b6mgd6zsrmafesoqltfbbrzqhjh@uochk3so46yx>
On Sunday, March 29th, 2026 at 12:12, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> On Sat, Mar 28, 2026 at 05:30:53PM +0000, cristian_ci wrote:
> > On Friday, March 27th, 2026 at 23:57, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > > On Fri, Mar 27, 2026 at 03:30:49PM +0100, 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>
> > > > ---
> > > > .../arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts | 73 ++++++++++++++++++++++
> > > > 1 file changed, 73 insertions(+)
> > > >
> > >
> > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> >
> > I wonder if I should, instead, edit the compatible property by adding a
> > second string (for the fallback), like this:
> >
> > compatible = "flipkart,rimob-panel-nt35532-cs", "novatek,nt35532";
> >
> > and, therefore, add "novatek,nt35532" string also to (patch 1/6)'s
> > bindings example. Let me know what you think.
>
> What would it mean? I think we usually don't include the IC into the
> compat list for the panel, but feel free to prove me wrong.
I've noticed use of that in this [1] patch series but I don't know why IC
string is used there (in the example) if the specific panel string (the
first one) is already defined in the panel driver.
[1] https://lore.kernel.org/linux-arm-msm/20251001135914.13754-2-caojunjie650@gmail.com/
Best Regards,
Cristian.
> --
> With best wishes
> Dmitry
>
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: perf: marvell: Document CN20K DDR PMU
From: Geetha sowjanya @ 2026-03-29 15:24 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
In-Reply-To: <20260329152439.10573-1-gakula@marvell.com>
Add a devicetree binding for the Marvell CN20K DDR performance
monitor block, including the marvell,cn20k-ddr-pmu compatible
string and the required MMIO reg region.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
---
Changes in v1:
- Added a description field to the binding.
- Simplified the compatible property using 'const' instead of 'items/enum'.
- Updated the example node name to include a unit-address matching the reg base.
.../bindings/perf/marvell-cn20k-ddr.yaml | 39 +++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
diff --git a/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
new file mode 100644
index 000000000000..470eac0a53c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/marvell-cn20k-ddr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell CN20K DDR performance monitor
+
+description:
+ Performance Monitoring Unit (PMU) for the DDR controller
+ in Marvell CN20K SoCs.
+
+maintainers:
+ - Geetha sowjanya <gakula@marvell.com>
+
+properties:
+ compatible:
+ const: marvell,cn20k-ddr-pmu
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ddr-pmu@c200000000 {
+ compatible = "marvell,cn20k-ddr-pmu";
+ reg = <0xc200 0x00000000 0x0 0x100000>;
+ };
+ };
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox