* Re: [PATCH v4 0/9] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Hans de Goede @ 2026-01-15 10:30 UTC (permalink / raw)
To: manivannan.sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Ilpo Järvinen,
Mark Pearson, Derek J. Clark, Manivannan Sadhasivam,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski
Cc: 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,
Bartosz Golaszewski
In-Reply-To: <20260112-pci-m2-e-v4-0-eff84d2c6d26@oss.qualcomm.com>
Hi Mani,
On 12-Jan-26 17:25, Manivannan Sadhasivam via B4 Relay wrote:
> Hi,
>
> This series is the continuation of the series [1] that added the initial support
> for the PCIe M.2 connectors. This series extends it by adding support for Key E
> connectors. These connectors are used to connect the Wireless Connectivity
> devices such as WiFi, BT, NFC and GNSS devices to the host machine over
> interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
> connectors that expose PCIe interface for WiFi and UART interface for BT. Other
> interfaces are left for future improvements.
Thank you for your work on this.
I've tested this on a ThinkPad T14s gen 6 together with your DTS changes
for the T14s.
I started out with CONFIG_POWER_SEQUENCING_PCIE_M2=m and that does not work.
I think it might be easiest to just change that option to a boolean option.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Regards,
Hans
> Serdev device support for BT
> ============================
>
> Adding support for the PCIe interface was mostly straightforward and a lot
> similar to the previous Key M connector. But adding UART interface has proved to
> be tricky. This is mostly because of the fact UART is a non-discoverable bus,
> unlike PCIe which is discoverable. So this series relied on the PCI notifier to
> create the serdev device for UART/BT. This means the PCIe interface will be
> brought up first and after the PCIe device enumeration, the serdev device will
> be created by the pwrseq driver. This logic is necessary since the connector
> driver and DT node don't describe the device, but just the connector. So to make
> the connector interface Plug and Play, the connector driver uses the PCIe device
> ID to identify the card and creates the serdev device. This logic could be
> extended in the future to support more M.2 cards. Even if the M.2 card uses SDIO
> interface for connecting WLAN, a SDIO notifier could be added to create the
> serdev device.
>
> Open questions
> ==============
>
> Though this series adds the relevant functionality for handling the M.2 Key M
> connectors, there are still a few open questions exists on the design.
>
> 1. Created a dynamic 'bluetooth' node with the compatible property matching the
> WCN7850 device and attached it to the serdev device. This allowed reusing the
> existing OF based BT driver without much modifications.
>
> 2. PCIe client drivers of some M.2 WLAN cards like the Qcom QCA6390, rely on
> the PCIe device DT node to extract properties such as
> 'qcom,calibration-variant', 'firmware-name', etc... For those drivers, should we
> add the PCIe DT node in the Root Port in conjunction with the Port node as
> below?
>
> pcie@0 {
> wifi@0 {
> compatible = "pci17cb,1103";
> ...
> qcom,calibration-variant = "LE_X13S";
> };
>
> port {
> pcie4_port0_ep: endpoint {
> remote-endpoint = <&m2_e_pcie_ep>;
> };
> };
> };
>
> This will also require marking the PMU supplies optional in the relevant ath
> bindings for M.2 cards.
>
> 3. Some M.2 cards require specific power up sequence like delays between
> regulator/GPIO and such. For instance, the WCN7850 card supported in this series
> requires 50ms delay between powering up an interface and driving it. I've just
> hardcoded the delay in the driver, but it is a pure hack. Since the pwrseq
> driver doesn't know anything about the device it is dealing with before powering
> it ON, how should it handle the device specific power requirements? Should we
> hardcode the device specific property in the connector node? But then, it will
> no longer become a generic M.2 connector and sort of defeats the purpose of the
> connector binding.
>
> I hope to address these questions with the help of the relevant subsystem
> maintainers and the community.
>
> Testing
> =======
>
> This series, together with the devicetree changes [2] was tested on the
> Qualcomm X1e based Lenovo Thinkpad T14s Laptop which has the WCN7850 WLAN/BT
> 1620 LGA card connected over PCIe and UART.
>
> Dependency
> ==========
>
> This series is dependent on the M.2 Key M series [1] on top of v6.19-rc1.
>
> [1] https://lore.kernel.org/linux-pci/20260107-pci-m2-v5-0-8173d8a72641@oss.qualcomm.com
> [2] https://github.com/Mani-Sadhasivam/linux/commit/753033861360171f2af1fdd56e8985ff916e1ac2
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
> Changes in v4:
> - Switched to dynamic OF node for serdev instead of swnode and dropped all
> swnode related patches
> - Link to v3: https://lore.kernel.org/r/20260110-pci-m2-e-v3-0-4faee7d0d5ae@oss.qualcomm.com
>
> Changes in v3:
> - Switched to swnode for the serdev device and dropped the custom
> serdev_device_id related patches
> - Added new swnode APIs to match the swnode with existing of_device_id
> - Incorporated comments in the bindings patch
> - Dropped the UIM interface from binding since it is not clear how it should get
> wired
> - Incorporated comments in the pwrseq driver patch
> - Splitted the pwrseq patch into two
> - Added the 1620 LGA compatible with Key E fallback based on Stephan's finding
> - Link to v2: https://lore.kernel.org/r/20251125-pci-m2-e-v2-0-32826de07cc5@oss.qualcomm.com
>
> Changes in v2:
> - Used '-' for GPIO names in the binding and removed led*-gpios properties
> - Described the endpoint nodes for port@0 and port@1 nodes
> - Added the OF graph port to the serial binding
> - Fixed the hci_qca driver to return err if devm_pwrseq_get() fails
> - Incorporated various review comments in pwrseq driver
> - Collected Ack
> - Link to v1: https://lore.kernel.org/r/20251112-pci-m2-e-v1-0-97413d6bf824@oss.qualcomm.com
>
> ---
> Manivannan Sadhasivam (9):
> serdev: Convert to_serdev_*() helpers to macros and use container_of_const()
> serdev: Add an API to find the serdev controller associated with the devicetree node
> serdev: Do not return -ENODEV from of_serdev_register_devices() if external connector is used
> dt-bindings: serial: Document the graph port
> dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
> dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
> Bluetooth: hci_qca: Add M.2 Bluetooth device support using pwrseq
> power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors
> power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth
>
> .../bindings/connector/pcie-m2-e-connector.yaml | 161 ++++++++++++
> .../devicetree/bindings/serial/serial.yaml | 3 +
> MAINTAINERS | 1 +
> drivers/bluetooth/hci_qca.c | 9 +
> drivers/power/sequencing/Kconfig | 1 +
> drivers/power/sequencing/pwrseq-pcie-m2.c | 278 ++++++++++++++++++++-
> drivers/tty/serdev/core.c | 25 +-
> include/linux/serdev.h | 24 +-
> 8 files changed, 482 insertions(+), 20 deletions(-)
> ---
> base-commit: cb6649f6217c0331b885cf787f1d175963e2a1d2
> change-id: 20251112-pci-m2-e-94695ac9d657
> prerequisite-message-id: 20251125-pci-m2-v3-0-c528042aea47@oss.qualcomm.com
> prerequisite-patch-id: 58778d8eb97ab86008cd48fb5d28ed6cc0bbbc1b
> prerequisite-patch-id: 2dd7d793a67f59ef6e6b5137e69436896198b965
> prerequisite-patch-id: 8ccaa5fdd95e64e69cd942f93c26e89b827d0453
> prerequisite-patch-id: 3d3e1bb7959ab1e140c5024acdd8655e7a7e99ef
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Manivannan Sadhasivam @ 2026-01-15 10: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_JsqJxBNm0y6T7vji6MXgsO65iDJ-tdUEo0cOxkw7EuMKpkg@mail.gmail.com>
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?
> This isn't exactly a new issue. It could be an issue on any binding
> with GPIOs. Perhaps this needs to be handled within GPIO or pinctrl.
>
> > > > +
> > > > + oneOf:
> > > > + - required:
> > > > + - port@0
> > > > +
> > > > + clocks:
> > > > + description: 32.768 KHz Suspend Clock (SUSCLK) input from the host system to
> > > > + the M.2 card. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.1 for
> > > > + more details.
> > > > + maxItems: 1
> > > > +
> > > > + w-disable1-gpios:
> > > > + description: GPIO input to W_DISABLE1# signal. This signal is used by the
> > > > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
> > > > + Specification r4.0, sec 3.1.12.3 for more details.
> > > > + maxItems: 1
> > > > +
> > > > + w-disable2-gpios:
> > > > + description: GPIO input to W_DISABLE2# signal. This signal is used by the
> > > > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
> > > > + Specification r4.0, sec 3.1.12.3 for more details.
> > > > + maxItems: 1
> > > > +
> > > > + viocfg-gpios:
> > > > + description: GPIO output to IO voltage configuration (VIO_CFG) signal. This
> > > > + signal is used by the M.2 card to indicate to the host system that the
> > > > + card supports an independent IO voltage domain for the sideband signals.
> > > > + Refer, PCI Express M.2 Specification r4.0, sec 3.1.15.1 for more details.
> > > > + maxItems: 1
> > >
> > > What about SDIO and UART WAKE, SDIO RESET, and vendor defined signals?
> > >
> >
> > Not sure about vendor defined signals as they can be either GPIO or interface
> > signals. How should them be defined?
>
> That kind of breaks any notion of this being a generic slot/connector.
> How's the host supposed to know how to connect them? What if a card
> required them to be driven a certain way before you can discover the
> card? If they can be GPIOs and can be hooked up to the host system
> GPIOs, then you should define GPIOs for them. If they aren't GPIOs on
> a host, then you omit them.
>
Ok, then defining them as 'vendorN-gpios' is fine?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Manivannan Sadhasivam @ 2026-01-15 10:43 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: <20260113172536.GA3975461-robh@kernel.org>
On Tue, Jan 13, 2026 at 11:25:36AM -0600, Rob Herring wrote:
> On Mon, Jan 12, 2026 at 09:56:05PM +0530, Manivannan Sadhasivam wrote:
> > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > spec, it looks very similar to the M.2 Key M connector. So add the
> > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > to reuse the Key M binding.
>
> Key M or Key E? I'm confused.
>
Sorry, typo due to respinning both series at a time. Key E only.
- Mani
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> > .../devicetree/bindings/connector/pcie-m2-e-connector.yaml | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > index b65b39ddfd19..9757fe92907b 100644
> > --- a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > @@ -17,7 +17,14 @@ description:
> >
> > properties:
> > compatible:
> > - const: pcie-m2-e-connector
> > + oneOf:
> > + - items:
> > + - enum:
> > + - pcie-m2-1620-lga-connector
> > + - const: pcie-m2-e-connector
> > + - items:
> > + - enum:
> > + - pcie-m2-e-connector
> >
> > vpcie3v3-supply:
> > description: A phandle to the regulator for 3.3v supply.
> >
> > --
> > 2.48.1
> >
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Manivannan Sadhasivam @ 2026-01-15 10:44 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: <20260113171601.GB3925312-robh@kernel.org>
On Tue, Jan 13, 2026 at 11:16:01AM -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.
> > +
> > + ports:
>
> Also, nodes go after all properties.
>
Ack.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 10/19] fs: pstore: platform: Migrate to register_console_force helper
From: Petr Mladek @ 2026-01-15 11:05 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-10-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:17, 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.
> --- a/fs/pstore/platform.c
> +++ b/fs/pstore/platform.c
> @@ -418,10 +418,10 @@ static void pstore_register_console(void)
> sizeof(pstore_console.name));
> /*
> * Always initialize flags here since prior unregister_console()
> - * calls may have changed settings (specifically CON_ENABLED).
> + * calls may have changed settings.
> */
> - pstore_console.flags = CON_PRINTBUFFER | CON_ENABLED | CON_ANYTIME;
> - register_console(&pstore_console);
> + pstore_console.flags = CON_PRINTBUFFER | CON_ANYTIME;
As the original comment suggests, this was done primary because
of CON_ENABLED flag. Otherwise, the console was not registered again.
register_console() might remove CON_PRINTBUFFER when there was
a boot console and the newly registered console will get associated
with /dev/console. But I consider this a corner case. Other console
drivers ignore this scenario.
I suggest to define the two flags statically in
struct console pstore_console definition as it is done by
other console drivers. Remove this explicit dynamic assigment.
And add the following into the commit message:
<proposal>
Define the remaining console flags statically in the structure definition
as it is done by other console drivers.
The flags were re-defined primary because of the CON_ENABLED flag.
Otherwise, the re-registration failed.
The CON_PRINTBUFFER might get cleared when a boot console was registered
and the pstrore console got associated with /dev/console. In this
case, the pstore console would not re-play the entire ring buffer
on re-registration. But it is a corner case. And it actually might
be a desired behavior.
</proposal>
Otherwise, the next generations of kernel developers might think that
the re-assigment was there because of CON_PRINTBUFFER flag.
And it might cause non-necessary headaches ;-)
> + register_console_force(&pstore_console);
> }
>
> static void pstore_unregister_console(void)
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v5 0/7] riscv: spacemit: Add SpacemiT K3 SoC and K3 Pico-ITX board
From: Yixun Lan @ 2026-01-15 11:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan,
Daniel Lezcano, Samuel Holland, Anup Patel, Greg Kroah-Hartman,
Jiri Slaby, Lubomir Rintel, Yangyu Chen, Thomas Gleixner,
Guodong Xu
Cc: Yixun Lan, Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
Kevin Meng Zhang, Andrew Jones, devicetree, linux-riscv,
linux-kernel, spacemit, linux-serial, Krzysztof Kozlowski,
Heinrich Schuchardt, Conor Dooley
In-Reply-To: <20260115-k3-basic-dt-v5-0-6990ac9f4308@riscstar.com>
On Thu, 15 Jan 2026 14:51:39 +0800, Guodong Xu wrote:
> This series introduces basic support for the SpacemiT K3 SoC and the
> K3 Pico-ITX evaluation board.
>
> In v5, patches 6-9 (dt-bindings) have been dropped as they were accepted
> by Conor and applied to riscv-dt-for-next.
>
> The series has been rebased on linux-next tag: next-20260114.
>
> [...]
Applied, thanks!
[1/7] dt-bindings: riscv: add SpacemiT X100 CPU compatible
https://github.com/spacemit-com/linux/commit/14f77777687e182aa782db86220409f4c149e0b8
[2/7] dt-bindings: timer: add SpacemiT K3 CLINT
https://github.com/spacemit-com/linux/commit/b647b5e6a7e6533c2974f9aa3255aa7879a7b5f4
[3/7] dt-bindings: interrupt-controller: add SpacemiT K3 APLIC
https://github.com/spacemit-com/linux/commit/23b3bd93e1e14c1cf7146166c39bdb24e7d713c7
[4/7] dt-bindings: interrupt-controller: add SpacemiT K3 IMSIC
https://github.com/spacemit-com/linux/commit/5c414d0c0987b95cc985b23e532f1341371eef86
[5/7] dt-bindings: riscv: spacemit: add K3 and Pico-ITX board bindings
https://github.com/spacemit-com/linux/commit/66041d5fd564d94249d41bb6aa004ff1e3f25787
[6/7] riscv: dts: spacemit: add initial support for K3 SoC
https://github.com/spacemit-com/linux/commit/0ef9a718421fbc464edb6e5f6d483e0915e18599
[7/7] riscv: dts: spacemit: add K3 Pico-ITX board support
https://github.com/spacemit-com/linux/commit/8e149fcd4854204bbb82ee037cdfb62a9978587f
Best regards,
--
Yixun Lan <dlan@kernel.org>
^ permalink raw reply
* [PATCH v5 00/11] Add support for Microchip 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
This series adds support for the Microchip LAN969x switch SoC family.
Series is a bit long since after discussions in previous versions, it was
recommended[1][2] to add SoC specific compatibles for device nodes so it
includes the required bindings updates.
[1] https://lore.kernel.org/all/20251203-splendor-cubbyhole-eda2d6982b46@spud/
[2] https://lore.kernel.org/all/173412c8-c2fb-4c38-8de7-5b1c2eebdbf9@microchip.com/
[3] https://lore.kernel.org/all/20251203-duly-leotard-86b83bd840c6@spud/
[4] https://lore.kernel.org/all/756ead5d-8c9b-480d-8ae5-71667575ab7c@kernel.org/
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Changes in v5:
* Picked Acked-by and Reviewed-by tags
* Change clock header license to match the DTSI one
* Alphabetize EV23X71A pin nodes
* Remove the requirment for all ethernet-port nodes to have phys property
as when RGMII is used there is no SERDES being used
* Drop phys from RGMII port on EV23X71A
* Drop USB, DMA, MIIM, SPI and I2C bindings as those were already picked
Changes in v4:
* Pick Acked-by from Andi for I2C bindings
* Move clock indexes from dt-bindings into a DTS header as suggested by
Krzysztof[4]
Changes in v3:
* Pick Acked-by from Conor
* Drop HWMON binding as it was picked into hwmon already
* Document EV23X71A into AT91 binding
* Drop SparX-5 and AT91 bindings merge
* Apply remark from Conor on DMA binding regarding merging cases
Changes in v2:
* Change LAN969x wildcards to LAN9691 in patches
* Split SoC DTSI and evaluation board patches
* Add the suggested binding changes required for SoC specific compatibles
* Merge SparX-5 and AT91 bindings as suggested[3]
Robert Marko (11):
dt-bindings: mfd: atmel,sama5d2-flexcom: add microchip,lan9691-flexcom
dt-bindings: serial: atmel,at91-usart: add microchip,lan9691-usart
dt-bindings: rng: atmel,at91-trng: add microchip,lan9691-trng
dt-bindings: crypto: atmel,at91sam9g46-aes: add microchip,lan9691-aes
dt-bindings: crypto: atmel,at91sam9g46-sha: add microchip,lan9691-sha
dt-bindings: pinctrl: pinctrl-microchip-sgpio: add LAN969x
arm64: dts: microchip: add LAN969x clock header file
arm64: dts: microchip: add LAN969x support
dt-bindings: arm: AT91: document EV23X71A board
dt-bindings: net: sparx5: do not require phys when RGMII is used
arm64: dts: microchip: add EV23X71A board
.../devicetree/bindings/arm/atmel-at91.yaml | 6 +
.../crypto/atmel,at91sam9g46-aes.yaml | 1 +
.../crypto/atmel,at91sam9g46-sha.yaml | 1 +
.../bindings/mfd/atmel,sama5d2-flexcom.yaml | 1 +
.../bindings/net/microchip,sparx5-switch.yaml | 15 +-
.../pinctrl/microchip,sparx5-sgpio.yaml | 20 +-
.../bindings/rng/atmel,at91-trng.yaml | 1 +
.../bindings/serial/atmel,at91-usart.yaml | 1 +
arch/arm64/boot/dts/microchip/Makefile | 1 +
arch/arm64/boot/dts/microchip/clk-lan9691.h | 24 +
arch/arm64/boot/dts/microchip/lan9691.dtsi | 488 +++++++++++
.../boot/dts/microchip/lan9696-ev23x71a.dts | 756 ++++++++++++++++++
12 files changed, 1309 insertions(+), 6 deletions(-)
create mode 100644 arch/arm64/boot/dts/microchip/clk-lan9691.h
create mode 100644 arch/arm64/boot/dts/microchip/lan9691.dtsi
create mode 100644 arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts
--
2.52.0
^ permalink raw reply
* [PATCH v5 01/11] dt-bindings: mfd: atmel,sama5d2-flexcom: add microchip,lan9691-flexcom
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>
Add binding documentation for Microchip LAN969x.
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
Documentation/devicetree/bindings/mfd/atmel,sama5d2-flexcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/mfd/atmel,sama5d2-flexcom.yaml b/Documentation/devicetree/bindings/mfd/atmel,sama5d2-flexcom.yaml
index c7d6cf96796c..5e5dec2f6564 100644
--- a/Documentation/devicetree/bindings/mfd/atmel,sama5d2-flexcom.yaml
+++ b/Documentation/devicetree/bindings/mfd/atmel,sama5d2-flexcom.yaml
@@ -20,6 +20,7 @@ properties:
- const: atmel,sama5d2-flexcom
- items:
- enum:
+ - microchip,lan9691-flexcom
- microchip,sam9x7-flexcom
- microchip,sama7d65-flexcom
- microchip,sama7g5-flexcom
--
2.52.0
^ permalink raw reply related
* [PATCH v5 02/11] dt-bindings: serial: atmel,at91-usart: add microchip,lan9691-usart
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 Microchip LAN969x USART compatible.
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
Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml
index 087a8926f8b4..375cd50bc5cc 100644
--- a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml
+++ b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml
@@ -24,6 +24,7 @@ properties:
- const: atmel,at91sam9260-usart
- items:
- enum:
+ - microchip,lan9691-usart
- microchip,sam9x60-usart
- microchip,sam9x7-usart
- microchip,sama7d65-usart
--
2.52.0
^ permalink raw reply related
* [PATCH v5 03/11] dt-bindings: rng: atmel,at91-trng: add microchip,lan9691-trng
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 Microchip LAN969X TRNG compatible.
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
Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml b/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml
index f78614100ea8..3628251b8c51 100644
--- a/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml
+++ b/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml
@@ -19,6 +19,7 @@ properties:
- microchip,sam9x60-trng
- items:
- enum:
+ - microchip,lan9691-trng
- microchip,sama7g5-trng
- const: atmel,at91sam9g45-trng
- items:
--
2.52.0
^ permalink raw reply related
* [PATCH v5 04/11] dt-bindings: crypto: atmel,at91sam9g46-aes: add microchip,lan9691-aes
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 Microchip LAN969x AES compatible.
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
.../devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml
index 19010f90198a..f3b6af6baf15 100644
--- a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml
+++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml
@@ -16,6 +16,7 @@ properties:
- const: atmel,at91sam9g46-aes
- items:
- enum:
+ - microchip,lan9691-aes
- microchip,sam9x7-aes
- microchip,sama7d65-aes
- const: atmel,at91sam9g46-aes
--
2.52.0
^ permalink raw reply related
* [PATCH v5 05/11] dt-bindings: crypto: atmel,at91sam9g46-sha: add microchip,lan9691-sha
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 Microchip LAN969x SHA compatible.
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
.../devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml
index 39e076b275b3..16704ff0dd7f 100644
--- a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml
+++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml
@@ -16,6 +16,7 @@ properties:
- const: atmel,at91sam9g46-sha
- items:
- enum:
+ - microchip,lan9691-sha
- microchip,sam9x7-sha
- microchip,sama7d65-sha
- const: atmel,at91sam9g46-sha
--
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
* [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 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 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 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 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
* 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
* 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 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 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 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 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] 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
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