* [PATCH net-next v3 5/9] net: dsa: lan9645x: add bridge support
From: Jens Emil Schulz Østergaard @ 2026-04-10 11:48 UTC (permalink / raw)
To: UNGLinuxDriver, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Woojung Huh,
Russell King, Steen Hegelund, Daniel Machon
Cc: linux-kernel, netdev, devicetree,
Jens Emil Schulz Østergaard
In-Reply-To: <20260410-dsa_lan9645x_switch_driver_base-v3-0-aadc8595306d@microchip.com>
Add support for hardware offloading of the bridge. We support a single
bridge device.
Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
Signed-off-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
---
Changes in v3:
- allow disabling aging with explicit zero parameters.
- fix non-forwarding stp states
- fix restore host_flood requests on bridge leave
Changes in v2:
- variable name consistency
- port_set_learning use stp_state before writing to hw
- add set_host_flood for selftests, which need promic/all_multi on
standalone interfaces
---
drivers/net/dsa/microchip/lan9645x/lan9645x_main.c | 296 +++++++++++++++++++++
drivers/net/dsa/microchip/lan9645x/lan9645x_main.h | 18 ++
2 files changed, 314 insertions(+)
diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
index 3e68542ba81d..e709396c2298 100644
--- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
+++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
@@ -28,6 +28,14 @@ static const char *lan9645x_resource_names[NUM_TARGETS + 1] = {
[NUM_TARGETS] = NULL,
};
+struct lan9645x_host_flood_work {
+ struct work_struct work;
+ struct lan9645x *lan9645x;
+ int port;
+ bool uc;
+ bool mc;
+};
+
static int lan9645x_tag_npi_setup(struct dsa_switch *ds)
{
struct dsa_port *dp, *first_cpu_dp = NULL;
@@ -61,7 +69,9 @@ static void lan9645x_teardown(struct dsa_switch *ds)
{
struct lan9645x *lan9645x = ds->priv;
+ destroy_workqueue(lan9645x->owq);
lan9645x_npi_port_deinit(lan9645x, lan9645x->npi);
+ mutex_destroy(&lan9645x->fwd_domain_lock);
}
static int lan9645x_change_mtu(struct dsa_switch *ds, int port, int new_mtu)
@@ -145,6 +155,8 @@ static int lan9645x_setup(struct dsa_switch *ds)
return err;
}
+ mutex_init(&lan9645x->fwd_domain_lock);
+
/* Link Aggregation Mode: NETDEV_LAG_HASH_L2 */
lan_wr(ANA_AGGR_CFG_AC_SMAC_ENA |
ANA_AGGR_CFG_AC_DMAC_ENA,
@@ -242,6 +254,11 @@ static int lan9645x_setup(struct dsa_switch *ds)
lan9645x_port_set_tail_drop_wm(lan9645x);
+ lan9645x->owq = alloc_ordered_workqueue("%s-owq", 0,
+ dev_name(lan9645x->dev));
+ if (!lan9645x->owq)
+ return -ENOMEM;
+
ds->mtu_enforcement_ingress = true;
ds->assisted_learning_on_cpu_port = true;
ds->fdb_isolation = true;
@@ -260,6 +277,276 @@ static void lan9645x_port_phylink_get_caps(struct dsa_switch *ds, int port,
lan9645x_phylink_get_caps(ds->priv, port, config);
}
+static int lan9645x_set_ageing_time(struct dsa_switch *ds, unsigned int msecs)
+{
+ u32 age_secs = max(1, msecs / MSEC_PER_SEC / 2);
+ struct lan9645x *lan9645x = ds->priv;
+
+ /* Entry is must suffer two aging scans before it is removed, so it is
+ * aged after 2*AGE_PERIOD, and the unit is in seconds.
+ * An age period of 0 disables automatic aging.
+ */
+ lan_rmw(ANA_AUTOAGE_AGE_PERIOD_SET(msecs ? age_secs : 0),
+ ANA_AUTOAGE_AGE_PERIOD,
+ lan9645x, ANA_AUTOAGE);
+ return 0;
+}
+
+static int lan9645x_port_pre_bridge_flags(struct dsa_switch *ds, int port,
+ struct switchdev_brport_flags flags,
+ struct netlink_ext_ack *extack)
+{
+ if (flags.mask &
+ ~(BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD))
+ return -EINVAL;
+
+ return 0;
+}
+
+static void lan9645x_port_pgid_set(struct lan9645x *lan9645x, u16 pgid,
+ int chip_port, bool enabled)
+{
+ u32 reg_msk, port_msk;
+
+ WARN_ON(chip_port > CPU_PORT);
+
+ port_msk = ANA_PGID_PGID_SET(enabled ? BIT(chip_port) : 0);
+ reg_msk = ANA_PGID_PGID_SET(BIT(chip_port));
+
+ lan_rmw(port_msk, reg_msk, lan9645x, ANA_PGID(pgid));
+}
+
+static void lan9645x_port_set_learning(struct lan9645x *lan9645x, int port,
+ bool enabled)
+{
+ struct lan9645x_port *p = lan9645x_to_port(lan9645x, port);
+
+ p->learn_ena = enabled;
+
+ enabled = enabled && (p->stp_state == BR_STATE_LEARNING ||
+ p->stp_state == BR_STATE_FORWARDING);
+
+ lan_rmw(ANA_PORT_CFG_LEARN_ENA_SET(enabled), ANA_PORT_CFG_LEARN_ENA,
+ lan9645x, ANA_PORT_CFG(port));
+}
+
+static int lan9645x_port_bridge_flags(struct dsa_switch *ds, int port,
+ struct switchdev_brport_flags f,
+ struct netlink_ext_ack *extack)
+{
+ struct lan9645x *lan9645x = ds->priv;
+
+ if (WARN_ON(port == lan9645x->npi))
+ return -EINVAL;
+
+ if (f.mask & BR_LEARNING)
+ lan9645x_port_set_learning(lan9645x, port,
+ !!(f.val & BR_LEARNING));
+
+ if (f.mask & BR_FLOOD)
+ lan9645x_port_pgid_set(lan9645x, PGID_UC, port,
+ !!(f.val & BR_FLOOD));
+
+ if (f.mask & BR_MCAST_FLOOD) {
+ bool ena = !!(f.val & BR_MCAST_FLOOD);
+
+ lan9645x_port_pgid_set(lan9645x, PGID_MC, port, ena);
+ lan9645x_port_pgid_set(lan9645x, PGID_MCIPV4, port, ena);
+ lan9645x_port_pgid_set(lan9645x, PGID_MCIPV6, port, ena);
+ }
+
+ if (f.mask & BR_BCAST_FLOOD)
+ lan9645x_port_pgid_set(lan9645x, PGID_BC, port,
+ !!(f.val & BR_BCAST_FLOOD));
+
+ return 0;
+}
+
+static void lan9645x_update_fwd_mask(struct lan9645x *lan9645x)
+{
+ struct lan9645x_port *p;
+ struct dsa_port *dp;
+
+ lockdep_assert_held(&lan9645x->fwd_domain_lock);
+
+ /* Updates the source port PGIDs, making sure frames from p
+ * are only forwarded to ports q != p, where q is relevant to forward
+ */
+ dsa_switch_for_each_available_port(dp, lan9645x->ds) {
+ u32 mask = 0;
+
+ p = lan9645x_to_port(lan9645x, dp->index);
+
+ if (lan9645x_port_is_bridged(p) &&
+ (lan9645x->bridge_fwd_mask & BIT(dp->index))) {
+ mask = lan9645x->bridge_mask &
+ lan9645x->bridge_fwd_mask & ~BIT(dp->index);
+ }
+
+ lan_wr(mask, lan9645x, ANA_PGID(PGID_SRC + dp->index));
+ }
+}
+
+static void __lan9645x_port_mark_host_flood(struct lan9645x *lan9645x, int port,
+ bool uc, bool mc)
+{
+ lockdep_assert_held(&lan9645x->fwd_domain_lock);
+
+ if (uc)
+ lan9645x->host_flood_uc_mask |= BIT(port);
+ else
+ lan9645x->host_flood_uc_mask &= ~BIT(port);
+
+ if (mc)
+ lan9645x->host_flood_mc_mask |= BIT(port);
+ else
+ lan9645x->host_flood_mc_mask &= ~BIT(port);
+}
+
+static void __lan9645x_port_set_host_flood(struct lan9645x *lan9645x, int port)
+{
+ bool mc_ena, uc_ena;
+ u16 unbridged;
+
+ lockdep_assert_held(&lan9645x->fwd_domain_lock);
+
+ /* We want promiscuous and all_multi to affect standalone ports, for
+ * debug and test purposes.
+ *
+ * However, the linux bridge is incredibly eager to put bridged ports in
+ * promiscuous mode.
+
+ * This is unfortunate since lan9645x flood masks are global and not per
+ * ingress port. When some port triggers unknown uc/mc to the CPU, the
+ * traffic from any port is forwarded to the CPU.
+ *
+ * If the host CPU is weak, this can cause tremendous stress. Therefore,
+ * we compromise by ignoring this host flood request for bridged ports.
+ */
+ unbridged = ~lan9645x->bridge_mask & GENMASK(NUM_PHYS_PORTS - 1, 0);
+
+ uc_ena = !!(lan9645x->host_flood_uc_mask & unbridged);
+ lan9645x_port_pgid_set(lan9645x, PGID_UC, CPU_PORT, uc_ena);
+
+ mc_ena = !!(lan9645x->host_flood_mc_mask & unbridged);
+ lan9645x_port_pgid_set(lan9645x, PGID_MC, CPU_PORT, mc_ena);
+ lan9645x_port_pgid_set(lan9645x, PGID_MCIPV4, CPU_PORT, mc_ena);
+ lan9645x_port_pgid_set(lan9645x, PGID_MCIPV6, CPU_PORT, mc_ena);
+}
+
+static void lan9645x_host_flood_work_fn(struct work_struct *work)
+{
+ struct lan9645x_host_flood_work *w =
+ container_of(work, struct lan9645x_host_flood_work, work);
+
+ mutex_lock(&w->lan9645x->fwd_domain_lock);
+ __lan9645x_port_mark_host_flood(w->lan9645x, w->port, w->uc, w->mc);
+ __lan9645x_port_set_host_flood(w->lan9645x, w->port);
+ mutex_unlock(&w->lan9645x->fwd_domain_lock);
+ kfree(w);
+}
+
+/* Called in atomic context */
+static void lan9645x_port_set_host_flood(struct dsa_switch *ds, int port,
+ bool uc, bool mc)
+{
+ struct lan9645x *lan9645x = ds->priv;
+ struct lan9645x_host_flood_work *w;
+
+ w = kzalloc_obj(*w, GFP_ATOMIC);
+ if (!w)
+ return;
+
+ INIT_WORK(&w->work, lan9645x_host_flood_work_fn);
+ w->lan9645x = lan9645x;
+ w->port = port;
+ w->uc = uc;
+ w->mc = mc;
+ queue_work(lan9645x->owq, &w->work);
+}
+
+static int lan9645x_port_bridge_join(struct dsa_switch *ds, int port,
+ struct dsa_bridge bridge,
+ bool *tx_fwd_offload,
+ struct netlink_ext_ack *extack)
+{
+ struct lan9645x *lan9645x = ds->priv;
+ struct lan9645x_port *p;
+
+ p = lan9645x_to_port(lan9645x, port);
+
+ if (lan9645x->bridge && lan9645x->bridge != bridge.dev) {
+ NL_SET_ERR_MSG_MOD(extack, "Only one bridge supported");
+ return -EBUSY;
+ }
+
+ mutex_lock(&lan9645x->fwd_domain_lock);
+ /* First bridged port sets bridge dev */
+ if (!lan9645x->bridge_mask)
+ lan9645x->bridge = bridge.dev;
+
+ lan9645x->bridge_mask |= BIT(p->chip_port);
+ __lan9645x_port_set_host_flood(lan9645x, port);
+
+ mutex_unlock(&lan9645x->fwd_domain_lock);
+
+ /* Later: stp_state_set updates forwarding */
+
+ return 0;
+}
+
+static void lan9645x_port_bridge_stp_state_set(struct dsa_switch *ds, int port,
+ u8 state)
+{
+ struct lan9645x *lan9645x;
+ struct lan9645x_port *p;
+ bool learn_ena;
+
+ lan9645x = ds->priv;
+ p = lan9645x_to_port(lan9645x, port);
+
+ mutex_lock(&lan9645x->fwd_domain_lock);
+
+ p->stp_state = state;
+
+ if (state == BR_STATE_FORWARDING)
+ lan9645x->bridge_fwd_mask |= BIT(p->chip_port);
+ else
+ lan9645x->bridge_fwd_mask &= ~BIT(p->chip_port);
+
+ learn_ena = (state == BR_STATE_LEARNING ||
+ state == BR_STATE_FORWARDING) && p->learn_ena;
+
+ lan_rmw(ANA_PORT_CFG_LEARN_ENA_SET(learn_ena),
+ ANA_PORT_CFG_LEARN_ENA, lan9645x,
+ ANA_PORT_CFG(p->chip_port));
+
+ lan9645x_update_fwd_mask(lan9645x);
+ mutex_unlock(&lan9645x->fwd_domain_lock);
+}
+
+static void lan9645x_port_bridge_leave(struct dsa_switch *ds, int port,
+ struct dsa_bridge bridge)
+{
+ struct lan9645x *lan9645x = ds->priv;
+ struct lan9645x_port *p;
+
+ p = lan9645x_to_port(lan9645x, port);
+
+ mutex_lock(&lan9645x->fwd_domain_lock);
+
+ lan9645x->bridge_mask &= ~BIT(p->chip_port);
+
+ /* Last port leaving clears bridge dev */
+ if (!lan9645x->bridge_mask)
+ lan9645x->bridge = NULL;
+
+ __lan9645x_port_set_host_flood(lan9645x, port);
+ lan9645x_update_fwd_mask(lan9645x);
+
+ mutex_unlock(&lan9645x->fwd_domain_lock);
+}
+
static const struct dsa_switch_ops lan9645x_switch_ops = {
.get_tag_protocol = lan9645x_get_tag_protocol,
@@ -273,6 +560,15 @@ static const struct dsa_switch_ops lan9645x_switch_ops = {
/* MTU */
.port_change_mtu = lan9645x_change_mtu,
.port_max_mtu = lan9645x_get_max_mtu,
+
+ /* Bridge integration */
+ .set_ageing_time = lan9645x_set_ageing_time,
+ .port_pre_bridge_flags = lan9645x_port_pre_bridge_flags,
+ .port_bridge_flags = lan9645x_port_bridge_flags,
+ .port_bridge_join = lan9645x_port_bridge_join,
+ .port_bridge_leave = lan9645x_port_bridge_leave,
+ .port_stp_state_set = lan9645x_port_bridge_stp_state_set,
+ .port_set_host_flood = lan9645x_port_set_host_flood,
};
static int lan9645x_request_target_regmaps(struct lan9645x *lan9645x)
diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.h b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.h
index d8bdcb8a92ed..22576bb8dd52 100644
--- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.h
+++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.h
@@ -155,6 +155,11 @@ struct lan9645x {
struct dsa_switch *ds;
struct regmap *rmap[NUM_TARGETS];
+ u16 host_flood_uc_mask;
+ u16 host_flood_mc_mask;
+
+ struct workqueue_struct *owq;
+
int shared_queue_sz;
/* NPI chip_port */
@@ -163,6 +168,12 @@ struct lan9645x {
u8 num_phys_ports;
struct lan9645x_port **ports;
+ /* Forwarding Database */
+ struct net_device *bridge; /* Only support single bridge */
+ u16 bridge_mask; /* Mask for bridged ports */
+ u16 bridge_fwd_mask; /* Mask for forwarding bridged ports */
+ struct mutex fwd_domain_lock; /* lock forwarding configuration */
+
int num_port_dis;
bool dd_dis;
bool tsn_dis;
@@ -172,6 +183,8 @@ struct lan9645x_port {
struct lan9645x *lan9645x;
u8 chip_port;
+ u8 stp_state;
+ bool learn_ena;
bool rx_internal_delay;
bool tx_internal_delay;
@@ -224,6 +237,11 @@ static inline struct lan9645x_port *lan9645x_to_port(struct lan9645x *lan9645x,
return lan9645x->ports[port];
}
+static inline bool lan9645x_port_is_bridged(struct lan9645x_port *p)
+{
+ return p && (p->lan9645x->bridge_mask & BIT(p->chip_port));
+}
+
static inline struct regmap *lan_tgt2rmap(struct lan9645x *lan9645x,
enum lan9645x_target t, int tinst)
{
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v3 2/9] dt-bindings: net: lan9645x: add LAN9645X switch bindings
From: Jens Emil Schulz Østergaard @ 2026-04-10 11:48 UTC (permalink / raw)
To: UNGLinuxDriver, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Woojung Huh,
Russell King, Steen Hegelund, Daniel Machon
Cc: linux-kernel, netdev, devicetree,
Jens Emil Schulz Østergaard
In-Reply-To: <20260410-dsa_lan9645x_switch_driver_base-v3-0-aadc8595306d@microchip.com>
Add bindings for LAN9645X switch. We use a fallback compatible for the
smallest SKU microchip,lan96455s-switch.
Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
Signed-off-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
---
Changes in v3:
- remove additionalProperties: true
- remove unnecessary | from description
- change top level $ref to dsa.yaml#/$defs/ethernet-ports
- use ethernet-ports and ethernet-port
- move ethernet-ports under properties instead of patternProperties
- move unevaluatedProperties: false after $ref
- update example to use ethernet-ports and ethernet-port
Changes in v2:
- rename file to microchip,lan96455s-switch.yaml
- remove led vendor property
- add {rx,tx}-internal-delay-ps for rgmii delay
- remove labels from example
- remove container node from example
---
.../net/dsa/microchip,lan96455s-switch.yaml | 111 +++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 112 insertions(+)
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..043fb48922b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/microchip,lan96455s-switch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip LAN9645x Ethernet switch
+
+maintainers:
+ - Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
+
+description:
+ The LAN9645x switch is a multi-port Gigabit AVB/TSN Ethernet switch with
+ five integrated 10/100/1000Base-T PHYs. In addition to the integrated PHYs,
+ it supports up to 2 RGMII/RMII, up to 2 BASE-X/SERDES/2.5GBASE-X and one
+ Quad-SGMII interfaces.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - microchip,lan96455s-switch
+ - items:
+ - enum:
+ - microchip,lan96455f-switch
+ - microchip,lan96457f-switch
+ - microchip,lan96459f-switch
+ - microchip,lan96457s-switch
+ - microchip,lan96459s-switch
+ - const: microchip,lan96455s-switch
+
+ reg:
+ maxItems: 1
+
+ ethernet-ports:
+ type: object
+ patternProperties:
+ "^ethernet-port@[0-8]$":
+ type: object
+ description: Ethernet switch ports
+
+ $ref: dsa-port.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ rx-internal-delay-ps:
+ const: 2000
+
+ tx-internal-delay-ps:
+ const: 2000
+
+$ref: dsa.yaml#/$defs/ethernet-ports
+
+required:
+ - compatible
+ - reg
+ - ethernet-ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet-switch@4000 {
+ compatible = "microchip,lan96459f-switch", "microchip,lan96455s-switch";
+ reg = <0x4000 0x244>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-port@0 {
+ reg = <0>;
+ phy-mode = "gmii";
+ phy-handle = <&cuphy0>;
+ };
+
+ ethernet-port@1 {
+ reg = <1>;
+ phy-mode = "gmii";
+ phy-handle = <&cuphy1>;
+ };
+
+ ethernet-port@2 {
+ reg = <2>;
+ phy-mode = "gmii";
+ phy-handle = <&cuphy2>;
+ };
+
+ ethernet-port@3 {
+ reg = <3>;
+ phy-mode = "gmii";
+ phy-handle = <&cuphy3>;
+ };
+
+ ethernet-port@7 {
+ reg = <7>;
+ phy-mode = "rgmii";
+ ethernet = <&cpu_host_port>;
+ rx-internal-delay-ps = <2000>;
+ tx-internal-delay-ps = <2000>;
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+ };
+ };
+...
+
diff --git a/MAINTAINERS b/MAINTAINERS
index a8e4b5f5da3c..eeb67eed905c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17283,6 +17283,7 @@ M: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
M: UNGLinuxDriver@microchip.com
L: netdev@vger.kernel.org
S: Maintained
+F: Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
F: include/linux/dsa/lan9645x.h
F: net/dsa/tag_lan9645x.c
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v3 0/9] net: dsa: add DSA support for the LAN9645x switch chip family
From: Jens Emil Schulz Østergaard @ 2026-04-10 11:48 UTC (permalink / raw)
To: UNGLinuxDriver, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Woojung Huh,
Russell King, Steen Hegelund, Daniel Machon
Cc: linux-kernel, netdev, devicetree,
Jens Emil Schulz Østergaard
This series provides the Microchip LAN9645X Switch driver.
The LAN9645x is a family of chips with ethernet switch functionality and
multiple peripheral functions. The switch delivers up to 9 ethernet
ports and 12 Gbps switching bandwidth.
The switch chip has 5 integrated copper PHYs, support for 2x RGMII
interfaces, 2x SGMII and one QSGMII interface.
The switch chip is from the same design architecture family as ocelot
and lan966x, and the driver reflects this similarity. However, LAN9645x
does not have an internal CPU in any package, and must be driven
externally. For register IO it supports interfaces such as SPI, I2C and
MDIO.
The chip supports a variety of network features such as
* Mactable for MDB/FDB functionality
* Bridge forwarding offload
* VLAN-aware bridging
* IGMP/MLD snooping
* Link aggregation
* PTP timestamping
* FRER (802.1CB)
* Media Redundancy Protocol
* Parallel Redundancy and High-Availability Seamless Redundancy
(HSR/PRP) in DANH/DANP mode
* Per stream filtering and policing
* Shapers such as Credit Based Shaping and Time Aware Shaing
* Frame preemption
* A TCAM (VCAP) for line-rate frame processing
The LAN9645x family consists of the following SKUs:
LAN96455F
LAN96457F
LAN96459F
LAN96455S
LAN96457S
LAN96459S
The difference between the SKUs is the number of supported ports (5, 7
or 9) and features supported. The F subfamily supports HSR/PRP and TSN,
while the S subfamily does not.
The intended way to bind this driver is using a parent MFD driver,
responsible for the register IO protocol, and distributing regmaps to
child devices. The goal is to use the same approach as the MFD driver in
drivers/mfd/ocelot-spi.c.
This driver expects to request named regmaps from a parent device. This
approach is similar to the DSA driver
drivers/net/dsa/ocelot/ocelot_ext.c
which supports being driven by an external CPU via SPI with parent
device drivers/mfd/ocelot-spi.c.
The MFD driver will come in a later series, because there are
requirements on the number of child devices before a driver qualifies as
a MFD device.
Development is done using the LAN966x as a host CPU, running the lan966x
swichdev driver, using the EVB-LAN9668 EDS2 board.
The datasheet is available here:
https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/LAN9645xF-Data-Sheet-DS00006065.pdf
This series will deliver the following features:
* Standalone ports
* Bridge forwarding and FDB offloading
* VLAN-aware bridge
* Stats integration
More support will be added at a later stage. Here is a tentative plan of
future patches for this DSA driver:
* Add LAG support.
* Add MDB support.
* Add TC matchall mirror support.
* Add TC matchall police support.
* Add DCB/qos support.
* Add simple TC support: mqprio, cbs, tbf, ebf.
* Add TC flower filter support.
* Add HSR/PRP offloading support.
* Add PTP support.
* Add TC taprio support.
For completeness I include tentative plan of planned patches for
LAN9645x peripherals:
* Extend pinctrl-ocelot for LAN9645x:
https://lore.kernel.org/linux-gpio/20260119-pinctrl_ocelot_extend_support_for_lan9645x-v1-0-1228155ed0ee@microchip.com/
* Add driver for internal PHY:
https://lore.kernel.org/netdev/20260123-phy_micrel_add_support_for_lan9645x_internal_phy-v1-1-8484b1a5a7fd@microchip.com/
* MFD driver for managing register IO protocol and child device
initialization.
* Extend pinctrl-microchip-sgpio for LAN9645x support.
* Extend i2c_designware for LAN9645x support.
* Add driver for outbound interrupt controller.
* Add serdes driver for lan9645x.
Signed-off-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
---
Changes in v3:
- Individual patches mention specific v3 changes.
- Add guard before vlan_remove_tag on xmit
- Add pskb_may_pull checks on rx
- Remove additionalProperties: true in bindings
- Remove unnecessary | from description in bindings
- Change top level $ref to dsa.yaml#/$defs/ethernet-ports
- Use ethernet-ports and ethernet-port
- Move ethernet-ports under properties instead of patternProperties
- Move unevaluatedProperties: false after $ref
- Update bindings example to use ethernet-ports and ethernet-port
- Move DEV_MAC_TAGS_CFG to port setup, instead of vlan config, so vlan
overhead is always included in port frame maxlen calculation.
- Remove code disabling ipv6 on conduit
- Use of_property_read_u32 for {rx,tx}-internal-delay-ps
- Use dsa_user_ports(ds) instead of
GENMASK(lan9645x->num_phys_ports - 1, 0) as base flood mask.
- Add comment explaining obey vlan
- Allow disabling aging with explicit zero parameters.
- Fix non-forwarding STP states in bridge fwd calculation.
- Restore host flood state on bridge leave.
- Avoid mac_entry dealloc when mac table writes fail.
- Avoid mdb_entry dealloc when mac table writes fail.
- Dealloc mac_entries on deinit.
- Dealloc mdb_entries on deinit.
- Link to v2: https://lore.kernel.org/r/20260324-dsa_lan9645x_switch_driver_base-v2-0-f7504e3b0681@microchip.com
Changes in v2:
- Individual patches have specific v2 changes.
- Ran DSA, and std counters, selftests, which prompted several changes.
The following selftests pass, except for some expected failures:
- bridge_vlan_aware.sh
- bridge_vlan_unaware.sh
- bridge_vlan_mcast.sh
- no_forwarding.sh
- bridge_mdb.sh
- bridge_mld.sh
- test_fdb_stress_test.sh
- .../drivers/net/hw/ethtool_rmon.sh
- .../drivers/net/hw/ethtool_std_stats.sh (from Ioana's series)
- Added new patch for MDB management, as this was required for selftests.
- Added port_set_host_flood to enable unknown traffic to standalone during
promisc/ALL_MULTI (selftests).
- Remove the dubugfs.
- Link to v1: https://lore.kernel.org/r/20260303-dsa_lan9645x_switch_driver_base-v1-0-bff8ca1396f5@microchip.com
---
Jens Emil Schulz Østergaard (9):
net: dsa: add tag driver for LAN9645X
dt-bindings: net: lan9645x: add LAN9645X switch bindings
net: dsa: lan9645x: add autogenerated register macros
net: dsa: lan9645x: add basic dsa driver for LAN9645X
net: dsa: lan9645x: add bridge support
net: dsa: lan9645x: add vlan support
net: dsa: lan9645x: add mac table integration
net: dsa: lan9645x: add mdb management
net: dsa: lan9645x: add port statistics
.../net/dsa/microchip,lan96455s-switch.yaml | 111 ++
MAINTAINERS | 10 +
drivers/net/dsa/Kconfig | 2 +
drivers/net/dsa/microchip/Makefile | 1 +
drivers/net/dsa/microchip/lan9645x/Kconfig | 11 +
drivers/net/dsa/microchip/lan9645x/Makefile | 12 +
drivers/net/dsa/microchip/lan9645x/lan9645x_mac.c | 430 +++++
drivers/net/dsa/microchip/lan9645x/lan9645x_main.c | 993 ++++++++++
drivers/net/dsa/microchip/lan9645x/lan9645x_main.h | 450 +++++
drivers/net/dsa/microchip/lan9645x/lan9645x_mdb.c | 383 ++++
drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c | 76 +
.../net/dsa/microchip/lan9645x/lan9645x_phylink.c | 381 ++++
drivers/net/dsa/microchip/lan9645x/lan9645x_port.c | 204 +++
drivers/net/dsa/microchip/lan9645x/lan9645x_regs.h | 1915 ++++++++++++++++++++
.../net/dsa/microchip/lan9645x/lan9645x_stats.c | 922 ++++++++++
.../net/dsa/microchip/lan9645x/lan9645x_stats.h | 277 +++
drivers/net/dsa/microchip/lan9645x/lan9645x_vlan.c | 378 ++++
include/linux/dsa/lan9645x.h | 145 ++
include/net/dsa.h | 2 +
net/dsa/Kconfig | 11 +
net/dsa/Makefile | 1 +
net/dsa/tag_lan9645x.c | 301 +++
22 files changed, 7016 insertions(+)
---
base-commit: b3e69fc3196fc421e26196e7792f17b0463edc6f
change-id: 20260210-dsa_lan9645x_switch_driver_base-312bbfc37edb
Best regards,
--
Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
^ permalink raw reply
* [PATCH net-next v3 1/9] net: dsa: add tag driver for LAN9645X
From: Jens Emil Schulz Østergaard @ 2026-04-10 11:48 UTC (permalink / raw)
To: UNGLinuxDriver, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Woojung Huh,
Russell King, Steen Hegelund, Daniel Machon
Cc: linux-kernel, netdev, devicetree,
Jens Emil Schulz Østergaard
In-Reply-To: <20260410-dsa_lan9645x_switch_driver_base-v3-0-aadc8595306d@microchip.com>
Add tag driver for LAN9645x using a front port as CPU port. This mode
is called an NPI port in the datasheet.
Use long prefix on extraction (RX) and no prefix on injection (TX). A
long prefix on extraction helps get through the conduit port on host
side, since it will see a broadcast MAC.
The LAN9645x chip is in the same design architecture family as ocelot
and lan966x. The tagging protocol has the same structure as these chips,
but the particular fields are different or have different sizes.
Therefore, this tag driver is similar to tag_ocelot.c, but the
differences in fields makes it hard to reuse.
LAN9645x supports 3 different tag formats for extraction/injection of
frames from a CPU port: long prefix, short prefix and no prefix.
The tag is prepended to the frame. The critical data for the chip is
contained in an internal frame header (IFH) which is 28 bytes. The
prefix formats look like this:
Long prefix (16 bytes) + IFH:
- DMAC = 0xffffffffffff on extraction.
- SMAC = 0xfeffffffffff on extraction.
- ETYPE = 0x8880
- payload = 0x0011
- IFH
Short prefix (4 bytes) + IFH:
- 0x8880
- 0x0011
- IFH
No prefix:
- IFH
The format can be configured asymmetrically on RX and TX.
The IFH get/set functions are declared as inline. All the field
constants are compile-time known, so when these calls are inlined
efficient code is generated with branches pruned and loops unrolled.
During testing it was observed that without explicit inlining GCC would
have trouble inlining the functions, which hurt performance.
Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
Signed-off-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
---
Changes in v3:
- guard vlan_remove_tag behind skb_headlen(skb) >= VLAN_ETH_HLEN on xmit
- add pskb_may_pull checks in rx path
Changes in v2:
- sorting in net/dsa/Kconfig
- sorting in net/dsa/Makefile
- remove default zero promisc_on_conduit
- move functions to to .c file
- add justification for inline usage to commit message
- add __skb_put_padto on xmit path
- fix hwaccel_put_tag
---
MAINTAINERS | 8 ++
include/linux/dsa/lan9645x.h | 134 ++++++++++++++++++++
include/net/dsa.h | 2 +
net/dsa/Kconfig | 11 ++
net/dsa/Makefile | 1 +
net/dsa/tag_lan9645x.c | 286 +++++++++++++++++++++++++++++++++++++++++++
6 files changed, 442 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d1e6d3acbac..a8e4b5f5da3c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17278,6 +17278,14 @@ L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/phy/microchip_t1.c
+MICROCHIP LAN9645X ETHERNET SWITCH DRIVER
+M: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
+M: UNGLinuxDriver@microchip.com
+L: netdev@vger.kernel.org
+S: Maintained
+F: include/linux/dsa/lan9645x.h
+F: net/dsa/tag_lan9645x.c
+
MICROCHIP LAN966X ETHERNET DRIVER
M: Horatiu Vultur <horatiu.vultur@microchip.com>
M: UNGLinuxDriver@microchip.com
diff --git a/include/linux/dsa/lan9645x.h b/include/linux/dsa/lan9645x.h
new file mode 100644
index 000000000000..34c18bf975d0
--- /dev/null
+++ b/include/linux/dsa/lan9645x.h
@@ -0,0 +1,134 @@
+/* SPDX-License-Identifier: GPL-2.0
+ * Copyright (C) 2026 Microchip Technology Inc.
+ */
+
+#ifndef _NET_DSA_TAG_LAN9645X_H_
+#define _NET_DSA_TAG_LAN9645X_H_
+
+#include <net/dsa.h>
+
+/* LAN9645x supports 3 different formats on an NPI port, long prefix, short
+ * prefix and no prefix. The format can be configured asymmetrically on RX and
+ * TX. We use long prefix on extraction (RX), and no prefix on injection.
+ * The long prefix on extraction helps get through the conduit port on host
+ * side, since it will see a broadcast MAC.
+ *
+ * The internal frame header (IFH) is 28 bytes, and the fields are documented
+ * below.
+ *
+ * Long prefix, 16 bytes + IFH:
+ * - DMAC = 0xFFFFFFFFFFFF on extraction.
+ * - SMAC = 0xFEFFFFFFFFFF on extraction.
+ * - ETYPE = 0x8880
+ * - payload = 0x0011
+ * - IFH
+ *
+ * Short prefix, 4 bytes + IFH:
+ * - 0x8880
+ * - 0x0011
+ * - IFH
+ *
+ * No prefix:
+ * - IFH
+ *
+ */
+#define LAN9645X_IFH_TAG_TYPE_C 0
+#define LAN9645X_IFH_TAG_TYPE_S 1
+#define LAN9645X_IFH_LEN_U32 7
+#define LAN9645X_IFH_LEN (LAN9645X_IFH_LEN_U32 * sizeof(u32))
+#define LAN9645X_IFH_BITS (LAN9645X_IFH_LEN * BITS_PER_BYTE)
+#define LAN9645X_SHORT_PREFIX_LEN 4
+#define LAN9645X_LONG_PREFIX_LEN 16
+#define LAN9645X_TOTAL_TAG_LEN (LAN9645X_LONG_PREFIX_LEN + LAN9645X_IFH_LEN)
+
+#define IFH_INJ_TIMESTAMP 192
+#define IFH_BYPASS 191
+#define IFH_MASQ 190
+#define IFH_TIMESTAMP 186
+#define IFH_TIMESTAMP_NS 194
+#define IFH_TIMESTAMP_SUBNS 186
+#define IFH_MASQ_PORT 186
+#define IFH_RCT_INJ 185
+#define IFH_LEN 171
+#define IFH_WRDMODE 169
+#define IFH_RTAGD 167
+#define IFH_CUTTHRU 166
+#define IFH_REW_CMD 156
+#define IFH_REW_OAM 155
+#define IFH_PDU_TYPE 151
+#define IFH_FCS_UPD 150
+#define IFH_DP 149
+#define IFH_RTE_INB_UPDATE 148
+#define IFH_POP_CNT 146
+#define IFH_ETYPE_OFS 144
+#define IFH_SRCPORT 140
+#define IFH_SEQ_NUM 120
+#define IFH_TAG_TYPE 119
+#define IFH_TCI 103
+#define IFH_DSCP 97
+#define IFH_QOS_CLASS 94
+#define IFH_CPUQ 86
+#define IFH_LEARN_FLAGS 84
+#define IFH_SFLOW_ID 80
+#define IFH_ACL_HIT 79
+#define IFH_ACL_IDX 73
+#define IFH_ISDX 65
+#define IFH_DSTS 55
+#define IFH_FLOOD 53
+#define IFH_SEQ_OP 51
+#define IFH_IPV 48
+#define IFH_AFI 47
+#define IFH_RTP_ID 37
+#define IFH_RTP_SUBID 36
+#define IFH_PN_DATA_STATUS 28
+#define IFH_PN_TRANSF_STATUS_ZERO 27
+#define IFH_PN_CC 11
+#define IFH_DUPL_DISC_ENA 10
+#define IFH_RCT_AVAIL 9
+
+#define IFH_INJ_TIMESTAMP_SZ 32
+#define IFH_BYPASS_SZ 1
+#define IFH_MASQ_SZ 1
+#define IFH_TIMESTAMP_SZ 38
+#define IFH_TIMESTAMP_NS_SZ 30
+#define IFH_TIMESTAMP_SUBNS_SZ 8
+#define IFH_MASQ_PORT_SZ 4
+#define IFH_RCT_INJ_SZ 1
+#define IFH_LEN_SZ 14
+#define IFH_WRDMODE_SZ 2
+#define IFH_RTAGD_SZ 2
+#define IFH_CUTTHRU_SZ 1
+#define IFH_REW_CMD_SZ 10
+#define IFH_REW_OAM_SZ 1
+#define IFH_PDU_TYPE_SZ 4
+#define IFH_FCS_UPD_SZ 1
+#define IFH_DP_SZ 1
+#define IFH_RTE_INB_UPDATE_SZ 1
+#define IFH_POP_CNT_SZ 2
+#define IFH_ETYPE_OFS_SZ 2
+#define IFH_SRCPORT_SZ 4
+#define IFH_SEQ_NUM_SZ 16
+#define IFH_TAG_TYPE_SZ 1
+#define IFH_TCI_SZ 16
+#define IFH_DSCP_SZ 6
+#define IFH_QOS_CLASS_SZ 3
+#define IFH_CPUQ_SZ 8
+#define IFH_LEARN_FLAGS_SZ 2
+#define IFH_SFLOW_ID_SZ 4
+#define IFH_ACL_HIT_SZ 1
+#define IFH_ACL_IDX_SZ 6
+#define IFH_ISDX_SZ 8
+#define IFH_DSTS_SZ 10
+#define IFH_FLOOD_SZ 2
+#define IFH_SEQ_OP_SZ 2
+#define IFH_IPV_SZ 3
+#define IFH_AFI_SZ 1
+#define IFH_RTP_ID_SZ 10
+#define IFH_RTP_SUBID_SZ 1
+#define IFH_PN_DATA_STATUS_SZ 8
+#define IFH_PN_TRANSF_STATUS_ZERO_SZ 1
+#define IFH_PN_CC_SZ 16
+#define IFH_DUPL_DISC_ENA_SZ 1
+#define IFH_RCT_AVAIL_SZ 1
+
+#endif /* _NET_DSA_TAG_LAN9645X_H_ */
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 8b6d34e8a6f0..f900dc0e1301 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -58,6 +58,7 @@ struct tc_action;
#define DSA_TAG_PROTO_YT921X_VALUE 30
#define DSA_TAG_PROTO_MXL_GSW1XX_VALUE 31
#define DSA_TAG_PROTO_MXL862_VALUE 32
+#define DSA_TAG_PROTO_LAN9645X_VALUE 33
enum dsa_tag_protocol {
DSA_TAG_PROTO_NONE = DSA_TAG_PROTO_NONE_VALUE,
@@ -93,6 +94,7 @@ enum dsa_tag_protocol {
DSA_TAG_PROTO_YT921X = DSA_TAG_PROTO_YT921X_VALUE,
DSA_TAG_PROTO_MXL_GSW1XX = DSA_TAG_PROTO_MXL_GSW1XX_VALUE,
DSA_TAG_PROTO_MXL862 = DSA_TAG_PROTO_MXL862_VALUE,
+ DSA_TAG_PROTO_LAN9645X = DSA_TAG_PROTO_LAN9645X_VALUE,
};
struct dsa_switch;
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index 5ed8c704636d..f3facb12e96e 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -75,6 +75,17 @@ config NET_DSA_TAG_HELLCREEK
Say Y or M if you want to enable support for tagging frames
for the Hirschmann Hellcreek TSN switches.
+config NET_DSA_TAG_LAN9645X
+ tristate "Tag driver for Lan9645x switches"
+ help
+ Say Y or M if you want to enable NPI tagging for the Lan9645x switches.
+ In this mode, the frames over the Ethernet CPU port are prepended with
+ a hardware-defined injection/extraction frame header.
+ On injection a 28 byte internal frame header (IFH) is used. On
+ extraction a 16 byte prefix is prepended before the internal frame
+ header. This prefix starts with a broadcast MAC, to ease passage
+ through the host side RX filter.
+
config NET_DSA_TAG_GSWIP
tristate "Tag driver for Lantiq / Intel GSWIP switches"
help
diff --git a/net/dsa/Makefile b/net/dsa/Makefile
index bf7247759a64..ca1e2dc90b80 100644
--- a/net/dsa/Makefile
+++ b/net/dsa/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_NET_DSA_TAG_GSWIP) += tag_gswip.o
obj-$(CONFIG_NET_DSA_TAG_HELLCREEK) += tag_hellcreek.o
obj-$(CONFIG_NET_DSA_TAG_KSZ) += tag_ksz.o
obj-$(CONFIG_NET_DSA_TAG_LAN9303) += tag_lan9303.o
+obj-$(CONFIG_NET_DSA_TAG_LAN9645X) += tag_lan9645x.o
obj-$(CONFIG_NET_DSA_TAG_MTK) += tag_mtk.o
obj-$(CONFIG_NET_DSA_TAG_MXL_862XX) += tag_mxl862xx.o
obj-$(CONFIG_NET_DSA_TAG_MXL_GSW1XX) += tag_mxl-gsw1xx.o
diff --git a/net/dsa/tag_lan9645x.c b/net/dsa/tag_lan9645x.c
new file mode 100644
index 000000000000..6dae3b9ec240
--- /dev/null
+++ b/net/dsa/tag_lan9645x.c
@@ -0,0 +1,286 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2026 Microchip Technology Inc.
+ */
+
+#include <linux/dsa/lan9645x.h>
+
+#include "tag.h"
+
+#define LAN9645X_NAME "lan9645x"
+
+#define BTM_MSK(n) ((u8)GENMASK(n, 0))
+#define TOP_MSK(n) ((u8)GENMASK(7, n))
+
+static inline void set_merge_mask(u8 *on_zero, u8 on_one, u8 mask)
+{
+ *on_zero = *on_zero ^ ((*on_zero ^ on_one) & mask);
+}
+
+/* The internal frame header (IFH) is a big-endian 28 byte unpadded bit array.
+ * Frames can be prepended with an IFH on injection and extraction. There
+ * are two field layouts, one for extraction and one for injection.
+ *
+ * IFH bits go from high to low, for instance
+ * ifh[0] = [223:216]
+ * ifh[27] = [7:0]
+ *
+ * Here is an example of setting a value starting at bit 13 of bit length 17.
+ *
+ * val = 0x1ff
+ * pos = 13
+ * length = 17
+ *
+ *
+ * IFH[] 0 23 24 25 26 27
+ *
+ * end_u8 start_u8
+ * +--------+----------------+--------+--------+--------+--------+--------+
+ * | | | | | | | |
+ * IFH | | .... | | vvvvvvvvvvvvvvvvvvv | |
+ * | | | | | | | | | |
+ * +--------+----------------+--------+--+-----+--------+--+-----+--------+
+ * Bits 223 39 32 31| 24 23 16 15| 8 7 0
+ * | |
+ * | |
+ * | |
+ * v v
+ * end = 29 pos = 13
+ * end_rem = 5 pos_rem = 5
+ * end_u8 = 3 start_u8 = 1
+ * BTM_MSK(5)= 0x3f TOP_MSK(5) = 0xe0
+ *
+ *
+ * In end_u8 and start_u8 we must merge the existing IFH byte with the new
+ * value. In the 'middle' bytes of the value we can overwrite the corresponding
+ * IFH byte.
+ */
+static inline void lan9645x_ifh_set(u8 *ifh, u32 val, size_t pos, size_t length)
+{
+ size_t end = (pos + length) - 1;
+ size_t end_rem = end & 0x7;
+ size_t pos_rem = pos & 0x7;
+ size_t start_u8 = pos >> 3;
+ size_t end_u8 = end >> 3;
+ u8 end_mask, start_mask;
+ size_t vshift;
+ u8 *ptr;
+
+ BUILD_BUG_ON_MSG(length > 32, "IFH field size wider than 32.");
+ BUILD_BUG_ON_MSG(length == 0, "IFH field size of 0.");
+ BUILD_BUG_ON_MSG(pos + length > LAN9645X_IFH_BITS,
+ "IFH field overflows IFH");
+
+ end_mask = BTM_MSK(end_rem);
+ start_mask = TOP_MSK(pos_rem);
+
+ ptr = &ifh[LAN9645X_IFH_LEN - 1 - end_u8];
+
+ if (end_u8 == start_u8)
+ return set_merge_mask(ptr, val << pos_rem,
+ end_mask & start_mask);
+
+ vshift = length - end_rem - 1;
+ set_merge_mask(ptr++, val >> vshift, end_mask);
+
+ for (size_t j = 1; j < end_u8 - start_u8; j++) {
+ vshift -= 8;
+ *ptr++ = val >> vshift;
+ }
+
+ set_merge_mask(ptr, val << pos_rem, start_mask);
+}
+
+static inline u32 lan9645x_ifh_get(const u8 *ifh, size_t pos, size_t length)
+{
+ size_t end = (pos + length) - 1;
+ size_t end_rem = end & 0x7;
+ size_t pos_rem = pos & 0x7;
+ size_t start_u8 = pos >> 3;
+ size_t end_u8 = end >> 3;
+ u8 end_mask, start_mask;
+ const u8 *ptr;
+ u32 val;
+
+ BUILD_BUG_ON_MSG(length > 32, "IFH field size wider than 32.");
+ BUILD_BUG_ON_MSG(length == 0, "IFH field size of 0.");
+ BUILD_BUG_ON_MSG(pos + length > LAN9645X_IFH_BITS,
+ "IFH field overflows IFH");
+
+ end_mask = BTM_MSK(end_rem);
+ start_mask = TOP_MSK(pos_rem);
+
+ ptr = &ifh[LAN9645X_IFH_LEN - 1 - end_u8];
+
+ if (end_u8 == start_u8)
+ return (*ptr & end_mask & start_mask) >> pos_rem;
+
+ val = *ptr++ & end_mask;
+
+ for (size_t j = 1; j < end_u8 - start_u8; j++)
+ val = val << 8 | *ptr++;
+
+ return val << (8 - pos_rem) | (*ptr & start_mask) >> pos_rem;
+}
+
+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 (skb_headlen(skb) >= VLAN_ETH_HLEN &&
+ ntohs(hdr->h_vlan_proto) == proto) {
+ vlan_remove_tag(skb, &tci);
+ *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_xmit(struct sk_buff *skb,
+ struct net_device *ndev)
+{
+ struct dsa_port *dp = dsa_user_to_port(ndev);
+ struct dsa_switch *ds = dp->ds;
+ u32 cpu_port = ds->num_ports;
+ u32 vlan_tci, tag_type;
+ u32 qos_class;
+ void *ifh;
+
+ lan9645x_xmit_get_vlan_info(skb, dsa_port_bridge_dev_get(dp), &vlan_tci,
+ &tag_type);
+
+ /* We need to make sure frame has the proper size after IFH is stripped
+ * by hw.
+ */
+ if (__skb_put_padto(skb, ETH_ZLEN, false))
+ return NULL;
+
+ qos_class = netdev_get_num_tc(ndev) ?
+ netdev_get_prio_tc_map(ndev, skb->priority) :
+ skb->priority;
+
+ /* Make room for IFH */
+ ifh = skb_push(skb, LAN9645X_IFH_LEN);
+ memset(ifh, 0, LAN9645X_IFH_LEN);
+
+ lan9645x_ifh_set(ifh, 1, IFH_BYPASS, IFH_BYPASS_SZ);
+ lan9645x_ifh_set(ifh, cpu_port, IFH_SRCPORT, IFH_SRCPORT_SZ);
+ lan9645x_ifh_set(ifh, tag_type, IFH_TAG_TYPE, IFH_TAG_TYPE_SZ);
+ lan9645x_ifh_set(ifh, vlan_tci, IFH_TCI, IFH_TCI_SZ);
+ lan9645x_ifh_set(ifh, qos_class, IFH_QOS_CLASS, IFH_QOS_CLASS_SZ);
+ lan9645x_ifh_set(ifh, BIT(dp->index), IFH_DSTS, IFH_DSTS_SZ);
+
+ return skb;
+}
+
+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;
+ 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);
+
+ if (unlikely(!pskb_may_pull(skb, LAN9645X_TOTAL_TAG_LEN)))
+ return NULL;
+
+ /* IFH starts after our long prefix */
+ ifh = skb_pull(skb, LAN9645X_LONG_PREFIX_LEN);
+
+ 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);
+ tag_type = lan9645x_ifh_get(ifh, IFH_TAG_TYPE, IFH_TAG_TYPE_SZ);
+ vlan_tci = lan9645x_ifh_get(ifh, IFH_TCI, IFH_TCI_SZ);
+ qos_class = lan9645x_ifh_get(ifh, IFH_QOS_CLASS, IFH_QOS_CLASS_SZ);
+
+ /* Set skb->data at start of real header
+ *
+ * Since REW_PORT_NO_REWRITE=0 is required on the NPI port, we need to
+ * account for any tags popped by the hardware, as that will leave a gap
+ * between the IFH and DMAC.
+ */
+ if (popcnt == 0 && etype_ofs == 0)
+ ifh_gap_len = 2 * VLAN_HLEN;
+ else if (popcnt == 3)
+ ifh_gap_len = VLAN_HLEN;
+
+ skb_pull(skb, LAN9645X_IFH_LEN);
+
+ if (unlikely(!pskb_may_pull(skb, ifh_gap_len + ETH_HLEN)))
+ return NULL;
+
+ skb_pull(skb, ifh_gap_len);
+ skb_reset_mac_header(skb);
+ skb_set_network_header(skb, ETH_HLEN);
+ skb_reset_mac_len(skb);
+
+ /* Reset skb->data past the actual ethernet header. */
+ skb_pull(skb, ETH_HLEN);
+ skb_postpull_rcsum(skb,
+ skb->data - LAN9645X_TOTAL_TAG_LEN - ifh_gap_len,
+ LAN9645X_TOTAL_TAG_LEN + ifh_gap_len);
+
+ skb->dev = dsa_conduit_find_user(ndev, 0, src_port);
+ if (WARN_ON_ONCE(!skb->dev)) {
+ /* This should never happen since we have disabled reflection
+ * back to CPU_PORT.
+ */
+ return NULL;
+ }
+
+ dsa_default_offload_fwd_mark(skb);
+
+ skb->priority = qos_class;
+
+ /* While we have REW_PORT_NO_REWRITE=0 on the NPI port, we still disable
+ * port VLAN tagging with REW_TAG_CFG. Any classified VID, different
+ * from a VID in the frame, will not be written to the frame, but is
+ * only communicated via the IFH. So for VLAN-aware ports we add the IFH
+ * vlan to the skb.
+ */
+ dp = dsa_user_to_port(skb->dev);
+ vlan_tpid = tag_type ? ETH_P_8021AD : ETH_P_8021Q;
+
+ if (dsa_port_is_vlan_filtering(dp) && vlan_tci)
+ __vlan_hwaccel_put_tag(skb, htons(vlan_tpid), vlan_tci);
+
+ return skb;
+}
+
+static const struct dsa_device_ops lan9645x_netdev_ops = {
+ .name = LAN9645X_NAME,
+ .proto = DSA_TAG_PROTO_LAN9645X,
+ .xmit = lan9645x_xmit,
+ .rcv = lan9645x_rcv,
+ .needed_headroom = LAN9645X_TOTAL_TAG_LEN,
+};
+
+MODULE_DESCRIPTION("DSA tag driver for LAN9645x family of switches, using NPI port");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS_DSA_TAG_DRIVER(DSA_TAG_PROTO_LAN9645X, LAN9645X_NAME);
+
+module_dsa_tag_driver(lan9645x_netdev_ops);
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v1 1/2] dt-bindings: usb: dwc3: add support for StarFive JHB100
From: Minda Chen @ 2026-04-10 11:28 UTC (permalink / raw)
To: Conor Dooley, Greg Kroah-Hartman, Thinh Nguyen
Cc: Rob Herring, Krzysztof Kozlowski, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20260409-perish-speckled-1da7daabca31@spud>
> 主题: Re: [PATCH v1 1/2] dt-bindings: usb: dwc3: add support for StarFive JHB100
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> pw-bot: not-applicable
Thanks Conor
Hi Thinh
Could you review patch2? Just add a compatible to generic platform driver. Thanks
Hi Greg
Can this patch-set be merged in v7.1? Thanks
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: usb: dwc3: add support for StarFive JHB100
From: Minda Chen @ 2026-04-10 11:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, Thinh Nguyen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-usb
Cc: linux-kernel, devicetree, Minda Chen
In-Reply-To: <20260410112500.90432-1-minda.chen@starfivetech.com>
Add support for the USB 2.0 Dual-Role Device (DRD) controller embedded
in the StarFive JHB100 SoC. The controller is based on the Synopsys
DesignWare Core USB 3 (DWC3) IP.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../bindings/usb/starfive,jhb100-dwc3.yaml | 64 +++++++++++++++++++
MAINTAINERS | 3 +-
2 files changed, 66 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml
diff --git a/Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml b/Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml
new file mode 100644
index 000000000000..fbabe99e9d5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/starfive,jhb100-dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JHB100 DWC3 USB SoC Controller
+
+maintainers:
+ - Minda Chen <minda.chen@starfivetech.com>
+
+description:
+ The USB DRD controller on JHB100 BMC SoC.
+
+allOf:
+ - $ref: snps,dwc3-common.yaml#
+
+properties:
+ compatible:
+ const: starfive,jhb100-dwc3
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: USB main enable clk
+ - description: DWC3 bus early clock
+ - description: DWC3 ref clock
+
+ clock-names:
+ items:
+ - const: main
+ - const: bus_early
+ - const: ref
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ usb@11800000 {
+ compatible = "starfive,jhb100-dwc3";
+ reg = <0x11800000 0x10000>;
+ clocks = <&usbcrg 9>,
+ <&usbcrg 5>,
+ <&usbcrg 6>;
+ clock-names = "main", "bus_early", "ref";
+ resets = <&usbcrg 4>;
+ interrupts = <105>;
+ dr_mode = "host";
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 32bd94a0b94c..2f3475e0b678 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25252,10 +25252,11 @@ F: Documentation/devicetree/bindings/reset/starfive,jh7100-reset.yaml
F: drivers/reset/starfive/reset-starfive-jh71*
F: include/dt-bindings/reset/starfive?jh71*.h
-STARFIVE JH71X0 USB DRIVERS
+STARFIVE USB DRIVERS
M: Minda Chen <minda.chen@starfivetech.com>
S: Maintained
F: Documentation/devicetree/bindings/usb/starfive,jh7110-usb.yaml
+F: Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml
F: drivers/usb/cdns3/cdns3-starfive.c
STARFIVE JH71XX PMU CONTROLLER DRIVER
--
2.17.1
^ permalink raw reply related
* [PATCH v2 0/2] Add StarFive JHB100 soc BMC DRD USB support
From: Minda Chen @ 2026-04-10 11:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, Thinh Nguyen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-usb
Cc: linux-kernel, devicetree, Minda Chen
JHB100 is a Starfive new RISC-V SoC for datacenter BMC (Baseboard
Managent Controller). Similar with Aspeed 27x0.
The JHB100 minimal system upstream is in progress:
https://patchwork.kernel.org/project/linux-riscv/cover/20260403054945.467700-1-changhuang.liang@starfivetech.com/
JHB100 contain 2 USB 2.0 dwc3 USB port, and integrated with USB
2.0 PHY. These 2 ports just for BMC soc use. Actually JHB100 contain
other dwc3 usb controllers, which is using as xhci over PCIe and locate
in PCIe EP. It is working for host server. But now PCIe EP driver is not
in upstream progress. So just commit BMC USB 2.0 port driver patches to
upstream first.
The patch base in V7.0-rc5
changes form v1:
1. Add review tag to patch1
2.v1 patch 2 delte one more line, v2 just add device compatible.
Minda Chen (2):
dt-bindings: usb: dwc3: add support for StarFive JHB100
usb: dwc3: starfive: Add JHB100 USB 2.0 DRD controller
.../bindings/usb/starfive,jhb100-dwc3.yaml | 64 +++++++++++++++++++
MAINTAINERS | 3 +-
drivers/usb/dwc3/dwc3-generic-plat.c | 1 +
3 files changed, 67 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml
base-commit: c369299895a591d96745d6492d4888259b004a9e
--
2.17.1
^ permalink raw reply
* [PATCH v2 2/2] usb: dwc3: starfive: Add JHB100 USB 2.0 DRD controller
From: Minda Chen @ 2026-04-10 11:25 UTC (permalink / raw)
To: Greg Kroah-Hartman, Thinh Nguyen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-usb
Cc: linux-kernel, devicetree, Minda Chen
In-Reply-To: <20260410112500.90432-1-minda.chen@starfivetech.com>
JHB100 contains 2 dwc3 USB controllers and PHYs and working
as USB 2.0 speed. It can working in generic platform and
setting default properties.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
drivers/usb/dwc3/dwc3-generic-plat.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc3/dwc3-generic-plat.c b/drivers/usb/dwc3/dwc3-generic-plat.c
index e846844e0023..e9e29b63aaa4 100644
--- a/drivers/usb/dwc3/dwc3-generic-plat.c
+++ b/drivers/usb/dwc3/dwc3-generic-plat.c
@@ -214,6 +214,7 @@ static const struct of_device_id dwc3_generic_of_match[] = {
{ .compatible = "spacemit,k1-dwc3", },
{ .compatible = "fsl,ls1028a-dwc3", &fsl_ls1028_dwc3},
{ .compatible = "eswin,eic7700-dwc3", &eic7700_dwc3},
+ { .compatible = "starfive,jhb100-dwc3", },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, dwc3_generic_of_match);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 1/4] dt-bindings: media: Add bindings for qcom,x1p42100-camss
From: Krzysztof Kozlowski @ 2026-04-10 11:36 UTC (permalink / raw)
To: Wenmeng Liu
Cc: Robert Foss, Todor Tomov, Bryan O'Donoghue,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260410-purwa_camss-v1-1-eedcf6d9d8ee@oss.qualcomm.com>
On Fri, Apr 10, 2026 at 12:25:31PM +0800, Wenmeng Liu wrote:
> Add bindings for the Camera Subsystem for X1P42100.
>
A nit, subject: drop second/last, redundant "bindings for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
Please use subject prefixes matching the subsystem. You can get them for
example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
> The X1P42100 platform provides:
> - 2 x CSIPHY
> - 3 x TPG
> - 3 x CSID
> - 2 x CSID Lite
> - 1 x IFE
> - 2 x IFE Lite
>
> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,x1p42100-camss.yaml | 424 +++++++++++++++++++++
> 1 file changed, 424 insertions(+)
>
You have ~20 prerequisities and some are even DTS patches, so either you
organized this wrong or patches are wrong. They cannot depend on DTS.
Probably this does not affect the binding, but it is not really
maintainers task to figure that out. You really should make it obvious
and easy for the community to review.
> diff --git a/Documentation/devicetree/bindings/media/qcom,x1p42100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1p42100-camss.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..8bfa7e616c3b6b91adc8e21ebfbbe6fb579484f6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,x1p42100-camss.yaml
> @@ -0,0 +1,424 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/qcom,x1p42100-camss.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm X1P42100 Camera Subsystem (CAMSS)
> +
> +maintainers:
> + - Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
> +
> +description:
> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
> +
> +properties:
> + compatible:
> + const: qcom,x1p42100-camss
> +
> + reg:
> + maxItems: 14
> +
> + reg-names:
> + items:
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csid_lite0
> + - const: csid_lite1
> + - const: csid_wrapper
> + - const: csiphy0
> + - const: csiphy4
> + - const: csitpg0
> + - const: csitpg1
> + - const: csitpg2
> + - const: vfe0
> + - const: vfe_lite0
> + - const: vfe_lite1
> +
> + '#address-cells':
> + const: 2
> +
> + '#size-cells':
> + const: 2
> +
> + ranges: true
> +
> + clocks:
> + maxItems: 22
> +
> + clock-names:
> + items:
> + - const: camnoc_nrt_axi
> + - const: camnoc_rt_axi
> + - const: core_ahb
> + - const: cpas_ahb
> + - const: cpas_fast_ahb
> + - const: cpas_vfe0
> + - const: cpas_vfe_lite
> + - const: cphy_rx_clk_src
> + - const: csid
> + - const: csid_csiphy_rx
> + - const: csiphy0
> + - const: csiphy0_timer
> + - const: csiphy4
> + - const: csiphy4_timer
> + - const: gcc_axi_hf
> + - const: gcc_axi_sf
> + - const: vfe0
> + - const: vfe0_fast_ahb
> + - const: vfe_lite
> + - const: vfe_lite_ahb
> + - const: vfe_lite_cphy_rx
> + - const: vfe_lite_csid
> +
> + interrupts:
> + maxItems: 10
> +
> + interrupt-names:
> + items:
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csid_lite0
> + - const: csid_lite1
> + - const: csiphy0
> + - const: csiphy4
> + - const: vfe0
> + - const: vfe_lite0
> + - const: vfe_lite1
> +
> + interconnects:
> + maxItems: 4
> +
> + interconnect-names:
> + items:
> + - const: ahb
> + - const: hf_mnoc
> + - const: sf_mnoc
> + - const: sf_icp_mnoc
> +
> + iommus:
> + oneOf:
> + - items:
> + - description: S1 HLOS IFE and IFE_LITE non-protected read
> + - description: S1 HLOS IFE and IFE_LITE non-protected write
> + - description: S1 HLOS SFE non-protected read
> + - description: S1 HLOS SFE non-protected write
> + - description: S1 HLOS CDM IFE non-protected
> + - description: Legacy slot 0 - do not use
> + - description: Legacy slot 1 - do not use
> + - description: Legacy slot 2 - do not use
> + - items:
> + - description: S1 HLOS IFE and IFE_LITE non-protected read
> + - description: S1 HLOS IFE and IFE_LITE non-protected write
> + - description: S1 HLOS SFE non-protected read
> + - description: S1 HLOS SFE non-protected write
> + - description: S1 HLOS CDM IFE non-protected
> +
> + power-domains:
> + items:
> + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
> + - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller.
> +
> + power-domain-names:
> + items:
> + - const: ife0
> + - const: top
> +
> + vdd-csiphy-0p8-supply:
> + description:
> + 0.8V supply to a PHY.
> +
> + vdd-csiphy-1p2-supply:
> + description:
> + 1.2V supply to a PHY.
Properties of phys.
> +
> + phys:
> + maxItems: 2
> +
> + phy-names:
> + items:
> + - const: csiphy0
> + - const: csiphy4
If phys are listed here, why they are also child nodes? Drop above phys,
unless you want to say that phys should not be children of camss?
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + description:
> + CSI input ports. Supports either standard single sensor mode or
> + Qualcomm's combo mode with one sensor in 2x1 + 1x1 data-lane, clock-lane mode.
> +
> + patternProperties:
> + "^port@[0-3]$":
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> +
> + description:
> + Input port for receiving CSI data.
> +
> + properties:
> + endpoint@0:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + description:
> + Endpoint for receiving a single sensor input (or first leg of combo).
> +
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 4 # Base max allows 4 (for D-PHY)
> +
> + clock-lanes:
> + maxItems: 1
> +
> + bus-type:
> + enum:
> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
> +
> + endpoint@1:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + description:
> + Endpoint for receiving the second leg of a combo sensor input.
> +
> + properties:
> + data-lanes:
> + maxItems: 1
> +
> + clock-lanes:
> + maxItems: 1
> +
> + bus-type:
> + const: 4 # Combo is D-PHY specific
> +
> + required:
> + - data-lanes
> +
> + allOf:
> + # Case 1: Combo Mode (endpoint@1 is present)
> + # If endpoint@1 exists, we restrict endpoint@0 to 2 lanes (D-PHY split)
> + - if:
> + required:
> + - endpoint@1
> + then:
> + properties:
> + endpoint@0:
> + properties:
> + data-lanes:
> + minItems: 2
> + maxItems: 2
> + bus-type:
> + const: 4
> + endpoint@1:
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 1
> + bus-type:
> + const: 4
> +
> + # Case 2: Single Mode (endpoint@1 is missing)
> + # We explicitly allow up to 4 lanes here to cover the D-PHY use case.
> + - if:
> + not:
> + required:
> + - endpoint@1
> + then:
> + properties:
> + endpoint@0:
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> +patternProperties:
> + "^phy@[0-9a-f]+$":
> + $ref: /schemas/phy/qcom,x1e80100-csi2-phy.yaml
> + unevaluatedProperties: false
> +
> + "^opp-table(-.*)?$":
Why multiple opp-tables?
> + type: object
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - interrupts
> + - interrupt-names
> + - interconnects
> + - interconnect-names
> + - iommus
> + - power-domains
> + - power-domain-names
> + - ports
> +
...
> + power-domains = <&camcc CAM_CC_IFE_0_GDSC>,
> + <&camcc CAM_CC_TITAN_TOP_GDSC>;
> +
> + power-domain-names = "ife0",
> + "top";
> +
> + vdd-csiphy-0p8-supply = <&csiphy_0p8_supply>;
> + vdd-csiphy-1p2-supply = <&csiphy_1p2_supply>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + csiphy_ep0: endpoint {
> + data-lanes = <0 1>;
> + remote-endpoint = <&sensor_ep>;
> + };
> + };
> + };
Incomplete, please add children.
> + };
> + };
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH net-next v3 04/12] net: airoha: Rely on net_device pointer in HTB callbacks
From: Benjamin Larsson @ 2026-04-10 11:29 UTC (permalink / raw)
To: Jakub Kicinski, lorenzo
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, linux-arm-kernel, linux-mediatek, netdev, devicetree
In-Reply-To: <20260410025722.1809973-1-kuba@kernel.org>
On 10/04/2026 04:57, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email says "For your consideration."
> ---
> net: airoha: Introduce WAN device flag
>
> This commit introduces a WAN flag to specify whether a device is used to
> transmit or receive WAN or LAN traffic. It enables specifying multiple LAN
> devices but limits the configuration to a single WAN device.
>
[...]
>> + fallthrough;
>> + }
>> + case AIROHA_GDM2_IDX:
>> + /* GDM2 is always used as wan */
>> + dev->flags |= PRIV_FLAG_WAN;
>> break;
>> default:
>> break;
>> }
>>
>> - for (i = 0; i < eth->soc->num_ppe; i++)
>> - airoha_ppe_set_cpu_port(dev, i, airoha_get_fe_port(dev));
>> + airoha_dev_set_qdma(dev);
>> + airoha_set_macaddr(dev, netdev->dev_addr);
>
> Since the commit message notes it is possible to specify multiple LAN
> devices, does unconditionally calling airoha_set_macaddr() for each
> device overwrite the single shared hardware LAN MAC register?
>
> If so, could this cause only the last initialized LAN device to have its MAC
> correctly programmed into the hardware, leading to dropped unicast
> packets for the other LAN interfaces?
>
>> +
>> + if (!airoha_is_lan_gdm_dev(dev) &&
>> + (port->id == AIROHA_GDM3_IDX || port->id == AIROHA_GDM4_IDX)) {
>> + int err;
>
> [ ... ]
Hi, the frame engine can be configured with a range of wan mac addresses
and a range of lan mac addresses via registers that set the top 24 bits
and then 2 registers that form a range of the low 24 bits.
Documentation says that packets that fall into this mac address range
either on the lan side or the wan side are to be treated as layer 3
packages and if a packet is not then it will be handled as a layer 2 packet.
The exact implication of this and if it actually matters is unknown. But
traffic that comes in on an interface that is not matched by an
acceleration flow is usually forwarded to the cpu for further processing.
MvH
Benjamin Larsson
^ permalink raw reply
* [PATCH 2/2] dt-bindings: pinctrl: nvidia,tegra234: Correctly use additionalProperties
From: Krzysztof Kozlowski @ 2026-04-10 11:10 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Jonathan Hunter, Prathamesh Shete, linux-gpio,
devicetree, linux-tegra, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260410111047.309798-3-krzysztof.kozlowski@oss.qualcomm.com>
The binding does not reference any other schema, thus should use
"additionalProperties: false" to disallow any undocumented properties.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml | 2 +-
.../devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
index 56fb9cf763ef..4910dc8e8aeb 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
@@ -62,7 +62,7 @@ required:
- compatible
- reg
-unevaluatedProperties: false
+additionalProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
index bd305a34eee2..52b3d40e8839 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
@@ -119,7 +119,7 @@ required:
- compatible
- reg
-unevaluatedProperties: false
+additionalProperties: false
examples:
- |
--
2.51.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: pinctrl: nvidia,tegra234: Add missing required block
From: Krzysztof Kozlowski @ 2026-04-10 11:10 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Jonathan Hunter, Prathamesh Shete, linux-gpio,
devicetree, linux-tegra, linux-kernel
Cc: Krzysztof Kozlowski
Binding should require 'reg' property, because address space cannot be
missing in the hardware and is already needed by the Linux drivers.
Require also 'compatible' by convention, although it is not strictly
necessary.
Fixes: 857982138b79 ("dt-bindings: pinctrl: Document Tegra234 pin controllers")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml | 4 ++++
.../devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
index db8224dfba2c..56fb9cf763ef 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
@@ -58,6 +58,10 @@ patternProperties:
drive_soc_gpio27_pee6, drive_ao_retention_n_pee2,
drive_vcomp_alert_pee1, drive_hdmi_cec_pgg0 ]
+required:
+ - compatible
+ - reg
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
index f5a3a881dec4..bd305a34eee2 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
@@ -115,6 +115,10 @@ patternProperties:
drive_sdmmc1_dat2_pj4, drive_sdmmc1_dat1_pj3,
drive_sdmmc1_dat0_pj2 ]
+required:
+ - compatible
+ - reg
+
unevaluatedProperties: false
examples:
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2] dt-bindings: display: ti,am65x-dss: Fix AM62L DSS reg and clock constraints
From: Swamil Jain @ 2026-04-10 11:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: jyri.sarha, tomi.valkeinen, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, robh, krzk+dt, conor+dt, devarsht,
dri-devel, devicetree, linux-kernel, praneeth, vigneshr
In-Reply-To: <bb9712c6-a8be-4068-b549-96a12bc55e3c@kernel.org>
On 3/16/26 22:14, Krzysztof Kozlowski wrote:
> On 16/03/2026 13:36, Swamil Jain wrote:
>>> description:
>>> Addresses to each DSS memory region described in the SoC's TRM.
>>> oneOf:
>>> - items:
>>> - description: common DSS register area
>>> - description: VIDL1 light video plane
>>> - description: VID video plane
>>> - description: OVR1 overlay manager for vp1
>>> - description: OVR2 overlay manager for vp2
>>> - description: VP1 video port 1
>>> - description: VP2 video port 2
>>> - description: common1 DSS register area
>>> - items:
>>> - description: common DSS register area
>>> - description: VIDL1 light video plane
>>> - description: OVR1 overlay manager for vp1
>>> - description: VP1 video port 1
>>> - description: common1 DSS register area
>>>
>>> .....(Similarly for reg-names, clocks, clock-names,...)
>>>
>>> allOf:
>>> - if:
>>> properties:
>>> compatible:
>>> contains:
>>> const: ti,am62l-dss
>>> then:
>>> properties:
>>> clock-names:
>>> maxItems: 2
>>> clocks:
>>> maxItems: 2
>>> reg:
>>> maxItems: 5
>>> else:
>>> properties:
>>> clock-names:
>>> minItems: 3
>>> clocks:
>>> minItems: 3
>>> reg:
>>> minItems: 8
>>>
>>> ```
>>>
>>> Could you please confirm on this?
>
> If there is no common part of each list, then this looks correct. Other
> way would be the example I wrote ~2 hours ago on DT IRC (different
> patchset) - so the qcom,ufs way. It depends how readable is the final
> schema.
>
>>
>> Hi Krzysztof,
>>
>> Gentle ping, could you please confirm on the above design?
>
> If you do not hear from me or other reviewer for some time after asking
> "shall I do like that", just send next version implementing what you
> think should be done and mentioning in changelog, that this is how you
> address reviewers feedback.
>
Thanks Krzysztof, sent a v3:
https://lore.kernel.org/all/20260410105955.843868-1-s-jain1@ti.com/
Regards,
Swamil.
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 2/6] dt-bindings: pinctrl: Document Tegra238 pin controllers
From: Krzysztof Kozlowski @ 2026-04-10 11:04 UTC (permalink / raw)
To: pshete
Cc: linux-gpio, devicetree, linux-tegra, linux-kernel, arnd,
bjorn.andersson, conor+dt, dmitry.baryshkov, ebiggers, geert,
jonathanh, krzk+dt, kuninori.morimoto.gx, linusw, luca.weiss,
michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp, sven,
thierry.reding, webgeek1234
In-Reply-To: <20260409131340.168556-3-pshete@nvidia.com>
On Thu, Apr 09, 2026 at 01:13:36PM +0000, pshete@nvidia.com wrote:
> + properties:
> + nvidia,pins:
> + items:
> + enum: [ bootv_ctl_n_paa0, soc_gpio00_paa1, vcomp_alert_paa2,
> + pwm1_paa3, batt_oc_paa4, soc_gpio04_paa5,
> + soc_gpio25_paa6, soc_gpio26_paa7,
> + hdmi_cec_pbb0,
> + spi2_sck_pcc0, spi2_miso_pcc1, spi2_mosi_pcc2,
> + spi2_cs0_pcc3, spi2_cs1_pcc4, uart3_tx_pcc5,
> + uart3_rx_pcc6, gen2_i2c_scl_pcc7,
> + gen2_i2c_sda_pdd0, gen8_i2c_scl_pdd1,
> + gen8_i2c_sda_pdd2, touch_clk_pdd3, dmic1_clk_pdd4,
> + dmic1_dat_pdd5, soc_gpio19_pdd6, pwm2_pdd7,
> + pwm3_pee0, pwm7_pee1,
> + # drive groups (ordered PAA, PBB, PCC, PDD, PEE)
> + drive_bootv_ctl_n_paa0, drive_soc_gpio00_paa1,
> + drive_vcomp_alert_paa2, drive_pwm1_paa3,
> + drive_batt_oc_paa4, drive_soc_gpio04_paa5,
> + drive_soc_gpio25_paa6, drive_soc_gpio26_paa7,
> + drive_hdmi_cec_pbb0,
> + drive_spi2_sck_pcc0, drive_spi2_miso_pcc1,
> + drive_spi2_mosi_pcc2, drive_spi2_cs0_pcc3,
> + drive_spi2_cs1_pcc4, drive_uart3_tx_pcc5,
> + drive_uart3_rx_pcc6, drive_gen2_i2c_scl_pcc7,
> + drive_gen2_i2c_sda_pdd0, drive_gen8_i2c_scl_pdd1,
> + drive_gen8_i2c_sda_pdd2, drive_touch_clk_pdd3,
> + drive_dmic1_clk_pdd4, drive_dmic1_dat_pdd5,
> + drive_soc_gpio19_pdd6, drive_pwm2_pdd7,
> + drive_pwm3_pee0, drive_pwm7_pee1 ]
> +
And missing required. I'll also fix existing ones.
> +unevaluatedProperties: false
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/6] dt-bindings: pinctrl: Document Tegra238 pin controllers
From: Krzysztof Kozlowski @ 2026-04-10 11:00 UTC (permalink / raw)
To: pshete
Cc: linux-gpio, devicetree, linux-tegra, linux-kernel, arnd,
bjorn.andersson, conor+dt, dmitry.baryshkov, ebiggers, geert,
jonathanh, krzk+dt, kuninori.morimoto.gx, linusw, luca.weiss,
michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp, sven,
thierry.reding, webgeek1234
In-Reply-To: <20260409131340.168556-3-pshete@nvidia.com>
On Thu, Apr 09, 2026 at 01:13:36PM +0000, pshete@nvidia.com wrote:
> +patternProperties:
> + "^pinmux(-[a-z0-9-]+)?$":
> + type: object
> +
> + # pin groups
> + additionalProperties:
> + $ref: nvidia,tegra238-pinmux-common.yaml
> +
> + properties:
> + nvidia,pins:
> + items:
> + enum: [ bootv_ctl_n_paa0, soc_gpio00_paa1, vcomp_alert_paa2,
> + pwm1_paa3, batt_oc_paa4, soc_gpio04_paa5,
> + soc_gpio25_paa6, soc_gpio26_paa7,
> + hdmi_cec_pbb0,
> + spi2_sck_pcc0, spi2_miso_pcc1, spi2_mosi_pcc2,
> + spi2_cs0_pcc3, spi2_cs1_pcc4, uart3_tx_pcc5,
> + uart3_rx_pcc6, gen2_i2c_scl_pcc7,
> + gen2_i2c_sda_pdd0, gen8_i2c_scl_pdd1,
> + gen8_i2c_sda_pdd2, touch_clk_pdd3, dmic1_clk_pdd4,
> + dmic1_dat_pdd5, soc_gpio19_pdd6, pwm2_pdd7,
> + pwm3_pee0, pwm7_pee1,
> + # drive groups (ordered PAA, PBB, PCC, PDD, PEE)
> + drive_bootv_ctl_n_paa0, drive_soc_gpio00_paa1,
> + drive_vcomp_alert_paa2, drive_pwm1_paa3,
> + drive_batt_oc_paa4, drive_soc_gpio04_paa5,
> + drive_soc_gpio25_paa6, drive_soc_gpio26_paa7,
> + drive_hdmi_cec_pbb0,
> + drive_spi2_sck_pcc0, drive_spi2_miso_pcc1,
> + drive_spi2_mosi_pcc2, drive_spi2_cs0_pcc3,
> + drive_spi2_cs1_pcc4, drive_uart3_tx_pcc5,
> + drive_uart3_rx_pcc6, drive_gen2_i2c_scl_pcc7,
> + drive_gen2_i2c_sda_pdd0, drive_gen8_i2c_scl_pdd1,
> + drive_gen8_i2c_sda_pdd2, drive_touch_clk_pdd3,
> + drive_dmic1_clk_pdd4, drive_dmic1_dat_pdd5,
> + drive_soc_gpio19_pdd6, drive_pwm2_pdd7,
> + drive_pwm3_pee0, drive_pwm7_pee1 ]
> +
> +unevaluatedProperties: false
additionalProperties. I'll fix existing files.
> +
> +examples:
> + - |
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3] dt-bindings: display: ti, am65x-dss: Fix AM62L DSS reg and clock constraints
From: Swamil Jain @ 2026-04-10 10:59 UTC (permalink / raw)
To: jyri.sarha, tomi.valkeinen, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, robh, krzk+dt, conor+dt, devarsht
Cc: dri-devel, devicetree, linux-kernel, praneeth, vigneshr, s-jain1
The AM62L DSS [1] support incorrectly used the same register and
clock constraints as AM65x, but AM62L has a single video port
Fix this by adding conditional constraints that properly define the
register regions and clocks for AM62L DSS (single video port) versus
other AM65x variants (dual video port).
[1]: Section 12.7 (Display Subsystem and Peripherals)
Link : https://www.ti.com/lit/pdf/sprujb4
Fixes: cb8d4323302c ("dt-bindings: display: ti,am65x-dss: Add support for AM62L DSS")
Cc: stable@vger.kernel.org
Signed-off-by: Swamil Jain <s-jain1@ti.com>
---
Validated the changes with some examples:
https://gist.github.com/swamiljain/79f30568c9ece89f5a20218f52647486
Changelog:
v2->v3:
- Reduce redundancy and use constraints suggested by maintainers
- Remove blank line between the tags
Link to v2:
https://lore.kernel.org/all/20260129150601.185882-1-s-jain1@ti.com/
v1->v2:
- Remove oneOf from top level constraints, it makes bindings redundant
- Remove minItems from top level constraints
- "dma-coherent" property shouldn't be changed in v1 itself
- Add description for reg-names, clock and clock-names
- Add constraints specific to AM62L and for other SoCs within allOf
check
Link to v1:
https://lore.kernel.org/all/20251224133150.2266524-1-s-jain1@ti.com/
---
.../bindings/display/ti/ti,am65x-dss.yaml | 66 ++++++++++++++-----
1 file changed, 48 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
index 38fcee91211e..d8a05bf62c2f 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -36,34 +36,50 @@ properties:
reg:
description:
Addresses to each DSS memory region described in the SoC's TRM.
- items:
- - description: common DSS register area
- - description: VIDL1 light video plane
- - description: VID video plane
- - description: OVR1 overlay manager for vp1
- - description: OVR2 overlay manager for vp2
- - description: VP1 video port 1
- - description: VP2 video port 2
- - description: common1 DSS register area
+ oneOf:
+ - items:
+ - description: common DSS register area
+ - description: VIDL1 light video plane
+ - description: VID video plane
+ - description: OVR1 overlay manager for vp1
+ - description: OVR2 overlay manager for vp2
+ - description: VP1 video port 1
+ - description: VP2 video port 2
+ - description: common1 DSS register area
+ - items:
+ - description: common DSS register area
+ - description: VIDL1 light video plane
+ - description: OVR1 overlay manager for vp1
+ - description: VP1 video port 1
+ - description: common1 DSS register area
reg-names:
- items:
- - const: common
- - const: vidl1
- - const: vid
- - const: ovr1
- - const: ovr2
- - const: vp1
- - const: vp2
- - const: common1
+ oneOf:
+ - items:
+ - const: common
+ - const: vidl1
+ - const: vid
+ - const: ovr1
+ - const: ovr2
+ - const: vp1
+ - const: vp2
+ - const: common1
+ - items:
+ - const: common
+ - const: vidl1
+ - const: ovr1
+ - const: vp1
+ - const: common1
clocks:
+ minItems: 2
items:
- description: fck DSS functional clock
- description: vp1 Video Port 1 pixel clock
- description: vp2 Video Port 2 pixel clock
clock-names:
+ minItems: 2
items:
- const: fck
- const: vp1
@@ -179,6 +195,20 @@ allOf:
ports:
properties:
port@1: false
+ clock-names:
+ maxItems: 2
+ clocks:
+ maxItems: 2
+ reg:
+ maxItems: 5
+ else:
+ properties:
+ clock-names:
+ minItems: 3
+ clocks:
+ minItems: 3
+ reg:
+ minItems: 8
- if:
properties:
^ permalink raw reply related
* Re: [PATCH v2 02/13] ACPICA: Read LVR from the I2C resource descriptor
From: Rafael J. Wysocki @ 2026-04-10 10:59 UTC (permalink / raw)
To: Akhil R
Cc: frank.li, acpica-devel, alexandre.belloni, conor+dt, devicetree,
ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon, linux-i3c,
linux-kernel, linux, miquel.raynal, p.zabel, rafael, robh,
sakari.ailus, wsa+renesas
In-Reply-To: <20260410044515.23667-1-akhilrajeev@nvidia.com>
On Fri, Apr 10, 2026 at 6:45 AM Akhil R <akhilrajeev@nvidia.com> wrote:
>
> On Thu, 9 Apr 2026 22:04:05 -0400, Frank Li wrote:
> > On Thu, Apr 09, 2026 at 04:27:32PM +0530, Akhil R wrote:
> >> ACPI 6.3 specifies byte 8 of I2C Serial Bus Connection descriptor to be
> >> used for Legacy Virtual Register (LVR) data as specified in the MIPI
> >> I3C Specification for an I2C device connected to an I3C Host Controller.
> >> LVR will be read by I3C host controller drivers and it provides details
> >> about the specific speed and 50ns spike filter capabilities of I2C
> >> devices.
> >>
> >> Update the rsconvert_info to include this field. For I2C devices on an
> >> I2C bus, this field is Reserved and unused.
> >>
> >> This commit is the result of squashing the following:
> >> ACPICA commit 70082dc8fc847673ac7f4bbb1541776730f0b63e
> >> ACPICA commit e62e74baf7e08cf059ec82049aeccd565b24d661
> >> ACPICA commit c404118235108012cad396c834b5aabe2dd1b51a
> >> ACPICA commit 7650d4a889ea7907060bfce89f4f780ce83e7b28
> >> ACPICA commit 014fa9f2dbcc6b1bd42a4a4a6f6705d9cf7d460b
> >
> > These commit number is not existed at linus official tree. Please remove it.
>
> These are commits from ACPI-CA github. The files in the acpica folder is
> a mirror of that repo. I suppose the commits in this folder are expected
> to be structured like this. The process is also described here -
> https://docs.kernel.org/driver-api/acpi/linuxized-acpica.html
While the above is correct overall, it would also be sufficient to use
Link: tags pointing to those commits.
^ permalink raw reply
* Re: [PATCH v2 02/13] ACPICA: Read LVR from the I2C resource descriptor
From: Rafael J. Wysocki @ 2026-04-10 10:57 UTC (permalink / raw)
To: Frank Li
Cc: Akhil R, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafael J . Wysocki, Robert Moore, Len Brown,
Guenter Roeck, Philipp Zabel, Eric Biggers, Sakari Ailus,
Wolfram Sang, Miquel Raynal, linux-i3c, devicetree, linux-kernel,
linux-acpi, acpica-devel, linux-hwmon
In-Reply-To: <adhalQxfbMsL3V0T@lizhi-Precision-Tower-5810>
On Fri, Apr 10, 2026 at 4:04 AM Frank Li <Frank.li@nxp.com> wrote:
>
> On Thu, Apr 09, 2026 at 04:27:32PM +0530, Akhil R wrote:
> > ACPI 6.3 specifies byte 8 of I2C Serial Bus Connection descriptor to be
> > used for Legacy Virtual Register (LVR) data as specified in the MIPI
> > I3C Specification for an I2C device connected to an I3C Host Controller.
> > LVR will be read by I3C host controller drivers and it provides details
> > about the specific speed and 50ns spike filter capabilities of I2C
> > devices.
> >
> > Update the rsconvert_info to include this field. For I2C devices on an
> > I2C bus, this field is Reserved and unused.
> >
> > This commit is the result of squashing the following:
> > ACPICA commit 70082dc8fc847673ac7f4bbb1541776730f0b63e
> > ACPICA commit e62e74baf7e08cf059ec82049aeccd565b24d661
> > ACPICA commit c404118235108012cad396c834b5aabe2dd1b51a
> > ACPICA commit 7650d4a889ea7907060bfce89f4f780ce83e7b28
> > ACPICA commit 014fa9f2dbcc6b1bd42a4a4a6f6705d9cf7d460b
>
> These commit number is not existed at linus official tree. Please remove it.
These are upstream ACPICA commits and it is entirely legitimate to
mention them in kernel commits touching ACPICA code.
However, Link: tags pointing to those commits would be sufficient.
> >
> > Link: https://github.com/acpica/acpica/commit/70082dc8
> > Link: https://github.com/acpica/acpica/commit/b3c38dc9
> > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> > ---
> > drivers/acpi/acpica/rsserial.c | 6 +++++-
> > include/acpi/acrestyp.h | 1 +
> > 2 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/acpica/rsserial.c b/drivers/acpi/acpica/rsserial.c
> > index 279bfa27da94..c06e918ab889 100644
> > --- a/drivers/acpi/acpica/rsserial.c
> > +++ b/drivers/acpi/acpica/rsserial.c
> > @@ -315,7 +315,7 @@ struct acpi_rsconvert_info acpi_rs_convert_csi2_serial_bus[14] = {
> > *
> > ******************************************************************************/
> >
> > -struct acpi_rsconvert_info acpi_rs_convert_i2c_serial_bus[17] = {
> > +struct acpi_rsconvert_info acpi_rs_convert_i2c_serial_bus[18] = {
> > {ACPI_RSC_INITGET, ACPI_RESOURCE_TYPE_SERIAL_BUS,
> > ACPI_RS_SIZE(struct acpi_resource_i2c_serialbus),
> > ACPI_RSC_TABLE_SIZE(acpi_rs_convert_i2c_serial_bus)},
> > @@ -391,6 +391,10 @@ struct acpi_rsconvert_info acpi_rs_convert_i2c_serial_bus[17] = {
> > AML_OFFSET(i2c_serial_bus.type_specific_flags),
> > 0},
> >
> > + {ACPI_RSC_MOVE8, ACPI_RS_OFFSET(data.i2c_serial_bus.lvr),
> > + AML_OFFSET(i2c_serial_bus.type_specific_flags) + 1,
> > + 1},
> > +
> > {ACPI_RSC_MOVE32, ACPI_RS_OFFSET(data.i2c_serial_bus.connection_speed),
> > AML_OFFSET(i2c_serial_bus.connection_speed),
> > 1},
> > diff --git a/include/acpi/acrestyp.h b/include/acpi/acrestyp.h
> > index 842f932e2c2b..38a19b1d19ac 100644
> > --- a/include/acpi/acrestyp.h
> > +++ b/include/acpi/acrestyp.h
> > @@ -423,6 +423,7 @@ struct acpi_resource_i2c_serialbus {
> > ACPI_RESOURCE_SERIAL_COMMON u8 access_mode;
> > u16 slave_address;
> > u32 connection_speed;
> > + u8 lvr;
> > };
> >
> > /* Values for access_mode field above */
> > --
> > 2.50.1
> >
>
^ permalink raw reply
* Re: [PATCH v8 5/5] arm64: dts: qcom: monaco: Add OPP-table for ICE UFS and ICE eMMC nodes
From: Kuldeep Singh @ 2026-04-10 10:57 UTC (permalink / raw)
To: Abhinaba Rakshit, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, James E.J. Bottomley, Martin K. Petersen,
Adrian Hunter, Ulf Hansson, Neeraj Soni, Harshal Dev, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, linux-scsi, linux-mmc, devicetree
In-Reply-To: <20260409-enable-ice-clock-scaling-v8-5-ca1129798606@oss.qualcomm.com>
On 4/9/2026 5:14 PM, Abhinaba Rakshit wrote:
> Qualcomm Inline Crypto Engine (ICE) platform driver now, supports
> an optional OPP-table.
>
> Add OPP-table for ICE UFS and ICE eMMC device nodes for Monaco
> platform.
>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/monaco.dtsi | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index 487bb682ae8620b819f022162edd11023ed07be8..cb0e554e94d237b0adccb55fa9ed967bae9eea05 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> @@ -2730,6 +2730,22 @@ ice: crypto@1d88000 {
> clock-names = "core",
> "iface";
> power-domains = <&gcc GCC_UFS_PHY_GDSC>;
> +
> + operating-points-v2 = <&ice_opp_table>;
> +
> + ice_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
75MHz is supported too. Please add that entry.
> + opp-201600000 {
> + opp-hz = /bits/ 64 <201600000>;
> + required-opps = <&rpmhpd_opp_svs_l1>;
> + };
> +
> + opp-403200000 {
> + opp-hz = /bits/ 64 <403200000>;
> + required-opps = <&rpmhpd_opp_nom>;
> + };
> + };
> };
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH v1 1/7] dt-bindings: arm: fsl: Add verdin imx8m[mp] and imx95 zinnia board
From: Krzysztof Kozlowski @ 2026-04-10 10:56 UTC (permalink / raw)
To: Francesco Dolcini
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260409095855.61252-2-francesco@dolcini.it>
On Thu, Apr 09, 2026 at 11:58:47AM +0200, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini@toradex.com>
>
> Add Toradex Verdin Zinnia carrier board mated with Verdin
> iMX8M Plus, Verdin iMX8M Mini and Verdin iMX95.
>
> Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 4/5] arm64: dts: qcom: kodiak: Add OPP-table for ICE UFS and ICE eMMC nodes
From: Kuldeep Singh @ 2026-04-10 10:53 UTC (permalink / raw)
To: Abhinaba Rakshit, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, James E.J. Bottomley, Martin K. Petersen,
Adrian Hunter, Ulf Hansson, Neeraj Soni, Harshal Dev, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, linux-scsi, linux-mmc, devicetree
In-Reply-To: <20260409-enable-ice-clock-scaling-v8-4-ca1129798606@oss.qualcomm.com>
On 4/9/2026 5:14 PM, Abhinaba Rakshit wrote:
> Qualcomm Inline Crypto Engine (ICE) platform driver now, supports
> an optional OPP-table.
>
> Add OPP-table for ICE UFS and ICE eMMC device nodes for Kodiak
> platform.
>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kodiak.dtsi | 42 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index c899a17026fd2a10ebc528a816629c88ee3bde5d..b0aa1970d42a3bb0b9d371e0e6cd09b8cd164dbe 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -1087,6 +1087,27 @@ sdhc_ice: crypto@7c8000 {
> clock-names = "core",
> "iface";
> power-domains = <&rpmhpd SC7280_CX>;
> +
> + operating-points-v2 = <&ice_mmc_opp_table>;
> +
> + ice_mmc_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-100000000 {
> + opp-hz = /bits/ 64 <100000000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + };
> +
> + opp-150000000 {
> + opp-hz = /bits/ 64 <150000000>;
> + required-opps = <&rpmhpd_opp_svs>;
> + };
> +
> + opp-300000000 {
> + opp-hz = /bits/ 64 <300000000>;
> + required-opps = <&rpmhpd_opp_nom>;
As per hardware spec, 300MHz is supported by SVS_L1.
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-10 10:47 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov
In-Reply-To: <adjQl37-6a--_y3Y@apocalypse>
[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]
Hello Andrea,
On Fri, Apr 10, 2026 at 12:27:35PM +0200, Andrea della Porta wrote:
> On 08:27 Fri 10 Apr , Uwe Kleine-König wrote:
> > On Thu, Apr 09, 2026 at 06:16:41PM +0200, Andrea della Porta wrote:
> > > On 23:45 Sun 05 Apr , Uwe Kleine-König wrote:
> > > > On Fri, Apr 03, 2026 at 04:31:55PM +0200, Andrea della Porta wrote:
> > > > > +static void rp1_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> > > > > +{
> > > > > + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> > > > > + u32 value;
> > > > > +
> > > > > + value = readl(rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > > > + value &= ~PWM_MODE_MASK;
> > > > > + writel(value, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > > > +
> > > > > + rp1_pwm_apply_config(chip, pwm);
> > > >
> > > > What is the purpose of this call?
> > >
> > > To update the configuration on the next PWM strobe in order to avoid
> > > glitches. I'll add a short comment in the code.
> >
> > .pwm_free() should not touch the hardware configuration. Changing the
> > pinmuxing (which I guess is the purpose of clearing PWM_MODE_MASK) is
> > somewhat a grey area. If that saves energy, that's okish. Otherwise
> > not interfering with the operation of the PWM (e.g. to keep a display on
> > during kexec or so) is preferred.
>
> Sorry I should've been more clear on this. The pinmux/conf is not changed
> at all by this mask, only the PWM output mode is. The controller can output
> several type of waveforms and clearing PWM_MODE_MASK is just setting the
> controller to output a 0, which is the reset default i.e. the same value
> as just before exporting the channel.
> I guess this is the expected behaviour in case of a fan, it should stop
> spinning in case you unexport the pwm channel, but I see it could be
> different with displays.
> Honestly I don't have a strong opinion about that, please just let me
> know if I should drop that pwm_free entirely.
Yes, in this case drop the function completely. It's the responsibility
of the consumer to stop the PWM before releasing it.
> > > > > +static int rp1_pwm_resume(struct device *dev)
> > > > > +{
> > > > > + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> > > > > +
> > > > > + return clk_prepare_enable(rp1->clk);
> > > >
> > > > Hmm, if this fails and then the driver is unbound, the clk operations
> > > > are not balanced.
> > >
> > > I'll add some flags to check if the clock is really enabled or not.
> >
> > To be honest, I guess that is a problem of several drivers, not only in
> > drivers/pwm. If this complicates the driver, I guess addressing this
> > isn't very critical.
>
> I'll come up with something, we can always drop this check if deemed
> too 'noisy'.
Great, thanks
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 00/12] net: airoha: Support multiple net_devices connected to the same GDM port
From: Lorenzo Bianconi @ 2026-04-10 10:39 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
Benjamin Larsson, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
In-Reply-To: <20260409195645.16c68979@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
On Apr 09, Jakub Kicinski wrote:
> On Mon, 06 Apr 2026 12:34:05 +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 arbiter 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.
>
> Still waiting for the device tree review. I'm going to blindly send out
> the Sashiko review, please comment if any of it makes sense?
ack, I will do.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v1 3/5] irqchip: starfive: Use devm_ interfaces to simplify resource release
From: Changhuang Liang @ 2026-04-10 9:01 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner,
Philipp Zabel
Cc: linux-kernel, devicetree, linux-riscv, Ley Foon Tan,
Changhuang Liang
In-Reply-To: <20260410090106.622781-1-changhuang.liang@starfivetech.com>
Use devm_ interfaces to simplify resource release. Make clock and reset
get optional as they are not used on the JHB100 SoC. Replace pr_ logging
with dev_* logging.
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
---
drivers/irqchip/irq-starfive-jhb100-intc.c | 44 ++++++++--------------
1 file changed, 15 insertions(+), 29 deletions(-)
diff --git a/drivers/irqchip/irq-starfive-jhb100-intc.c b/drivers/irqchip/irq-starfive-jhb100-intc.c
index 2c9cdad7f377..312a4634870a 100644
--- a/drivers/irqchip/irq-starfive-jhb100-intc.c
+++ b/drivers/irqchip/irq-starfive-jhb100-intc.c
@@ -7,16 +7,14 @@
* Author: Changhuang Liang <changhuang.liang@starfivetech.com>
*/
-#define pr_fmt(fmt) "irq-starfive-jhb100: " fmt
-
#include <linux/bitops.h>
#include <linux/clk.h>
#include <linux/irq.h>
#include <linux/irqchip.h>
#include <linux/irqchip/chained_irq.h>
#include <linux/irqdomain.h>
-#include <linux/of_address.h>
#include <linux/of_irq.h>
+#include <linux/platform_device.h>
#include <linux/reset.h>
#include <linux/spinlock.h>
@@ -127,48 +125,44 @@ static int starfive_intc_probe(struct platform_device *pdev, struct device_node
if (!irqc)
return -ENOMEM;
- irqc->base = of_iomap(intc, 0);
+ irqc->base = devm_platform_ioremap_resource(pdev, 0);
if (!irqc->base) {
- pr_err("Unable to map registers\n");
+ dev_err(&pdev->dev, "unable to map registers\n");
ret = -ENXIO;
goto err_free;
}
- rst = of_reset_control_get_exclusive(intc, NULL);
+ rst = devm_reset_control_get_optional(&pdev->dev, NULL);
if (IS_ERR(rst)) {
- pr_err("Unable to get reset control %pe\n", rst);
+ dev_err(&pdev->dev, "Unable to get reset control %pe\n", rst);
ret = PTR_ERR(rst);
- goto err_unmap;
+ goto err_free;
}
- clk = of_clk_get(intc, 0);
+ clk = devm_clk_get_optional_enabled(&pdev->dev, NULL);
if (IS_ERR(clk)) {
- pr_err("Unable to get clock %pe\n", clk);
+ dev_err(&pdev->dev, "Unable to get and enable clock %pe\n", clk);
ret = PTR_ERR(clk);
- goto err_reset_put;
+ goto err_free;
}
ret = reset_control_deassert(rst);
if (ret)
- goto err_clk_put;
-
- ret = clk_prepare_enable(clk);
- if (ret)
- goto err_reset_assert;
+ goto err_free;
raw_spin_lock_init(&irqc->lock);
irqc->domain = irq_domain_create_linear(of_fwnode_handle(intc), STARFIVE_INTC_SRC_IRQ_NUM,
&starfive_intc_domain_ops, irqc);
if (!irqc->domain) {
- pr_err("Unable to create IRQ domain\n");
+ dev_err(&pdev->dev, "Unable to create IRQ domain\n");
ret = -EINVAL;
- goto err_clk_disable;
+ goto err_reset_assert;
}
parent_irq = of_irq_get(intc, 0);
if (parent_irq < 0) {
- pr_err("Failed to get main IRQ: %d\n", parent_irq);
+ dev_err(&pdev->dev, "Failed to get main IRQ: %d\n", parent_irq);
ret = parent_irq;
goto err_remove_domain;
}
@@ -176,23 +170,15 @@ static int starfive_intc_probe(struct platform_device *pdev, struct device_node
irq_set_chained_handler_and_data(parent_irq, starfive_intc_irq_handler,
irqc);
- pr_info("Interrupt controller register, nr_irqs %d\n",
- STARFIVE_INTC_SRC_IRQ_NUM);
+ dev_info(&pdev->dev, "Interrupt controller register, nr_irqs %d\n",
+ STARFIVE_INTC_SRC_IRQ_NUM);
return 0;
err_remove_domain:
irq_domain_remove(irqc->domain);
-err_clk_disable:
- clk_disable_unprepare(clk);
err_reset_assert:
reset_control_assert(rst);
-err_clk_put:
- clk_put(clk);
-err_reset_put:
- reset_control_put(rst);
-err_unmap:
- iounmap(irqc->base);
err_free:
kfree(irqc);
return ret;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net-next v3 10/12] net: airoha: Do not stop GDM port if it is shared
From: Lorenzo Bianconi @ 2026-04-10 10:35 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, benjamin.larsson, linux-arm-kernel, linux-mediatek,
netdev, devicetree, Xuegang Lu
In-Reply-To: <20260410025726.1810041-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4665 bytes --]
> This is an AI-generated review of your patch. The human sending this
> email says "For your consideration."
> ---
> net: airoha: Do not stop GDM port if it is shared
>
> Theoretically, in the current codebase, two independent net_devices can
> be connected to the same GDM port so we need to check the GDM port is not
> used by any other running net_device before setting the forward
> configuration to FE_PSE_PORT_DROP.
>
> Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> > index fd27ba13029bd..5b0cd37b155e4 100644
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
>
> [ ... ]
>
> > @@ -1688,18 +1693,18 @@ static int airoha_dev_stop(struct net_device *netdev)
> > struct airoha_gdm_dev *dev = netdev_priv(netdev);
> > struct airoha_gdm_port *port = dev->port;
> > struct airoha_qdma *qdma = dev->qdma;
> > - int i, err;
> > + int i;
> >
> > netif_tx_disable(netdev);
> > - err = airoha_set_vip_for_gdm_port(dev, false);
> > - if (err)
> > - return err;
> > -
> > for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
> > netdev_tx_reset_subqueue(netdev, i);
> >
> > - airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
> > - FE_PSE_PORT_DROP);
> > + if (atomic_dec_and_test(&port->users)) {
> > + airoha_set_vip_for_gdm_port(dev, false);
> > + airoha_set_gdm_port_fwd_cfg(qdma->eth,
> > + REG_GDM_FWD_CFG(port->id),
> > + FE_PSE_PORT_DROP);
> > + }
> >
> > if (atomic_dec_and_test(&qdma->users)) {
> > airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
> > GLOBAL_CFG_TX_DMA_EN_MASK |
> > GLOBAL_CFG_RX_DMA_EN_MASK);
> >
> > for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++) {
> > if (!qdma->q_tx[i].ndesc)
> > continue;
> >
> > airoha_qdma_cleanup_tx_queue(&qdma->q_tx[i]);
> > }
> > }
>
> This problem wasn't introduced by this patch, but does the QDMA teardown
> path have a DMA corruption vulnerability here?
>
> When GLOBAL_CFG_TX_DMA_EN_MASK is cleared, it fails to poll
> GLOBAL_CFG_TX_DMA_BUSY_MASK, proceeding to unmap memory while the hardware
> DMA engine may still be processing in-flight descriptors.
>
> Furthermore, airoha_qdma_cleanup_tx_queue() unmaps the DMA addresses and
> frees the SKBs, but it does not appear to clear the physical hardware
> descriptors or reset the hardware ring pointers (REG_TX_CPU_IDX /
> REG_TX_DMA_IDX).
>
> When the device is later reopened in airoha_dev_open(),
> GLOBAL_CFG_TX_DMA_EN_MASK is set again without re-initializing the rings.
> Will the hardware DMA engine resume fetching from its previous index,
> processing stale descriptors whose backing memory was already unmapped
> and freed?
ack, I will work on it with a dedicated patch.
>
> [ ... ]
>
> > @@ -1851,10 +1856,22 @@ static void airoha_dev_get_stats64(struct net_device *netdev,
> > static int airoha_dev_change_mtu(struct net_device *netdev, int mtu)
> > {
> > struct airoha_gdm_dev *dev = netdev_priv(netdev);
> > + u32 cur_len, len = ETH_HLEN + mtu + ETH_FCS_LEN;
> > struct airoha_gdm_port *port = dev->port;
> > - u32 len = ETH_HLEN + mtu + ETH_FCS_LEN;
> > struct airoha_eth *eth = dev->eth;
> >
> > + cur_len = FIELD_GET(GDM_LONG_LEN_MASK,
> > + airoha_fe_rr(eth, REG_GDM_LEN_CFG(port->id)));
> > + if (len < cur_len) {
> > + u8 port_refcnt = atomic_read(&port->users);
> > +
> > + /* We can decrease the device MTU just if the GDM port is
> > + * not shared or if the other device is not running.
> > + */
> > + if (port_refcnt > 1 || (port_refcnt && !netif_running(netdev)))
> > + return -EBUSY;
> > + }
> > +
>
> Does this MTU decrease validation create a state trap on shared ports?
>
> If both eth0 and eth1 (sharing a port) are up, and a user increases eth0 MTU
> to 9000, the hardware MTU updates to 9000. If the user then tries to lower
> eth0 MTU back to 1500, len < cur_len evaluates to true. Because eth1 is also
> up (port_refcnt > 1), this returns -EBUSY.
>
> This would prevent either interface from decreasing its MTU without fully
> bringing down the sibling interface.
>
> Should the software netdev->mtu be decoupled from the hardware validation,
> allowing valid MTU changes in software while dynamically programming the
> hardware MTU to the maximum of all currently up interfaces on the shared
> port?
It seems more correct to me avoid receiving in the stack packet bigger than the
configured 'SW MTU".
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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