* Re: [PATCH net-next v2 4/9] net: dsa: lan9645x: add basic dsa driver for LAN9645X
From: Jakub Kicinski @ 2026-03-29 19:56 UTC (permalink / raw)
To: jensemil.schulzostergaard
Cc: Jakub Kicinski, UNGLinuxDriver, andrew, olteanv, davem, edumazet,
pabeni, horms, robh, krzk+dt, conor+dt, woojung.huh, linux,
Steen.Hegelund, daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260324-dsa_lan9645x_switch_driver_base-v2-4-f7504e3b0681@microchip.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
Subject: net: dsa: lan9645x: add basic dsa driver for LAN9645X
This commit adds a basic DSA driver for the Microchip LAN9645X switch. It
includes initialization, port module setup for NPI, CPU, and front ports,
and phylink integration for MAC side configuration.
diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
--- a/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
+++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
[ ... ]
> +static void disable_conduit_ipv6(struct lan9645x *lan9645x,
> + struct net_device *conduit)
> +{
> + struct inet6_dev *dev_v6;
> +
> + if (!conduit)
> + return;
> +
> + /* IPv6 on the conduit will generate frames bypassing our tag driver, so
> + * they lack an IFH. This will be garbage in garbage out and we want to
> + * avoid this.
> + */
> + rtnl_lock();
> + dev_v6 = __in6_dev_get(conduit);
> + if (dev_v6) {
> + WRITE_ONCE(dev_v6->cnf.disable_ipv6, 1);
> + dev_warn(lan9645x->dev, "Disabled IPv6 on conduit device: %s\n",
> + netdev_name(conduit));
> + }
> + rtnl_lock();
> +}
Does directly modifying dev_v6->cnf.disable_ipv6 bypass the proper sysctl
teardown path (addrconf_disable_ipv6) and leave the IPv6 stack in an
inconsistent state on the conduit device by failing to clean up routes,
addresses, and MLD memberships?
Is it a layering violation for a switch driver to alter the networking
configuration of an external upper device, especially since this change
isn't reverted during driver unbind?
[ ... ]
> +void lan9645x_npi_port_init(struct lan9645x *lan9645x,
> + struct dsa_port *cpu_port)
> +{
> + int port = cpu_port->index;
> + struct lan9645x_port *p;
> +
> + p = lan9645x_to_port(lan9645x, port);
> + lan9645x->npi = port;
In a cascaded multi-switch DSA topology, cpu_port->index may belong to a
different switch and be greater than 8. If lan9645x_to_port returns NULL,
will this cause a panic when dereferencing p->chip_port below?
[ ... ]
> + /* Configure IFH prefix mode for NPI port. */
> + lan_rmw(SYS_PORT_MODE_INCL_XTR_HDR_SET(LAN9645X_TAG_PREFIX_LONG) |
> + SYS_PORT_MODE_INCL_INJ_HDR_SET(LAN9645X_TAG_PREFIX_NONE),
> + SYS_PORT_MODE_INCL_XTR_HDR |
> + SYS_PORT_MODE_INCL_INJ_HDR,
> + lan9645x,
> + SYS_PORT_MODE(p->chip_port));
Setting LAN9645X_TAG_PREFIX_NONE means the hardware interprets the first
bytes of any frame received from the host as an IFH command structure.
Does this allow a local user to transmit crafted frames (for example, via
raw sockets or standard protocols) whose MAC address bytes map to malicious
IFH commands, thereby bypassing VLAN isolation or flooding the switch?
Should the hardware be configured to require a strict prefix, such as
LAN9645X_TAG_PREFIX_LONG, for injected frames to prevent this?
diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
--- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
+++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
[ ... ]
> +static int lan9645x_setup(struct dsa_switch *ds)
> +{
> + struct lan9645x *lan9645x = ds->priv;
> + struct device *dev = lan9645x->dev;
> + u32 all_phys_ports;
> + int err;
> +
> + lan9645x->num_phys_ports = ds->num_ports;
> + all_phys_ports = GENMASK(lan9645x->num_phys_ports - 1, 0);
> +
> + err = lan9645x_reset_switch(lan9645x);
> + if (err)
> + return err;
> +
> + lan9645x->ports = devm_kcalloc(lan9645x->dev, lan9645x->num_phys_ports,
> + sizeof(struct lan9645x_port *),
> + GFP_KERNEL);
Since the DSA .setup callback can be invoked multiple times during the
platform device's lifetime (for example, when the DSA master interface is
unbound and bound again), does using devm_kcalloc here cause a memory leak?
Should these allocations be moved to .probe or managed with kcalloc and
freed in .teardown?
[ ... ]
> + /* Set all the entries to obey VLAN. */
> + for (int i = 0; i < PGID_ENTRIES; ++i)
> + lan_wr(ANA_PGID_CFG_OBEY_VLAN_SET(1),
> + lan9645x, ANA_PGID_CFG(i));
PGID_ENTRIES is defined as 89, so this loop initializes indices 0 through
88. Since the CPU port is index 9, its source PGID is PGID_SRC + CPU_PORT
(80 + 9 = 89).
Is index 89 left uninitialized, breaking the OBEY_VLAN rule and allowing
CPU-injected frames to leak across VLAN boundaries?
[ ... ]
> + /* Multicast to all front ports */
> + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MC));
> +
> + /* IP multicast to all front ports */
> + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MCIPV4));
> + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MCIPV6));
> +
> + /* Unicast to all front ports */
> + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_UC));
> +
> + /* Broadcast to all ports */
> + lan_wr(BIT(CPU_PORT) | all_phys_ports, lan9645x, ANA_PGID(PGID_BC));
PGID_BC includes BIT(CPU_PORT) and all_phys_ports (which includes the NPI
port). Will this forward broadcast frames to both the CPU extraction queue
and the NPI port's normal egress queue, causing duplicate frames for the host?
Conversely, the multicast masks and PGID_UC exclude BIT(CPU_PORT). Does
this cause them to bypass the CPU extraction queue entirely, thereby
lacking the LONG extraction prefix and breaking the host's DSA tagger parsing?
diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_phylink.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_phylink.c
--- a/drivers/net/dsa/microchip/lan9645x/lan9645x_phylink.c
+++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_phylink.c
[ ... ]
> +static int lan9645x_phylink_mac_prepare(struct phylink_config *config,
> + unsigned int mode,
> + phy_interface_t iface)
> +{
> + struct lan9645x_port *p = lan9645x_phylink_config_to_port(config);
> + struct lan9645x *lan9645x = p->lan9645x;
> + int port = p->chip_port;
> + u32 mask;
> +
> + if (port == 5 || port == 6 || port > 8)
> + return -EINVAL;
> +
> + mask = HSIO_HW_CFG_GMII_ENA_SET(BIT(port));
> + lan_rmw(mask, mask, lan9645x, HSIO_HW_CFG);
> +
> + if (port == 4 && phy_interface_mode_is_rgmii(iface))
> + lan_rmw(HSIO_HW_CFG_RGMII_0_CFG_SET(1),
> + HSIO_HW_CFG_RGMII_0_CFG,
> + lan9645x, HSIO_HW_CFG);
The lan9645x_phylink_get_caps function advertises RGMII support for ports
4, 7, and 8. Does restricting the hardware multiplexer configuration here to
port 4 break connectivity for ports 7 and 8 when used in RGMII mode?
diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_port.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_port.c
--- a/drivers/net/dsa/microchip/lan9645x/lan9645x_port.c
+++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_port.c
[ ... ]
> +int lan9645x_port_set_maxlen(struct lan9645x *lan9645x, int port, size_t sdu)
> +{
> + struct lan9645x_port *p = lan9645x_to_port(lan9645x, port);
> + int maxlen = sdu + ETH_HLEN + ETH_FCS_LEN;
Does this maximum frame length calculation drop standard 1500-byte MTU
frames that are 802.1Q VLAN tagged (1522 bytes total), since it does not
account for VLAN_HLEN?
[ ... ]
> +int lan9645x_port_setup(struct dsa_switch *ds, int port)
> +{
> + struct dsa_port *dp = dsa_to_port(ds, port);
> + struct lan9645x *lan9645x = ds->priv;
> + struct lan9645x_port *p;
> +
> + p = lan9645x_to_port(lan9645x, port);
> +
> + if (dp->dn) {
> + p->rx_internal_delay =
> + of_property_present(dp->dn, "rx-internal-delay-ps");
> + p->tx_internal_delay =
> + of_property_present(dp->dn, "tx-internal-delay-ps");
> + }
These are standard integer properties specifying delays in picoseconds. If
a user explicitly disables the delay via devicetree using a value of 0,
will of_property_present evaluate to true and enable the hardware delay
anyway? Should of_property_read_u32 be used instead to check the value?
^ permalink raw reply
* Re: [PATCH net-next v2 3/9] net: dsa: lan9645x: add autogenerated register macros
From: Jakub Kicinski @ 2026-03-29 19:56 UTC (permalink / raw)
To: jensemil.schulzostergaard
Cc: Jakub Kicinski, UNGLinuxDriver, andrew, olteanv, davem, edumazet,
pabeni, horms, robh, krzk+dt, conor+dt, woojung.huh, linux,
Steen.Hegelund, daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260324-dsa_lan9645x_switch_driver_base-v2-3-f7504e3b0681@microchip.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
No issues found.
^ permalink raw reply
* Re: [PATCH net-next v2 2/9] dt-bindings: net: lan9645x: add LAN9645X switch bindings
From: Jakub Kicinski @ 2026-03-29 19:56 UTC (permalink / raw)
To: jensemil.schulzostergaard
Cc: Jakub Kicinski, UNGLinuxDriver, andrew, olteanv, davem, edumazet,
pabeni, horms, robh, krzk+dt, conor+dt, woojung.huh, linux,
Steen.Hegelund, daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260324-dsa_lan9645x_switch_driver_base-v2-2-f7504e3b0681@microchip.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
dt-bindings: net: lan9645x: add LAN9645X switch bindings
Add bindings for LAN9645X switch. We use a fallback compatible for the
smallest SKU microchip,lan96455s-switch.
> diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> new file mode 100644
> index 000000000000..0282e25c05d4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
[ ... ]
> +patternProperties:
> + "^(ethernet-)?ports$":
> + type: object
> + additionalProperties: true
> + patternProperties:
> + "^(ethernet-)?port@[0-8]$":
Does having additionalProperties set to true bypass the port number
restriction?
Since dsa.yaml allows port@[0-9a-f]+, it seems port@9 would silently pass
validation as an additional property. Should this be unevaluatedProperties
set to false instead?
> + type: object
> + description: Ethernet switch ports
> +
> + $ref: dsa-port.yaml#
> +
> + properties:
> + rx-internal-delay-ps:
> + const: 2000
> +
> + tx-internal-delay-ps:
> + const: 2000
Does enforcing a 2000ps delay conflict with standard rgmii bindings?
As documented in net/ethernet-controller.yaml, a full 2ns delay is
typically modeled using phy-mode set to rgmii-id rather than hardcoding the
delay properties with a base rgmii mode.
[ ... ]
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
How are the five integrated 10/100/1000Base-T phys mentioned in the
description modeled?
Since unevaluatedProperties is false at the top level and there is no
definition or reference for an mdio node, wouldn't adding an mdio subnode
to configure these phys fail schema validation?
Should there be a reference to /schemas/net/mdio.yaml#?
^ permalink raw reply
* Re: [PATCH net-next v2 1/9] net: dsa: add tag driver for LAN9645X
From: Jakub Kicinski @ 2026-03-29 19:56 UTC (permalink / raw)
To: jensemil.schulzostergaard
Cc: Jakub Kicinski, UNGLinuxDriver, andrew, olteanv, davem, edumazet,
pabeni, horms, robh, krzk+dt, conor+dt, woojung.huh, linux,
Steen.Hegelund, daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260324-dsa_lan9645x_switch_driver_base-v2-1-f7504e3b0681@microchip.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: dsa: add tag driver for LAN9645X
Add a tag driver for LAN9645x switches using a front port as the CPU port
(NPI port). The driver configures a long prefix for extraction and no
prefix for injection to handle the internal frame header (IFH).
> diff --git a/net/dsa/tag_lan9645x.c b/net/dsa/tag_lan9645x.c
> new file mode 100644
> index 000000000000..9130fb0d61be
> --- /dev/null
> +++ b/net/dsa/tag_lan9645x.c
[ ... ]
> +static void lan9645x_xmit_get_vlan_info(struct sk_buff *skb,
> + struct net_device *br,
> + u32 *vlan_tci, u32 *tag_type)
> +{
> + struct vlan_ethhdr *hdr;
> + u16 proto, tci;
> +
> + if (!br || !br_vlan_enabled(br)) {
> + *vlan_tci = 0;
> + *tag_type = LAN9645X_IFH_TAG_TYPE_C;
> + return;
> + }
> +
> + hdr = (struct vlan_ethhdr *)skb_mac_header(skb);
> + br_vlan_get_proto(br, &proto);
> +
> + if (ntohs(hdr->h_vlan_proto) == proto) {
> + vlan_remove_tag(skb, &tci);
Is it possible for a maliciously crafted packet (e.g., via AF_PACKET) to have a
length of 14 bytes with h_vlan_proto set to ETH_P_8021Q?
If so, vlan_remove_tag() would read vhdr->h_vlan_TCI at offset 14, causing an
out-of-bounds read.
Furthermore, if the packet contains fragments and the VLAN header is not in the
linear data area, vlan_remove_tag() could corrupt the SKB when shifting the MAC
header.
Would it be safer to use skb_vlan_untag() instead?
> + *vlan_tci = tci;
> + } else {
> + rcu_read_lock();
> + br_vlan_get_pvid_rcu(br, &tci);
> + rcu_read_unlock();
> + *vlan_tci = tci;
> + }
> +
> + *tag_type = (proto != ETH_P_8021Q) ? LAN9645X_IFH_TAG_TYPE_S :
> + LAN9645X_IFH_TAG_TYPE_C;
> +}
[ ... ]
> +static struct sk_buff *lan9645x_rcv(struct sk_buff *skb,
> + struct net_device *ndev)
> +{
> + u32 src_port, qos_class, vlan_tci, tag_type, popcnt, etype_ofs;
> + u8 *orig_skb_data = skb->data;
> + struct dsa_port *dp;
> + u32 ifh_gap_len = 0;
> + u16 vlan_tpid;
> + u8 *ifh;
> +
> + /* DSA master already consumed DMAC,SMAC,ETYPE from long prefix. Go back
> + * to beginning of frame.
> + */
> + skb_push(skb, ETH_HLEN);
> + /* IFH starts after our long prefix */
> + ifh = skb_pull(skb, LAN9645X_LONG_PREFIX_LEN);
Could skb_pull() return NULL here if skb->len is less than 16 bytes?
If it returns NULL, the blind dereference of ifh in the subsequent
lan9645x_ifh_get() calls would cause a NULL pointer dereference.
Additionally, is the 44-byte tag (16-byte prefix + 28-byte IFH) guaranteed to
be in the linear data buffer (skb->data)?
Without calling pskb_may_pull(skb, LAN9645X_TOTAL_TAG_LEN) first, accessing it
via the ifh pointer might result in out-of-bounds reads if the packet payload
is in paged fragments.
> +
> + popcnt = lan9645x_ifh_get(ifh, IFH_POP_CNT, IFH_POP_CNT_SZ);
> + etype_ofs = lan9645x_ifh_get(ifh, IFH_ETYPE_OFS, IFH_ETYPE_OFS_SZ);
> + src_port = lan9645x_ifh_get(ifh, IFH_SRCPORT, IFH_SRCPORT_SZ);
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Linus Walleij @ 2026-03-29 18:57 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Krzysztof Kozlowski, Rob Herring (Arm), Khushal Chitturi,
devicetree, linux-kernel, linux-pm, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <aciItMCdBbrVvMKB@venus>
On Sun, Mar 29, 2026 at 4:09 AM Sebastian Reichel <sre@kernel.org> wrote:
> The problem is the node name (power-controller@4b000000), which is
> reserved for power domains. You can keep the compatible.
Ah, sweet, Khushal can you change this?
I think you can use gemini-poweroff@4b000000 because
this is pretty much a poweroff thingie.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] dt-bindings: rtc: moxa,moxart-rtc: convert to json-schema
From: Serban-Pascu Robert @ 2026-03-29 18:46 UTC (permalink / raw)
To: alexandre.belloni
Cc: robh, krzk+dt, conor+dt, devicetree, linux-rtc, linux-kernel,
daniel.baluta, Serban-Pascu Robert
Convert the MOXA ART real-time clock text binding to DT schema.
Signed-off-by: Serban-Pascu Robert <robyserbanpascu06@gmail.com>
---
.../bindings/rtc/moxa,moxart-rtc.txt | 17 --------
.../bindings/rtc/moxa,moxart-rtc.yaml | 43 +++++++++++++++++++
2 files changed, 43 insertions(+), 17 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
create mode 100644 Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.yaml
diff --git a/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt b/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
deleted file mode 100644
index 1374df7bf9d6..000000000000
--- a/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-MOXA ART real-time clock
-
-Required properties:
-
-- compatible : Should be "moxa,moxart-rtc"
-- rtc-sclk-gpios : RTC sclk gpio, with zero flags
-- rtc-data-gpios : RTC data gpio, with zero flags
-- rtc-reset-gpios : RTC reset gpio, with zero flags
-
-Example:
-
- rtc: rtc {
- compatible = "moxa,moxart-rtc";
- rtc-sclk-gpios = <&gpio 5 0>;
- rtc-data-gpios = <&gpio 6 0>;
- rtc-reset-gpios = <&gpio 7 0>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.yaml b/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.yaml
new file mode 100644
index 000000000000..6b8f6e5f99e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/moxa,moxart-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MOXA ART Real-time Clock
+
+maintainers:
+ - Serban-Pascu Robert <robyserbanpascu06@gmail.com>
+
+properties:
+ compatible:
+ const: moxa,moxart-rtc
+
+ rtc-sclk-gpios:
+ maxItems: 1
+ description: GPIO line for the RTC clock signal.
+
+ rtc-data-gpios:
+ maxItems: 1
+ description: GPIO line for the RTC data signal.
+
+ rtc-reset-gpios:
+ maxItems: 1
+ description: GPIO line for the RTC reset signal.
+
+required:
+ - compatible
+ - rtc-sclk-gpios
+ - rtc-data-gpios
+ - rtc-reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ rtc {
+ compatible = "moxa,moxart-rtc";
+ rtc-sclk-gpios = <&gpio 5 0>;
+ rtc-data-gpios = <&gpio 6 0>;
+ rtc-reset-gpios = <&gpio 7 0>;
+ };
--
2.43.0
^ permalink raw reply related
* [GIT PULL] RISC-V T-HEAD Devicetrees for v7.1, part 2
From: Drew Fustini @ 2026-03-29 18:44 UTC (permalink / raw)
To: soc
Cc: devicetree, Alexandre Belloni, Arnd Bergmann, Linus Walleij,
Han Gao, Conor Dooley, Krzysztof Kozlowski, linux-kernel,
Icenowy Zheng, Jisheng Zhang, Michal Wilczynski, Yao Zi, Guo Ren,
linux-riscv, Luca Ceresoli, Fu Wei, Robert Mazur
Two minor improvements that weren't ready when I sent the originall pull
request. They have now been tested in next. No problem if it is too late
for this cycle.
Thanks,
Drew
The following changes since commit 9c99a784d9117a192ebf779d4f72ebec435ada97:
riscv: dts: thead: lichee-pi-4a: enable HDMI (2026-03-14 09:19:26 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux.git tags/thead-dt-for-v7.1-p2
for you to fetch changes up to 74ec3d52c0035b662ec295bef2bbffad68446391:
riscv: dts: thead: beaglev-ahead: enable HDMI output (2026-03-25 09:20:38 -0700)
----------------------------------------------------------------
T-HEAD Devicetrees for 7.1, part 2
Additional updates to T-Head device trees for v7.1:
- Enable the display pipeline for the TH1520-based BeagleV Ahead board
by adding the HDMI connector node, connecting it to the HDMI
controller, and activating the DPU and HDMI nodes.
- Add coefficients to the TH1520 PVT node as the values in the TH1520
manual differ from the defaults in the driver.
----------------------------------------------------------------
Icenowy Zheng (1):
riscv: dts: thead: th1520: add coefficients to the PVT node
Robert Mazur (1):
riscv: dts: thead: beaglev-ahead: enable HDMI output
arch/riscv/boot/dts/thead/th1520-beaglev-ahead.dts | 25 ++++++++++++++++++++++
arch/riscv/boot/dts/thead/th1520.dtsi | 4 ++++
2 files changed, 29 insertions(+)
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: bridge: ldb: Require reg property only for i.MX6SX/8MP LDBs
From: Marek Vasut @ 2026-03-29 18:29 UTC (permalink / raw)
To: Marco Felsch, Liu Ying
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Laurentiu Palcu,
dri-devel, devicetree, linux-kernel
In-Reply-To: <crqzju5cqhvmy5msxvuquydmnpb2ft2t3gsyr6qsre6ccqjvzz@46gfcrelczsr>
On 3/29/26 7:42 PM, Marco Felsch wrote:
Hello Marco,
> sorry for not writting back earlier, the last weeks were quite busy.
Tell me about it ...
> On 26-03-29, Liu Ying wrote:
>> LDB's parent device could be a syscon which doesn't allow a reg property
>> to be present in it's child devices, e.g., NXP i.MX93 Media blk-ctrl
>> has a child device NXP i.MX93 Parallel Display Format Configuration(PDFC)
>> without a reg property(LDB is also a child device of the Media blk-ctrl).
>> To make the LDB schema be able to describe LDBs without the reg property
>> like i.MX93 LDB, require the reg property only for i.MX6SX/8MP LDBs.
>
> NACK, we want to describe the HW and from HW PoV the LDB is and was
> always part of a syscon. This is the case for all SoCs i.MX6SX/8MP/93.
>
>> Fixes: 8aa2f0ac08d3 ("dt-bindings: display: bridge: ldb: Add check for reg and reg-names")
>
> Therefore I would just revert this patch completely.
Last time, I pointed out the hardware is part of syscon, but as a
subnode and therefore with reg properties. What is the problem there ?
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: kaanpaali: Add USB support for QRD platform
From: Krishna Kurapati @ 2026-03-29 18:15 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Konrad Dybcio, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Ronak Raheja, Jingyi Wang
In-Reply-To: <qycxxxlt3koyt7snnwpkmpo2udskhad3l5vjpj3mpdi5qyoriy@akxv27lrpi3n>
On 3/29/2026 11:37 PM, Dmitry Baryshkov wrote:
> On Sun, Mar 29, 2026 at 11:22:49PM +0530, Krishna Kurapati wrote:
>> From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>>
>> Enable USB support on Kaanapali QRD variant. Enable USB controller in
>> device mode till glink node is added.
>
> Why can't it be added as a part of this patchset?
>
Hi Dmitry,
SoCCP changes are not yet acked. Hence I wanted to get the base
changes in.
Regards,
Krishna,
>>
>> Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 27 ++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
>> index 6a7eb7f4050a..1929ea273a4f 100644
>> --- a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
>> +++ b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
>> @@ -80,6 +80,11 @@ key-volume-up {
>> wakeup-source;
>> };
>> };
>> +
>> + pmih0108_e1_eusb2_repeater {
>> + vdd18-supply = <&vreg_l15b_1p8>;
>> + vdd3-supply = <&vreg_l5b_3p1>;
>> + };
>> };
>>
>> &apps_rsc {
>> @@ -821,3 +826,25 @@ &ufs_mem_phy {
>>
>> status = "okay";
>> };
>> +
>> +&usb {
>> + dr_mode = "peripheral";
>> +
>> + status = "okay";
>> +};
>> +
>> +&usb_hsphy {
>> + vdd-supply = <&vreg_l4f_0p8>;
>> + vdda12-supply = <&vreg_l1d_1p2>;
>> +
>> + phys = <&pmih0108_e1_eusb2_repeater>;
>> +
>> + status = "okay";
>> +};
>> +
>> +&usb_dp_qmpphy {
>> + vdda-phy-supply = <&vreg_l1d_1p2>;
>> + vdda-pll-supply = <&vreg_l4f_0p8>;
>> +
>> + status = "okay";
>> +};
>> --
>> 2.34.1
>>
>
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: kaanpaali: Add USB support for QRD platform
From: Dmitry Baryshkov @ 2026-03-29 18:07 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Konrad Dybcio, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Ronak Raheja, Jingyi Wang
In-Reply-To: <20260329175249.2946508-4-krishna.kurapati@oss.qualcomm.com>
On Sun, Mar 29, 2026 at 11:22:49PM +0530, Krishna Kurapati wrote:
> From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>
> Enable USB support on Kaanapali QRD variant. Enable USB controller in
> device mode till glink node is added.
Why can't it be added as a part of this patchset?
>
> Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
> index 6a7eb7f4050a..1929ea273a4f 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
> +++ b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
> @@ -80,6 +80,11 @@ key-volume-up {
> wakeup-source;
> };
> };
> +
> + pmih0108_e1_eusb2_repeater {
> + vdd18-supply = <&vreg_l15b_1p8>;
> + vdd3-supply = <&vreg_l5b_3p1>;
> + };
> };
>
> &apps_rsc {
> @@ -821,3 +826,25 @@ &ufs_mem_phy {
>
> status = "okay";
> };
> +
> +&usb {
> + dr_mode = "peripheral";
> +
> + status = "okay";
> +};
> +
> +&usb_hsphy {
> + vdd-supply = <&vreg_l4f_0p8>;
> + vdda12-supply = <&vreg_l1d_1p2>;
> +
> + phys = <&pmih0108_e1_eusb2_repeater>;
> +
> + status = "okay";
> +};
> +
> +&usb_dp_qmpphy {
> + vdda-phy-supply = <&vreg_l1d_1p2>;
> + vdda-pll-supply = <&vreg_l4f_0p8>;
> +
> + status = "okay";
> +};
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v5 3/4] rust: add visibility to of_device_table macro
From: Markus Probst via B4 Relay @ 2026-03-29 18:02 UTC (permalink / raw)
To: Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman,
Rafael J. Wysocki, Len Brown, Saravana Kannan
Cc: platform-driver-x86, linux-leds, devicetree, linux-kernel,
rust-for-linux, linux-acpi, Markus Probst
In-Reply-To: <20260329-synology_microp_initial-v5-0-27cb80bdf591@posteo.de>
From: Markus Probst <markus.probst@posteo.de>
Add visibility argument to macro to allow defining an of device table in
a different module than the driver, which can improve readability.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
rust/kernel/of.rs | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/rust/kernel/of.rs b/rust/kernel/of.rs
index 58b20c367f99..a0de98a23416 100644
--- a/rust/kernel/of.rs
+++ b/rust/kernel/of.rs
@@ -53,8 +53,9 @@ pub const fn new(compatible: &'static CStr) -> Self {
/// Create an OF `IdTable` with an "alias" for modpost.
#[macro_export]
macro_rules! of_device_table {
- ($table_name:ident, $module_table_name:ident, $id_info_type: ty, $table_data: expr) => {
- const $table_name: $crate::device_id::IdArray<
+ ($table_vis:vis $table_name:ident, $module_table_name:ident, $id_info_type: ty,
+ $table_data: expr) => {
+ $table_vis const $table_name: $crate::device_id::IdArray<
$crate::of::DeviceId,
$id_info_type,
{ $table_data.len() },
--
2.52.0
^ permalink raw reply related
* [PATCH v5 4/4] platform: Add initial synology microp driver
From: Markus Probst via B4 Relay @ 2026-03-29 18:02 UTC (permalink / raw)
To: Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman,
Rafael J. Wysocki, Len Brown, Saravana Kannan
Cc: platform-driver-x86, linux-leds, devicetree, linux-kernel,
rust-for-linux, linux-acpi, Markus Probst
In-Reply-To: <20260329-synology_microp_initial-v5-0-27cb80bdf591@posteo.de>
From: Markus Probst <markus.probst@posteo.de>
Add a initial synology microp driver, written in Rust.
The driver targets a microcontroller found in Synology NAS devices. It
currently only supports controlling of the power led, status led, alert
led and usb led. Other components such as fan control or handling
on-device buttons will be added once the required rust abstractions are
there.
This driver can be used both on arm and x86, thus it goes into the root
directory of drivers/platform.
Tested successfully on a Synology DS923+.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
MAINTAINERS | 6 +
drivers/platform/Kconfig | 2 +
drivers/platform/Makefile | 1 +
drivers/platform/synology_microp/Kconfig | 13 +
drivers/platform/synology_microp/Makefile | 3 +
drivers/platform/synology_microp/TODO | 7 +
drivers/platform/synology_microp/command.rs | 55 ++++
drivers/platform/synology_microp/led.rs | 276 +++++++++++++++++++++
drivers/platform/synology_microp/model.rs | 171 +++++++++++++
.../platform/synology_microp/synology_microp.rs | 54 ++++
10 files changed, 588 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 83b5a45de729..24cc4f63cce6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25544,6 +25544,12 @@ F: drivers/dma-buf/sync_*
F: include/linux/sync_file.h
F: include/uapi/linux/sync_file.h
+SYNOLOGY MICROP DRIVER
+M: Markus Probst <markus.probst@posteo.de>
+S: Maintained
+F: Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml
+F: drivers/platform/synology_microp/
+
SYNOPSYS ARC ARCHITECTURE
M: Vineet Gupta <vgupta@kernel.org>
L: linux-snps-arc@lists.infradead.org
diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig
index 312788f249c9..996050566a4a 100644
--- a/drivers/platform/Kconfig
+++ b/drivers/platform/Kconfig
@@ -22,3 +22,5 @@ source "drivers/platform/arm64/Kconfig"
source "drivers/platform/raspberrypi/Kconfig"
source "drivers/platform/wmi/Kconfig"
+
+source "drivers/platform/synology_microp/Kconfig"
diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile
index fa322e7f8716..2381872e9133 100644
--- a/drivers/platform/Makefile
+++ b/drivers/platform/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_SURFACE_PLATFORMS) += surface/
obj-$(CONFIG_ARM64_PLATFORM_DEVICES) += arm64/
obj-$(CONFIG_BCM2835_VCHIQ) += raspberrypi/
obj-$(CONFIG_ACPI_WMI) += wmi/
+obj-$(CONFIG_SYNOLOGY_MICROP) += synology_microp/
diff --git a/drivers/platform/synology_microp/Kconfig b/drivers/platform/synology_microp/Kconfig
new file mode 100644
index 000000000000..0c145a5b7174
--- /dev/null
+++ b/drivers/platform/synology_microp/Kconfig
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+config SYNOLOGY_MICROP
+ tristate "Synology Microp driver"
+ depends on LEDS_CLASS && LEDS_CLASS_MULTICOLOR
+ depends on RUST_SERIAL_DEV_BUS_ABSTRACTIONS
+ help
+ Enable support for the MCU found in Synology NAS devices.
+
+ This is needed to properly shutdown and reboot the device, as well as
+ additional functionality like fan and LED control.
+
+ This driver is work in progress and may not be fully functional.
diff --git a/drivers/platform/synology_microp/Makefile b/drivers/platform/synology_microp/Makefile
new file mode 100644
index 000000000000..63585ccf76e4
--- /dev/null
+++ b/drivers/platform/synology_microp/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-y += synology_microp.o
diff --git a/drivers/platform/synology_microp/TODO b/drivers/platform/synology_microp/TODO
new file mode 100644
index 000000000000..1961a33115db
--- /dev/null
+++ b/drivers/platform/synology_microp/TODO
@@ -0,0 +1,7 @@
+TODO:
+- add missing components:
+ - handle on-device buttons (Power, Factory reset, "USB Copy")
+ - handle fan failure
+ - beeper
+ - fan speed control
+ - correctly perform device power-off and restart on Synology devices
diff --git a/drivers/platform/synology_microp/command.rs b/drivers/platform/synology_microp/command.rs
new file mode 100644
index 000000000000..5b3dd715afac
--- /dev/null
+++ b/drivers/platform/synology_microp/command.rs
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0
+
+use kernel::{
+ device::Bound,
+ error::Result,
+ serdev, //
+};
+
+use crate::led;
+
+#[derive(Copy, Clone)]
+#[expect(
+ clippy::enum_variant_names,
+ reason = "future variants will not end with Led"
+)]
+pub(crate) enum Command {
+ PowerLed(led::State),
+ StatusLed(led::StatusLedColor, led::State),
+ AlertLed(led::State),
+ UsbLed(led::State),
+ EsataLed(led::State),
+}
+
+impl Command {
+ pub(crate) fn write(self, dev: &serdev::Device<Bound>) -> Result {
+ dev.write_all(
+ match self {
+ Self::PowerLed(led::State::On) => &[0x34],
+ Self::PowerLed(led::State::Blink) => &[0x35],
+ Self::PowerLed(led::State::Off) => &[0x36],
+
+ Self::StatusLed(_, led::State::Off) => &[0x37],
+ Self::StatusLed(led::StatusLedColor::Green, led::State::On) => &[0x38],
+ Self::StatusLed(led::StatusLedColor::Green, led::State::Blink) => &[0x39],
+ Self::StatusLed(led::StatusLedColor::Orange, led::State::On) => &[0x3A],
+ Self::StatusLed(led::StatusLedColor::Orange, led::State::Blink) => &[0x3B],
+
+ Self::AlertLed(led::State::On) => &[0x4C, 0x41, 0x31],
+ Self::AlertLed(led::State::Blink) => &[0x4C, 0x41, 0x32],
+ Self::AlertLed(led::State::Off) => &[0x4C, 0x41, 0x33],
+
+ Self::UsbLed(led::State::On) => &[0x40],
+ Self::UsbLed(led::State::Blink) => &[0x41],
+ Self::UsbLed(led::State::Off) => &[0x42],
+
+ Self::EsataLed(led::State::On) => &[0x4C, 0x45, 0x31],
+ Self::EsataLed(led::State::Blink) => &[0x4C, 0x45, 0x32],
+ Self::EsataLed(led::State::Off) => &[0x4C, 0x45, 0x33],
+ },
+ serdev::Timeout::Max,
+ )?;
+ dev.wait_until_sent(serdev::Timeout::Max);
+ Ok(())
+ }
+}
diff --git a/drivers/platform/synology_microp/led.rs b/drivers/platform/synology_microp/led.rs
new file mode 100644
index 000000000000..a78a95588456
--- /dev/null
+++ b/drivers/platform/synology_microp/led.rs
@@ -0,0 +1,276 @@
+// SPDX-License-Identifier: GPL-2.0
+
+use kernel::{
+ device::Bound,
+ devres::{
+ self,
+ Devres, //
+ },
+ led::{
+ self,
+ LedOps,
+ MultiColorSubLed, //
+ },
+ new_mutex,
+ prelude::*,
+ serdev,
+ str::CString,
+ sync::Mutex, //
+};
+use pin_init::pin_init_scope;
+
+use crate::{
+ command::Command,
+ model::Model, //
+};
+
+#[pin_data]
+pub(crate) struct Data {
+ #[pin]
+ status: Devres<led::MultiColorDevice<StatusLedHandler>>,
+ power_name: CString,
+ #[pin]
+ power: Devres<led::Device<LedHandler>>,
+}
+
+impl Data {
+ pub(super) fn register<'a>(
+ dev: &'a serdev::Device<Bound>,
+ model: &'a Model,
+ ) -> impl PinInit<Self, Error> + 'a {
+ pin_init_scope(move || {
+ if let Some(color) = model.led_alert {
+ let name = CString::try_from_fmt(fmt!("{}:alarm", color.as_c_str().to_str()?))?;
+ devres::register(
+ dev.as_ref(),
+ led::DeviceBuilder::new().color(color).name(&name).build(
+ dev,
+ try_pin_init!(LedHandler {
+ blink <- new_mutex!(false),
+ command: Command::AlertLed,
+ }),
+ ),
+ GFP_KERNEL,
+ )?;
+ }
+
+ if model.led_usb_copy {
+ devres::register(
+ dev.as_ref(),
+ led::DeviceBuilder::new()
+ .color(led::Color::Green)
+ .name(c"green:usb")
+ .build(
+ dev,
+ try_pin_init!(LedHandler {
+ blink <- new_mutex!(false),
+ command: Command::UsbLed,
+ }),
+ ),
+ GFP_KERNEL,
+ )?;
+ }
+
+ if model.led_esata {
+ devres::register(
+ dev.as_ref(),
+ led::DeviceBuilder::new()
+ .color(led::Color::Green)
+ .name(c"green:esata")
+ .build(
+ dev,
+ try_pin_init!(LedHandler {
+ blink <- new_mutex!(false),
+ command: Command::EsataLed,
+ }),
+ ),
+ GFP_KERNEL,
+ )?;
+ }
+
+ Ok(try_pin_init!(Self {
+ status <- led::DeviceBuilder::new()
+ .color(led::Color::Multi)
+ .name(c"multicolor:status")
+ .build_multicolor(
+ dev,
+ try_pin_init!(StatusLedHandler {
+ blink <- new_mutex!(false),
+ }),
+ StatusLedHandler::SUBLEDS,
+ ),
+ power_name: CString::try_from_fmt(fmt!(
+ "{}:power",
+ model.led_power.as_c_str().to_str()?
+ ))?,
+ power <- led::DeviceBuilder::new()
+ .color(model.led_power)
+ .name(power_name)
+ .build(
+ dev,
+ try_pin_init!(LedHandler {
+ blink <- new_mutex!(true),
+ command: Command::PowerLed,
+ }),
+ ),
+ }))
+ })
+ }
+}
+
+#[derive(Copy, Clone)]
+pub(crate) enum StatusLedColor {
+ Green,
+ Orange,
+}
+
+#[derive(Copy, Clone)]
+pub(crate) enum State {
+ On,
+ Blink,
+ Off,
+}
+
+#[pin_data]
+struct LedHandler {
+ #[pin]
+ blink: Mutex<bool>,
+ command: fn(State) -> Command,
+}
+
+#[vtable]
+impl LedOps for LedHandler {
+ type Bus = serdev::Device<Bound>;
+ type Mode = led::Normal;
+ const BLOCKING: bool = true;
+ const MAX_BRIGHTNESS: u32 = 1;
+
+ fn brightness_set(
+ &self,
+ dev: &Self::Bus,
+ _classdev: &led::Device<Self>,
+ brightness: u32,
+ ) -> Result<()> {
+ let mut blink = self.blink.lock();
+ (self.command)(if brightness == 0 {
+ *blink = false;
+ State::Off
+ } else if *blink {
+ State::Blink
+ } else {
+ State::On
+ })
+ .write(dev)?;
+
+ Ok(())
+ }
+
+ fn blink_set(
+ &self,
+ dev: &Self::Bus,
+ _classdev: &led::Device<Self>,
+ delay_on: &mut usize,
+ delay_off: &mut usize,
+ ) -> Result<()> {
+ let mut blink = self.blink.lock();
+
+ (self.command)(if *delay_on == 0 && *delay_off != 0 {
+ State::Off
+ } else if *delay_on != 0 && *delay_off == 0 {
+ State::On
+ } else {
+ *blink = true;
+ *delay_on = 167;
+ *delay_off = 167;
+
+ State::Blink
+ })
+ .write(dev)
+ }
+}
+
+#[pin_data]
+struct StatusLedHandler {
+ #[pin]
+ blink: Mutex<bool>,
+}
+
+impl StatusLedHandler {
+ const SUBLEDS: &[MultiColorSubLed] = &[
+ MultiColorSubLed::new(led::Color::Green).initial_intensity(1),
+ MultiColorSubLed::new(led::Color::Orange),
+ ];
+}
+
+#[vtable]
+impl LedOps for StatusLedHandler {
+ type Bus = serdev::Device<Bound>;
+ type Mode = led::MultiColor;
+ const BLOCKING: bool = true;
+ const MAX_BRIGHTNESS: u32 = 1;
+
+ fn brightness_set(
+ &self,
+ dev: &Self::Bus,
+ classdev: &led::MultiColorDevice<Self>,
+ brightness: u32,
+ ) -> Result<()> {
+ let mut blink = self.blink.lock();
+ if brightness == 0 {
+ *blink = false;
+ }
+
+ let (color, subled_brightness) = if classdev.subleds()[1].intensity == 0 {
+ (StatusLedColor::Green, classdev.subleds()[0].brightness)
+ } else {
+ (StatusLedColor::Orange, classdev.subleds()[1].brightness)
+ };
+
+ Command::StatusLed(
+ color,
+ if subled_brightness == 0 {
+ State::Off
+ } else if *blink {
+ State::Blink
+ } else {
+ State::On
+ },
+ )
+ .write(dev)
+ }
+
+ fn blink_set(
+ &self,
+ dev: &Self::Bus,
+ classdev: &led::MultiColorDevice<Self>,
+ delay_on: &mut usize,
+ delay_off: &mut usize,
+ ) -> Result<()> {
+ let mut blink = self.blink.lock();
+ *blink = true;
+
+ let (color, subled_intensity) = if classdev.subleds()[1].intensity == 0 {
+ (StatusLedColor::Green, classdev.subleds()[0].intensity)
+ } else {
+ (StatusLedColor::Orange, classdev.subleds()[1].intensity)
+ };
+ Command::StatusLed(
+ color,
+ if *delay_on == 0 && *delay_off != 0 {
+ *blink = false;
+ State::Off
+ } else if subled_intensity == 0 {
+ State::Off
+ } else if *delay_on != 0 && *delay_off == 0 {
+ *blink = false;
+ State::On
+ } else {
+ *delay_on = 167;
+ *delay_off = 167;
+
+ State::Blink
+ },
+ )
+ .write(dev)
+ }
+}
diff --git a/drivers/platform/synology_microp/model.rs b/drivers/platform/synology_microp/model.rs
new file mode 100644
index 000000000000..b972aae2b805
--- /dev/null
+++ b/drivers/platform/synology_microp/model.rs
@@ -0,0 +1,171 @@
+// SPDX-License-Identifier: GPL-2.0
+
+use kernel::{
+ led::{
+ self,
+ Color, //
+ },
+ of::DeviceId, //
+};
+
+pub(crate) struct Architecture;
+
+impl Architecture {
+ const fn new() -> Self {
+ Self
+ }
+}
+
+pub(crate) struct Model {
+ #[expect(
+ dead_code,
+ reason = "needed later for architecture specific properties, like poweroff behaviour"
+ )]
+ pub(crate) arch: Architecture,
+ pub(crate) led_power: led::Color,
+ pub(crate) led_alert: Option<led::Color>,
+ pub(crate) led_usb_copy: bool,
+ pub(crate) led_esata: bool,
+}
+
+impl Model {
+ const fn new(arch: Architecture) -> Self {
+ Self {
+ arch,
+ led_power: led::Color::Blue,
+ led_alert: None,
+ led_usb_copy: false,
+ led_esata: false,
+ }
+ }
+
+ const fn led_power(self, color: led::Color) -> Self {
+ Self {
+ led_power: color,
+ ..self
+ }
+ }
+
+ const fn led_alert(self, color: led::Color) -> Self {
+ Self {
+ led_alert: Some(color),
+ ..self
+ }
+ }
+
+ const fn led_esata(self) -> Self {
+ Self {
+ led_esata: true,
+ ..self
+ }
+ }
+
+ const fn led_usb_copy(self) -> Self {
+ Self {
+ led_usb_copy: true,
+ ..self
+ }
+ }
+}
+
+macro_rules! models {
+ [
+ $($arch:ident $(.$arch_func:ident( $($arch_arg:tt)* ))*
+ @ [
+ $($model:ident $(.$func:ident( $($arg:tt)* ))*, )*
+ ],
+ )*
+ ] => {
+ models![
+ $(
+ {
+ Architecture::new()
+ $(
+ .$arch_func($($arch_arg)*)
+ )*
+ }
+ @
+ [
+ $(
+ $model $(.$func($($arg)*))*,
+ )*
+ ],
+ )*
+ ]
+ };
+ [
+ $($arch:block
+ @ [
+ $($model:ident $(.$func:ident( $($arg:tt)* ))*, )*
+ ],
+ )*
+ ] => {
+ [
+ $(
+ $((
+ DeviceId::new(::kernel::c_str!(
+ ::core::concat!(
+ "synology,",
+ ::core::stringify!($model),
+ "-microp",
+ )
+ )),
+ Model::new($arch)
+ $(
+ .$func($($arg)*)
+ )*
+ ),)*
+ )*
+ ]
+ };
+}
+
+kernel::of_device_table!(
+ pub(crate) OF_TABLE,
+ MODULE_OF_TABLE,
+ Model,
+ models![
+ apollolake @ [
+ ds918p,
+ ],
+ evansport @ [
+ ds214play,
+ ],
+ geminilakenk @ [
+ ds225p.led_usb_copy(),
+ ds425p,
+ ],
+ pineview @ [
+ ds710p.led_esata(),
+ ds1010p.led_alert(Color::Orange),
+ ],
+ r1000 @ [
+ ds923p,
+ ds723p,
+ ds1522p,
+ rs422p.led_power(Color::Green),
+ ],
+ r1000nk @ [
+ ds725p,
+ ],
+ rtd1296 @ [
+ ds118,
+ ],
+ rtd1619b @ [
+ ds124,
+ ds223.led_usb_copy(),
+ ds223j,
+ ],
+ v1000 @ [
+ ds1823xsp,
+ rs822p.led_power(Color::Green),
+ rs1221p.led_power(Color::Green),
+ rs1221rpp.led_power(Color::Green),
+ ],
+ v1000nk @ [
+ ds925p,
+ ds1525p,
+ ds1825p,
+ ],
+ ]
+);
diff --git a/drivers/platform/synology_microp/synology_microp.rs b/drivers/platform/synology_microp/synology_microp.rs
new file mode 100644
index 000000000000..51152cc14b1e
--- /dev/null
+++ b/drivers/platform/synology_microp/synology_microp.rs
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Synology Microp driver
+
+use kernel::{
+ device,
+ of,
+ prelude::*,
+ serdev, //
+};
+use pin_init::pin_init_scope;
+
+use crate::model::Model;
+
+pub(crate) mod command;
+mod led;
+mod model;
+
+kernel::module_serdev_device_driver! {
+ type: SynologyMicropDriver,
+ name: "synology_microp",
+ authors: ["Markus Probst <markus.probst@posteo.de>"],
+ description: "Synology Microp driver",
+ license: "GPL v2",
+}
+
+#[pin_data]
+struct SynologyMicropDriver {
+ #[pin]
+ led: led::Data,
+}
+
+#[vtable]
+impl serdev::Driver for SynologyMicropDriver {
+ type IdInfo = Model;
+ const OF_ID_TABLE: Option<of::IdTable<Self::IdInfo>> = Some(&model::OF_TABLE);
+
+ fn probe(
+ dev: &serdev::Device<device::Core>,
+ model: Option<&Model>,
+ ) -> impl PinInit<Self, kernel::error::Error> {
+ pin_init_scope(move || {
+ let model = model.ok_or(EINVAL)?;
+
+ dev.set_baudrate(9600).map_err(|_| EINVAL)?;
+ dev.set_flow_control(false);
+ dev.set_parity(serdev::Parity::None)?;
+
+ Ok(try_pin_init!(Self {
+ led <- led::Data::register(dev, model),
+ }))
+ })
+ }
+}
--
2.52.0
^ permalink raw reply related
* [PATCH v5 2/4] ACPI: of: match PRP0001 in of_match_device
From: Markus Probst via B4 Relay @ 2026-03-29 18:02 UTC (permalink / raw)
To: Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman,
Rafael J. Wysocki, Len Brown, Saravana Kannan
Cc: platform-driver-x86, linux-leds, devicetree, linux-kernel,
rust-for-linux, linux-acpi, Markus Probst
In-Reply-To: <20260329-synology_microp_initial-v5-0-27cb80bdf591@posteo.de>
From: Markus Probst <markus.probst@posteo.de>
Export `acpi_of_match_device` function and use it to match for PRP0001
in `of_match_device`, if the device does not have a device node.
This fixes the match data being NULL when using ACPI PRP0001, even though
the device was matched against an of device table.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
drivers/acpi/bus.c | 7 ++++---
drivers/of/device.c | 9 +++++++--
include/linux/acpi.h | 11 +++++++++++
3 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 2ec095e2009e..cd02f04cf685 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -831,9 +831,9 @@ const struct acpi_device *acpi_companion_match(const struct device *dev)
* identifiers and a _DSD object with the "compatible" property, use that
* property to match against the given list of identifiers.
*/
-static bool acpi_of_match_device(const struct acpi_device *adev,
- const struct of_device_id *of_match_table,
- const struct of_device_id **of_id)
+bool acpi_of_match_device(const struct acpi_device *adev,
+ const struct of_device_id *of_match_table,
+ const struct of_device_id **of_id)
{
const union acpi_object *of_compatible, *obj;
int i, nval;
@@ -866,6 +866,7 @@ static bool acpi_of_match_device(const struct acpi_device *adev,
return false;
}
+EXPORT_SYMBOL_GPL(acpi_of_match_device);
static bool acpi_of_modalias(struct acpi_device *adev,
char *modalias, size_t len)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index f7e75e527667..128682390058 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -11,6 +11,7 @@
#include <linux/mod_devicetable.h>
#include <linux/slab.h>
#include <linux/platform_device.h>
+#include <linux/acpi.h>
#include <asm/errno.h>
#include "of_private.h"
@@ -26,8 +27,12 @@
const struct of_device_id *of_match_device(const struct of_device_id *matches,
const struct device *dev)
{
- if (!matches || !dev->of_node || dev->of_node_reused)
- return NULL;
+ if (!matches || !dev->of_node || dev->of_node_reused) {
+ const struct of_device_id *id = NULL;
+
+ acpi_of_match_device(ACPI_COMPANION(dev), matches, &id);
+ return id;
+ }
return of_match_node(matches, dev->of_node);
}
EXPORT_SYMBOL(of_match_device);
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 4d2f0bed7a06..1cf23edcbfbb 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -736,6 +736,10 @@ const struct acpi_device_id *acpi_match_acpi_device(const struct acpi_device_id
const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
const struct device *dev);
+bool acpi_of_match_device(const struct acpi_device *adev,
+ const struct of_device_id *of_match_table,
+ const struct of_device_id **of_id);
+
const void *acpi_device_get_match_data(const struct device *dev);
extern bool acpi_driver_match_device(struct device *dev,
const struct device_driver *drv);
@@ -965,6 +969,13 @@ static inline const struct acpi_device_id *acpi_match_device(
return NULL;
}
+static inline bool acpi_of_match_device(const struct acpi_device *adev,
+ const struct of_device_id *of_match_table,
+ const struct of_device_id **of_id)
+{
+ return false;
+}
+
static inline const void *acpi_device_get_match_data(const struct device *dev)
{
return NULL;
--
2.52.0
^ permalink raw reply related
* [PATCH v5 0/4] Introduce Synology Microp driver
From: Markus Probst via B4 Relay @ 2026-03-29 18:02 UTC (permalink / raw)
To: Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman,
Rafael J. Wysocki, Len Brown, Saravana Kannan
Cc: platform-driver-x86, linux-leds, devicetree, linux-kernel,
rust-for-linux, linux-acpi, Markus Probst
Synology uses a microcontroller in their NAS devices connected to a
serial port to control certain LEDs, fan speeds, a beeper, to handle
proper shutdown and restart, buttons and fan failures.
This patch series depends on the rust led abstraction [1] and the rust
serdev abstraction [2].
This is only a initial version of the driver able to control LEDs.
The following rust abstractions would be required, to implement the
remaining features:
- hwmon (include/linux/hwmon.h)
- input (include/linux/input.h)
- sysoff handler + hardware protection shutdown (include/linux/reboot.h)
[1] https://lore.kernel.org/rust-for-linux/20260329-rust_leds-v13-0-21a599c5b2d1@posteo.de/
[2] https://lore.kernel.org/rust-for-linux/20260313-rust_serdev-v3-0-c9a3af214f7f@posteo.de/
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
Changes in v5:
- add esata led support
- use different compatible for each model
- add visibility modifier to of_device_table macro
- fix match data missing when using PRP0001
- Link to v4: https://lore.kernel.org/r/20260320-synology_microp_initial-v4-0-0423ddb83ca4@posteo.de
Changes in v4:
- convert to monolithic driver and moved it into drivers/platform
- removed mfd rust abstraction
- moved dt-bindings to embedded-controller
- Link to v3: https://lore.kernel.org/r/20260313-synology_microp_initial-v3-0-ad6ac463a201@posteo.de
Changes in v3:
- remove `default n` from Kconfig entry, as n is the default already.
- select RUST_SERIAL_DEV_BUS_ABSTRACTIONS in Kconfig
- add mfd rust abstraction
- split core and led parts into their own driver. It should now be considered a
MFD device.
- split led part of dt binding into its own file
- Link to v2: https://lore.kernel.org/r/20260308-synology_microp_initial-v2-0-9389963f31c5@posteo.de
Changes in v2:
- fix missing tabs in MAINTAINERS file
- remove word binding from patch subject
- add missing signed-off-by
- add missing help entry in Kconfig
- add missing spdx license headers
- remove no-check{,-cpu}-fan properties from the dt-bindings and replace
them with the check_fan module parameter
- use patternProperties for leds in dt-bindings
- license dt-binding as GPL-2.0-only OR BSD-2-Clause
- move driver from staging tree into mfd tree and mark it as work in
progress inside Kconfig
- only register alert and usb led if fwnode is present
- Link to v1: https://lore.kernel.org/r/20260306-synology_microp_initial-v1-0-fcffede6448c@posteo.de
---
Markus Probst (4):
dt-bindings: embedded-controller: Add synology microp devices
ACPI: of: match PRP0001 in of_match_device
rust: add visibility to of_device_table macro
platform: Add initial synology microp driver
.../synology,ds923p-microp.yaml | 65 +++++
MAINTAINERS | 6 +
drivers/acpi/bus.c | 7 +-
drivers/of/device.c | 9 +-
drivers/platform/Kconfig | 2 +
drivers/platform/Makefile | 1 +
drivers/platform/synology_microp/Kconfig | 13 +
drivers/platform/synology_microp/Makefile | 3 +
drivers/platform/synology_microp/TODO | 7 +
drivers/platform/synology_microp/command.rs | 55 ++++
drivers/platform/synology_microp/led.rs | 276 +++++++++++++++++++++
drivers/platform/synology_microp/model.rs | 171 +++++++++++++
.../platform/synology_microp/synology_microp.rs | 54 ++++
include/linux/acpi.h | 11 +
rust/kernel/of.rs | 5 +-
15 files changed, 678 insertions(+), 7 deletions(-)
---
base-commit: d1d81e9d1a4dd846aee9ae77ff9ecc2800d72148
change-id: 20260306-synology_microp_initial-0f7dac7b7496
prerequisite-change-id: 20251217-rust_serdev-ee5481e9085c:v3
prerequisite-patch-id: 52b17274481cc770c257d8f95335293eca32a2c5
prerequisite-patch-id: eec47e5051640d08bcd34a9670b98804449cad52
prerequisite-patch-id: f24b68c71c3f69371e8ac0251efca0a023b31cc4
prerequisite-patch-id: 3dfc1f7e5ecd3e0dd65d676aeb16f55260847b25
prerequisite-change-id: 20251114-rust_leds-a959f7c2f7f9:v13
prerequisite-patch-id: 818700f22dcb9676157c985f82762d7c607b861e
prerequisite-patch-id: b15ffa7d95d9260151bfb116b259c4473f721c82
prerequisite-patch-id: 8c47e0d107530f577a1be0b79f8ee791f95d3cbe
^ permalink raw reply
* [PATCH v5 1/4] dt-bindings: embedded-controller: Add synology microp devices
From: Markus Probst via B4 Relay @ 2026-03-29 18:02 UTC (permalink / raw)
To: Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman,
Rafael J. Wysocki, Len Brown, Saravana Kannan
Cc: platform-driver-x86, linux-leds, devicetree, linux-kernel,
rust-for-linux, linux-acpi, Markus Probst
In-Reply-To: <20260329-synology_microp_initial-v5-0-27cb80bdf591@posteo.de>
From: Markus Probst <markus.probst@posteo.de>
Add the Synology Microp devicetree bindings. Those devices are
microcontrollers found on Synology NAS devices. They are connected to a
serial port on the host device.
Those devices are used to control certain LEDs, fan speeds, a beeper, to
handle buttons, fan failures and to properly shutdown and reboot the
device.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
.../synology,ds923p-microp.yaml | 65 ++++++++++++++++++++++
1 file changed, 65 insertions(+)
diff --git a/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml b/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml
new file mode 100644
index 000000000000..599d32ce2be9
--- /dev/null
+++ b/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/embedded-controller/synology,ds923p-microp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synology NAS on-board Microcontroller
+
+maintainers:
+ - Markus Probst <markus.probst@posteo.de>
+
+description: |
+ Synology Microp is a microcontroller found in Synology NAS devices.
+ It is connected to a serial port on the host device.
+
+ It is necessary to properly shutdown and reboot the NAS device and
+ provides additional functionality such as led control, fan speed control,
+ a beeper and buttons on the NAS device.
+
+properties:
+ compatible:
+ enum:
+ - synology,ds923p-microp
+ - synology,ds918p-microp
+ - synology,ds214play-microp
+ - synology,ds225p-microp
+ - synology,ds425p-microp
+ - synology,ds710p-microp
+ - synology,ds1010p-microp
+ - synology,ds723p-microp
+ - synology,ds1522p-microp
+ - synology,rs422p-microp
+ - synology,ds725p-microp
+ - synology,ds118-microp
+ - synology,ds124-microp
+ - synology,ds223-microp
+ - synology,ds223j-microp
+ - synology,ds1823xsp-microp
+ - synology,rs822p-microp
+ - synology,rs1221p-microp
+ - synology,rs1221rpp-microp
+ - synology,ds925p-microp
+ - synology,ds1525p-microp
+ - synology,ds1825p-microp
+
+ fan-failure-gpios:
+ description: GPIOs needed to determine which fans stopped working on a fan failure event.
+ minItems: 2
+ maxItems: 3
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ embedded-controller {
+ compatible = "synology,ds923p-microp";
+
+ fan-failure-gpios = <&gpio 68 GPIO_ACTIVE_HIGH>, <&gpio 69 GPIO_ACTIVE_HIGH>;
+ };
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v3 06/24] dt-bindings: firmware: arm,scmi: Add support for telemetry protocol
From: Cristian Marussi @ 2026-03-29 18:00 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Cristian Marussi, etienne.carriere, Krzysztof Kozlowski, d-gole,
linux-fsdevel, Conor Dooley, linux-doc, f.fainelli,
vincent.guittot, philip.radford, souvik.chakravarty, peng.fan,
dan.carpenter, lukasz.luba, arm-scmi, sudeep.holla, michal.simek,
linux-kernel, jonathan.cameron, elif.topuz, linux-arm-kernel,
james.quinlan, devicetree, brauner
In-Reply-To: <177480549380.3925363.5137815678176793743.robh@kernel.org>
On Sun, Mar 29, 2026 at 12:31:33PM -0500, Rob Herring (Arm) wrote:
>
> On Sun, 29 Mar 2026 17:33:17 +0100, Cristian Marussi wrote:
> > Add new SCMI v4.0 Telemetry protocol bindings definitions.
> >
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> > Cc: Conor Dooley <conor+dt@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > ---
> > Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/firmware/arm,scmi.example.dtb: scmi (arm,scmi): protocol@19: Unevaluated properties are not allowed ('i2c2-pins', 'keys-pins', 'mdio-pins' were unexpected)
> from schema $id: http://devicetree.org/schemas/firmware/arm,scmi.yaml
>
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.kernel.org/project/devicetree/patch/20260329163337.637393-7-cristian.marussi@arm.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
Yes...the new protocol block definition ended up intermixed with the
previous protocol block...totally wrong.
My bad.
I will fix in V4.
Thanks,
Cristian
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: qcom: kaanpaali: Add USB support for QRD platform
From: Krishna Kurapati @ 2026-03-29 17:52 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja,
Jingyi Wang, Krishna Kurapati
In-Reply-To: <20260329175249.2946508-1-krishna.kurapati@oss.qualcomm.com>
From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
Enable USB support on Kaanapali QRD variant. Enable USB controller in
device mode till glink node is added.
Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
index 6a7eb7f4050a..1929ea273a4f 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
@@ -80,6 +80,11 @@ key-volume-up {
wakeup-source;
};
};
+
+ pmih0108_e1_eusb2_repeater {
+ vdd18-supply = <&vreg_l15b_1p8>;
+ vdd3-supply = <&vreg_l5b_3p1>;
+ };
};
&apps_rsc {
@@ -821,3 +826,25 @@ &ufs_mem_phy {
status = "okay";
};
+
+&usb {
+ dr_mode = "peripheral";
+
+ status = "okay";
+};
+
+&usb_hsphy {
+ vdd-supply = <&vreg_l4f_0p8>;
+ vdda12-supply = <&vreg_l1d_1p2>;
+
+ phys = <&pmih0108_e1_eusb2_repeater>;
+
+ status = "okay";
+};
+
+&usb_dp_qmpphy {
+ vdda-phy-supply = <&vreg_l1d_1p2>;
+ vdda-pll-supply = <&vreg_l4f_0p8>;
+
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: qcom: kaanpaali: Add USB support for MTP platform
From: Krishna Kurapati @ 2026-03-29 17:52 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja,
Jingyi Wang, Krishna Kurapati
In-Reply-To: <20260329175249.2946508-1-krishna.kurapati@oss.qualcomm.com>
From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
Enable USB support on Kaanapali MTP variant. Enable USB controller in
device mode till glink node is added.
Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
index a603f3056d83..38269aebdf03 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
@@ -82,6 +82,11 @@ key-volume-up {
};
};
+ pmih0108_e1_eusb2_repeater {
+ vdd18-supply = <&vreg_l15b_1p8>;
+ vdd3-supply = <&vreg_l5b_3p1>;
+ };
+
sound {
compatible = "qcom,kaanapali-sndcard", "qcom,sm8450-sndcard";
model = "Kaanapali-MTP";
@@ -1326,3 +1331,25 @@ &ufs_mem_phy {
status = "okay";
};
+
+&usb {
+ dr_mode = "peripheral";
+
+ status = "okay";
+};
+
+&usb_hsphy {
+ vdd-supply = <&vreg_l4f_0p8>;
+ vdda12-supply = <&vreg_l1d_1p2>;
+
+ phys = <&pmih0108_e1_eusb2_repeater>;
+
+ status = "okay";
+};
+
+&usb_dp_qmpphy {
+ vdda-phy-supply = <&vreg_l1d_1p2>;
+ vdda-pll-supply = <&vreg_l4f_0p8>;
+
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/3] arm64: dts: qcom: kaanapali: Add USB support for Kaanapali SoC
From: Krishna Kurapati @ 2026-03-29 17:52 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja,
Jingyi Wang, Krishna Kurapati
In-Reply-To: <20260329175249.2946508-1-krishna.kurapati@oss.qualcomm.com>
From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
Add the base USB devicetree definitions for Kaanapali platform. The overall
chipset contains a single DWC3 USB3 controller (rev. 200a), SS QMP PHY
(rev. v8) and M31 eUSB2 PHY.
Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 154 ++++++++++++++++++++++++
1 file changed, 154 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index ac6a6c789902..08d7c1a1d829 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -6026,6 +6026,160 @@ pdp_tx: scp-sram-section@100 {
reg = <0x100 0x80>;
};
};
+
+ usb_hsphy: phy@88e3000 {
+ compatible = "qcom,kaanapali-m31-eusb2-phy",
+ "qcom,sm8750-m31-eusb2-phy";
+ reg = <0x0 0x88e3000 0x0 0x29c>;
+
+ clocks = <&tcsr TCSR_USB2_CLKREF_EN>;
+ clock-names = "ref";
+
+ resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
+
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
+ usb_dp_qmpphy: phy@88e8000 {
+ compatible = "qcom,kaanapali-qmp-usb3-dp-phy",
+ "qcom,sm8750-qmp-usb3-dp-phy";
+ reg = <0x0 0x088e8000 0x0 0x4000>;
+
+ clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
+ <&tcsr TCSR_USB3_CLKREF_EN>,
+ <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
+ <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
+ clock-names = "aux",
+ "ref",
+ "com_aux",
+ "usb3_pipe";
+
+ resets = <&gcc GCC_USB3_PHY_PRIM_BCR>,
+ <&gcc GCC_USB3_DP_PHY_PRIM_BCR>;
+ reset-names = "phy",
+ "common";
+
+ power-domains = <&gcc GCC_USB3_PHY_GDSC>;
+
+ #clock-cells = <1>;
+ #phy-cells = <1>;
+
+ orientation-switch;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb_dp_qmpphy_out: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb_dp_qmpphy_usb_ss_in: endpoint {
+ remote-endpoint = <&usb_dwc3_ss>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ usb_dp_qmpphy_dp_in: endpoint {
+ };
+ };
+ };
+ };
+
+ usb: usb@a600000 {
+ compatible = "qcom,kaanapali-dwc3", "qcom,snps-dwc3";
+ reg = <0x0 0x0a600000 0x0 0xfc100>;
+
+ clocks = <&gcc GCC_CFG_NOC_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_USB30_PRIM_MASTER_CLK>,
+ <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_USB30_PRIM_SLEEP_CLK>,
+ <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>;
+ clock-names = "cfg_noc",
+ "core",
+ "iface",
+ "sleep",
+ "mock_utmi";
+
+ assigned-clocks = <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
+ <&gcc GCC_USB30_PRIM_MASTER_CLK>;
+ assigned-clock-rates = <19200000>, <200000000>;
+
+ interrupts-extended = <&intc GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>,
+ <&intc GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
+ <&intc GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
+ <&pdc 14 IRQ_TYPE_EDGE_BOTH>,
+ <&pdc 15 IRQ_TYPE_EDGE_BOTH>,
+ <&pdc 17 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "dwc_usb3",
+ "pwr_event",
+ "hs_phy_irq",
+ "dp_hs_phy_irq",
+ "dm_hs_phy_irq",
+ "ss_phy_irq";
+
+ power-domains = <&gcc GCC_USB30_PRIM_GDSC>;
+ required-opps = <&rpmhpd_opp_nom>;
+
+ resets = <&gcc GCC_USB30_PRIM_BCR>;
+
+ interconnects = <&aggre_noc MASTER_USB3 QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_USB3 QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "usb-ddr", "apps-usb";
+ iommus = <&apps_smmu 0x40 0x0>;
+
+ phys = <&usb_hsphy>, <&usb_dp_qmpphy QMP_USB43DP_USB3_PHY>;
+ phy-names = "usb2-phy", "usb3-phy";
+
+ snps,hird-threshold = /bits/ 8 <0x0>;
+ snps,usb2-gadget-lpm-disable;
+ snps,dis_u2_susphy_quirk;
+ snps,dis_enblslpm_quirk;
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
+ snps,is-utmi-l1-suspend;
+ snps,usb3_lpm_capable;
+ snps,usb2-lpm-disable;
+ snps,has-lpm-erratum;
+ tx-fifo-resize;
+ dma-coherent;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb_dwc3_hs: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb_dwc3_ss: endpoint {
+ remote-endpoint = <&usb_dp_qmpphy_usb_ss_in>;
+ };
+ };
+ };
+ };
};
thermal-zones {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/3] Add USB support for Kaanapali
From: Krishna Kurapati @ 2026-03-29 17:52 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Krishna Kurapati
Add support for the PHYs and controllers used for USB on Kaanapali SoCs.
V1 of this was a consolidated series of many functionlities on Kaanapali.
The first patch is patch-6 from v1 unchanges. The second and third patches
are parts of MTP and QRD specific changes (patches 14 and 16) and commit
text modified to indicate mtp and qrd specific changes are being made.
Ronak is the original author of the patches. Kept Jingyi's and mine SoB
(with no CDB) since we just rebased and send the patches in v1 and v2.
Since SoCCP changes are not acked yet, enabling only device mode.
Changes in v2:
- Sent USB specific changes instead of all MTP and QRD specific changes
Link to v1:
https://lore.kernel.org/all/20250924-knp-dts-v1-0-3fdbc4b9e1b1@oss.qualcomm.com/
Ronak Raheja (3):
arm64: dts: qcom: kaanapali: Add USB support for Kaanapali SoC
arm64: dts: qcom: kaanpaali: Add USB support for MTP platform
arm64: dts: qcom: kaanpaali: Add USB support for QRD platform
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 27 ++++
arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 27 ++++
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 154 +++++++++++++++++++++
3 files changed, 208 insertions(+)
--
2.34.1
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: bridge: ldb: Require reg property only for i.MX6SX/8MP LDBs
From: Marco Felsch @ 2026-03-29 17:42 UTC (permalink / raw)
To: Liu Ying
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Laurentiu Palcu,
dri-devel, devicetree, linux-kernel
In-Reply-To: <20260329-fsl_ldb_schema_fix-v1-1-351372754bc0@nxp.com>
Hi Liu,
sorry for not writting back earlier, the last weeks were quite busy.
On 26-03-29, Liu Ying wrote:
> LDB's parent device could be a syscon which doesn't allow a reg property
> to be present in it's child devices, e.g., NXP i.MX93 Media blk-ctrl
> has a child device NXP i.MX93 Parallel Display Format Configuration(PDFC)
> without a reg property(LDB is also a child device of the Media blk-ctrl).
> To make the LDB schema be able to describe LDBs without the reg property
> like i.MX93 LDB, require the reg property only for i.MX6SX/8MP LDBs.
NACK, we want to describe the HW and from HW PoV the LDB is and was
always part of a syscon. This is the case for all SoCs i.MX6SX/8MP/93.
> Fixes: 8aa2f0ac08d3 ("dt-bindings: display: bridge: ldb: Add check for reg and reg-names")
Therefore I would just revert this patch completely.
Regards,
Marco
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> ---
> .../bindings/display/bridge/fsl,ldb.yaml | 23 ++++++++++++++++------
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
> index 7f380879fffd..5f6dc2b11d7b 100644
> --- a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
> @@ -28,6 +28,7 @@ properties:
> const: ldb
>
> reg:
> + minItems: 1
> maxItems: 2
>
> reg-names:
> @@ -68,7 +69,6 @@ required:
> - compatible
> - clocks
> - ports
> - - reg
>
> allOf:
> - if:
> @@ -83,12 +83,23 @@ allOf:
> ports:
> properties:
> port@2: false
> +
> - if:
> - not:
> - properties:
> - compatible:
> - contains:
> - const: fsl,imx6sx-ldb
> + properties:
> + compatible:
> + contains:
> + enum:
> + - fsl,imx6sx-ldb
> + - fsl,imx8mp-ldb
> + then:
> + required:
> + - reg
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: fsl,imx8mp-ldb
> then:
> required:
> - reg-names
>
> ---
> base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
> change-id: 20260329-fsl_ldb_schema_fix-4fe01c42bff3
>
> Best regards,
> --
> Liu Ying <victor.liu@nxp.com>
>
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
^ permalink raw reply
* Re: [PATCH net-next 00/10] net: airoha: Support multiple net_devices connected to the same GDM port
From: Jakub Kicinski @ 2026-03-29 17:36 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
linux-arm-kernel, linux-mediatek, netdev, devicetree, Xuegang Lu
In-Reply-To: <20260329-airoha-eth-multi-serdes-v1-0-00f52dc360ca@kernel.org>
On Sun, 29 Mar 2026 15:07:50 +0200 Lorenzo Bianconi wrote:
> EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw multiplexer that
> manages the traffic in a TDM manner. As a result multiple net_devices can
> connect to the same GDM{3,4} port and there is a theoretical "1:n"
> relation between GDM ports and net_devices.
Does not apply.
^ permalink raw reply
* Re: [PATCH v3 06/24] dt-bindings: firmware: arm,scmi: Add support for telemetry protocol
From: Rob Herring (Arm) @ 2026-03-29 17:31 UTC (permalink / raw)
To: Cristian Marussi
Cc: etienne.carriere, Krzysztof Kozlowski, d-gole, linux-fsdevel,
Conor Dooley, linux-doc, f.fainelli, vincent.guittot,
philip.radford, souvik.chakravarty, peng.fan, dan.carpenter,
lukasz.luba, arm-scmi, sudeep.holla, michal.simek, linux-kernel,
jonathan.cameron, elif.topuz, linux-arm-kernel, james.quinlan,
devicetree, brauner
In-Reply-To: <20260329163337.637393-7-cristian.marussi@arm.com>
On Sun, 29 Mar 2026 17:33:17 +0100, Cristian Marussi wrote:
> Add new SCMI v4.0 Telemetry protocol bindings definitions.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> Cc: Rob Herring <robh@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> ---
> Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/firmware/arm,scmi.example.dtb: scmi (arm,scmi): protocol@19: Unevaluated properties are not allowed ('i2c2-pins', 'keys-pins', 'mdio-pins' were unexpected)
from schema $id: http://devicetree.org/schemas/firmware/arm,scmi.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260329163337.637393-7-cristian.marussi@arm.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH] dt-bindings: mailbox: qcom-ipcc: Document the Eliza Inter-Processor Communication Controller
From: Jassi Brar @ 2026-03-29 17:10 UTC (permalink / raw)
To: Abel Vesa
Cc: Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260327-eliza-bindings-mailbox-ipcc-v1-1-3f1c89bdf72e@oss.qualcomm.com>
On Fri, Mar 27, 2026 at 7:36 AM Abel Vesa <abel.vesa@oss.qualcomm.com> wrote:
>
> Document the Inter-Processor Communication Controller (IPCC) found in the
> Qualcomm Eliza SoC. It is used to route interrupts across various
> subsystems.
>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> index 7c4d6170491d..f5c584cf2146 100644
> --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> @@ -24,6 +24,7 @@ properties:
> compatible:
> items:
> - enum:
> + - qcom,eliza-ipcc
> - qcom,glymur-ipcc
> - qcom,kaanapali-ipcc
> - qcom,milos-ipcc
>
Applied to mailbox/for-next
Thanks
Jassi
^ permalink raw reply
* [PATCH v3 0/3] riscv: dts: spacemit: Add PMIC regulators usb pcie
From: Han Gao @ 2026-03-29 17:05 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan
Cc: devicetree, linux-riscv, spacemit, linux-kernel, Han Gao, Han Gao
Changes in v3:
- Merge patch 2 into 3
- Fix
Rename regulator-name from USB30_HUB to USB_HUB_EN
Drop regulator-usb3-vbus-5v
Drop reset-gpios from usb hub nodes
Fix reg_dc_in regulator-name from "dc_in_12v" to "dc_in_5v"
- Link to v2: https://lore.kernel.org/linux-riscv/20260310161853.3900605-1-gaohan@iscas.ac.cn/
Han Gao (3):
riscv: dts: spacemit: Enable i2c8 adapter for OrangePi RV2
riscv: dts: spacemit: Define the P1 PMIC regulators for OrangePi RV2
riscv: dts: spacemit: Enable USB3.0/PCIe on OrangePi RV2
.../boot/dts/spacemit/k1-orangepi-rv2.dts | 222 ++++++++++++++++++
1 file changed, 222 insertions(+)
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
prerequisite-patch-id: ef6e9c7b5854d0c08066b72f9a7868db8c2140eb
prerequisite-patch-id: cfe3800f8c791ec4c63e070af9628e88e0fc31b9
prerequisite-patch-id: b76493e625ae257c8adcd67874178458420e4d47
prerequisite-patch-id: 88e01dc92c83bd88ddeb78891d3088209fed8d6b
prerequisite-patch-id: 60336d10ab8322c70596d0f046b6b5c54bb24b54
prerequisite-patch-id: 68c4d869548687dc115dd91e2ffb8f4c11482d86
prerequisite-patch-id: fdadcf964c2cb3406160edb579d99a8d5695f8e6
prerequisite-patch-id: 73b9e745338b0499b849fa4f7f9508987ab39a59
prerequisite-patch-id: cd26770c2160c3c31a406bd8a6b01ab666180ae0
prerequisite-patch-id: e5dfddc32cefae195692da8b80e19adf086e4ad7
prerequisite-patch-id: 7fd53cbe4977598f26148a4bb1cf692bbdb79a09
prerequisite-patch-id: 96ebac57bb29619b97fe95422206a685825618e9
prerequisite-patch-id: 00fac16b52f60383db3140e2885f3f7f8d14dd1a
prerequisite-patch-id: 3b7a60047b922c48e93599f621cb738856f42354
prerequisite-patch-id: 275c030b963be05dd1041451f539a130ce614277
prerequisite-patch-id: 93963424b0871e64276af0e0b2199b52e29b4603
prerequisite-patch-id: 8383188b1c01ed6280629faaa29c37d699ade241
prerequisite-patch-id: 5f8126b912b924d63d4a1e0c5eb42d212eb0d369
--
2.47.3
^ permalink raw reply
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