* Re: [PATCH v2 2/5] arm64: dts: imx91-11x11-evk: remove unused property clock-frequency from mdio node
From: Andrew Lunn @ 2026-03-26 15:07 UTC (permalink / raw)
To: Joy Zou
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ye Li, Jacky Bai, Peng Fan, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260326-b4-imx91-qsb-dts-v2-2-b991b81639e6@nxp.com>
On Thu, Mar 26, 2026 at 03:51:38PM +0800, Joy Zou wrote:
> The clock-frequency property is not implemented. Remove it to clean up the
> device tree.
>
> Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Rob Herring @ 2026-03-26 15:05 UTC (permalink / raw)
To: Conor Dooley
Cc: Akhil R, Alexandre Belloni, Frank Li, Krzysztof Kozlowski,
Conor Dooley, Rafael J . Wysocki, Robert Moore, Len Brown,
Guenter Roeck, Philipp Zabel, Eric Biggers, Fredrik Markstrom,
Miquel Raynal, Thierry Reding, Jon Hunter, Suresh Mangipudi,
linux-tegra, linux-i3c, devicetree, linux-kernel, linux-acpi,
acpica-devel, linux-hwmon
In-Reply-To: <20260318-tweed-herbicide-eb924ef056b8@spud>
On Wed, Mar 18, 2026 at 05:31:50PM +0000, Conor Dooley wrote:
> On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
> > Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
> > Discovery and Configuration Specification [1] to specify which discovery
> > method an I3C device supports during bus initialization. The property is
> > a bitmap, where a bit value of 1 indicates support for that method, and 0
> > indicates lack of support.
> > Bit 0: SETDASA CCC (Direct)
> > Bit 1: SETAASA CCC (Broadcast)
> > Bit 2: Other CCC (vendor / standards extension)
> > All other bits are reserved.
> >
> > It is specifically needed when an I3C device requires SETAASA for the
> > address assignment. SETDASA will be supported by default if this property
> > is absent - which means for now the property just serves as a flag to
> > enable SETAASA, but keep the property as a bitmap to align with the
> > specifications.
> >
> > [1] https://www.mipi.org/specifications/disco
> >
> > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> > ---
> > .../devicetree/bindings/i3c/i3c.yaml | 30 ++++++++++++++++---
> > 1 file changed, 26 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> > index e25fa72fd785..1705d90d4d79 100644
> > --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
> > +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
> > @@ -31,10 +31,12 @@ properties:
> > described in the device tree, which in turn means we have to describe
> > I3C devices.
> >
> > - Another use case for describing an I3C device in the device tree is when
> > - this I3C device has a static I2C address and we want to assign it a
> > - specific I3C dynamic address before the DAA takes place (so that other
> > - devices on the bus can't take this dynamic address).
> > + Other use-cases for describing an I3C device in the device tree are:
> > + - When the I3C device has a static I2C address and we want to assign
> > + it a specific I3C dynamic address before the DAA takes place (so
> > + that other devices on the bus can't take this dynamic address).
> > + - When the I3C device requires SETAASA for its discovery and uses a
> > + pre-defined static address.
> >
> > "#size-cells":
> > const: 0
> > @@ -147,6 +149,26 @@ patternProperties:
> > through SETDASA. If static address is not present, this address is assigned
> > through SETNEWDA after assigning a temporary address via ENTDAA.
> >
> > + mipi-i3c-static-method:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + minimum: 0x1
> > + maximum: 0xff
> > + default: 1
> > + description: |
> > + Bitmap describing which methods of Dynamic Address Assignment from a
> > + static address are supported by this I3C Target. A bit value of 1
> > + indicates support for that method, and 0 indicates lack of support.
>
> I really am not keen on properties that are bitmaps, why can't we just
> use the strings "setdasa", "setaasa" etc?
If this comes from a specification, then I'd tend to just copy it rather
than invent our own thing. Obviously if is something structured
fundamentally different from how DT is designed, then we wouldn't. But
this is just a simple property.
Rob
^ permalink raw reply
* Re: [PATCH v4 5/8] dt-bindings: i2c: realtek,rtl9301-i2c: extend for clocks and RTL9607C support
From: Rustam Adilov @ 2026-03-26 14:59 UTC (permalink / raw)
To: Conor Dooley
Cc: Chris Packham, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, linux-kernel
In-Reply-To: <20260324-musty-tapering-f7700d6ed947@spud>
On 2026-03-24 17:48, Conor Dooley wrote:
> On Tue, Mar 24, 2026 at 03:30:34PM +0000, Rustam Adilov wrote:
>> Hello,
>> On 2026-03-23 19:41, Conor Dooley wrote:
>> > On Mon, Mar 23, 2026 at 12:13:34PM +0500, Rustam Adilov wrote:
>> >> Add the "realtek,rtl9607-i2c" compatible for i2c controller on the
>> >> RTL9607C SoC series.
>> >>
>> >> Add a clocks property to the properties to describe the i2c reference
>> >> clock and make it available for all the compatibles. This i2c reference
>> >
>> > Why? I can see that you're doing that, and it's good to know that that
>> > is intentional, but why is it being done? Need to explain that all of
>> > these devices actually do have this clock etc.
>>
>> As far as available information goes, there are some datasheets that
>> note
>> the existence of these clocks. For example, RTL9310 Developer Guide
>> 1.0 in [1]
>> mentions "I2C master support 12 peripherals with 2 clocks" at page 19.
>
>> I hope this explains the whole intention behind it. And if there is
>> better way to explain
>> this in the commit message, let me know.
>
> What you need to say in the commit message effectively boils down to
> "the existing devices have these clocks too".
Alrighty then, will update the commit message in the next patch series.
Thanks,
Rustam
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: remoteproc: k3-r5f: Add memory-region-names
From: Rob Herring (Arm) @ 2026-03-26 14:53 UTC (permalink / raw)
To: Markus Schneider-Pargmann (TI)
Cc: Vignesh Raghavendra, devicetree, linux-kernel, Kevin Hilman,
Akashdeep Kaur, linux-arm-kernel, Sebin Francis,
Krzysztof Kozlowski, Conor Dooley, Mathieu Poirier, Suman Anna,
Dhruva Gole, Vishal Mahaveer, Nishanth Menon, Kendall Willis,
Bjorn Andersson, Tero Kristo, linux-remoteproc
In-Reply-To: <20260318-topic-am62a-ioddr-dt-v6-19-v3-2-c41473cb23c3@baylibre.com>
On Wed, 18 Mar 2026 16:13:08 +0100, Markus Schneider-Pargmann (TI) wrote:
> Add names to the memory-region-names for easier identification of memory
> regions. As the meaning of the second memory region can be different
> also require the use of memory-region-names if memory-region is in use.
>
> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
> ---
> .../bindings/remoteproc/ti,k3-r5f-rproc.yaml | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: remoteproc: k3-r5f: Split up memory regions
From: Rob Herring (Arm) @ 2026-03-26 14:53 UTC (permalink / raw)
To: Markus Schneider-Pargmann (TI)
Cc: linux-remoteproc, Vignesh Raghavendra, Dhruva Gole,
Kendall Willis, linux-kernel, Conor Dooley, Tero Kristo,
Kevin Hilman, linux-arm-kernel, Mathieu Poirier,
Krzysztof Kozlowski, Akashdeep Kaur, Bjorn Andersson, Suman Anna,
Vishal Mahaveer, Nishanth Menon, Sebin Francis, devicetree
In-Reply-To: <20260318-topic-am62a-ioddr-dt-v6-19-v3-1-c41473cb23c3@baylibre.com>
On Wed, 18 Mar 2026 16:13:07 +0100, Markus Schneider-Pargmann (TI) wrote:
> Split up the region reserved for the firmware image in more specific
> sections to expose the full fixed layout. Especially the LPM metadata
> section is important for bootloaders as it contains information about
> how to exit IO+DDR. This is read by the bootloader but is written by the
> firmware.
>
> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
> ---
> .../bindings/remoteproc/ti,k3-r5f-rproc.yaml | 29 ++++++++++++++--------
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Vladimir Zapolskiy @ 2026-03-26 14:49 UTC (permalink / raw)
To: Bryan O'Donoghue, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <5d7d5bf8-4420-4d75-b928-820bb9233e52@kernel.org>
On 3/26/26 16:42, Bryan O'Donoghue wrote:
> On 26/03/2026 10:28, Vladimir Zapolskiy wrote:
>> On 3/26/26 04:03, Bryan O'Donoghue wrote:
>>> On 26/03/2026 01:46, Vladimir Zapolskiy wrote:
>>>> On 3/26/26 03:04, Bryan O'Donoghue wrote:
>>>>> Add a base schema initially compatible with x1e80100 to describe MIPI
>>>>> CSI2
>>>>> PHY devices.
>>>>>
>>>>> The hardware can support both CPHY, DPHY and a special split-mode
>>>>> DPHY. We
>>>>> capture those modes as:
>>>>>
>>>>> - PHY_QCOM_CSI2_MODE_DPHY
>>>>> - PHY_QCOM_CSI2_MODE_CPHY
>>>>> - PHY_QCOM_CSI2_MODE_SPLIT_DPHY
>>>>
>>>> Distinction between PHY_QCOM_CSI2_MODE_DPHY and
>>>> PHY_QCOM_CSI2_MODE_SPLIT_DPHY
>>>> is
>>>> 1) insufficient in just this simplistic form, because the assignment of
>>>> particular lanes is also needed,
>>>> 2) and under the assumption that the lane mapping is set somewhere else,
>>>> then
>>>> there should be no difference between PHY_QCOM_CSI2_MODE_{DPHY,SPLIT_DPHY},
>>>> it's just DPHY, and the subtype is deductible from data-lanes property on
>>>> the consumer side.
>>>>
>>>> So far the rationale is unclear, why anything above regular PHY_TYPE_DPHY
>>>> and PHY_TYPE_CPHY is needed here, those two are sufficient.
>>>
>>> Because knowing the split-mode exists and that you have asked about how
>>> such a thing would be supported, I thought about how to represent that
>>> mode right from the start, even if we don't support it.
>>
>> It is good to think about this hardware confguration in advance, however
>> the process of describing such hardware setup is incomplete.
>>
>>>
>>> To support split phy we will need to pass the parameter.
>>
>> What you call "split phy" is a DPHY, and "split phy" can not be supported
>> by adding this parameter, because it does not provide information about
>> lanes, and after removing this information it is just DPHY.
>
> That's just not true. If you read the camx source code you can see
> split/combo mode 2+1 1+1 data/clock mode requires special programming of
> the PHY to support.
Please do not reduce the upraised problem of proper hardware description
to some particular realisation in camx, this is irrelevant.
Here the description of hardware is done, and my point is that the new
PHY_QCOM_CSI2_MODE_SPLIT_DPHY phy type is simply not needed, since it's
possible to give a proper description of hardware without this invention.
> https://review.lineageos.org/c/LineageOS/android_kernel_motorola_sm6375/+/423960/1/drivers/cam_sensor_module/cam_csiphy/cam_csiphy_core.c#b285
>
> There is disjunction all over this file depending on the mode.
>
> https://review.lineageos.org/c/LineageOS/android_kernel_motorola_sm6375/+/423960/1/drivers/cam_sensor_module/cam_csiphy/cam_csiphy_core.c#b767
>
> And besides, think about it - you need different init sequences if one
> of the lanes is clock instead of data...
>
> If we use phy.h::PHY_TYPE_DPHY then that means to support split-mode in
> the future we need to get that mode represented in phy.h - but really
> this fixed split mode isn't a generic CSI2 PHY mode, its a Qualcommism.
>
> Nothing wrong with that - but then the mode should reflect the fact it
> is vendor specific and we absolutely 100% have to do different things in
> the PHY driver whether we are in regular DPHY mode or in split DPHY mode.
>
> If we use PHY_TYPE_DPHY as I did in the previous patch then we can't
> convert to a vendor type later on as its an ABI break.
>
> So we have both a sound technical reason hardware will require it to
> differentiate between DPHY and split-mode DPHY - and we also don't want
> to be bound to phy.h and then try to upstream a new DPHY_SPLIT_MODE here
> which a reviewer might reasonably say "why is this special mode from a
> specific vendor driving new defines in a shared file"
>
>>
>>> So we define those parameters upfront.
>>
>> This new header file has to be removed, it does not bring anything valuable.
>>
>>>>
>>>>>
>>>>> The CSIPHY devices have their own pinouts on the SoC as well as their own
>>>>> individual voltage rails.
>>>>>
>>>>> The need to model voltage rails on a per-PHY basis leads us to define
>>>>> CSIPHY devices as individual nodes.
>>>>>
>>>>> Two nice outcomes in terms of schema and DT arise from this change.
>>>>>
>>>>> 1. The ability to define on a per-PHY basis voltage rails.
>>>>> 2. The ability to require those voltage.
>>>>>
>>>>> We have had a complete bodge upstream for this where a single set of
>>>>> voltage rail for all CSIPHYs has been buried inside of CAMSS.
>>>>>
>>>>> Much like the I2C bus which is dedicated to Camera sensors - the CCI
>>>>> bus in
>>>>> CAMSS parlance, the CSIPHY devices should be individually modelled.
>>>>>
>>>>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>>>> ---
>>>>> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 130 +++++++++++
>>>>> ++++++++++
>>>>> include/dt-bindings/phy/phy-qcom-mipi-csi2.h | 15 +++
>>>>> 2 files changed, 145 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-
>>>>> phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-
>>>>> phy.yaml
>>>>> new file mode 100644
>>>>> index 0000000000000..63114151104b4
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>>>>> @@ -0,0 +1,130 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/phy/qcom,x1e80100-csi2-phy.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: Qualcomm CSI2 PHY
>>>>> +
>>>>> +maintainers:
>>>>> + - Bryan O'Donoghue <bod@kernel.org>
>>>>> +
>>>>> +description:
>>>>> + Qualcomm MIPI CSI2 C-PHY/D-PHY combination PHY. Connects MIPI CSI2
>>>>> sensors
>>>>> + to Qualcomm's Camera CSI Decoder. The PHY supports both C-PHY and
>>>>> D-PHY
>>>>> + modes.
>>>>> +
>>>>> +properties:
>>>>> + compatible:
>>>>> + const: qcom,x1e80100-csi2-phy
>>>>> +
>>>>> + reg:
>>>>> + maxItems: 1
>>>>> +
>>>>> + "#phy-cells":
>>>>> + const: 1
>>>>> + description:
>>>>> + The single cell specifies the PHY operating mode.
>>>>> + See include/dt-bindings/phy/phy-qcom-mipi-csi2.h for valid values.
>>>>
>>>> include/dt-bindings/phy/phy.h should be good enough as it's stated above.
>>>
>>> While include/dt-bindings/phy/phy.h provides generic definitions for
>>> D-PHY and C-PHY, it does not contain a definition for Qualcomm's
>>> proprietary Split D-PHY mode. Because this hardware supports a
>>
>> What Qualcomm's proprietary Split D-PHY mode is manifested by lane mapping,
>> there is no need to introduce another PHY mode, it is DPHY.
>>
>>> vendor-specific operating mode, introducing a vendor-specific header to
>>> define that state is necessary.
>>>
>>> This is exactly what we do with the QMP to support a similar use-case -
>>> the PHYs do vendor specific things, so we use vendor specific defines.
>>>
>>> If we lock to phy.h CPHY/DPHY only then we exclude the possibility of
>>> say adding split-mode to an upstream SoC as the DT ABI will not then
>>> facilitate the mode.
>>>
>>>>
>>>>> +
>>>>> + clocks:
>>>>> + maxItems: 2
>>>>> +
>>>>> + clock-names:
>>>>> + items:
>>>>> + - const: core
>>>>> + - const: timer
>>>>> +
>>>>> + interrupts:
>>>>> + maxItems: 1
>>>>> +
>>>>> + operating-points-v2:
>>>>> + maxItems: 1
>>>>> +
>>>>> + power-domains:
>>>>> + items:
>>>>> + - description: MXC or MXA voltage rail
>>>>> + - description: MMCX voltage rail
>>>>> +
>>>>> + power-domain-names:
>>>>> + items:
>>>>> + - const: mx
>>>>> + - const: mmcx
>>>>> +
>>>>> + vdda-0p9-supply:
>>>>> + description: Phandle to a 0.9V regulator supply to a PHY.
>>>>> +
>>>>> + vdda-1p2-supply:
>>>>> + description: Phandle to 1.2V regulator supply to a PHY.
>>>>> +
>>>>> +required:
>>>>> + - compatible
>>>>> + - reg
>>>>> + - "#phy-cells"
>>>>> + - clocks
>>>>> + - clock-names
>>>>> + - interrupts
>>>>> + - operating-points-v2
>>>>> + - power-domains
>>>>> + - power-domain-names
>>>>> + - vdda-0p9-supply
>>>>> + - vdda-1p2-supply
>>>>> +
>>>>> +additionalProperties: false
>>>>> +
>>>>> +examples:
>>>>> + - |
>>>>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
>>>>> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
>>>>> + #include <dt-bindings/phy/phy-qcom-mipi-csi2.h>
>>>>> + #include <dt-bindings/power/qcom,rpmhpd.h>
>>>>> +
>>>>> + csiphy4: csiphy@ace4000 {
>>>>> + compatible = "qcom,x1e80100-csi2-phy";
>>>>> + reg = <0x0ace4000 0x2000>;
>>>>> + #phy-cells = <1>;
>>>>> +
>>>>> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
>>>>> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>;
>>>>> + clock-names = "core",
>>>>> + "timer";
>>>>> +
>>>>> + operating-points-v2 = <&csiphy_opp_table>;
>>>>> +
>>>>> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
>>>>> +
>>>>> + power-domains = <&rpmhpd RPMHPD_MX>,
>>>>> + <&rpmhpd RPMHPD_MMCX>;
>>>>> + power-domain-names = "mx",
>>>>> + "mmcx";
>>>>> +
>>>>> + vdda-0p9-supply = <&vreg_l2c_0p8>;
>>>>> + vdda-1p2-supply = <&vreg_l1c_1p2>;
>>>>> + };
>>>>> +
>>>>> + csiphy_opp_table: opp-table {
>>>>> + compatible = "operating-points-v2";
>>>>> +
>>>>> + opp-300000000 {
>>>>> + opp-hz = /bits/ 64 <300000000>;
>>>>> + required-opps = <&rpmhpd_opp_low_svs_d1>,
>>>>> + <&rpmhpd_opp_low_svs_d1>;
>>>>> + };
>>>>> +
>>>>> + opp-400000000 {
>>>>> + opp-hz = /bits/ 64 <400000000>;
>>>>> + required-opps = <&rpmhpd_opp_low_svs>,
>>>>> + <&rpmhpd_opp_low_svs>;
>>>>> + };
>>>>> +
>>>>> + opp-480000000 {
>>>>> + opp-hz = /bits/ 64 <480000000>;
>>>>> + required-opps = <&rpmhpd_opp_low_svs>,
>>>>> + <&rpmhpd_opp_low_svs>;
>>>>> + };
>>>>> + };
>>>>> +
>>>>> + isp@acb7000 {
>>>>> + phys = <&csiphy4 PHY_QCOM_CSI2_MODE_DPHY>;
>>>>> + };
>>>>
>>>> This example is incomplete in sense that it does not include CAMSS
>>>> CSIPHY IP hardware configuration in whole.
>>>
>>>
>>> No that's not the way examples work. You don't replicate entire nodes
>>> from other schemas you just give a terse reference.
>>>
>>
>> If so, then this example makes no sense and it'd be better to remove it.
> You know you're right its not strictly necessary - its just there to be
> helpful.
>
> "Be less helpful" is not usually review feedback I give or take but,
> I'll drop this anyway.
>
Thank you.
--
Best wishes,
Vladimir
^ permalink raw reply
* [PATCH net-next] dt-bindings: net: wireless: brcm: Add compatible for bcm43752
From: Ronald Claveau @ 2026-03-26 14:47 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
van Spriel
Cc: linux-wireless, devicetree, linux-kernel, Conor Dooley,
Ronald Claveau
Add bcm43752 compatible with its bcm4329 compatible fallback.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
The Khadas VIM4 board based on Amlogic A311D2 aka T7 features an AP6275s Wi-Fi/Bluetooth module with a BCM43752 chipset.
This patch aims to add this chipset with its fallback to bcm4329 compatible.
The original patch series is here:
https://lore.kernel.org/r/20260326-add-emmc-t7-vim4-v5-0-d3f182b48e9d@aliel.fr
---
Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
index 3be7576787644..81fd3e37452a6 100644
--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
@@ -42,6 +42,7 @@ properties:
- brcm,bcm4356-fmac
- brcm,bcm4359-fmac
- brcm,bcm4366-fmac
+ - brcm,bcm43752-fmac
- cypress,cyw4373-fmac
- cypress,cyw43012-fmac
- infineon,cyw43439-fmac
---
base-commit: 45b2b84ac6fde39c427018d6cdf7d44258938faa
change-id: 20260326-add-bcm43752-compatible-e264a4f7973a
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: serial: renesas,rsci: Document RZ/G3L SoC
From: Geert Uytterhoeven @ 2026-03-26 14:47 UTC (permalink / raw)
To: Biju
Cc: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Biju Das, Lad Prabhakar, linux-kernel,
linux-serial, devicetree, linux-renesas-soc
In-Reply-To: <20260312082708.98835-2-biju.das.jz@bp.renesas.com>
On Thu, 12 Mar 2026 at 09:27, Biju <biju.das.au@gmail.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document the serial communication interface (RSCI) used on the Renesas
> RZ/G3L (R9A08G046) SoC. This SoC integrates the same RSCI IP block as
> the RZ/G3E (R9A09G047), but it has 3 clocks compared to 6 clocks on
> the RZ/G3E SoC. The RZ/G3L has a single TCLK with internal dividers,
> whereas the RZ/G3E has explicit clocks for TCLK and its dividers.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-03-26 14:42 UTC (permalink / raw)
To: Vladimir Zapolskiy, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <8ac55e5f-72ed-4331-bf42-92ccf97507dd@linaro.org>
On 26/03/2026 10:28, Vladimir Zapolskiy wrote:
> On 3/26/26 04:03, Bryan O'Donoghue wrote:
>> On 26/03/2026 01:46, Vladimir Zapolskiy wrote:
>>> On 3/26/26 03:04, Bryan O'Donoghue wrote:
>>>> Add a base schema initially compatible with x1e80100 to describe MIPI
>>>> CSI2
>>>> PHY devices.
>>>>
>>>> The hardware can support both CPHY, DPHY and a special split-mode
>>>> DPHY. We
>>>> capture those modes as:
>>>>
>>>> - PHY_QCOM_CSI2_MODE_DPHY
>>>> - PHY_QCOM_CSI2_MODE_CPHY
>>>> - PHY_QCOM_CSI2_MODE_SPLIT_DPHY
>>>
>>> Distinction between PHY_QCOM_CSI2_MODE_DPHY and
>>> PHY_QCOM_CSI2_MODE_SPLIT_DPHY
>>> is
>>> 1) insufficient in just this simplistic form, because the assignment of
>>> particular lanes is also needed,
>>> 2) and under the assumption that the lane mapping is set somewhere else,
>>> then
>>> there should be no difference between PHY_QCOM_CSI2_MODE_{DPHY,SPLIT_DPHY},
>>> it's just DPHY, and the subtype is deductible from data-lanes property on
>>> the consumer side.
>>>
>>> So far the rationale is unclear, why anything above regular PHY_TYPE_DPHY
>>> and PHY_TYPE_CPHY is needed here, those two are sufficient.
>>
>> Because knowing the split-mode exists and that you have asked about how
>> such a thing would be supported, I thought about how to represent that
>> mode right from the start, even if we don't support it.
>
> It is good to think about this hardware confguration in advance, however
> the process of describing such hardware setup is incomplete.
>
>>
>> To support split phy we will need to pass the parameter.
>
> What you call "split phy" is a DPHY, and "split phy" can not be supported
> by adding this parameter, because it does not provide information about
> lanes, and after removing this information it is just DPHY.
That's just not true. If you read the camx source code you can see
split/combo mode 2+1 1+1 data/clock mode requires special programming of
the PHY to support.
https://review.lineageos.org/c/LineageOS/android_kernel_motorola_sm6375/+/423960/1/drivers/cam_sensor_module/cam_csiphy/cam_csiphy_core.c#b285
There is disjunction all over this file depending on the mode.
https://review.lineageos.org/c/LineageOS/android_kernel_motorola_sm6375/+/423960/1/drivers/cam_sensor_module/cam_csiphy/cam_csiphy_core.c#b767
And besides, think about it - you need different init sequences if one
of the lanes is clock instead of data...
If we use phy.h::PHY_TYPE_DPHY then that means to support split-mode in
the future we need to get that mode represented in phy.h - but really
this fixed split mode isn't a generic CSI2 PHY mode, its a Qualcommism.
Nothing wrong with that - but then the mode should reflect the fact it
is vendor specific and we absolutely 100% have to do different things in
the PHY driver whether we are in regular DPHY mode or in split DPHY mode.
If we use PHY_TYPE_DPHY as I did in the previous patch then we can't
convert to a vendor type later on as its an ABI break.
So we have both a sound technical reason hardware will require it to
differentiate between DPHY and split-mode DPHY - and we also don't want
to be bound to phy.h and then try to upstream a new DPHY_SPLIT_MODE here
which a reviewer might reasonably say "why is this special mode from a
specific vendor driving new defines in a shared file"
>
>> So we define those parameters upfront.
>
> This new header file has to be removed, it does not bring anything valuable.
>
>>>
>>>>
>>>> The CSIPHY devices have their own pinouts on the SoC as well as their own
>>>> individual voltage rails.
>>>>
>>>> The need to model voltage rails on a per-PHY basis leads us to define
>>>> CSIPHY devices as individual nodes.
>>>>
>>>> Two nice outcomes in terms of schema and DT arise from this change.
>>>>
>>>> 1. The ability to define on a per-PHY basis voltage rails.
>>>> 2. The ability to require those voltage.
>>>>
>>>> We have had a complete bodge upstream for this where a single set of
>>>> voltage rail for all CSIPHYs has been buried inside of CAMSS.
>>>>
>>>> Much like the I2C bus which is dedicated to Camera sensors - the CCI
>>>> bus in
>>>> CAMSS parlance, the CSIPHY devices should be individually modelled.
>>>>
>>>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>>> ---
>>>> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 130 +++++++++++
>>>> ++++++++++
>>>> include/dt-bindings/phy/phy-qcom-mipi-csi2.h | 15 +++
>>>> 2 files changed, 145 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-
>>>> phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-
>>>> phy.yaml
>>>> new file mode 100644
>>>> index 0000000000000..63114151104b4
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>>>> @@ -0,0 +1,130 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/phy/qcom,x1e80100-csi2-phy.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Qualcomm CSI2 PHY
>>>> +
>>>> +maintainers:
>>>> + - Bryan O'Donoghue <bod@kernel.org>
>>>> +
>>>> +description:
>>>> + Qualcomm MIPI CSI2 C-PHY/D-PHY combination PHY. Connects MIPI CSI2
>>>> sensors
>>>> + to Qualcomm's Camera CSI Decoder. The PHY supports both C-PHY and
>>>> D-PHY
>>>> + modes.
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + const: qcom,x1e80100-csi2-phy
>>>> +
>>>> + reg:
>>>> + maxItems: 1
>>>> +
>>>> + "#phy-cells":
>>>> + const: 1
>>>> + description:
>>>> + The single cell specifies the PHY operating mode.
>>>> + See include/dt-bindings/phy/phy-qcom-mipi-csi2.h for valid values.
>>>
>>> include/dt-bindings/phy/phy.h should be good enough as it's stated above.
>>
>> While include/dt-bindings/phy/phy.h provides generic definitions for
>> D-PHY and C-PHY, it does not contain a definition for Qualcomm's
>> proprietary Split D-PHY mode. Because this hardware supports a
>
> What Qualcomm's proprietary Split D-PHY mode is manifested by lane mapping,
> there is no need to introduce another PHY mode, it is DPHY.
>
>> vendor-specific operating mode, introducing a vendor-specific header to
>> define that state is necessary.
>>
>> This is exactly what we do with the QMP to support a similar use-case -
>> the PHYs do vendor specific things, so we use vendor specific defines.
>>
>> If we lock to phy.h CPHY/DPHY only then we exclude the possibility of
>> say adding split-mode to an upstream SoC as the DT ABI will not then
>> facilitate the mode.
>>
>>>
>>>> +
>>>> + clocks:
>>>> + maxItems: 2
>>>> +
>>>> + clock-names:
>>>> + items:
>>>> + - const: core
>>>> + - const: timer
>>>> +
>>>> + interrupts:
>>>> + maxItems: 1
>>>> +
>>>> + operating-points-v2:
>>>> + maxItems: 1
>>>> +
>>>> + power-domains:
>>>> + items:
>>>> + - description: MXC or MXA voltage rail
>>>> + - description: MMCX voltage rail
>>>> +
>>>> + power-domain-names:
>>>> + items:
>>>> + - const: mx
>>>> + - const: mmcx
>>>> +
>>>> + vdda-0p9-supply:
>>>> + description: Phandle to a 0.9V regulator supply to a PHY.
>>>> +
>>>> + vdda-1p2-supply:
>>>> + description: Phandle to 1.2V regulator supply to a PHY.
>>>> +
>>>> +required:
>>>> + - compatible
>>>> + - reg
>>>> + - "#phy-cells"
>>>> + - clocks
>>>> + - clock-names
>>>> + - interrupts
>>>> + - operating-points-v2
>>>> + - power-domains
>>>> + - power-domain-names
>>>> + - vdda-0p9-supply
>>>> + - vdda-1p2-supply
>>>> +
>>>> +additionalProperties: false
>>>> +
>>>> +examples:
>>>> + - |
>>>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
>>>> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
>>>> + #include <dt-bindings/phy/phy-qcom-mipi-csi2.h>
>>>> + #include <dt-bindings/power/qcom,rpmhpd.h>
>>>> +
>>>> + csiphy4: csiphy@ace4000 {
>>>> + compatible = "qcom,x1e80100-csi2-phy";
>>>> + reg = <0x0ace4000 0x2000>;
>>>> + #phy-cells = <1>;
>>>> +
>>>> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
>>>> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>;
>>>> + clock-names = "core",
>>>> + "timer";
>>>> +
>>>> + operating-points-v2 = <&csiphy_opp_table>;
>>>> +
>>>> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
>>>> +
>>>> + power-domains = <&rpmhpd RPMHPD_MX>,
>>>> + <&rpmhpd RPMHPD_MMCX>;
>>>> + power-domain-names = "mx",
>>>> + "mmcx";
>>>> +
>>>> + vdda-0p9-supply = <&vreg_l2c_0p8>;
>>>> + vdda-1p2-supply = <&vreg_l1c_1p2>;
>>>> + };
>>>> +
>>>> + csiphy_opp_table: opp-table {
>>>> + compatible = "operating-points-v2";
>>>> +
>>>> + opp-300000000 {
>>>> + opp-hz = /bits/ 64 <300000000>;
>>>> + required-opps = <&rpmhpd_opp_low_svs_d1>,
>>>> + <&rpmhpd_opp_low_svs_d1>;
>>>> + };
>>>> +
>>>> + opp-400000000 {
>>>> + opp-hz = /bits/ 64 <400000000>;
>>>> + required-opps = <&rpmhpd_opp_low_svs>,
>>>> + <&rpmhpd_opp_low_svs>;
>>>> + };
>>>> +
>>>> + opp-480000000 {
>>>> + opp-hz = /bits/ 64 <480000000>;
>>>> + required-opps = <&rpmhpd_opp_low_svs>,
>>>> + <&rpmhpd_opp_low_svs>;
>>>> + };
>>>> + };
>>>> +
>>>> + isp@acb7000 {
>>>> + phys = <&csiphy4 PHY_QCOM_CSI2_MODE_DPHY>;
>>>> + };
>>>
>>> This example is incomplete in sense that it does not include CAMSS
>>> CSIPHY IP hardware configuration in whole.
>>
>>
>> No that's not the way examples work. You don't replicate entire nodes
>> from other schemas you just give a terse reference.
>>
>
> If so, then this example makes no sense and it'd be better to remove it.
You know you're right its not strictly necessary - its just there to be
helpful.
"Be less helpful" is not usually review feedback I give or take but,
I'll drop this anyway.
---
bod
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: freescale: imx95-toradex-smarc: Use gpio-hog for WIFI_UART_EN
From: Franz Schnyder @ 2026-03-26 14:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Franz Schnyder, devicetree, imx, linux-arm-kernel, linux-kernel,
Francesco Dolcini
In-Reply-To: <20260326143711.143462-1-fra.schnyder@gmail.com>
From: Franz Schnyder <franz.schnyder@toradex.com>
On the Toradex SMARC iMX95, the WiFi UART signals are shared with the
JTAG. The WIFI_UART_EN signal is used to select between these
two functions. A GPIO hog is used to select the UART function by
default. This DT file is going to be used by both Linux and the boot
firmware, and the boot firmware will configure the GPIO hog way before
the Linux kernel is booted, therefore there is no actual race condition
between the Linux kernel BT UART driver and GPIO hog probe.
Configure WIFI_UART_EN as a gpio-hog driven high.
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v2: Remove unused label for wifi-uart-en-hog node
Add explanation to clarify the safe usage of the GPIO hog
---
arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
index a90edefc5197..8eef26eb0f87 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
@@ -451,6 +451,13 @@ som_gpio_expander_1: gpio@21 {
"",
"",
"SMARC_SDIO_WP";
+
+ wifi-uart-en-hog {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_HIGH>;
+ line-name = "WIFI_UART_EN";
+ output-high;
+ };
};
embedded-controller@28 {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: freescale: imx95-toradex-smarc: Enable bluetooth on lpuart5
From: Franz Schnyder @ 2026-03-26 14:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Franz Schnyder, devicetree, imx, linux-arm-kernel, linux-kernel,
Francesco Dolcini
In-Reply-To: <20260326143711.143462-1-fra.schnyder@gmail.com>
From: Franz Schnyder <franz.schnyder@toradex.com>
The Toradex SMARC iMX95 uses the MAYA-W260 WiFi/Bluetooth module, which
uses the UART interface for Bluetooth.
Add UART support to enable bluetooth functionality on the MAYA-W260.
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
Although Documentation/devicetree/bindings/dts-coding-style.rst
recommends an empty line between status and latest property, leave it
unchanged for consistency with the rest of the file.
v2: no changes
---
.../dts/freescale/imx95-toradex-smarc.dtsi | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
index 1d369983cf7d..a90edefc5197 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
@@ -616,6 +616,19 @@ &lpuart3 {
pinctrl-0 = <&pinctrl_uart3>;
};
+/* On-module Bluetooth */
+&lpuart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_bt_uart>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ fw-init-baudrate = <3000000>;
+ };
+};
+
/* SMARC SER2 */
&lpuart6 {
pinctrl-names = "default";
@@ -830,6 +843,14 @@ &wdog3 {
};
&scmi_iomuxc {
+ /* On-module Bluetooth, UART pins shared with JTAG */
+ pinctrl_bt_uart: btuartgrp {
+ fsl,pins = <IMX95_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e>, /* WiFI_UART_RXD */
+ <IMX95_PAD_DAP_TDI__LPUART5_RX 0x31e>, /* WiFI_UART_TXD */
+ <IMX95_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e>, /* WiFI_UART_RTS# */
+ <IMX95_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e>; /* WiFI_UART_CTS# */
+ };
+
/* SMARC CAM_MCK */
pinctrl_cam_mck: cammckgrp {
fsl,pins = <IMX95_PAD_CCM_CLKO1__CCMSRCGPCMIX_TOP_CLKO_1 0x51e>; /* SMARC S6 - CAM_MCK */
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/3] arm64: dts: freescale: imx95-toradex-smarc: Add SER2 interface
From: Franz Schnyder @ 2026-03-26 14:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Franz Schnyder, devicetree, imx, linux-arm-kernel, linux-kernel,
Francesco Dolcini
In-Reply-To: <20260326143711.143462-1-fra.schnyder@gmail.com>
From: Franz Schnyder <franz.schnyder@toradex.com>
The Toradex SMARC iMX95 has four exposed serial interfaces, one of these
is SER2, which supports RTS/CTS.
Add UART support for SMARC SER2.
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v2: no changes
---
.../dts/freescale/imx95-toradex-smarc-dev.dts | 5 +++++
.../boot/dts/freescale/imx95-toradex-smarc.dtsi | 16 ++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc-dev.dts b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc-dev.dts
index 5b05f256fd52..7437e523ff63 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc-dev.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc-dev.dts
@@ -210,6 +210,11 @@ &lpuart3 {
status = "okay";
};
+/* SMARC SER2 */
+&lpuart6 {
+ status = "okay";
+};
+
/* SMARC MDIO, shared between all ethernet ports */
&netc_emdio {
status = "okay";
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
index 7a73958f6eec..1d369983cf7d 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
@@ -22,6 +22,7 @@ aliases {
rtc1 = &scmi_bbm;
serial0 = &lpuart2;
serial1 = &lpuart1;
+ serial2 = &lpuart6;
serial3 = &lpuart3;
};
@@ -615,6 +616,13 @@ &lpuart3 {
pinctrl-0 = <&pinctrl_uart3>;
};
+/* SMARC SER2 */
+&lpuart6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart6>;
+ uart-has-rtscts;
+};
+
&mu7 {
status = "okay";
};
@@ -1105,6 +1113,14 @@ pinctrl_uart3: uart3grp {
<IMX95_PAD_GPIO_IO15__LPUART3_RX 0x31e>; /* SMARC P141 - SER3_RX */
};
+ /* SMARC SER2 */
+ pinctrl_uart6: uart6grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO34__LPUART6_CTS_B 0x31e>, /* SMARC P139 - SER2_CTS# */
+ <IMX95_PAD_GPIO_IO07__LPUART6_RTS_B 0x31e>, /* SMARC P138 - SER2_RTS# */
+ <IMX95_PAD_GPIO_IO05__LPUART6_RX 0x31e>, /* SMARC P137 - SER2_RX */
+ <IMX95_PAD_GPIO_IO04__LPUART6_TX 0x31e>; /* SMARC P136 - SER2_TX */
+ };
+
/* On-module eMMC */
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e>, /* SD1_CLK */
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/3] arm64: dts: freescale: imx95-toradex-smarc: Add Bluetooth and SER2
From: Franz Schnyder @ 2026-03-26 14:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Franz Schnyder, devicetree, imx, linux-arm-kernel, linux-kernel,
Francesco Dolcini
From: Franz Schnyder <franz.schnyder@toradex.com>
This patch series adds support for missing interfaces on the Toradex
SMARC i.MX95 SoM.
It adds:
- SER2 interface
- UART interface for Bluetooth
- WIFI_UART_EN as a gpio-hog to select the UART function by default,
as the MAYA-W260 UART signals are shared with the JTAG.
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v2: Remove unused label for wifi-uart-en-hog node
Add explanation to clarify the safe usage of the GPIO hog
---
Franz Schnyder (3):
arm64: dts: freescale: imx95-toradex-smarc: Add SER2 interface
arm64: dts: freescale: imx95-toradex-smarc: Enable bluetooth on
lpuart5
arm64: dts: freescale: imx95-toradex-smarc: Use gpio-hog for
WIFI_UART_EN
.../dts/freescale/imx95-toradex-smarc-dev.dts | 5 +++
.../dts/freescale/imx95-toradex-smarc.dtsi | 44 +++++++++++++++++++
2 files changed, 49 insertions(+)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: imx8qm-mek: switch Type-C connector power-role to dual
From: Frank Li @ 2026-03-26 14:28 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, Xu Yang
Cc: Frank Li, devicetree, imx, linux-arm-kernel, linux-kernel, jun.li
In-Reply-To: <20260324110459.2838767-1-xu.yang_2@nxp.com>
On Tue, 24 Mar 2026 19:04:58 +0800, Xu Yang wrote:
> When attach to PC Type-A port, the USB device controller does not function
> at all. Because it is configured as source-only and a Type-A port doesn't
> support PD capability, a data role swap is impossible.
>
> Actually, PTN5110THQ is configured for Source role only at POR, but after
> POR it can operate as a DRP (Dual-Role Power). By switching the power-role
> to dual, the port can operate as a sink and enter device mode when attach
> to Type-A port.
>
> [...]
Applied, thanks!
[1/2] arm64: dts: imx8qm-mek: switch Type-C connector power-role to dual
commit: 755d74cc06950d0f0449794dd23f42669811f6c4
[2/2] arm64: dts: imx8qxp-mek: switch Type-C connector power-role to dual
commit: 8c5dbb306887fc81737e0077b9d821909f64a5fb
Add fixes tags for both patches
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
From: Geert Uytterhoeven @ 2026-03-26 14:28 UTC (permalink / raw)
To: Biju
Cc: Fabrizio Castro, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Biju Das, linux-spi, linux-renesas-soc,
devicetree, linux-kernel, Prabhakar Mahadev Lad
In-Reply-To: <20260304074907.9697-2-biju.das.jz@bp.renesas.com>
On Wed, 4 Mar 2026 at 08:49, Biju <biju.das.au@gmail.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document RSPI IP found on the RZ/G3L SoC. The RSPI IP is compatible with
> the RZ/V2H RSPI IP, but has 2 clocks compared to 3 on RZ/V2H.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: Move board nodes to common DTSI
From: Krzysztof Kozlowski @ 2026-03-26 14:25 UTC (permalink / raw)
To: Gopikrishna Garmidi, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, sibi.sankar,
rajendra.nayak
In-Reply-To: <20260326-glymur-mahua-common-nodes-v1-1-12bb26920ea4@oss.qualcomm.com>
On 26/03/2026 15:21, Gopikrishna Garmidi wrote:
> The display, peripherals (touchpad/touchscreen/keypad), usb and their
> dependent device nodes are common to both Glymur and Mahua CRDs,
> so move them from glymur-crd.dts to glymur-crd.dtsi to enable code
> reuse.
>
Same questions as for earlier tries (why this has to be repeated?), e.g.
x1-crd: Please describe here what is the actual common hardware. In
terms of physical hardware, not what you want to share.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: qcom: Move board nodes to common DTSI
From: Gopikrishna Garmidi @ 2026-03-26 14:21 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, sibi.sankar,
rajendra.nayak, Gopikrishna Garmidi
The display, peripherals (touchpad/touchscreen/keypad), usb and their
dependent device nodes are common to both Glymur and Mahua CRDs,
so move them from glymur-crd.dts to glymur-crd.dtsi to enable code
reuse.
Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur-crd.dts | 403 -------------------------------
arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 401 ++++++++++++++++++++++++++++++
2 files changed, 401 insertions(+), 403 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dts b/arch/arm64/boot/dts/qcom/glymur-crd.dts
index 51ea23a49b9e..0efd9e27c82f 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dts
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dts
@@ -8,410 +8,7 @@
#include "glymur.dtsi"
#include "glymur-crd.dtsi"
-#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
-
/ {
model = "Qualcomm Technologies, Inc. Glymur CRD";
compatible = "qcom,glymur-crd", "qcom,glymur";
-
- pmic-glink {
- compatible = "qcom,glymur-pmic-glink",
- "qcom,pmic-glink";
- #address-cells = <1>;
- #size-cells = <0>;
-
- connector@0 {
- compatible = "usb-c-connector";
- reg = <0>;
- power-role = "dual";
- data-role = "dual";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- pmic_glink_hs_in: endpoint {
- remote-endpoint = <&usb_0_dwc3_hs>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- pmic_glink_ss_in: endpoint {
- remote-endpoint = <&usb_0_qmpphy_out>;
- };
- };
- };
- };
-
- connector@1 {
- compatible = "usb-c-connector";
- reg = <1>;
- power-role = "dual";
- data-role = "dual";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- pmic_glink_hs_in1: endpoint {
- remote-endpoint = <&usb_1_dwc3_hs>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- pmic_glink_ss_in1: endpoint {
- remote-endpoint = <&usb_1_qmpphy_out>;
- };
- };
- };
- };
- };
-
- vreg_edp_3p3: regulator-edp-3p3 {
- compatible = "regulator-fixed";
-
- regulator-name = "VREG_EDP_3P3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
-
- gpio = <&tlmm 70 GPIO_ACTIVE_HIGH>;
- enable-active-high;
-
- pinctrl-0 = <&edp_reg_en>;
- pinctrl-names = "default";
-
- regulator-boot-on;
- };
-
- vreg_misc_3p3: regulator-misc-3p3 {
- compatible = "regulator-fixed";
-
- regulator-name = "VREG_MISC_3P3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
-
- gpio = <&pmh0110_f_e0_gpios 6 GPIO_ACTIVE_HIGH>;
- enable-active-high;
-
- pinctrl-0 = <&misc_3p3_reg_en>;
- pinctrl-names = "default";
-
- regulator-boot-on;
- };
-};
-
-&i2c0 {
- clock-frequency = <400000>;
-
- status = "okay";
-
- touchpad@2c {
- compatible = "hid-over-i2c";
- reg = <0x2c>;
-
- hid-descr-addr = <0x20>;
- interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>;
-
- vdd-supply = <&vreg_misc_3p3>;
- vddl-supply = <&vreg_l15b_e0_1p8>;
-
- pinctrl-0 = <&tpad_default>;
- pinctrl-names = "default";
-
- wakeup-source;
- };
-
- keyboard@3a {
- compatible = "hid-over-i2c";
- reg = <0x3a>;
-
- hid-descr-addr = <0x1>;
- interrupts-extended = <&tlmm 67 IRQ_TYPE_LEVEL_LOW>;
-
- vdd-supply = <&vreg_misc_3p3>;
- vddl-supply = <&vreg_l15b_e0_1p8>;
-
- pinctrl-0 = <&kybd_default>;
- pinctrl-names = "default";
-
- wakeup-source;
- };
-};
-
-&i2c8 {
- clock-frequency = <400000>;
-
- status = "okay";
-
- touchscreen@38 {
- compatible = "hid-over-i2c";
- reg = <0x38>;
-
- hid-descr-addr = <0x1>;
- interrupts-extended = <&tlmm 51 IRQ_TYPE_LEVEL_LOW>;
-
- vdd-supply = <&vreg_misc_3p3>;
- vddl-supply = <&vreg_l15b_e0_1p8>;
-
- pinctrl-0 = <&ts0_default>;
- pinctrl-names = "default";
- };
-};
-
-&i2c5 {
- clock-frequency = <400000>;
-
- status = "okay";
-
- ptn3222_0: redriver@43 {
- compatible = "nxp,ptn3222";
- reg = <0x43>;
-
- reset-gpios = <&tlmm 8 GPIO_ACTIVE_LOW>;
-
- vdd3v3-supply = <&vreg_l8b_e0_1p50>;
- vdd1v8-supply = <&vreg_l15b_e0_1p8>;
-
- #phy-cells = <0>;
- };
-
- ptn3222_1: redriver@47 {
- compatible = "nxp,ptn3222";
- reg = <0x47>;
-
- reset-gpios = <&tlmm 9 GPIO_ACTIVE_LOW>;
-
- vdd3v3-supply = <&vreg_l8b_e0_1p50>;
- vdd1v8-supply = <&vreg_l15b_e0_1p8>;
-
- #phy-cells = <0>;
- };
-};
-
-&mdss {
- status = "okay";
-};
-
-&mdss_dp3 {
- /delete-property/ #sound-dai-cells;
-
- status = "okay";
-
- aux-bus {
- panel {
- compatible = "samsung,atna60cl08", "samsung,atna33xc20";
- enable-gpios = <&tlmm 18 GPIO_ACTIVE_HIGH>;
- power-supply = <&vreg_edp_3p3>;
-
- pinctrl-0 = <&edp_bl_en>;
- pinctrl-names = "default";
-
- port {
- edp_panel_in: endpoint {
- remote-endpoint = <&mdss_dp3_out>;
- };
- };
- };
- };
-};
-
-&mdss_dp3_out {
- data-lanes = <0 1 2 3>;
- link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
-
- remote-endpoint = <&edp_panel_in>;
-};
-
-&mdss_dp3_phy {
- vdda-phy-supply = <&vreg_l2f_e1_0p83>;
- vdda-pll-supply = <&vreg_l4f_e1_1p08>;
-
- status = "okay";
-};
-
-&pmh0110_f_e0_gpios {
- misc_3p3_reg_en: misc-3p3-reg-en-state {
- pins = "gpio6";
- function = "normal";
- bias-disable;
- input-disable;
- output-enable;
- drive-push-pull;
- power-source = <1>; /* 1.8 V */
- qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
- };
-};
-
-&smb2370_j_e2_eusb2_repeater {
- vdd18-supply = <&vreg_l15b_e0_1p8>;
- vdd3-supply = <&vreg_l7b_e0_2p79>;
-};
-
-&smb2370_k_e2_eusb2_repeater {
- vdd18-supply = <&vreg_l15b_e0_1p8>;
- vdd3-supply = <&vreg_l7b_e0_2p79>;
-};
-
-&tlmm {
- edp_bl_en: edp-bl-en-state {
- pins = "gpio18";
- function = "gpio";
- drive-strength = <16>;
- bias-disable;
- };
-
- edp_reg_en: edp-reg-en-state {
- pins = "gpio70";
- function = "gpio";
- drive-strength = <16>;
- bias-disable;
- };
-
- kybd_default: kybd-default-state {
- pins = "gpio67";
- function = "gpio";
- bias-disable;
- };
-
- tpad_default: tpad-default-state {
- pins = "gpio3";
- function = "gpio";
- bias-disable;
- };
-
- ts0_default: ts0-default-state {
- int-n-pins {
- pins = "gpio51";
- function = "gpio";
- bias-disable;
- };
-
- reset-n-pins {
- pins = "gpio48";
- function = "gpio";
- drive-strength = <16>;
- bias-disable;
- };
- };
-};
-
-&usb_0 {
- dr_mode = "host";
-
- status = "okay";
-};
-
-&usb_0_dwc3_hs {
- remote-endpoint = <&pmic_glink_hs_in>;
-};
-
-&usb_0_hsphy {
- vdd-supply = <&vreg_l3f_e0_0p72>;
- vdda12-supply = <&vreg_l4h_e0_1p2>;
-
- phys = <&smb2370_j_e2_eusb2_repeater>;
-
- status = "okay";
-};
-
-&usb_0_qmpphy {
- vdda-phy-supply = <&vreg_l4h_e0_1p2>;
- vdda-pll-supply = <&vreg_l3f_e0_0p72>;
- refgen-supply = <&vreg_l2f_e0_0p82>;
-
- status = "okay";
-};
-
-&usb_0_qmpphy_out {
- remote-endpoint = <&pmic_glink_ss_in>;
-};
-
-&usb_1 {
- dr_mode = "host";
-
- status = "okay";
-};
-
-&usb_1_dwc3_hs {
- remote-endpoint = <&pmic_glink_hs_in1>;
-};
-
-&usb_1_hsphy {
- vdd-supply = <&vreg_l3f_e0_0p72>;
- vdda12-supply = <&vreg_l4h_e0_1p2>;
-
- phys = <&smb2370_k_e2_eusb2_repeater>;
-
- status = "okay";
-};
-
-&usb_1_qmpphy {
- vdda-phy-supply = <&vreg_l4h_e0_1p2>;
- vdda-pll-supply = <&vreg_l1h_e0_0p89>;
- refgen-supply = <&vreg_l2f_e0_0p82>;
-
- status = "okay";
-};
-
-&usb_1_qmpphy_out {
- remote-endpoint = <&pmic_glink_ss_in1>;
-};
-
-&usb_hs {
- status = "okay";
-};
-
-&usb_hs_phy {
- vdd-supply = <&vreg_l2h_e0_0p72>;
- vdda12-supply = <&vreg_l4h_e0_1p2>;
-
- phys = <&ptn3222_1>;
-
- status = "okay";
-};
-
-&usb_mp {
- status = "okay";
-};
-
-&usb_mp_hsphy0 {
- vdd-supply = <&vreg_l2h_e0_0p72>;
- vdda12-supply = <&vreg_l4h_e0_1p2>;
-
- phys = <&ptn3222_0>;
-
- status = "okay";
-};
-
-&usb_mp_hsphy1 {
- vdd-supply = <&vreg_l2h_e0_0p72>;
- vdda12-supply = <&vreg_l4h_e0_1p2>;
-
- status = "okay";
-};
-
-&usb_mp_qmpphy0 {
- vdda-phy-supply = <&vreg_l4h_e0_1p2>;
- vdda-pll-supply = <&vreg_l2h_e0_0p72>;
- refgen-supply = <&vreg_l4f_e1_1p08>;
-
- status = "okay";
-};
-
-&usb_mp_qmpphy1 {
- vdda-phy-supply = <&vreg_l4h_e0_1p2>;
- vdda-pll-supply = <&vreg_l2h_e0_0p72>;
- refgen-supply = <&vreg_l4f_e1_1p08>;
-
- status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
index abc6cc8bb0a8..5ba9e586f3cf 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
@@ -10,6 +10,8 @@
#include "pmk8850.dtsi" /* SPMI0: SID-0 */
#include "smb2370.dtsi" /* SPMI2: SID-9/10/11 */
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+
/ {
model = "Qualcomm Technologies, Inc. Glymur CRD";
compatible = "qcom,glymur-crd", "qcom,glymur";
@@ -57,6 +59,101 @@ key-volume-up {
};
};
+ pmic-glink {
+ compatible = "qcom,glymur-pmic-glink",
+ "qcom,pmic-glink";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_hs_in: endpoint {
+ remote-endpoint = <&usb_0_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_ss_in: endpoint {
+ remote-endpoint = <&usb_0_qmpphy_out>;
+ };
+ };
+ };
+ };
+
+ connector@1 {
+ compatible = "usb-c-connector";
+ reg = <1>;
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_hs_in1: endpoint {
+ remote-endpoint = <&usb_1_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_ss_in1: endpoint {
+ remote-endpoint = <&usb_1_qmpphy_out>;
+ };
+ };
+ };
+ };
+ };
+
+ vreg_edp_3p3: regulator-edp-3p3 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_EDP_3P3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 70 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&edp_reg_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ };
+
+ vreg_misc_3p3: regulator-misc-3p3 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_MISC_3P3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&pmh0110_f_e0_gpios 6 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&misc_3p3_reg_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ };
+
vreg_nvme: regulator-nvme {
compatible = "regulator-fixed";
@@ -364,6 +461,135 @@ vreg_l4h_e0_1p2: ldo4 {
};
};
+&i2c0 {
+ clock-frequency = <400000>;
+
+ status = "okay";
+
+ touchpad@2c {
+ compatible = "hid-over-i2c";
+ reg = <0x2c>;
+
+ hid-descr-addr = <0x20>;
+ interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>;
+
+ vdd-supply = <&vreg_misc_3p3>;
+ vddl-supply = <&vreg_l15b_e0_1p8>;
+
+ pinctrl-0 = <&tpad_default>;
+ pinctrl-names = "default";
+
+ wakeup-source;
+ };
+
+ keyboard@3a {
+ compatible = "hid-over-i2c";
+ reg = <0x3a>;
+
+ hid-descr-addr = <0x1>;
+ interrupts-extended = <&tlmm 67 IRQ_TYPE_LEVEL_LOW>;
+
+ vdd-supply = <&vreg_misc_3p3>;
+ vddl-supply = <&vreg_l15b_e0_1p8>;
+
+ pinctrl-0 = <&kybd_default>;
+ pinctrl-names = "default";
+
+ wakeup-source;
+ };
+};
+
+&i2c5 {
+ clock-frequency = <400000>;
+
+ status = "okay";
+
+ ptn3222_0: redriver@43 {
+ compatible = "nxp,ptn3222";
+ reg = <0x43>;
+
+ reset-gpios = <&tlmm 8 GPIO_ACTIVE_LOW>;
+
+ vdd3v3-supply = <&vreg_l8b_e0_1p50>;
+ vdd1v8-supply = <&vreg_l15b_e0_1p8>;
+
+ #phy-cells = <0>;
+ };
+
+ ptn3222_1: redriver@47 {
+ compatible = "nxp,ptn3222";
+ reg = <0x47>;
+
+ reset-gpios = <&tlmm 9 GPIO_ACTIVE_LOW>;
+
+ vdd3v3-supply = <&vreg_l8b_e0_1p50>;
+ vdd1v8-supply = <&vreg_l15b_e0_1p8>;
+
+ #phy-cells = <0>;
+ };
+};
+
+&i2c8 {
+ clock-frequency = <400000>;
+
+ status = "okay";
+
+ touchscreen@38 {
+ compatible = "hid-over-i2c";
+ reg = <0x38>;
+
+ hid-descr-addr = <0x1>;
+ interrupts-extended = <&tlmm 51 IRQ_TYPE_LEVEL_LOW>;
+
+ vdd-supply = <&vreg_misc_3p3>;
+ vddl-supply = <&vreg_l15b_e0_1p8>;
+
+ pinctrl-0 = <&ts0_default>;
+ pinctrl-names = "default";
+ };
+};
+
+&mdss {
+ status = "okay";
+};
+
+&mdss_dp3 {
+ /delete-property/ #sound-dai-cells;
+
+ status = "okay";
+
+ aux-bus {
+ panel {
+ compatible = "samsung,atna60cl08", "samsung,atna33xc20";
+ enable-gpios = <&tlmm 18 GPIO_ACTIVE_HIGH>;
+ power-supply = <&vreg_edp_3p3>;
+
+ pinctrl-0 = <&edp_bl_en>;
+ pinctrl-names = "default";
+
+ port {
+ edp_panel_in: endpoint {
+ remote-endpoint = <&mdss_dp3_out>;
+ };
+ };
+ };
+ };
+};
+
+&mdss_dp3_out {
+ data-lanes = <0 1 2 3>;
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+
+ remote-endpoint = <&edp_panel_in>;
+};
+
+&mdss_dp3_phy {
+ vdda-phy-supply = <&vreg_l2f_e1_0p83>;
+ vdda-pll-supply = <&vreg_l4f_e1_1p08>;
+
+ status = "okay";
+};
+
&pcie3b {
vddpe-3v3-supply = <&vreg_nvmesec>;
@@ -469,6 +695,19 @@ key_vol_up_default: key-vol-up-default-state {
};
};
+&pmh0110_f_e0_gpios {
+ misc_3p3_reg_en: misc-3p3-reg-en-state {
+ pins = "gpio6";
+ function = "normal";
+ bias-disable;
+ input-disable;
+ output-enable;
+ drive-push-pull;
+ power-source = <1>; /* 1.8 V */
+ qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
+ };
+};
+
&pmk8850_rtc {
qcom,no-alarm;
};
@@ -478,11 +717,41 @@ &pon_resin {
status = "okay";
};
+&smb2370_j_e2_eusb2_repeater {
+ vdd18-supply = <&vreg_l15b_e0_1p8>;
+ vdd3-supply = <&vreg_l7b_e0_2p79>;
+};
+
+&smb2370_k_e2_eusb2_repeater {
+ vdd18-supply = <&vreg_l15b_e0_1p8>;
+ vdd3-supply = <&vreg_l7b_e0_2p79>;
+};
+
&tlmm {
gpio-reserved-ranges = <4 4>, /* EC TZ Secure I3C */
<10 2>, /* OOB UART */
<44 4>; /* Security SPI (TPM) */
+ edp_bl_en: edp-bl-en-state {
+ pins = "gpio18";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ edp_reg_en: edp-reg-en-state {
+ pins = "gpio70";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ kybd_default: kybd-default-state {
+ pins = "gpio67";
+ function = "gpio";
+ bias-disable;
+ };
+
pcie4_default: pcie4-default-state {
clkreq-n-pins {
pins = "gpio147";
@@ -575,6 +844,27 @@ wake-n-pins {
};
};
+ tpad_default: tpad-default-state {
+ pins = "gpio3";
+ function = "gpio";
+ bias-disable;
+ };
+
+ ts0_default: ts0-default-state {
+ int-n-pins {
+ pins = "gpio51";
+ function = "gpio";
+ bias-disable;
+ };
+
+ reset-n-pins {
+ pins = "gpio48";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+ };
+
wlan_reg_en: wlan-reg-en-state {
pins = "gpio94";
function = "gpio";
@@ -589,3 +879,114 @@ wwan_reg_en: wwan-reg-en-state {
bias-disable;
};
};
+
+&usb_0 {
+ dr_mode = "host";
+
+ status = "okay";
+};
+
+&usb_0_dwc3_hs {
+ remote-endpoint = <&pmic_glink_hs_in>;
+};
+
+&usb_0_hsphy {
+ vdd-supply = <&vreg_l3f_e0_0p72>;
+ vdda12-supply = <&vreg_l4h_e0_1p2>;
+
+ phys = <&smb2370_j_e2_eusb2_repeater>;
+
+ status = "okay";
+};
+
+&usb_0_qmpphy {
+ vdda-phy-supply = <&vreg_l4h_e0_1p2>;
+ vdda-pll-supply = <&vreg_l3f_e0_0p72>;
+ refgen-supply = <&vreg_l2f_e0_0p82>;
+
+ status = "okay";
+};
+
+&usb_0_qmpphy_out {
+ remote-endpoint = <&pmic_glink_ss_in>;
+};
+
+&usb_1 {
+ dr_mode = "host";
+
+ status = "okay";
+};
+
+&usb_1_dwc3_hs {
+ remote-endpoint = <&pmic_glink_hs_in1>;
+};
+
+&usb_1_hsphy {
+ vdd-supply = <&vreg_l3f_e0_0p72>;
+ vdda12-supply = <&vreg_l4h_e0_1p2>;
+
+ phys = <&smb2370_k_e2_eusb2_repeater>;
+
+ status = "okay";
+};
+
+&usb_1_qmpphy {
+ vdda-phy-supply = <&vreg_l4h_e0_1p2>;
+ vdda-pll-supply = <&vreg_l1h_e0_0p89>;
+ refgen-supply = <&vreg_l2f_e0_0p82>;
+
+ status = "okay";
+};
+
+&usb_1_qmpphy_out {
+ remote-endpoint = <&pmic_glink_ss_in1>;
+};
+
+&usb_hs {
+ status = "okay";
+};
+
+&usb_hs_phy {
+ vdd-supply = <&vreg_l2h_e0_0p72>;
+ vdda12-supply = <&vreg_l4h_e0_1p2>;
+
+ phys = <&ptn3222_1>;
+
+ status = "okay";
+};
+
+&usb_mp {
+ status = "okay";
+};
+
+&usb_mp_hsphy0 {
+ vdd-supply = <&vreg_l2h_e0_0p72>;
+ vdda12-supply = <&vreg_l4h_e0_1p2>;
+
+ phys = <&ptn3222_0>;
+
+ status = "okay";
+};
+
+&usb_mp_hsphy1 {
+ vdd-supply = <&vreg_l2h_e0_0p72>;
+ vdda12-supply = <&vreg_l4h_e0_1p2>;
+
+ status = "okay";
+};
+
+&usb_mp_qmpphy0 {
+ vdda-phy-supply = <&vreg_l4h_e0_1p2>;
+ vdda-pll-supply = <&vreg_l2h_e0_0p72>;
+ refgen-supply = <&vreg_l4f_e1_1p08>;
+
+ status = "okay";
+};
+
+&usb_mp_qmpphy1 {
+ vdda-phy-supply = <&vreg_l4h_e0_1p2>;
+ vdda-pll-supply = <&vreg_l2h_e0_0p72>;
+ refgen-supply = <&vreg_l4f_e1_1p08>;
+
+ status = "okay";
+};
---
base-commit: 66ba480978ce390e631e870b740a3406e3eb6b01
change-id: 20260326-glymur-mahua-common-nodes-893fd80808cb
Best regards,
--
Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v6 00/10] arm64: dts: lx2160a: fix pinmux issues, update SolidRun boards
From: Frank Li @ 2026-03-26 14:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Carlos Song, Josua Mayer
Cc: Frank Li, Mikhail Anikin, Yazan Shhady, Rabeeh Khoury, Frank Li,
linux-arm-kernel, devicetree, linux-kernel, stable
In-Reply-To: <20260324-lx2160-sd-cd-v6-0-8bf207711848@solid-run.com>
On Tue, 24 Mar 2026 13:40:54 +0100, Josua Mayer wrote:
> Fix a bug with microsd card-detect & gpios pinmux on SolidRun
> LX2160A Clearfog-CX & Honeycomb, and LX2162A Clearfog.
>
> Then make small additions to SolidRun board descriptions.
>
>
Applied, thanks!
[01/10] arm64: dts: lx2160a-cex7/lx2162a-sr-som: fix usd-cd & gpio pinmux
commit: 6bdd023311d9cc754126418875b5265dc5705230
[02/10] arm64: dts: lx2160a: change i2c0 (iic1) pinmux mask to one bit
commit: 0973d9d880d26c85a9466f7b51163309c0d3177b
Remove words "This change" and rephrash last sentence to
Align with documentation by avoiding writes to reserved bits. No functional
change, as writing the extra two reserved bits is not known to cause
issues.
[03/10] arm64: dts: lx2160a: remove duplicate pinmux nodes
commit: 385c7dca29e416800f57fbaf96788257d455046e
[04/10] arm64: dts: lx2160a: rename pinmux nodes for readability
commit: bb9407c855bbf62c404a3bc5119033198c5ae8a4
[05/10] arm64: dts: lx2160a: add sda gpio references for i2c bus recovery
commit: fbf66a01af34364cb6b49fcf1d77deaf09afb9ab
[06/10] arm64: dts: lx2160a: change zeros to hexadecimal in pinmux nodes
commit: ac26aca831c037a57286a63a6d924c5b956b7b42
[07/10] arm64: dts: lx2160a: complete pinmux for rcwsr12 configuration word
commit: 92479a6b97a54a829a28ec57221f5b74e7ee53b2
[08/10] arm64: dts: lx2160a-cex7: add rtc alias
commit: 7593c15e9512022f8bb57bb24995955d8dcd137e
[09/10] arm64: dts: lx2162a-sr-som: add crypto & rtc aliases, model
commit: 112d3b46d3e00db17f0a309e479fe4678906b6f9
[10/10] arm64: dts: lx2162a-clearfog: set sfp connector leds function and source
commit: 7a387b0b0bc2f2c703d8d64250a056f43eb2c800
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v2 2/6] usb: xhci: tegra: Remove redundant mutex when setting phy mode
From: Diogo Ivo @ 2026-03-26 14:17 UTC (permalink / raw)
To: Thierry Reding
Cc: Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
Jonathan Hunter, JC Kuo, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <acJ50sQraVmy4zXs@orome>
Hello,
On 3/24/26 11:48, Thierry Reding wrote:
> On Tue, Jan 27, 2026 at 03:11:48PM +0000, Diogo Ivo wrote:
>> As the PHY subsystem already synchronizes concurrent accesses to a PHY
>> instance with a core-internal mutex remove the driver specific mutex
>> synchronization.
>>
>> Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
>> ---
>> v1->v2:
>> - New patch
>> ---
>> drivers/usb/host/xhci-tegra.c | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
>> index 8b492871d21d..927861ca14f2 100644
>> --- a/drivers/usb/host/xhci-tegra.c
>> +++ b/drivers/usb/host/xhci-tegra.c
>> @@ -1357,15 +1357,11 @@ static void tegra_xhci_id_work(struct work_struct *work)
>>
>> dev_dbg(tegra->dev, "host mode %s\n", str_on_off(tegra->host_mode));
>>
>> - mutex_lock(&tegra->lock);
>> -
>> if (tegra->host_mode)
>> phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_HOST);
>> else
>> phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_NONE);
>>
>> - mutex_unlock(&tegra->lock);
>> -
>
> It looks to me like the mutex here is trying to protect against
> tegra->host_mode changing while we're setting a different mode. That
> doesn't seem to be taken care of by the PHY internal mutex.
After taking another look at it I think I understand your point for the
mutex, but in that case wouldn't it also need to be held in the writer
of host_mode, tegra_xhci_id_notify()?
This patch has been picked up as-is into usb-next so it would be nice to
figure this out before it gets merged in the next merge window.
Diogo
> Thierry
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: input: touchscreen: ti,tsc2005: Add wakeup-source
From: Rob Herring @ 2026-03-26 14:15 UTC (permalink / raw)
To: phucduc.bui
Cc: conor+dt, krzk+dt, conor, devicetree, dmitry.torokhov, krzk,
linux-input, linux-kernel, marex, mingo, tglx
In-Reply-To: <20260318083124.21793-1-phucduc.bui@gmail.com>
On Wed, Mar 18, 2026 at 03:31:24PM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Document the "wakeup-source" property for the ti,tsc2005 touchscreen
> controllers to allow the device to wake the system from suspend.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
>
> changes:
> v3: Remove blank lines
> v2: Revise the commit content and remove patch1 related to I2C and SPI
> wakeup handling
>
> .../devicetree/bindings/input/touchscreen/ti,tsc2005.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml b/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
> index 7187c390b2f5..a9842509c1fe 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
> +++ b/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
> @@ -55,6 +55,9 @@ properties:
> touchscreen-size-x: true
> touchscreen-size-y: true
>
> + wakeup-source:
> + type: boolean
wakeup-source already has a defined type.
wakeup-source: true
> +
> allOf:
> - $ref: touchscreen.yaml#
> - if:
> @@ -97,6 +100,7 @@ examples:
>
> ti,x-plate-ohms = <280>;
> ti,esd-recovery-timeout-ms = <8000>;
> + wakeup-source;
> };
> };
> - |
> @@ -124,5 +128,6 @@ examples:
>
> ti,x-plate-ohms = <280>;
> ti,esd-recovery-timeout-ms = <8000>;
> + wakeup-source;
> };
> };
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: gpu: mali-bifrost: Add compatible for RZ/G3L SoC
From: Geert Uytterhoeven @ 2026-03-26 14:10 UTC (permalink / raw)
To: Biju
Cc: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Biju Das, dri-devel, devicetree, linux-kernel,
linux-renesas-soc, Prabhakar Mahadev Lad
In-Reply-To: <20260320164158.487406-2-biju.das.jz@bp.renesas.com>
On Fri, 20 Mar 2026 at 17:42, Biju <biju.das.au@gmail.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Add a compatible string for the Renesas RZ/G3L SoC variants that include a
> Mali-G31 GPU. These variants share the same restrictions on interrupts,
> clocks, and power domains as the RZ/G2L SoC, so extend the existing schema
> validation accordingly.
>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: renesas,riic: Document the R9A08G046 support
From: Geert Uytterhoeven @ 2026-03-26 14:05 UTC (permalink / raw)
To: Biju
Cc: Chris Brandt, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Biju Das, Wolfram Sang,
linux-renesas-soc, linux-i2c, devicetree, linux-kernel,
Prabhakar Mahadev Lad
In-Reply-To: <20260304071732.5864-1-biju.das.jz@bp.renesas.com>
On Wed, 4 Mar 2026 at 08:17, Biju <biju.das.au@gmail.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document the Renesas RZ/G3L (R9A08G046) RIIC IP. This is compatible with
> the version available on Renesas RZ/V2H (R9A09G057).
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] media: dt-bindings: i2c: Drop redundant endpoint properties
From: Rob Herring @ 2026-03-26 14:03 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Krzysztof Kozlowski, Sakari Ailus, Tommaso Merciai, Martin Hecht,
Mauro Carvalho Chehab, Krzysztof Kozlowski, Conor Dooley,
Sebastian Reichel, Alain Volmat, Jacopo Mondi, Kieran Bingham,
Niklas Söderlund, Dave Stevenson, Geert Uytterhoeven,
Magnus Damm, Vladimir Zapolskiy, Dongchun Zhu, Paul Kocialkowski,
Quentin Schulz, Todor Tomov, Paul J. Murphy,
Daniele Alessandrelli, Marco Felsch, Lubomir Rintel,
linux-renesas-soc, Lad Prabhakar, linux-media, devicetree,
linux-kernel
In-Reply-To: <20260318171246.GH633439@killaraus.ideasonboard.com>
On Wed, Mar 18, 2026 at 07:12:46PM +0200, Laurent Pinchart wrote:
> Hello Krzysztof,
>
> On Mon, Mar 16, 2026 at 07:02:41PM +0100, Krzysztof Kozlowski wrote:
> > On 16/03/2026 18:19, Sakari Ailus wrote:
> > > On Mon, Mar 16, 2026 at 03:42:09PM +0100, Krzysztof Kozlowski wrote:
> > >> On 16/03/2026 14:53, Laurent Pinchart wrote:
> > >>> On Mon, Mar 16, 2026 at 02:45:34PM +0100, Krzysztof Kozlowski wrote:
> > >>>> The "endpoint" node references video-interfaces.yaml schema with
> > >>>> "unevaluatedProperties: false" which means that all properties from
> > >>>> referenced schema apply. Listing some of them with ": true" is simply
> > >>>> redundant and does not make this code easier to read.
> > >>>
> > >>> I think you know my opinion on this topic. I believe we would be better
> > >>> off by turning "unevaluatedProperties: false" into
> > >>> "additionalProperties: false" here, and keeping the list of applicable
> > >>> properties. It brings value to device tree authors by telling which
> > >>> properties are applicable to the device at hand. For instance ... (see
> > >>> below)
> > >>
> > >> (let me trim)
> > >>
> > >>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml
> > >>>> index 2d7937a372a2..7a05a1eda58d 100644
> > >>>> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml
> > >>>> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml
> > >>>> @@ -51,9 +51,6 @@ properties:
> > >>>> $ref: /schemas/media/video-interfaces.yaml#
> > >>>> unevaluatedProperties: false
> > >>>>
> > >>>> - properties:
> > >>>> - clock-noncontinuous: true
> > >>>> -
> > >>>
> > >>> ... Without this, an integrator will need to dive into driver code to
> > >>> know if non-continuous clock is usable for the device.
> > >>
> > >> I see. Our usual interpretation of common schema, expressed by @Rob in
> > >> few places, that eventually all properties might be applicable. This
> > >> applies especially for ABI tied to the core Linux specifics, e.g.
> > >> rotation and orientation from video-interface-devices.yaml.
> > >>
> > >> Absolutely every sensor can be mounted rotated, therefore every binding
> > >> referencing video-interface-devices should allow it, even if driver is
> > >> not using it. Because basically that's the ABI we want to define for
> > >> each sensor, thus each binding referencing common schema should have
> > >> "unevaluatedProps: true" without listing them.
>
> Yes, that's totally fine. I agree that properties defined in
> video-interface-devices.yaml should not be listed in individual
> bindings. They're generic, and all of them are applicable to each image
> sensor device. That part is fine, I think we have no disagreement.
>
> > >> Similarly touchscreen.yaml.
> > >>
> > >> OTOH, second option, properties which are strictly hardware, e.g. name
> > >> of power supply or whether clock has or has not non-continuous mode,
> > >> should be allowed only when they match the hardware. Such bindings
> > >> should use "additionalProperties: false" so the hardware description is
> > >> constrained/fixed/specific.
> > >
> > > The patch may be technically correct but I'm afraid it won't improve the
> > > bindings but rather the opposite: it removes information telling whether a
> > > property is relevant for a given device.
> > >
> > > I bet there are a lot of possibilities to write invalid DTS while the
> > > checker says it's fine (missing data-lanes or link-frequencies, for
> > > instance). That may have been the case before the patch but I'd make
> > > properties a driver needs to function mandatory rather than removing them
> > > from bindings altogether.
> >
> > That's pretty different problem and I am not removing any mandatory
> > properties. I changed absolutely nothing from functional point of view.
> >
> > > It'd been on my to-do list to split the current video-interfaces.yaml into
> > > several files: generic camera sensor properties, CSI-2 interface
> > > properties, DVP/Bt.656 interface properties and the rest (full list
> > > probably requires more thought). That way we could only include properties
> > > that are relevant for the device without necessarily listing each one for
> > > all bindings.
> > >
> > > I'd also continue to list boolean properties relevant for devices as well
> > > as other properties that are relevant for a device but not mandatory.
> >
> > I don't think there is such goal and particular subsystem does not get
> > exception here. What is relevant for device comes either from the
> > hardware or implemented ABI, as I explained. Bindings arbitrarily
> > choosing "I think this might be relevant" from some big schema with
> > irrelevant pieces is not manageable and not correct.
>
> But that's not what we're discussing. The properties you're dropping
> here are not "arbitrarily" choosen as being relevant. Whether it is
> possible or not to use a non-continuous clock is a hardware property,
> it's not an arbitrary choice.
>
> Your patch will not change anything when it comes to validation of DT by
> tools using the schema, but it drops important information relevant to
> DT writers. What I recommend instead is to switch from
> "unevaluatedProperties: false" to "additionalProperties: false". Not
> only will we keep the information, but it will also be enforced properly
> by tools.
I agree with keeping the information. Really, I'm indifferent, so if
anyone finds it useful then let's leave it. I'm also not going to care
in reviews either, so it's up to the media maintainers to care and
ensure consistency.
Also, I don't think we can switch to additionalProperties here because
then we have to list all the standard graph properties, too. That I do
care about and don't care to see.
Rob
^ permalink raw reply
* Re: [PATCH v5 8/9] dt-bindings: net: wireless: brcm: Add compatible for bcm43752
From: Ronald Claveau @ 2026-03-26 14:03 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Conor Dooley, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Johannes Berg,
van Spriel
In-Reply-To: <9bc23f1e-1cf3-43d1-935a-c4738d576c29@linaro.org>
On 3/26/26 1:55 PM, Neil Armstrong wrote:
> On 3/26/26 10:59, Ronald Claveau wrote:
>> Add bcm43752 compatible with its bcm4329 compatible fallback.
>>
>> Acked-by: Conor Dooley <conor.dooley@microchip.com>
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> ---
>> Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-
>> fmac.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/
>> brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/
>> wireless/brcm,bcm4329-fmac.yaml
>> index 3be7576787644..81fd3e37452a6 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-
>> fmac.yaml
>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-
>> fmac.yaml
>> @@ -42,6 +42,7 @@ properties:
>> - brcm,bcm4356-fmac
>> - brcm,bcm4359-fmac
>> - brcm,bcm4366-fmac
>> + - brcm,bcm43752-fmac
>> - cypress,cyw4373-fmac
>> - cypress,cyw43012-fmac
>> - infineon,cyw43439-fmac
>>
>
> I'll apply all the other DT patches, please send this one alone with the
> [PATCH net-next] prefix so it gets picked by the wireless/net people.
>
> Thanks,
> Neil
I'm on it, thank you.
--
Best regards,
Ronald
^ permalink raw reply
* [PATCH v3 6/6] arm64: tegra: Add PCI controllers on Tegra264
From: Thierry Reding @ 2026-03-26 13:58 UTC (permalink / raw)
To: Thierry Reding, Bjorn Helgaas, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Jon Hunter, Mikko Perttunen, linux-pci, devicetree, linux-tegra
In-Reply-To: <20260326135855.2795149-1-thierry.reding@kernel.org>
From: Thierry Reding <treding@nvidia.com>
A total of six PCIe controllers can be found on Tegra264. One of them is
used internally for the integrated GPU while the other five can go to a
variety of connectors like full PCIe slots or M.2.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v2:
- order ECAM "reg" entry before others
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 248 ++++++++++++++++++++---
1 file changed, 221 insertions(+), 27 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
index 7644a41d5f72..5214cec21204 100644
--- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
@@ -32,7 +32,7 @@ bus@0 {
#address-cells = <2>;
#size-cells = <2>;
- ranges = <0x00 0x00000000 0x00 0x00000000 0x01 0x00000000>;
+ ranges = <0x00 0x00000000 0x00 0x00000000 0x00 0x20000000>; /* MMIO (512 MiB) */
misc@100000 {
compatible = "nvidia,tegra234-misc";
@@ -3356,9 +3356,10 @@ bus@8100000000 {
#address-cells = <2>;
#size-cells = <2>;
- ranges = <0x00 0x00000000 0x81 0x00000000 0x01 0x00000000>, /* MMIO */
- <0x01 0x00000000 0x00 0x20000000 0x00 0x40000000>, /* non-prefetchable memory (32-bit) */
- <0x02 0x00000000 0xd0 0x00000000 0x08 0x80000000>; /* ECAM, prefetchable memory, I/O */
+ ranges = <0x00 0x00000000 0x81 0x00000000 0x00 0x20000000>, /* MMIO (512 MiB) */
+ <0x00 0x20000000 0x00 0x20000000 0x00 0x20000000>, /* non-prefetchable memory (32-bit, 512 MiB) */
+ <0x00 0x40000000 0x81 0x40000000 0x00 0x20000000>, /* MMIO (512 MiB) */
+ <0xa8 0x80000000 0xa8 0x80000000 0x57 0x80000000>; /* I/O, ECAM, prefetchable memory (64-bit) */
smmu1: iommu@5000000 {
compatible = "nvidia,tegra264-smmu", "arm,smmu-v3";
@@ -3402,23 +3403,23 @@ cmdqv2: cmdqv@6200000 {
mc: memory-controller@8020000 {
compatible = "nvidia,tegra264-mc";
- reg = <0x00 0x8020000 0x0 0x20000>, /* MC broadcast */
- <0x00 0x8040000 0x0 0x20000>, /* MC 0 */
- <0x00 0x8060000 0x0 0x20000>, /* MC 1 */
- <0x00 0x8080000 0x0 0x20000>, /* MC 2 */
- <0x00 0x80a0000 0x0 0x20000>, /* MC 3 */
- <0x00 0x80c0000 0x0 0x20000>, /* MC 4 */
- <0x00 0x80e0000 0x0 0x20000>, /* MC 5 */
- <0x00 0x8100000 0x0 0x20000>, /* MC 6 */
- <0x00 0x8120000 0x0 0x20000>, /* MC 7 */
- <0x00 0x8140000 0x0 0x20000>, /* MC 8 */
- <0x00 0x8160000 0x0 0x20000>, /* MC 9 */
- <0x00 0x8180000 0x0 0x20000>, /* MC 10 */
- <0x00 0x81a0000 0x0 0x20000>, /* MC 11 */
- <0x00 0x81c0000 0x0 0x20000>, /* MC 12 */
- <0x00 0x81e0000 0x0 0x20000>, /* MC 13 */
- <0x00 0x8200000 0x0 0x20000>, /* MC 14 */
- <0x00 0x8220000 0x0 0x20000>; /* MC 15 */
+ reg = <0x000 0x8020000 0x0 0x20000>, /* MC broadcast */
+ <0x000 0x8040000 0x0 0x20000>, /* MC 0 */
+ <0x000 0x8060000 0x0 0x20000>, /* MC 1 */
+ <0x000 0x8080000 0x0 0x20000>, /* MC 2 */
+ <0x000 0x80a0000 0x0 0x20000>, /* MC 3 */
+ <0x000 0x80c0000 0x0 0x20000>, /* MC 4 */
+ <0x000 0x80e0000 0x0 0x20000>, /* MC 5 */
+ <0x000 0x8100000 0x0 0x20000>, /* MC 6 */
+ <0x000 0x8120000 0x0 0x20000>, /* MC 7 */
+ <0x000 0x8140000 0x0 0x20000>, /* MC 8 */
+ <0x000 0x8160000 0x0 0x20000>, /* MC 9 */
+ <0x000 0x8180000 0x0 0x20000>, /* MC 10 */
+ <0x000 0x81a0000 0x0 0x20000>, /* MC 11 */
+ <0x000 0x81c0000 0x0 0x20000>, /* MC 12 */
+ <0x000 0x81e0000 0x0 0x20000>, /* MC 13 */
+ <0x000 0x8200000 0x0 0x20000>, /* MC 14 */
+ <0x000 0x8220000 0x0 0x20000>; /* MC 15 */
reg-names = "broadcast", "ch0", "ch1", "ch2", "ch3",
"ch4", "ch5", "ch6", "ch7", "ch8", "ch9",
"ch10", "ch11", "ch12", "ch13", "ch14",
@@ -3437,12 +3438,12 @@ mc: memory-controller@8020000 {
#size-cells = <2>;
/* limit the DMA range for memory clients to [39:0] */
- dma-ranges = <0x0 0x0 0x0 0x0 0x100 0x0>;
+ dma-ranges = <0x000 0x0 0x000 0x0 0x100 0x0>;
emc: external-memory-controller@8800000 {
compatible = "nvidia,tegra264-emc";
- reg = <0x00 0x8800000 0x0 0x20000>,
- <0x00 0x8890000 0x0 0x20000>;
+ reg = <0x000 0x8800000 0x0 0x20000>,
+ <0x000 0x8890000 0x0 0x20000>;
interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&bpmp TEGRA264_CLK_EMC>,
<&bpmp TEGRA264_CLK_DBB_UPHY0>;
@@ -3493,6 +3494,38 @@ cmdqv4: cmdqv@b200000 {
status = "disabled";
};
+ pci@c000000 {
+ compatible = "nvidia,tegra264-pcie";
+ reg = <0xd0 0xb0000000 0x0 0x10000000>,
+ <0x00 0x0c000000 0x0 0x00004000>,
+ <0x00 0x0c004000 0x0 0x00001000>,
+ <0x00 0x0c005000 0x0 0x00001000>;
+ reg-names = "ecam", "xal", "xtl", "xtl-pri";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ linux,pci-domain = <0x00>;
+ #interrupt-cells = <0x1>;
+
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0x0 0x0 155 IRQ_TYPE_LEVEL_HIGH>,
+ <0x0 0x0 0x0 0x2 &gic 0x0 0x0 0x0 156 IRQ_TYPE_LEVEL_HIGH>,
+ <0x0 0x0 0x0 0x3 &gic 0x0 0x0 0x0 157 IRQ_TYPE_LEVEL_HIGH>,
+ <0x0 0x0 0x0 0x4 &gic 0x0 0x0 0x0 158 IRQ_TYPE_LEVEL_HIGH>;
+
+ iommu-map = <0x0 &smmu2 0x10000 0x10000>;
+ msi-map = <0x0 &its 0x210000 0x10000>;
+ dma-coherent;
+
+ ranges = <0x81000000 0x00 0x84000000 0xd0 0x84000000 0x00 0x00200000>, /* I/O */
+ <0x82000000 0x00 0x20000000 0x00 0x20000000 0x00 0x08000000>, /* non-prefetchable memory (128 MiB) */
+ <0xc3000000 0xd0 0xc0000000 0xd0 0xc0000000 0x07 0xc0000000>; /* prefetchable memory */
+ bus-range = <0x0 0xff>;
+
+ nvidia,bpmp = <&bpmp 0>;
+ status = "disabled";
+ };
+
i2c14: i2c@c410000 {
compatible = "nvidia,tegra264-i2c";
reg = <0x00 0x0c410000 0x0 0x10000>;
@@ -3720,7 +3753,7 @@ bus@8800000000 {
#address-cells = <2>;
#size-cells = <2>;
- ranges = <0x00 0x00000000 0x88 0x00000000 0x01 0x00000000>;
+ ranges = <0x00 0x00000000 0x88 0x00000000 0x00 0x20000000>; /* MMIO (512 MiB) */
smmu3: iommu@6000000 {
compatible = "nvidia,tegra264-smmu", "arm,smmu-v3";
@@ -3765,8 +3798,169 @@ bus@a800000000 {
#address-cells = <2>;
#size-cells = <2>;
- ranges = <0x00 0x00000000 0xa8 0x00000000 0x40 0x00000000>, /* MMIO, ECAM, prefetchable memory, I/O */
- <0x80 0x00000000 0x00 0x20000000 0x00 0x40000000>; /* non-prefetchable memory (32-bit) */
+ ranges = <0x00 0x00000000 0xa8 0x00000000 0x00 0x20000000>, /* MMIO (512 MiB) */
+ <0x00 0x20000000 0x00 0x20000000 0x00 0x60000000>, /* non-prefetchable memory (32-bit, 1536 GiB) */
+ <0xa8 0x80000000 0xa8 0x80000000 0x57 0x80000000>; /* I/O, ECAM, prefetchable memory (64-bit) */
+
+ pci@8400000 {
+ compatible = "nvidia,tegra264-pcie";
+ reg = <0xa8 0xb0000000 0x0 0x10000000>,
+ <0x00 0x08400000 0x0 0x00004000>,
+ <0x00 0x08404000 0x0 0x00001000>,
+ <0x00 0x08405000 0x0 0x00001000>,
+ <0x00 0x08410000 0x0 0x00010000>;
+ reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ linux,pci-domain = <0x01>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0x0 0x0 908 IRQ_TYPE_LEVEL_HIGH>, /* INTA */
+ <0x0 0x0 0x0 0x2 &gic 0x0 0x0 0x0 909 IRQ_TYPE_LEVEL_HIGH>, /* INTB */
+ <0x0 0x0 0x0 0x3 &gic 0x0 0x0 0x0 910 IRQ_TYPE_LEVEL_HIGH>, /* INTC */
+ <0x0 0x0 0x0 0x4 &gic 0x0 0x0 0x0 911 IRQ_TYPE_LEVEL_HIGH>; /* INTD */
+
+ iommu-map = <0x0 &smmu1 0x10000 0x10000>;
+ msi-map = <0x0 &its 0x110000 0x10000>;
+ dma-coherent;
+
+ ranges = <0x81000000 0x00 0x84000000 0xa8 0x84000000 0x00 0x00200000>, /* I/O */
+ <0x82000000 0x00 0x28000000 0x00 0x28000000 0x00 0x08000000>, /* non-prefetchable memory */
+ <0xc3000000 0xa8 0xc0000000 0xa8 0xc0000000 0x07 0xc0000000>; /* prefetchable memory */
+ bus-range = <0x00 0xff>;
+
+ nvidia,bpmp = <&bpmp 1>;
+ status = "disabled";
+ };
+
+ pci@8420000 {
+ compatible = "nvidia,tegra264-pcie";
+ reg = <0xb0 0xb0000000 0x0 0x10000000>,
+ <0x00 0x08420000 0x0 0x00004000>,
+ <0x00 0x08424000 0x0 0x00001000>,
+ <0x00 0x08425000 0x0 0x00001000>,
+ <0x00 0x08430000 0x0 0x00010000>;
+ reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ linux,pci-domain = <0x02>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0x0 0x0 917 IRQ_TYPE_LEVEL_HIGH>, /* INTA */
+ <0x0 0x0 0x0 0x2 &gic 0x0 0x0 0x0 918 IRQ_TYPE_LEVEL_HIGH>, /* INTB */
+ <0x0 0x0 0x0 0x3 &gic 0x0 0x0 0x0 919 IRQ_TYPE_LEVEL_HIGH>, /* INTC */
+ <0x0 0x0 0x0 0x4 &gic 0x0 0x0 0x0 920 IRQ_TYPE_LEVEL_HIGH>; /* INTD */
+
+ iommu-map = <0x0 &smmu1 0x20000 0x10000>;
+ msi-map = <0x0 &its 0x120000 0x10000>;
+ dma-coherent;
+
+ ranges = <0x81000000 0x00 0x84000000 0xb0 0x84000000 0x00 0x00200000>, /* I/O */
+ <0x82000000 0x00 0x30000000 0x00 0x30000000 0x00 0x08000000>, /* non-prefetchable memory */
+ <0xc3000000 0xb0 0xc0000000 0xb0 0xc0000000 0x07 0xc0000000>; /* prefetchable memory */
+ bus-range = <0x00 0xff>;
+
+ nvidia,bpmp = <&bpmp 2>;
+ status = "disabled";
+ };
+
+ pci@8440000 {
+ compatible = "nvidia,tegra264-pcie";
+ reg = <0xb8 0xb0000000 0x0 0x10000000>,
+ <0x00 0x08440000 0x0 0x00004000>,
+ <0x00 0x08444000 0x0 0x00001000>,
+ <0x00 0x08445000 0x0 0x00001000>,
+ <0x00 0x08450000 0x0 0x00010000>;
+ reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ linux,pci-domain = <0x03>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0x0 0x0 926 IRQ_TYPE_LEVEL_HIGH>, /* INTA */
+ <0x0 0x0 0x0 0x2 &gic 0x0 0x0 0x0 927 IRQ_TYPE_LEVEL_HIGH>, /* INTB */
+ <0x0 0x0 0x0 0x3 &gic 0x0 0x0 0x0 928 IRQ_TYPE_LEVEL_HIGH>, /* INTC */
+ <0x0 0x0 0x0 0x4 &gic 0x0 0x0 0x0 929 IRQ_TYPE_LEVEL_HIGH>; /* INTD */
+
+ iommu-map = <0x0 &smmu1 0x30000 0x10000>;
+ msi-map = <0x0 &its 0x130000 0x10000>;
+ dma-coherent;
+
+ ranges = <0x81000000 0x00 0x84000000 0xb8 0x84000000 0x00 0x00200000>, /* I/O */
+ <0x82000000 0x00 0x38000000 0x00 0x38000000 0x00 0x08000000>, /* non-prefetchable memory */
+ <0xc3000000 0xb8 0xc0000000 0xb8 0xc0000000 0x07 0xc0000000>; /* prefetchable memory */
+ bus-range = <0x00 0xff>;
+
+ nvidia,bpmp = <&bpmp 3>;
+ status = "disabled";
+ };
+
+ pci@8460000 {
+ compatible = "nvidia,tegra264-pcie";
+ reg = <0xc0 0xb0000000 0x0 0x10000000>,
+ <0x00 0x08460000 0x0 0x00004000>,
+ <0x00 0x08464000 0x0 0x00001000>,
+ <0x00 0x08465000 0x0 0x00001000>,
+ <0x00 0x08470000 0x0 0x00010000>;
+ reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ linux,pci-domain = <0x04>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0x0 0x0 935 IRQ_TYPE_LEVEL_HIGH>, /* INTA */
+ <0x0 0x0 0x0 0x2 &gic 0x0 0x0 0x0 936 IRQ_TYPE_LEVEL_HIGH>, /* INTB */
+ <0x0 0x0 0x0 0x3 &gic 0x0 0x0 0x0 937 IRQ_TYPE_LEVEL_HIGH>, /* INTC */
+ <0x0 0x0 0x0 0x4 &gic 0x0 0x0 0x0 938 IRQ_TYPE_LEVEL_HIGH>; /* INTD */
+
+ iommu-map = <0x0 &smmu1 0x40000 0x10000>;
+ msi-map = <0x0 &its 0x140000 0x10000>;
+ dma-coherent;
+
+ ranges = <0x81000000 0x00 0x84000000 0xc0 0x84000000 0x00 0x00200000>, /* I/O */
+ <0x82000000 0x00 0x40000000 0x00 0x40000000 0x00 0x08000000>, /* non-prefetchable memory */
+ <0xc3000000 0xc0 0xc0000000 0xc0 0xc0000000 0x07 0xc0000000>; /* prefetchable memory */
+ bus-range = <0x00 0xff>;
+
+ nvidia,bpmp = <&bpmp 4>;
+ status = "disabled";
+ };
+
+ pci@8480000 {
+ compatible = "nvidia,tegra264-pcie";
+ reg = <0xc8 0xb0000000 0x0 0x10000000>,
+ <0x00 0x08480000 0x0 0x00004000>,
+ <0x00 0x08484000 0x0 0x00001000>,
+ <0x00 0x08485000 0x0 0x00001000>,
+ <0x00 0x08490000 0x0 0x00010000>;
+ reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ linux,pci-domain = <0x05>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0x0 0x0 944 IRQ_TYPE_LEVEL_HIGH>, /* INTA */
+ <0x0 0x0 0x0 0x2 &gic 0x0 0x0 0x0 945 IRQ_TYPE_LEVEL_HIGH>, /* INTB */
+ <0x0 0x0 0x0 0x3 &gic 0x0 0x0 0x0 946 IRQ_TYPE_LEVEL_HIGH>, /* INTC */
+ <0x0 0x0 0x0 0x4 &gic 0x0 0x0 0x0 947 IRQ_TYPE_LEVEL_HIGH>; /* INTD */
+
+ iommu-map = <0x0 &smmu1 0x50000 0x10000>;
+ msi-map = <0x0 &its 0x150000 0x10000>;
+ dma-coherent;
+
+ ranges = <0x81000000 0x00 0x84000000 0xc8 0x84000000 0x00 0x00200000>, /* I/O */
+ <0x82000000 0x00 0x48000000 0x00 0x48000000 0x00 0x08000000>, /* non-prefetchable memory */
+ <0xc3000000 0xc8 0xc0000000 0xc8 0xc0000000 0x07 0xc0000000>; /* prefetchable memory */
+ bus-range = <0x00 0xff>;
+
+ nvidia,bpmp = <&bpmp 5>;
+ status = "disabled";
+ };
};
cpus {
--
2.52.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox