* Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Rob Herring @ 2026-01-16 17:30 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Manivannan Sadhasivam, Greg Kroah-Hartman, Jiri Slaby,
Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi
In-Reply-To: <ysfkemsf4w7r3eoahfpjdr3z3buec5kvw4qol2njhxrz5tsdpo@4scz632uaj5i>
On Fri, Jan 16, 2026 at 8:43 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Fri, Jan 16, 2026 at 08:19:07AM -0600, Rob Herring wrote:
> > On Thu, Jan 15, 2026 at 4:42 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Wed, Jan 14, 2026 at 11:45:42AM -0600, Rob Herring wrote:
> > > > On Wed, Jan 14, 2026 at 10:14 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > >
> > > > > On Tue, Jan 13, 2026 at 11:14:24AM -0600, Rob Herring wrote:
> > > > > > On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote:
> > > > > > > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined
> > > > > > > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector
> > > > > > > provides interfaces like PCIe or SDIO to attach the WiFi devices to the
> > > > > > > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT)
> > > > > > > devices. Spec also provides an optional interface to connect the UIM card,
> > > > > > > but that is not covered in this binding.
> > > > > > >
> > > > > > > The connector provides a primary power supply of 3.3v, along with an
> > > > > > > optional 1.8v VIO supply for the Adapter I/O buffer circuitry operating at
> > > > > > > 1.8v sideband signaling.
> > > > > > >
> > > > > > > The connector also supplies optional signals in the form of GPIOs for fine
> > > > > > > grained power management.
> > > > > > >
> > > > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > > > ---
> > > > > > > .../bindings/connector/pcie-m2-e-connector.yaml | 154 +++++++++++++++++++++
> > > > > > > MAINTAINERS | 1 +
> > > > > > > 2 files changed, 155 insertions(+)
> > > > > > >
> > > > > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..b65b39ddfd19
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > > > > @@ -0,0 +1,154 @@
> > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: PCIe M.2 Mechanical Key E Connector
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > > > +
> > > > > > > +description:
> > > > > > > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E
> > > > > > > + connector. Mechanical Key E connectors are used to connect Wireless
> > > > > > > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host
> > > > > > > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C.
> > > > > > > +
> > > > > > > +properties:
> > > > > > > + compatible:
> > > > > > > + const: pcie-m2-e-connector
> > > > > > > +
> > > > > > > + vpcie3v3-supply:
> > > > > > > + description: A phandle to the regulator for 3.3v supply.
> > > > > > > +
> > > > > > > + vpcie1v8-supply:
> > > > > > > + description: A phandle to the regulator for VIO 1.8v supply.
> > > > > >
> > > > > > I don't see any 1.8V supply on the connector. There are 1.8V IOs and you
> > > > > > may need something in DT to ensure those are powered. However, there's
> > > > > > no guarantee that it's a single supply.
> > > > > >
> > > > >
> > > > > 1.8v VIO supply is an optional supply and is only required if the platform
> > > > > supports 1.8v for sideband signals such as PERST#, WAKE#... I can include it in
> > > > > the example for completeness.
> > > >
> > > > My point is that PERST# and WAKE# supplies could be 2 different 1.8V
> > > > supplies and those supply the I/O pads of the GPIO pins (and possibly
> > > > external pull-ups) that drive them. The 1.8V supply doesn't supply
> > > > 1.8V to the slot, so making it a slot/connector property is wrong.
> > > >
> > >
> > > Ok, I get your point that VIO 1.8v supply is just limited to the I/O logic and
> > > not the whole card/adapter. But I don't get your multiple supplies concern. Spec
> > > says, "A 1.8 V supply pin called VIO 1.8 V is used to supply the on-Adapter I/O
> > > buffer circuitry operating at 1.8 V." So it implies that either the single
> > > supply available to the card through VIO might be used to power the whole I/O
> > > circuit logic or the card can derive its own 1.8v supply from 3.3v supply.
> > >
> > > So how come the card can have 2 different 1.8v supplies powering the I/O
> > > circuitry?
> >
> > Is there a pin on the connector for 1.8V supply? I don't have the
> > spec, but the pinout I found[1] didn't show one. If there's a pin,
> > then I have no concern.
> >
>
> Oh yes, there is a single VIO pin defined in the spec for multiple Keys. Since
> it is optional, it could've been omitted in the design you referenced.
>
> So should I name it as vio1v8-supply or vpcie1v8-supply? I don't see any other
> 1.8v supplies other than the VIO supply though.
vpcie1v8 is fine.
Rob
^ permalink raw reply
* Re: [PATCH] serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists
From: Greg Kroah-Hartman @ 2026-01-16 15:47 UTC (permalink / raw)
To: Kendall Willis
Cc: Jiri Slaby, d-gole, vishalm, sebin.francis, msp, khilman, a-kaur,
s-kochidanadu, linux-kernel, linux-serial
In-Reply-To: <f7a2e47b-a37e-4735-91ea-4fcac3217186@ti.com>
On Fri, Jan 16, 2026 at 09:37:44AM -0600, Kendall Willis wrote:
> On 1/16/26 07:16, Greg Kroah-Hartman wrote:
> > On Tue, Dec 30, 2025 at 03:24:51PM -0600, Kendall Willis wrote:
> > > In TI K3 SoCs, I/O daisy chaining is used to allow wakeup from UART when
> > > the UART controller is off. Set UART device as wakeup capable using
> > > out-of-band wakeup if the 'wakeup' pinctrl state exists and the device may
> > > wakeup.
> > >
> > > Signed-off-by: Kendall Willis <k-willis@ti.com>
> > > ---
> > > Implementation
> > > --------------
> > > This patch is intended to be implemented along with the following
> > > series. This patch has no dependencies on any of the other series:
> > >
> > > 1. "pmdomain: ti_sci: handle wakeup constraint for out-of-band wakeup":
> > > Skips setting constraints for wakeup sources that have out-of-band
> > > wakeup capability.
> > > https://github.com/kwillis01/linux/commits/v6.19/uart-daisy-chain/pmdomain
> > >
> > > 2. "serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists"
> > > (this patch): Implements out-of-band wakeup from the UARTs for TI K3
> > > SoCs
> > > https://github.com/kwillis01/linux/tree/v6.19/uart-daisy-chain/uart-wakeup
> > >
> > > 3. "arm64: dts: ti: k3-am62: Support Main UART wakeup": Implements the
> > > functionality to wakeup the system from the Main UART
> > > https://github.com/kwillis01/linux/tree/b4/uart-daisy-chain-dts
> >
> > How am I to pull any of this into the mainline kernel tree? If this is
> > dependant on those out-of-tree stuff, there's no need for me to take
> > this now, please submit this all together properly.
>
> This patch has no dependencies on the listed series. I listed them so that
> there was a full picture of the feature implementation. The "pmdomain:
> ti_sci: handle wakeup constraint for out-of-band wakeup" patch has been
> merged already [1]. The "arm64: dts: ti: k3-am62: Support Main UART wakeup"
> series is posted [2] and has a dependency on this patch. Sorry for the
> confusion with the GitHub links, in the future I either won't add them or
> will add lore links instead.
>
> [1] https://lore.kernel.org/all/20251230-pmdomain-v1-1-3a009d1ff72e@ti.com/
> [2] https://lore.kernel.org/all/20260106-b4-uart-daisy-chain-dts-v3-0-398a66258f2c@ti.com/
>
> Best,
> Kendall Willis <k-willis@ti.com>
Great, can you resend this then without that information to confuse me?
:)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists
From: Kendall Willis @ 2026-01-16 15:37 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, d-gole, vishalm, sebin.francis, msp, khilman, a-kaur,
s-kochidanadu, linux-kernel, linux-serial
In-Reply-To: <2026011620-clause-gecko-2cb0@gregkh>
On 1/16/26 07:16, Greg Kroah-Hartman wrote:
> On Tue, Dec 30, 2025 at 03:24:51PM -0600, Kendall Willis wrote:
>> In TI K3 SoCs, I/O daisy chaining is used to allow wakeup from UART when
>> the UART controller is off. Set UART device as wakeup capable using
>> out-of-band wakeup if the 'wakeup' pinctrl state exists and the device may
>> wakeup.
>>
>> Signed-off-by: Kendall Willis <k-willis@ti.com>
>> ---
>> Implementation
>> --------------
>> This patch is intended to be implemented along with the following
>> series. This patch has no dependencies on any of the other series:
>>
>> 1. "pmdomain: ti_sci: handle wakeup constraint for out-of-band wakeup":
>> Skips setting constraints for wakeup sources that have out-of-band
>> wakeup capability.
>> https://github.com/kwillis01/linux/commits/v6.19/uart-daisy-chain/pmdomain
>>
>> 2. "serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists"
>> (this patch): Implements out-of-band wakeup from the UARTs for TI K3
>> SoCs
>> https://github.com/kwillis01/linux/tree/v6.19/uart-daisy-chain/uart-wakeup
>>
>> 3. "arm64: dts: ti: k3-am62: Support Main UART wakeup": Implements the
>> functionality to wakeup the system from the Main UART
>> https://github.com/kwillis01/linux/tree/b4/uart-daisy-chain-dts
>
> How am I to pull any of this into the mainline kernel tree? If this is
> dependant on those out-of-tree stuff, there's no need for me to take
> this now, please submit this all together properly.
This patch has no dependencies on the listed series. I listed them so
that there was a full picture of the feature implementation. The
"pmdomain: ti_sci: handle wakeup constraint for out-of-band wakeup"
patch has been merged already [1]. The "arm64: dts: ti: k3-am62: Support
Main UART wakeup" series is posted [2] and has a dependency on this
patch. Sorry for the confusion with the GitHub links, in the future I
either won't add them or will add lore links instead.
[1] https://lore.kernel.org/all/20251230-pmdomain-v1-1-3a009d1ff72e@ti.com/
[2]
https://lore.kernel.org/all/20260106-b4-uart-daisy-chain-dts-v3-0-398a66258f2c@ti.com/
Best,
Kendall Willis <k-willis@ti.com>
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Manivannan Sadhasivam @ 2026-01-16 14:42 UTC (permalink / raw)
To: Rob Herring
Cc: Manivannan Sadhasivam, Greg Kroah-Hartman, Jiri Slaby,
Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi
In-Reply-To: <CAL_JsqKKBjurY7ZrScayvkTijR-F6GWBofry48xoPFBFi55u4w@mail.gmail.com>
On Fri, Jan 16, 2026 at 08:19:07AM -0600, Rob Herring wrote:
> On Thu, Jan 15, 2026 at 4:42 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Wed, Jan 14, 2026 at 11:45:42AM -0600, Rob Herring wrote:
> > > On Wed, Jan 14, 2026 at 10:14 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > >
> > > > On Tue, Jan 13, 2026 at 11:14:24AM -0600, Rob Herring wrote:
> > > > > On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote:
> > > > > > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined
> > > > > > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector
> > > > > > provides interfaces like PCIe or SDIO to attach the WiFi devices to the
> > > > > > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT)
> > > > > > devices. Spec also provides an optional interface to connect the UIM card,
> > > > > > but that is not covered in this binding.
> > > > > >
> > > > > > The connector provides a primary power supply of 3.3v, along with an
> > > > > > optional 1.8v VIO supply for the Adapter I/O buffer circuitry operating at
> > > > > > 1.8v sideband signaling.
> > > > > >
> > > > > > The connector also supplies optional signals in the form of GPIOs for fine
> > > > > > grained power management.
> > > > > >
> > > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > > ---
> > > > > > .../bindings/connector/pcie-m2-e-connector.yaml | 154 +++++++++++++++++++++
> > > > > > MAINTAINERS | 1 +
> > > > > > 2 files changed, 155 insertions(+)
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > > > new file mode 100644
> > > > > > index 000000000000..b65b39ddfd19
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > > > @@ -0,0 +1,154 @@
> > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > +%YAML 1.2
> > > > > > +---
> > > > > > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml#
> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > +
> > > > > > +title: PCIe M.2 Mechanical Key E Connector
> > > > > > +
> > > > > > +maintainers:
> > > > > > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > > +
> > > > > > +description:
> > > > > > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E
> > > > > > + connector. Mechanical Key E connectors are used to connect Wireless
> > > > > > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host
> > > > > > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C.
> > > > > > +
> > > > > > +properties:
> > > > > > + compatible:
> > > > > > + const: pcie-m2-e-connector
> > > > > > +
> > > > > > + vpcie3v3-supply:
> > > > > > + description: A phandle to the regulator for 3.3v supply.
> > > > > > +
> > > > > > + vpcie1v8-supply:
> > > > > > + description: A phandle to the regulator for VIO 1.8v supply.
> > > > >
> > > > > I don't see any 1.8V supply on the connector. There are 1.8V IOs and you
> > > > > may need something in DT to ensure those are powered. However, there's
> > > > > no guarantee that it's a single supply.
> > > > >
> > > >
> > > > 1.8v VIO supply is an optional supply and is only required if the platform
> > > > supports 1.8v for sideband signals such as PERST#, WAKE#... I can include it in
> > > > the example for completeness.
> > >
> > > My point is that PERST# and WAKE# supplies could be 2 different 1.8V
> > > supplies and those supply the I/O pads of the GPIO pins (and possibly
> > > external pull-ups) that drive them. The 1.8V supply doesn't supply
> > > 1.8V to the slot, so making it a slot/connector property is wrong.
> > >
> >
> > Ok, I get your point that VIO 1.8v supply is just limited to the I/O logic and
> > not the whole card/adapter. But I don't get your multiple supplies concern. Spec
> > says, "A 1.8 V supply pin called VIO 1.8 V is used to supply the on-Adapter I/O
> > buffer circuitry operating at 1.8 V." So it implies that either the single
> > supply available to the card through VIO might be used to power the whole I/O
> > circuit logic or the card can derive its own 1.8v supply from 3.3v supply.
> >
> > So how come the card can have 2 different 1.8v supplies powering the I/O
> > circuitry?
>
> Is there a pin on the connector for 1.8V supply? I don't have the
> spec, but the pinout I found[1] didn't show one. If there's a pin,
> then I have no concern.
>
Oh yes, there is a single VIO pin defined in the spec for multiple Keys. Since
it is optional, it could've been omitted in the design you referenced.
So should I name it as vio1v8-supply or vpcie1v8-supply? I don't see any other
1.8v supplies other than the VIO supply though.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Rob Herring @ 2026-01-16 14:19 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Manivannan Sadhasivam, Greg Kroah-Hartman, Jiri Slaby,
Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi
In-Reply-To: <gcmm23ji4fkcqeshcyiehuyega7kdbtvmofp4usmol2icwn6gy@i46icelwwqh5>
On Thu, Jan 15, 2026 at 4:42 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Wed, Jan 14, 2026 at 11:45:42AM -0600, Rob Herring wrote:
> > On Wed, Jan 14, 2026 at 10:14 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Tue, Jan 13, 2026 at 11:14:24AM -0600, Rob Herring wrote:
> > > > On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote:
> > > > > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined
> > > > > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector
> > > > > provides interfaces like PCIe or SDIO to attach the WiFi devices to the
> > > > > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT)
> > > > > devices. Spec also provides an optional interface to connect the UIM card,
> > > > > but that is not covered in this binding.
> > > > >
> > > > > The connector provides a primary power supply of 3.3v, along with an
> > > > > optional 1.8v VIO supply for the Adapter I/O buffer circuitry operating at
> > > > > 1.8v sideband signaling.
> > > > >
> > > > > The connector also supplies optional signals in the form of GPIOs for fine
> > > > > grained power management.
> > > > >
> > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > ---
> > > > > .../bindings/connector/pcie-m2-e-connector.yaml | 154 +++++++++++++++++++++
> > > > > MAINTAINERS | 1 +
> > > > > 2 files changed, 155 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..b65b39ddfd19
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > > @@ -0,0 +1,154 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: PCIe M.2 Mechanical Key E Connector
> > > > > +
> > > > > +maintainers:
> > > > > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > +
> > > > > +description:
> > > > > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E
> > > > > + connector. Mechanical Key E connectors are used to connect Wireless
> > > > > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host
> > > > > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C.
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > + const: pcie-m2-e-connector
> > > > > +
> > > > > + vpcie3v3-supply:
> > > > > + description: A phandle to the regulator for 3.3v supply.
> > > > > +
> > > > > + vpcie1v8-supply:
> > > > > + description: A phandle to the regulator for VIO 1.8v supply.
> > > >
> > > > I don't see any 1.8V supply on the connector. There are 1.8V IOs and you
> > > > may need something in DT to ensure those are powered. However, there's
> > > > no guarantee that it's a single supply.
> > > >
> > >
> > > 1.8v VIO supply is an optional supply and is only required if the platform
> > > supports 1.8v for sideband signals such as PERST#, WAKE#... I can include it in
> > > the example for completeness.
> >
> > My point is that PERST# and WAKE# supplies could be 2 different 1.8V
> > supplies and those supply the I/O pads of the GPIO pins (and possibly
> > external pull-ups) that drive them. The 1.8V supply doesn't supply
> > 1.8V to the slot, so making it a slot/connector property is wrong.
> >
>
> Ok, I get your point that VIO 1.8v supply is just limited to the I/O logic and
> not the whole card/adapter. But I don't get your multiple supplies concern. Spec
> says, "A 1.8 V supply pin called VIO 1.8 V is used to supply the on-Adapter I/O
> buffer circuitry operating at 1.8 V." So it implies that either the single
> supply available to the card through VIO might be used to power the whole I/O
> circuit logic or the card can derive its own 1.8v supply from 3.3v supply.
>
> So how come the card can have 2 different 1.8v supplies powering the I/O
> circuitry?
Is there a pin on the connector for 1.8V supply? I don't have the
spec, but the pinout I found[1] didn't show one. If there's a pin,
then I have no concern.
Rob
[1] https://pinoutguide.com/HD/M.2_NGFF_connector_pinout.shtml
^ permalink raw reply
* Re: [PATCH 14/19] drivers: hwtracing: stm: console.c: Migrate to register_console_force helper
From: Marcos Paulo de Souza @ 2026-01-16 13:54 UTC (permalink / raw)
To: Alexander Shishkin, Richard Weinberger, Anton Ivanov,
Johannes Berg, Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Petr Mladek, Steven Rostedt, John Ogness,
Sergey Senozhatsky, Jiri Slaby, Breno Leitao, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Geert Uytterhoeven, Kees Cook, Tony Luck, Guilherme G. Piccoli,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Andreas Larsson, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor
Cc: linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <83zf6daetu.fsf@black.igk.intel.com>
On Fri, 2026-01-16 at 14:04 +0100, Alexander Shishkin wrote:
> Marcos Paulo de Souza <mpdesouza@suse.com> writes:
>
> > The register_console_force function was introduced to register
> > consoles
> > even on the presence of default consoles, replacing the CON_ENABLE
> > flag
> > that was forcing the same behavior.
> >
> > No functional changes.
> >
> > Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
>
> Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Thanks Alexander!
>
> Should I pick this up or will you send this with the rest of the
> series?
I'll need a v2, since some things will also change in other parts of
the patchset, so I would wait for the next version.
>
> Cheers,
> --
> Alex
^ permalink raw reply
* Re: [PATCH v8] tty: tty_port: add workqueue to flip TTY buffer
From: Greg KH @ 2026-01-16 13:24 UTC (permalink / raw)
To: Xin Zhao; +Cc: jirislaby, linux-kernel, linux-serial, tj, hch
In-Reply-To: <20251230090341.853655-1-jackzxcui1989@163.com>
On Tue, Dec 30, 2025 at 05:03:41PM +0800, Xin Zhao wrote:
> Hi all,
>
> On Tue, 23 Dec 2025 11:48:36 +0800 Xin Zhao <jackzxcui1989@163.com> wrote:
> > On the embedded platform, certain critical data, such as IMU data, is
> > transmitted through UART. The tty_flip_buffer_push() interface in the TTY
> > layer uses system_dfl_wq to handle the flipping of the TTY buffer.
> > Although the unbound workqueue can create new threads on demand and wake
> > up the kworker thread on an idle CPU, it may be preempted by real-time
> > tasks or other high-prio tasks.
> >
> > flush_to_ldisc() needs to wake up the relevant data handle thread. When
> > executing __wake_up_common_lock(), it calls spin_lock_irqsave(), which
> > does not disable preemption but disables migration in RT-Linux. This
> > prevents the kworker thread from being migrated to other cores by CPU's
> > balancing logic, resulting in long delays. The call trace is as follows:
> >
> > ...
>
>
> Are there any other changes needed before the patch is merged?
>
> Jiri has reviewed the patch, and I have made the modifications. :)
I need Jiri to ack it :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] MEDIATEK: serial: 8250_mtk: Add ACPI support
From: Greg KH @ 2026-01-16 13:20 UTC (permalink / raw)
To: Zhiyong Tao
Cc: jirislaby, matthias.bgg, angelogioacchino.delregno, fred2599,
linux-kernel, linux-serial, linux-arm-kernel, linux-mediatek,
Project_Global_Digits_Upstream_Group, liguo.zhang, Vasanth.Reddy,
Yenchia Chen
In-Reply-To: <20260105024103.2027085-2-zhiyong.tao@mediatek.com>
On Mon, Jan 05, 2026 at 10:39:55AM +0800, Zhiyong Tao wrote:
> From: "Zhiyong.Tao" <zhiyong.tao@mediatek.com>
>
> Add ACPI support to 8250_mtk driver. This makes it possible to
> use UART on ARM-based desktops with EDK2 UEFI firmware.
>
> Signed-off-by: Yenchia Chen <yenchia.chen@mediatek.com>
> Signed-off-by: Zhiyong.Tao <zhiyong.tao@mediatek.com>
Please use your name, not '.' in it, like your email has. Yenchia did
it properly here.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists
From: Greg Kroah-Hartman @ 2026-01-16 13:16 UTC (permalink / raw)
To: Kendall Willis
Cc: Jiri Slaby, d-gole, vishalm, sebin.francis, msp, khilman, a-kaur,
s-kochidanadu, linux-kernel, linux-serial
In-Reply-To: <20251230-uart-wakeup-v1-1-13f1bb905f14@ti.com>
On Tue, Dec 30, 2025 at 03:24:51PM -0600, Kendall Willis wrote:
> In TI K3 SoCs, I/O daisy chaining is used to allow wakeup from UART when
> the UART controller is off. Set UART device as wakeup capable using
> out-of-band wakeup if the 'wakeup' pinctrl state exists and the device may
> wakeup.
>
> Signed-off-by: Kendall Willis <k-willis@ti.com>
> ---
> Implementation
> --------------
> This patch is intended to be implemented along with the following
> series. This patch has no dependencies on any of the other series:
>
> 1. "pmdomain: ti_sci: handle wakeup constraint for out-of-band wakeup":
> Skips setting constraints for wakeup sources that have out-of-band
> wakeup capability.
> https://github.com/kwillis01/linux/commits/v6.19/uart-daisy-chain/pmdomain
>
> 2. "serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists"
> (this patch): Implements out-of-band wakeup from the UARTs for TI K3
> SoCs
> https://github.com/kwillis01/linux/tree/v6.19/uart-daisy-chain/uart-wakeup
>
> 3. "arm64: dts: ti: k3-am62: Support Main UART wakeup": Implements the
> functionality to wakeup the system from the Main UART
> https://github.com/kwillis01/linux/tree/b4/uart-daisy-chain-dts
How am I to pull any of this into the mainline kernel tree? If this is
dependant on those out-of-tree stuff, there's no need for me to take
this now, please submit this all together properly.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 14/19] drivers: hwtracing: stm: console.c: Migrate to register_console_force helper
From: Alexander Shishkin @ 2026-01-16 13:04 UTC (permalink / raw)
To: Marcos Paulo de Souza, Richard Weinberger, Anton Ivanov,
Johannes Berg, Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Petr Mladek, Steven Rostedt, John Ogness,
Sergey Senozhatsky, Jiri Slaby, Breno Leitao, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Geert Uytterhoeven, Kees Cook, Tony Luck, Guilherme G. Piccoli,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Andreas Larsson, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor
Cc: linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel,
Marcos Paulo de Souza, Alexander Shishkin
In-Reply-To: <20251227-printk-cleanup-part3-v1-14-21a291bcf197@suse.com>
Marcos Paulo de Souza <mpdesouza@suse.com> writes:
> The register_console_force function was introduced to register consoles
> even on the presence of default consoles, replacing the CON_ENABLE flag
> that was forcing the same behavior.
>
> No functional changes.
>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Should I pick this up or will you send this with the rest of the series?
Cheers,
--
Alex
^ permalink raw reply
* Re: [PATCH 15/19] drivers: tty: serial: mux.c: Migrate to register_console_force helper
From: Petr Mladek @ 2026-01-16 9:59 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor,
linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-15-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:22, Marcos Paulo de Souza wrote:
> The register_console_force function was introduced to register consoles
> even on the presence of default consoles, replacing the CON_ENABLE flag
> that was forcing the same behavior.
>
> --- a/drivers/tty/serial/mux.c
> +++ b/drivers/tty/serial/mux.c
> @@ -390,7 +390,7 @@ static struct console mux_console = {
> .write = mux_console_write,
> .device = uart_console_device,
> .setup = mux_console_setup,
> - .flags = CON_ENABLED | CON_PRINTBUFFER,
> + .flags = CON_PRINTBUFFER,
> .index = 0,
> .data = &mux_driver,
> };
> @@ -547,7 +547,7 @@ static int __init mux_init(void)
> mod_timer(&mux_timer, jiffies + MUX_POLL_DELAY);
>
> #ifdef CONFIG_SERIAL_MUX_CONSOLE
> - register_console(&mux_console);
> + register_console_force(&mux_console);
The situation here is the same as in 16th patch for
ma35d1serial_console().
Also "mux_console" is assigned to
static int __init mux_probe(struct parisc_device *dev)
{
[...]
mux_driver.cons = MUX_CONSOLE;
status = uart_register_driver(&mux_driver);
[...]
status = uart_add_one_port(&mux_driver, port);
[...]
}
So, that it can get registered also by:
+ mux_probe()
+ uart_add_one_port()
+ serial_ctrl_register_port()
+ serial_core_register_port()
+ serial_core_add_one_port()
+ uart_configure_port()
+ register_console()
And we would need to pass the "force" information via CON_FORCE flag.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v5 07/11] arm64: dts: microchip: add LAN969x clock header file
From: claudiu beznea @ 2026-01-16 7:22 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver,
linusw, olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial
Cc: luka.perkov
In-Reply-To: <20260115114021.111324-8-robert.marko@sartura.hr>
On 1/15/26 13:37, Robert Marko wrote:
> LAN969x uses hardware clock indexes, so document theses in a header to make
> them humanly readable.
>
> Signed-off-by: Robert Marko<robert.marko@sartura.hr>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
^ permalink raw reply
* Re: [PATCH] serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists
From: Dhruva Gole @ 2026-01-16 5:40 UTC (permalink / raw)
To: Kendall Willis
Cc: Greg Kroah-Hartman, Jiri Slaby, vishalm, sebin.francis, msp,
khilman, a-kaur, s-kochidanadu, linux-kernel, linux-serial
In-Reply-To: <20251230-uart-wakeup-v1-1-13f1bb905f14@ti.com>
On Dec 30, 2025 at 15:24:51 -0600, Kendall Willis wrote:
> In TI K3 SoCs, I/O daisy chaining is used to allow wakeup from UART when
> the UART controller is off. Set UART device as wakeup capable using
> out-of-band wakeup if the 'wakeup' pinctrl state exists and the device may
> wakeup.
>
> Signed-off-by: Kendall Willis <k-willis@ti.com>
> ---
> Implementation
> --------------
> This patch is intended to be implemented along with the following
> series. This patch has no dependencies on any of the other series:
>
> 1. "pmdomain: ti_sci: handle wakeup constraint for out-of-band wakeup":
> Skips setting constraints for wakeup sources that have out-of-band
> wakeup capability.
> https://github.com/kwillis01/linux/commits/v6.19/uart-daisy-chain/pmdomain
>
> 2. "serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists"
> (this patch): Implements out-of-band wakeup from the UARTs for TI K3
> SoCs
> https://github.com/kwillis01/linux/tree/v6.19/uart-daisy-chain/uart-wakeup
>
> 3. "arm64: dts: ti: k3-am62: Support Main UART wakeup": Implements the
> functionality to wakeup the system from the Main UART
> https://github.com/kwillis01/linux/tree/b4/uart-daisy-chain-dts
>
> Testing
> -------
> Tested on a AM62P SK EVM board with all series and dependencies
> implemented. Suspend/resume verified with the Main UART wakeup source
> by entering a keypress on the console.
>
> This github branch has all the necessary patches to test the series
> using v6.19-rc1:
> https://github.com/kwillis01/linux/tree/v6.19/uart-daisy-chain/all
> ---
> drivers/tty/serial/8250/8250_omap.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index 9e49ef48b851bf6cd3b04a77a4d0d7b4e064dc5f..6a5722b722650c1710e79fb76fc1a01cdeccc68f 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -1363,6 +1363,8 @@ static int omap8250_select_wakeup_pinctrl(struct device *dev,
> if (!device_may_wakeup(dev))
> return 0;
>
> + device_set_out_band_wakeup(dev);
> +
Reviewed-by: Dhruva Gole <d-gole@ti.com>
--
Best regards,
Dhruva Gole
Texas Instruments Incorporated
^ permalink raw reply
* Re: [PATCH v4 6/6] dt-bindings: display: google,goldfish-fb: Convert to DT schema
From: Rob Herring (Arm) @ 2026-01-15 17:41 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: linux-kernel, linux-serial, sre, conor+dt, eleanor15x, simona,
airlied, tzimmermann, krzk+dt, gregkh, jserv, mripard,
linux-input, dri-devel, broonie, maarten.lankhorst, linux-sound,
devicetree, dmitry.torokhov, jirislaby, lgirdwood, linux-pm
In-Reply-To: <20260113092602.3197681-7-visitorckw@gmail.com>
On Tue, 13 Jan 2026 09:26:02 +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish Framebuffer binding to DT schema format.
> Update the example node name to 'display' to comply with generic node
> naming standards.
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> ---
> .../bindings/display/google,goldfish-fb.txt | 17 ---------
> .../bindings/display/google,goldfish-fb.yaml | 38 +++++++++++++++++++
> 2 files changed, 38 insertions(+), 17 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/google,goldfish-fb.txt
> create mode 100644 Documentation/devicetree/bindings/display/google,goldfish-fb.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 16/19] drivers: tty: serial: ma35d1_serial: Migrate to register_console_force helper
From: Petr Mladek @ 2026-01-15 16:28 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, linux-um,
linux-kernel, kgdb-bugreport, linux-serial, netdev, linux-m68k,
linux-hardening, linuxppc-dev, sparclinux, linux-stm32,
linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-16-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:23, Marcos Paulo de Souza wrote:
> The register_console_force function was introduced to register consoles
> even on the presence of default consoles, replacing the CON_ENABLE flag
> that was forcing the same behavior.
>
> No functional changes.
>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
> ---
> drivers/tty/serial/ma35d1_serial.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/ma35d1_serial.c b/drivers/tty/serial/ma35d1_serial.c
> index 285b0fe41a86..d1e03dee5579 100644
> --- a/drivers/tty/serial/ma35d1_serial.c
> +++ b/drivers/tty/serial/ma35d1_serial.c
> @@ -633,7 +633,7 @@ static struct console ma35d1serial_console = {
> .write = ma35d1serial_console_write,
> .device = uart_console_device,
> .setup = ma35d1serial_console_setup,
> - .flags = CON_PRINTBUFFER | CON_ENABLED,
> + .flags = CON_PRINTBUFFER,
> .index = -1,
> .data = &ma35d1serial_reg,
> };
> @@ -657,7 +657,7 @@ static void ma35d1serial_console_init_port(void)
> static int __init ma35d1serial_console_init(void)
> {
> ma35d1serial_console_init_port();
> - register_console(&ma35d1serial_console);
> + register_console_force(&ma35d1serial_console);
Sigh, I am afraid that this is not enough.
I double checked how "ma35d1serial_console" was used. I guess
that it could get registered also via the generic uart device
driver code. I see the following:
#ifdef CONFIG_SERIAL_NUVOTON_MA35D1_CONSOLE
[...]
#define MA35D1SERIAL_CONSOLE (&ma35d1serial_console)
#else
#define MA35D1SERIAL_CONSOLE NULL
#endif
static struct uart_driver ma35d1serial_reg = {
[...]
.cons = MA35D1SERIAL_CONSOLE,
[...]
};
static int __init ma35d1serial_init(void)
{
[...]
ret = uart_register_driver(&ma35d1serial_reg);
[...]
ret = platform_driver_register(&ma35d1serial_driver);
[...]
}
And the gneric code:
uart_configure_port(struct uart_driver *drv, struct uart_state *state,
struct uart_port *port)
{
[...]
/*
* If this driver supports console, and it hasn't been
* successfully registered yet, try to re-register it.
* It may be that the port was not available.
*/
if (port->cons && !console_is_registered(port->cons))
register_console(port->cons);
[...]
}
, which can called via from:
+ mux_probe()
+ uart_add_one_port()
+ serial_ctrl_register_port()
+serial_core_register_port()
+ serial_core_add_one_port()
+ uart_configure_port()
+ register_console()
Honestly, I am not 100% sure. The struct console is assigned to
.cons in struct uart_driver. And uart_configure_port() function
passes port->cons from struct uart_port *port. But I believe
that they can get assigned somewhere in the maze of
the init/probe code.
I would feel more comfortable if we kept the information as
as flag in struct console so that even the generic callbacks
could use it.
Anyway, it makes sense to create a sepate flag for this
purpose, e.g. CON_FORCE or CON_FORCE_ENABLE.
> return 0;
> }
> console_initcall(ma35d1serial_console_init);
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 14/19] drivers: hwtracing: stm: console.c: Migrate to register_console_force helper
From: Petr Mladek @ 2026-01-15 12:29 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, linux-um,
linux-kernel, kgdb-bugreport, linux-serial, netdev, linux-m68k,
linux-hardening, linuxppc-dev, sparclinux, linux-stm32,
linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-14-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:21, Marcos Paulo de Souza wrote:
> The register_console_force function was introduced to register consoles
> even on the presence of default consoles, replacing the CON_ENABLE flag
> that was forcing the same behavior.
>
> No functional changes.
>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
LGTM, nice cleanup!
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 13/19] um: drivers: mconsole_kern.c: Migrate to register_console_force helper
From: Petr Mladek @ 2026-01-15 12:24 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, linux-um,
linux-kernel, kgdb-bugreport, linux-serial, netdev, linux-m68k,
linux-hardening, linuxppc-dev, sparclinux, linux-stm32,
linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-13-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:20, Marcos Paulo de Souza wrote:
> The register_console_force function was introduced to register consoles
> even on the presence of default consoles, replacing the CON_ENABLE flag
> that was forcing the same behavior.
>
> No functional changes.
>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
LGTM, nice cleanup!
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 12/19] sparc: kernel: btext: Migrate to register_console_force helper
From: Petr Mladek @ 2026-01-15 12:14 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, linux-um,
linux-kernel, kgdb-bugreport, linux-serial, netdev, linux-m68k,
linux-hardening, linuxppc-dev, sparclinux, linux-stm32,
linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-12-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:19, Marcos Paulo de Souza wrote:
> The register_console_force function was introduced to register consoles
> even on the presence of default consoles, replacing the CON_ENABLE flag
> that was forcing the same behavior.
>
> No functional changes.
>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
LGTM, nice cleanup!
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 11/19] powerpc: kernel: udbg: Migrate to register_console_force helper
From: Petr Mladek @ 2026-01-15 12:13 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, linux-um,
linux-kernel, kgdb-bugreport, linux-serial, netdev, linux-m68k,
linux-hardening, linuxppc-dev, sparclinux, linux-stm32,
linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-11-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:18, Marcos Paulo de Souza wrote:
> The register_console_force function was introduced to register consoles
> even on the presence of default consoles, replacing the CON_ENABLE flag
> that was forcing the same behavior.
>
> No functional changes.
>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
LGTM, nice cleanup!
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* [PATCH v5 11/11] arm64: dts: microchip: add EV23X71A board
From: Robert Marko @ 2026-01-15 11:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver,
linusw, olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial
Cc: luka.perkov, Robert Marko
In-Reply-To: <20260115114021.111324-1-robert.marko@sartura.hr>
Microchip EV23X71A is an LAN9696 based evaluation board.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v5:
* Remove phys property from port 29
* Alphanumericaly sort pin nodes
Changes in v2:
* Split from SoC DTSI commit
* Apply DTS coding style
* Enclose array in i2c-mux
* Alphanumericaly sort nodes
* Change management port mode to RGMII-ID
arch/arm64/boot/dts/microchip/Makefile | 1 +
.../boot/dts/microchip/lan9696-ev23x71a.dts | 756 ++++++++++++++++++
2 files changed, 757 insertions(+)
create mode 100644 arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts
diff --git a/arch/arm64/boot/dts/microchip/Makefile b/arch/arm64/boot/dts/microchip/Makefile
index c6e0313eea0f..09d16fc1ce9a 100644
--- a/arch/arm64/boot/dts/microchip/Makefile
+++ b/arch/arm64/boot/dts/microchip/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_LAN969X) += lan9696-ev23x71a.dtb
dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb125.dtb
dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb134.dtb sparx5_pcb134_emmc.dtb
dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb135.dtb sparx5_pcb135_emmc.dtb
diff --git a/arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts b/arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts
new file mode 100644
index 000000000000..4012ea7d07bb
--- /dev/null
+++ b/arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts
@@ -0,0 +1,756 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2025 Microchip Technology Inc. and its subsidiaries.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include "lan9691.dtsi"
+
+/ {
+ model = "Microchip EV23X71A";
+ compatible = "microchip,ev23x71a", "microchip,lan9696", "microchip,lan9691";
+
+ aliases {
+ serial0 = &usart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ gpio-restart {
+ compatible = "gpio-restart";
+ gpios = <&gpio 60 GPIO_ACTIVE_LOW>;
+ open-source;
+ priority = <200>;
+ };
+
+ i2c-mux {
+ compatible = "i2c-mux-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-parent = <&i2c3>;
+ idle-state = <0x8>;
+ mux-gpios = <&sgpio_out 0 1 GPIO_ACTIVE_HIGH>,
+ <&sgpio_out 0 2 GPIO_ACTIVE_HIGH>,
+ <&sgpio_out 0 3 GPIO_ACTIVE_HIGH>;
+ settle-time-us = <100>;
+
+ i2c_sfp0: i2c@0 {
+ reg = <0x0>;
+ };
+
+ i2c_sfp1: i2c@1 {
+ reg = <0x1>;
+ };
+
+ i2c_sfp2: i2c@2 {
+ reg = <0x2>;
+ };
+
+ i2c_sfp3: i2c@3 {
+ reg = <0x3>;
+ };
+
+ i2c_poe: i2c@7 {
+ reg = <0x7>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-status {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio 61 GPIO_ACTIVE_LOW>;
+ };
+
+ led-sfp1-green {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ gpios = <&sgpio_out 6 0 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led-sfp1-yellow {
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ gpios = <&sgpio_out 6 1 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led-sfp2-green {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <1>;
+ gpios = <&sgpio_out 7 0 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led-sfp2-yellow {
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <1>;
+ gpios = <&sgpio_out 7 1 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led-sfp3-green {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <2>;
+ gpios = <&sgpio_out 8 0 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led-sfp3-yellow {
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <2>;
+ gpios = <&sgpio_out 8 1 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led-sfp4-green {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <3>;
+ gpios = <&sgpio_out 9 0 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led-sfp4-yellow {
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <3>;
+ gpios = <&sgpio_out 9 1 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ };
+
+ mux-controller {
+ compatible = "gpio-mux";
+ #mux-control-cells = <0>;
+ mux-gpios = <&sgpio_out 1 2 GPIO_ACTIVE_LOW>,
+ <&sgpio_out 1 3 GPIO_ACTIVE_LOW>;
+ };
+
+ sfp0: sfp0 {
+ compatible = "sff,sfp";
+ i2c-bus = <&i2c_sfp0>;
+ tx-disable-gpios = <&sgpio_out 6 2 GPIO_ACTIVE_HIGH>;
+ los-gpios = <&sgpio_in 6 0 GPIO_ACTIVE_HIGH>;
+ mod-def0-gpios = <&sgpio_in 6 1 GPIO_ACTIVE_LOW>;
+ tx-fault-gpios = <&sgpio_in 6 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ sfp1: sfp1 {
+ compatible = "sff,sfp";
+ i2c-bus = <&i2c_sfp1>;
+ tx-disable-gpios = <&sgpio_out 7 2 GPIO_ACTIVE_HIGH>;
+ los-gpios = <&sgpio_in 7 0 GPIO_ACTIVE_HIGH>;
+ mod-def0-gpios = <&sgpio_in 7 1 GPIO_ACTIVE_LOW>;
+ tx-fault-gpios = <&sgpio_in 7 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ sfp2: sfp2 {
+ compatible = "sff,sfp";
+ i2c-bus = <&i2c_sfp2>;
+ tx-disable-gpios = <&sgpio_out 8 2 GPIO_ACTIVE_HIGH>;
+ los-gpios = <&sgpio_in 8 0 GPIO_ACTIVE_HIGH>;
+ mod-def0-gpios = <&sgpio_in 8 1 GPIO_ACTIVE_LOW>;
+ tx-fault-gpios = <&sgpio_in 8 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ sfp3: sfp3 {
+ compatible = "sff,sfp";
+ i2c-bus = <&i2c_sfp3>;
+ tx-disable-gpios = <&sgpio_out 9 2 GPIO_ACTIVE_HIGH>;
+ los-gpios = <&sgpio_in 9 0 GPIO_ACTIVE_HIGH>;
+ mod-def0-gpios = <&sgpio_in 9 1 GPIO_ACTIVE_LOW>;
+ tx-fault-gpios = <&sgpio_in 9 2 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+&gpio {
+ emmc_sd_pins: emmc-sd-pins {
+ /* eMMC_SD - CMD, CLK, D0, D1, D2, D3, D4, D5, D6, D7, RSTN */
+ pins = "GPIO_14", "GPIO_15", "GPIO_16", "GPIO_17",
+ "GPIO_18", "GPIO_19", "GPIO_20", "GPIO_21",
+ "GPIO_22", "GPIO_23", "GPIO_24";
+ function = "emmc_sd";
+ };
+
+ fan_pins: fan-pins {
+ pins = "GPIO_25", "GPIO_26";
+ function = "fan";
+ };
+
+ fc0_pins: fc0-pins {
+ pins = "GPIO_3", "GPIO_4";
+ function = "fc";
+ };
+
+ fc2_pins: fc2-pins {
+ pins = "GPIO_64", "GPIO_65", "GPIO_66";
+ function = "fc";
+ };
+
+ fc3_pins: fc3-pins {
+ pins = "GPIO_55", "GPIO_56";
+ function = "fc";
+ };
+
+ mdio_irq_pins: mdio-irq-pins {
+ pins = "GPIO_11";
+ function = "miim_irq";
+ };
+
+ mdio_pins: mdio-pins {
+ pins = "GPIO_9", "GPIO_10";
+ function = "miim";
+ };
+
+ ptp_ext_pins: ptp-ext-pins {
+ pins = "GPIO_59";
+ function = "ptpsync_5";
+ };
+
+ ptp_out_pins: ptp-out-pins {
+ pins = "GPIO_58";
+ function = "ptpsync_4";
+ };
+
+ sgpio_pins: sgpio-pins {
+ /* SCK, D0, D1, LD */
+ pins = "GPIO_5", "GPIO_6", "GPIO_7", "GPIO_8";
+ function = "sgpio_a";
+ };
+
+ usb_over_pins: usb-over-pins {
+ pins = "GPIO_13";
+ function = "usb_over_detect";
+ };
+
+ usb_power_pins: usb-power-pins {
+ pins = "GPIO_1";
+ function = "usb_power";
+ };
+
+ usb_rst_pins: usb-rst-pins {
+ pins = "GPIO_12";
+ function = "usb2phy_rst";
+ };
+
+ usb_ulpi_pins: usb-ulpi-pins {
+ pins = "GPIO_30", "GPIO_31", "GPIO_32", "GPIO_33",
+ "GPIO_34", "GPIO_35", "GPIO_36", "GPIO_37",
+ "GPIO_38", "GPIO_39", "GPIO_40", "GPIO_41";
+ function = "usb_ulpi";
+ };
+};
+
+&flx0 {
+ atmel,flexcom-mode = <ATMEL_FLEXCOM_MODE_USART>;
+ status = "okay";
+};
+
+&flx2 {
+ atmel,flexcom-mode = <ATMEL_FLEXCOM_MODE_SPI>;
+ status = "okay";
+};
+
+&flx3 {
+ atmel,flexcom-mode = <ATMEL_FLEXCOM_MODE_TWI>;
+ status = "okay";
+};
+
+&i2c3 {
+ pinctrl-0 = <&fc3_pins>;
+ pinctrl-names = "default";
+ i2c-analog-filter;
+ i2c-digital-filter;
+ i2c-digital-filter-width-ns = <35>;
+ i2c-sda-hold-time-ns = <1500>;
+ status = "okay";
+};
+
+&mdio0 {
+ pinctrl-0 = <&mdio_pins>, <&mdio_irq_pins>;
+ pinctrl-names = "default";
+ reset-gpios = <&gpio 62 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ phy3: phy@3 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <3>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy4: phy@4 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <4>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy5: phy@5 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <5>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy6: phy@6 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <6>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy7: phy@7 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <7>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy8: phy@8 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <8>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy9: phy@9 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <9>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy10: phy@10 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <10>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy11: phy@11 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <11>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy12: phy@12 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <12>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy13: phy@13 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <13>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy14: phy@14 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <14>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy15: phy@15 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <15>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy16: phy@16 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <16>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy17: phy@17 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <17>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy18: phy@18 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <18>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy19: phy@19 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <19>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy20: phy@20 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <20>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy21: phy@21 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <21>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy22: phy@22 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <22>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy23: phy@23 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <23>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy24: phy@24 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <24>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy25: phy@25 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <25>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy26: phy@26 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <26>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+
+ phy27: phy@27 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <27>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ };
+};
+
+&serdes {
+ status = "okay";
+};
+
+&sgpio {
+ pinctrl-0 = <&sgpio_pins>;
+ pinctrl-names = "default";
+ microchip,sgpio-port-ranges = <0 1>, <6 9>;
+ status = "okay";
+
+ gpio@0 {
+ ngpios = <128>;
+ };
+ gpio@1 {
+ ngpios = <128>;
+ };
+};
+
+&spi2 {
+ pinctrl-0 = <&fc2_pins>;
+ pinctrl-names = "default";
+ cs-gpios = <&gpio 63 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&switch {
+ pinctrl-0 = <&ptp_out_pins>, <&ptp_ext_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port0: port@0 {
+ reg = <0>;
+ phy-handle = <&phy4>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 0>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port1: port@1 {
+ reg = <1>;
+ phy-handle = <&phy5>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 0>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port2: port@2 {
+ reg = <2>;
+ phy-handle = <&phy6>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 0>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port3: port@3 {
+ reg = <3>;
+ phy-handle = <&phy7>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 0>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port4: port@4 {
+ reg = <4>;
+ phy-handle = <&phy8>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 1>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port5: port@5 {
+ reg = <5>;
+ phy-handle = <&phy9>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 1>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port6: port@6 {
+ reg = <6>;
+ phy-handle = <&phy10>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 1>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port7: port@7 {
+ reg = <7>;
+ phy-handle = <&phy11>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 1>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port8: port@8 {
+ reg = <8>;
+ phy-handle = <&phy12>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 2>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port9: port@9 {
+ reg = <9>;
+ phy-handle = <&phy13>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 2>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port10: port@10 {
+ reg = <10>;
+ phy-handle = <&phy14>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 2>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port11: port@11 {
+ reg = <11>;
+ phy-handle = <&phy15>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 2>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port12: port@12 {
+ reg = <12>;
+ phy-handle = <&phy16>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 3>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port13: port@13 {
+ reg = <13>;
+ phy-handle = <&phy17>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 3>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port14: port@14 {
+ reg = <14>;
+ phy-handle = <&phy18>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 3>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port15: port@15 {
+ reg = <15>;
+ phy-handle = <&phy19>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 3>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port16: port@16 {
+ reg = <16>;
+ phy-handle = <&phy20>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 4>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port17: port@17 {
+ reg = <17>;
+ phy-handle = <&phy21>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 4>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port18: port@18 {
+ reg = <18>;
+ phy-handle = <&phy22>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 4>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port19: port@19 {
+ reg = <19>;
+ phy-handle = <&phy23>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 4>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port20: port@20 {
+ reg = <20>;
+ phy-handle = <&phy24>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 5>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port21: port@21 {
+ reg = <21>;
+ phy-handle = <&phy25>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 5>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port22: port@22 {
+ reg = <22>;
+ phy-handle = <&phy26>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 5>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port23: port@23 {
+ reg = <23>;
+ phy-handle = <&phy27>;
+ phy-mode = "qsgmii";
+ phys = <&serdes 5>;
+ microchip,bandwidth = <1000>;
+ };
+
+ port24: port@24 {
+ reg = <24>;
+ phys = <&serdes 6>;
+ phy-mode = "10gbase-r";
+ sfp = <&sfp0>;
+ managed = "in-band-status";
+ microchip,bandwidth = <10000>;
+ microchip,sd-sgpio = <24>;
+ };
+
+ port25: port@25 {
+ reg = <25>;
+ phys = <&serdes 7>;
+ phy-mode = "10gbase-r";
+ sfp = <&sfp1>;
+ managed = "in-band-status";
+ microchip,bandwidth = <10000>;
+ microchip,sd-sgpio = <28>;
+ };
+
+ port26: port@26 {
+ reg = <26>;
+ phys = <&serdes 8>;
+ phy-mode = "10gbase-r";
+ sfp = <&sfp2>;
+ managed = "in-band-status";
+ microchip,bandwidth = <10000>;
+ microchip,sd-sgpio = <32>;
+ };
+
+ port27: port@27 {
+ reg = <27>;
+ phys = <&serdes 9>;
+ phy-mode = "10gbase-r";
+ sfp = <&sfp3>;
+ managed = "in-band-status";
+ microchip,bandwidth = <10000>;
+ microchip,sd-sgpio = <36>;
+ };
+
+ port29: port@29 {
+ reg = <29>;
+ phy-handle = <&phy3>;
+ phy-mode = "rgmii-id";
+ microchip,bandwidth = <1000>;
+ };
+ };
+};
+
+&tmon {
+ pinctrl-0 = <&fan_pins>;
+ pinctrl-names = "default";
+};
+
+&usart0 {
+ pinctrl-0 = <&fc0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usb {
+ pinctrl-0 = <&usb_ulpi_pins>, <&usb_rst_pins>, <&usb_over_pins>, <&usb_power_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
--
2.52.0
^ permalink raw reply related
* [PATCH v5 10/11] dt-bindings: net: sparx5: do not require phys when RGMII is used
From: Robert Marko @ 2026-01-15 11:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver,
linusw, olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial
Cc: luka.perkov, Robert Marko
In-Reply-To: <20260115114021.111324-1-robert.marko@sartura.hr>
LAN969x has 2 dedicated RGMII ports, so regular SERDES lanes are not used
for RGMII.
So, lets not require phys to be defined when any of the rgmii phy-modes are
set.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
.../bindings/net/microchip,sparx5-switch.yaml | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
index 5491d0775ede..75c7c8d1f411 100644
--- a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
+++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
@@ -151,10 +151,23 @@ properties:
required:
- reg
- - phys
- phy-mode
- microchip,bandwidth
+ if:
+ not:
+ properties:
+ phy-mode:
+ contains:
+ enum:
+ - rgmii
+ - rgmii-id
+ - rgmii-rxid
+ - rgmii-txid
+ then:
+ required:
+ - phys
+
oneOf:
- required:
- phy-handle
--
2.52.0
^ permalink raw reply related
* [PATCH v5 09/11] dt-bindings: arm: AT91: document EV23X71A board
From: Robert Marko @ 2026-01-15 11:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver,
linusw, olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial
Cc: luka.perkov, Robert Marko, Conor Dooley
In-Reply-To: <20260115114021.111324-1-robert.marko@sartura.hr>
Microchip EV23X71A board is an LAN9696 based evaluation board.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
---
Changes in v5:
* Pick Acked-by from Conor
* Pick Reviewed-by from Claudiu
Documentation/devicetree/bindings/arm/atmel-at91.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
index 68d306d17c2a..bf161e0950ea 100644
--- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
@@ -243,6 +243,12 @@ properties:
- const: microchip,lan9668
- const: microchip,lan966
+ - description: Microchip LAN9696 EV23X71A Evaluation Board
+ items:
+ - const: microchip,ev23x71a
+ - const: microchip,lan9696
+ - const: microchip,lan9691
+
- description: Kontron KSwitch D10 MMT series
items:
- enum:
--
2.52.0
^ permalink raw reply related
* [PATCH v5 08/11] arm64: dts: microchip: add LAN969x support
From: Robert Marko @ 2026-01-15 11:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver,
linusw, olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial
Cc: luka.perkov, Robert Marko
In-Reply-To: <20260115114021.111324-1-robert.marko@sartura.hr>
Add support for Microchip LAN969x switch SoC series by adding the SoC DTSI.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
---
Changes in v5:
* Pick Reviewed-by from Claudiu
Changes in v4:
* Adapt to clock indexes now being in a DTS header only
Changes in v2:
* Rename to lan9691
* Split SoC DTSI and evaluation board commits
* Use SoC specific compatibles for devices
* Alphanumerically sort remaining nodes
* Apply DTS coding style
arch/arm64/boot/dts/microchip/lan9691.dtsi | 488 +++++++++++++++++++++
1 file changed, 488 insertions(+)
create mode 100644 arch/arm64/boot/dts/microchip/lan9691.dtsi
diff --git a/arch/arm64/boot/dts/microchip/lan9691.dtsi b/arch/arm64/boot/dts/microchip/lan9691.dtsi
new file mode 100644
index 000000000000..235e56bebbdb
--- /dev/null
+++ b/arch/arm64/boot/dts/microchip/lan9691.dtsi
@@ -0,0 +1,488 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2025 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include <dt-bindings/dma/at91.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/mfd/at91-usart.h>
+#include <dt-bindings/mfd/atmel-flexcom.h>
+
+#include "clk-lan9691.h"
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ model = "Microchip LAN969x";
+ compatible = "microchip,lan9691";
+ interrupt-parent = <&gic>;
+
+ clocks {
+ fx100_clk: fx100-clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <320000000>;
+ };
+
+ cpu_clk: cpu-clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1000000000>;
+ };
+
+ ddr_clk: ddr-clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <600000000>;
+ };
+
+ fabric_clk: fabric-clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <250000000>;
+ };
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x0 0x0>;
+ next-level-cache = <&l2_0>;
+ };
+
+ l2_0: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-unified;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* Secure Phys IRQ */
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* Non-secure Phys IRQ */
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* Virt IRQ */
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* Hyp IRQ */
+ };
+
+ axi: axi {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ usb: usb@300000 {
+ compatible = "microchip,lan9691-dwc3", "snps,dwc3";
+ reg = <0x300000 0x80000>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks GCK_GATE_USB_DRD>,
+ <&clks GCK_ID_USB_REFCLK>;
+ clock-names = "bus_early", "ref";
+ assigned-clocks = <&clks GCK_ID_USB_REFCLK>;
+ assigned-clock-rates = <60000000>;
+ maximum-speed = "high-speed";
+ dr_mode = "host";
+ status = "disabled";
+ };
+
+ flx0: flexcom@e0040000 {
+ compatible = "microchip,lan9691-flexcom", "atmel,sama5d2-flexcom";
+ reg = <0xe0040000 0x100>;
+ ranges = <0x0 0xe0040000 0x800>;
+ clocks = <&clks GCK_ID_FLEXCOM0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "disabled";
+
+ usart0: serial@200 {
+ compatible = "microchip,lan9691-usart", "atmel,at91sam9260-usart";
+ reg = <0x200 0x200>;
+ interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma AT91_XDMAC_DT_PERID(3)>,
+ <&dma AT91_XDMAC_DT_PERID(2)>;
+ dma-names = "tx", "rx";
+ clocks = <&fabric_clk>;
+ clock-names = "usart";
+ atmel,fifo-size = <32>;
+ atmel,usart-mode = <AT91_USART_MODE_SERIAL>;
+ status = "disabled";
+ };
+
+ spi0: spi@400 {
+ compatible = "microchip,lan9691-spi", "atmel,at91rm9200-spi";
+ reg = <0x400 0x200>;
+ interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma AT91_XDMAC_DT_PERID(3)>,
+ <&dma AT91_XDMAC_DT_PERID(2)>;
+ dma-names = "tx", "rx";
+ clocks = <&fabric_clk>;
+ clock-names = "spi_clk";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ atmel,fifo-size = <32>;
+ status = "disabled";
+ };
+
+ i2c0: i2c@600 {
+ compatible = "microchip,lan9691-i2c", "microchip,sam9x60-i2c";
+ reg = <0x600 0x200>;
+ interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma AT91_XDMAC_DT_PERID(3)>,
+ <&dma AT91_XDMAC_DT_PERID(2)>;
+ dma-names = "tx", "rx";
+ clocks = <&fabric_clk>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+ };
+
+ flx1: flexcom@e0044000 {
+ compatible = "microchip,lan9691-flexcom", "atmel,sama5d2-flexcom";
+ reg = <0xe0044000 0x100>;
+ ranges = <0x0 0xe0044000 0x800>;
+ clocks = <&clks GCK_ID_FLEXCOM1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "disabled";
+
+ usart1: serial@200 {
+ compatible = "microchip,lan9691-usart", "atmel,at91sam9260-usart";
+ reg = <0x200 0x200>;
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma AT91_XDMAC_DT_PERID(3)>,
+ <&dma AT91_XDMAC_DT_PERID(2)>;
+ dma-names = "tx", "rx";
+ clocks = <&fabric_clk>;
+ clock-names = "usart";
+ atmel,fifo-size = <32>;
+ atmel,usart-mode = <AT91_USART_MODE_SERIAL>;
+ status = "disabled";
+ };
+
+ spi1: spi@400 {
+ compatible = "microchip,lan9691-spi", "atmel,at91rm9200-spi";
+ reg = <0x400 0x200>;
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma AT91_XDMAC_DT_PERID(3)>,
+ <&dma AT91_XDMAC_DT_PERID(2)>;
+ dma-names = "tx", "rx";
+ clocks = <&fabric_clk>;
+ clock-names = "spi_clk";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ atmel,fifo-size = <32>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@600 {
+ compatible = "microchip,lan9691-i2c", "microchip,sam9x60-i2c";
+ reg = <0x600 0x200>;
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma AT91_XDMAC_DT_PERID(3)>,
+ <&dma AT91_XDMAC_DT_PERID(2)>;
+ dma-names = "tx", "rx";
+ clocks = <&fabric_clk>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+ };
+
+ trng: rng@e0048000 {
+ compatible = "microchip,lan9691-trng", "atmel,at91sam9g45-trng";
+ reg = <0xe0048000 0x100>;
+ clocks = <&fabric_clk>;
+ status = "disabled";
+ };
+
+ aes: crypto@e004c000 {
+ compatible = "microchip,lan9691-aes", "atmel,at91sam9g46-aes";
+ reg = <0xe004c000 0x100>;
+ interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma AT91_XDMAC_DT_PERID(12)>,
+ <&dma AT91_XDMAC_DT_PERID(13)>;
+ dma-names = "tx", "rx";
+ clocks = <&fabric_clk>;
+ clock-names = "aes_clk";
+ status = "disabled";
+ };
+
+ flx2: flexcom@e0060000 {
+ compatible = "microchip,lan9691-flexcom", "atmel,sama5d2-flexcom";
+ reg = <0xe0060000 0x100>;
+ ranges = <0x0 0xe0060000 0x800>;
+ clocks = <&clks GCK_ID_FLEXCOM2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "disabled";
+
+ usart2: serial@200 {
+ compatible = "microchip,lan9691-usart", "atmel,at91sam9260-usart";
+ reg = <0x200 0x200>;
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma AT91_XDMAC_DT_PERID(7)>,
+ <&dma AT91_XDMAC_DT_PERID(6)>;
+ dma-names = "tx", "rx";
+ clocks = <&fabric_clk>;
+ clock-names = "usart";
+ atmel,fifo-size = <32>;
+ atmel,usart-mode = <AT91_USART_MODE_SERIAL>;
+ status = "disabled";
+ };
+
+ spi2: spi@400 {
+ compatible = "microchip,lan9691-spi", "atmel,at91rm9200-spi";
+ reg = <0x400 0x200>;
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma AT91_XDMAC_DT_PERID(7)>,
+ <&dma AT91_XDMAC_DT_PERID(6)>;
+ dma-names = "tx", "rx";
+ clocks = <&fabric_clk>;
+ clock-names = "spi_clk";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ atmel,fifo-size = <32>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@600 {
+ compatible = "microchip,lan9691-i2c", "microchip,sam9x60-i2c";
+ reg = <0x600 0x200>;
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma AT91_XDMAC_DT_PERID(7)>,
+ <&dma AT91_XDMAC_DT_PERID(6)>;
+ dma-names = "tx", "rx";
+ clocks = <&fabric_clk>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+ };
+
+ flx3: flexcom@e0064000 {
+ compatible = "microchip,lan9691-flexcom", "atmel,sama5d2-flexcom";
+ reg = <0xe0064000 0x100>;
+ ranges = <0x0 0xe0064000 0x800>;
+ clocks = <&clks GCK_ID_FLEXCOM3>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "disabled";
+
+ usart3: serial@200 {
+ compatible = "microchip,lan9691-usart", "atmel,at91sam9260-usart";
+ reg = <0x200 0x200>;
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma AT91_XDMAC_DT_PERID(9)>,
+ <&dma AT91_XDMAC_DT_PERID(8)>;
+ dma-names = "tx", "rx";
+ clocks = <&fabric_clk>;
+ clock-names = "usart";
+ atmel,fifo-size = <32>;
+ atmel,usart-mode = <AT91_USART_MODE_SERIAL>;
+ status = "disabled";
+ };
+
+ spi3: spi@400 {
+ compatible = "microchip,lan9691-spi", "atmel,at91rm9200-spi";
+ reg = <0x400 0x200>;
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma AT91_XDMAC_DT_PERID(9)>,
+ <&dma AT91_XDMAC_DT_PERID(8)>;
+ dma-names = "tx", "rx";
+ clocks = <&fabric_clk>;
+ clock-names = "spi_clk";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ atmel,fifo-size = <32>;
+ status = "disabled";
+ };
+
+ i2c3: i2c@600 {
+ compatible = "microchip,lan9691-i2c", "microchip,sam9x60-i2c";
+ reg = <0x600 0x200>;
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma AT91_XDMAC_DT_PERID(9)>,
+ <&dma AT91_XDMAC_DT_PERID(8)>;
+ dma-names = "tx", "rx";
+ clocks = <&fabric_clk>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+ };
+
+ dma: dma-controller@e0068000 {
+ compatible = "microchip,lan9691-dma", "microchip,sama7g5-dma";
+ reg = <0xe0068000 0x1000>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ dma-channels = <16>;
+ #dma-cells = <1>;
+ clocks = <&fabric_clk>;
+ clock-names = "dma_clk";
+ };
+
+ sha: crypto@e006c000 {
+ compatible = "microchip,lan9691-sha", "atmel,at91sam9g46-sha";
+ reg = <0xe006c000 0xec>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma AT91_XDMAC_DT_PERID(14)>;
+ dma-names = "tx";
+ clocks = <&fabric_clk>;
+ clock-names = "sha_clk";
+ status = "disabled";
+ };
+
+ timer: timer@e008c000 {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xe008c000 0x400>;
+ clocks = <&fabric_clk>;
+ clock-names = "timer";
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ watchdog: watchdog@e0090000 {
+ compatible = "snps,dw-wdt";
+ reg = <0xe0090000 0x1000>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&fabric_clk>;
+ };
+
+ cpu_ctrl: syscon@e00c0000 {
+ compatible = "microchip,lan966x-cpu-syscon", "syscon";
+ reg = <0xe00c0000 0x350>;
+ };
+
+ switch: switch@e00c0000 {
+ compatible = "microchip,lan9691-switch";
+ reg = <0xe00c0000 0x0010000>,
+ <0xe2010000 0x1410000>;
+ reg-names = "cpu", "devices";
+ interrupt-names = "xtr", "fdma", "ptp";
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&reset 0>;
+ reset-names = "switch";
+ status = "disabled";
+ };
+
+ clks: clock-controller@e00c00b4 {
+ compatible = "microchip,lan9691-gck";
+ reg = <0xe00c00b4 0x30>, <0xe00c0308 0x4>;
+ #clock-cells = <1>;
+ clocks = <&cpu_clk>, <&ddr_clk>, <&fx100_clk>;
+ clock-names = "cpu", "ddr", "sys";
+ };
+
+ reset: reset-controller@e201000c {
+ compatible = "microchip,lan9691-switch-reset",
+ "microchip,lan966x-switch-reset";
+ reg = <0xe201000c 0x4>;
+ reg-names = "gcb";
+ #reset-cells = <1>;
+ cpu-syscon = <&cpu_ctrl>;
+ };
+
+ gpio: pinctrl@e20100d4 {
+ compatible = "microchip,lan9691-pinctrl";
+ reg = <0xe20100d4 0xd4>,
+ <0xe2010370 0xa8>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&gpio 0 0 66>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <2>;
+ };
+
+ mdio0: mdio@e20101a8 {
+ compatible = "microchip,lan9691-miim", "mscc,ocelot-miim";
+ reg = <0xe20101a8 0x24>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&fx100_clk>;
+ status = "disabled";
+ };
+
+ mdio1: mdio@e20101cc {
+ compatible = "microchip,lan9691-miim", "mscc,ocelot-miim";
+ reg = <0xe20101cc 0x24>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&fx100_clk>;
+ status = "disabled";
+ };
+
+ sgpio: gpio@e2010230 {
+ compatible = "microchip,lan9691-sgpio", "microchip,sparx5-sgpio";
+ reg = <0xe2010230 0x118>;
+ clocks = <&fx100_clk>;
+ resets = <&reset 0>;
+ reset-names = "switch";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ sgpio_in: gpio@0 {
+ compatible = "microchip,lan9691-sgpio-bank",
+ "microchip,sparx5-sgpio-bank";
+ reg = <0>;
+ gpio-controller;
+ #gpio-cells = <3>;
+ interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
+
+ sgpio_out: gpio@1 {
+ compatible = "microchip,lan9691-sgpio-bank",
+ "microchip,sparx5-sgpio-bank";
+ reg = <1>;
+ gpio-controller;
+ #gpio-cells = <3>;
+ };
+ };
+
+ tmon: hwmon@e2020100 {
+ compatible = "microchip,lan9691-temp", "microchip,sparx5-temp";
+ reg = <0xe2020100 0xc>;
+ clocks = <&fx100_clk>;
+ #thermal-sensor-cells = <0>;
+ };
+
+ serdes: serdes@e3410000 {
+ compatible = "microchip,lan9691-serdes";
+ reg = <0xe3410000 0x150000>;
+ #phy-cells = <1>;
+ clocks = <&fabric_clk>;
+ };
+
+ gic: interrupt-controller@e8c11000 {
+ compatible = "arm,gic-400";
+ reg = <0xe8c11000 0x1000>, /* Distributor GICD_ */
+ <0xe8c12000 0x2000>, /* CPU interface GICC_ */
+ <0xe8c14000 0x2000>, /* Virt interface control */
+ <0xe8c16000 0x2000>; /* Virt CPU interface */
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+};
--
2.52.0
^ permalink raw reply related
* [PATCH v5 07/11] arm64: dts: microchip: add LAN969x clock header file
From: Robert Marko @ 2026-01-15 11:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver,
linusw, olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial
Cc: luka.perkov, Robert Marko
In-Reply-To: <20260115114021.111324-1-robert.marko@sartura.hr>
LAN969x uses hardware clock indexes, so document theses in a header to make
them humanly readable.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v5:
* Relicense to GPL-2.0-or-later OR MIT to match DTSI
arch/arm64/boot/dts/microchip/clk-lan9691.h | 24 +++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 arch/arm64/boot/dts/microchip/clk-lan9691.h
diff --git a/arch/arm64/boot/dts/microchip/clk-lan9691.h b/arch/arm64/boot/dts/microchip/clk-lan9691.h
new file mode 100644
index 000000000000..0f2d7a0f881e
--- /dev/null
+++ b/arch/arm64/boot/dts/microchip/clk-lan9691.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: (GPL-2.0-or-later OR MIT) */
+
+#ifndef _DTS_CLK_LAN9691_H
+#define _DTS_CLK_LAN9691_H
+
+#define GCK_ID_QSPI0 0
+#define GCK_ID_QSPI2 1
+#define GCK_ID_SDMMC0 2
+#define GCK_ID_SDMMC1 3
+#define GCK_ID_MCAN0 4
+#define GCK_ID_MCAN1 5
+#define GCK_ID_FLEXCOM0 6
+#define GCK_ID_FLEXCOM1 7
+#define GCK_ID_FLEXCOM2 8
+#define GCK_ID_FLEXCOM3 9
+#define GCK_ID_TIMER 10
+#define GCK_ID_USB_REFCLK 11
+
+/* Gate clocks */
+#define GCK_GATE_USB_DRD 12
+#define GCK_GATE_MCRAMC 13
+#define GCK_GATE_HMATRIX 14
+
+#endif
--
2.52.0
^ permalink raw reply related
* [PATCH v5 06/11] dt-bindings: pinctrl: pinctrl-microchip-sgpio: add LAN969x
From: Robert Marko @ 2026-01-15 11:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver,
linusw, olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial
Cc: luka.perkov, Robert Marko, Conor Dooley
In-Reply-To: <20260115114021.111324-1-robert.marko@sartura.hr>
Document LAN969x compatibles for SGPIO.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
---
Changes in v5:
* Pick Reviewed-by from Claudiu
Changes in v3:
* Pick Acked-by from Conor
.../pinctrl/microchip,sparx5-sgpio.yaml | 20 ++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml b/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml
index fa47732d7cef..9fbbafcdc063 100644
--- a/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml
@@ -21,10 +21,15 @@ properties:
pattern: '^gpio@[0-9a-f]+$'
compatible:
- enum:
- - microchip,sparx5-sgpio
- - mscc,ocelot-sgpio
- - mscc,luton-sgpio
+ oneOf:
+ - enum:
+ - microchip,sparx5-sgpio
+ - mscc,ocelot-sgpio
+ - mscc,luton-sgpio
+ - items:
+ - enum:
+ - microchip,lan9691-sgpio
+ - const: microchip,sparx5-sgpio
'#address-cells':
const: 1
@@ -80,7 +85,12 @@ patternProperties:
type: object
properties:
compatible:
- const: microchip,sparx5-sgpio-bank
+ oneOf:
+ - items:
+ - enum:
+ - microchip,lan9691-sgpio-bank
+ - const: microchip,sparx5-sgpio-bank
+ - const: microchip,sparx5-sgpio-bank
reg:
description: |
--
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