From: Andrew Lunn <andrew@lunn.ch>
To: Vasilij Strassheim <v.strassheim@linutronix.de>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Russell King <linux@armlinux.org.uk>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org,
Martin Kaistra <martin.kaistra@linutronix.de>,
Benedikt Spranger <b.spranger@linutronix.de>
Subject: Re: [PATCH net-next v2 4/4] net: dsa: soce: Add basic support for SoC-e switch IP cores
Date: Mon, 7 Sep 2026 21:28:25 +0200 [thread overview]
Message-ID: <3c2c5b39-6a7d-4cb2-af1c-b5015b6bf1e8@lunn.ch> (raw)
In-Reply-To: <20260903-devel-vstrassheim-soce-dsa-ml-v2-4-fb0587cb466b@linutronix.de>
> +#define SOCE_MAX_NUM_PORTS 31
> +#define SOCE_MAX_MDIO_ADDR 32
Given what the binding says, that looks odd.
> +#define SOCE_MAX_MDIO_OUTPUTS SOCE_MAX_NUM_PORTS
> +
> +struct dsa_switch;
> +
> +struct soce_mdio_ops {
> + int (*phy_read)(struct dsa_switch *ds, int mdio_output, int phy_addr,
> + int regnum);
> + int (*phy_write)(struct dsa_switch *ds, int mdio_output, int phy_addr,
> + int regnum, u16 val);
> + int (*phy_read_c45)(struct dsa_switch *ds, int mdio_output, int phy_addr,
> + int devad, int regnum);
> + int (*phy_write_c45)(struct dsa_switch *ds, int mdio_output, int phy_addr,
> + int devad, int regnum, u16 val);
> +};
> +
> +struct soce_dsa_local {
> + void __iomem *base_addr;
> + void __iomem *mdio_master_addr;
> + /* Serializes all logical buses sharing the MDIO master. */
> + struct mutex mdio_lock;
What is the MDIO master?
> +static const struct soce_mdio_ops soce_mdio_ops_c22_c45 = {
> + .phy_read = soce_mdio_23_02_read,
> + .phy_write = soce_mdio_23_02_write,
> + .phy_read_c45 = soce_mdio_23_02_read_c45,
> + .phy_write_c45 = soce_mdio_23_02_write_c45,
> +};
It seems like this is the only struct soce_mdio_ops. Does the IP
support different MDIO buses? Is this level of abstraction actually
needed?
> +static inline bool soce_mdio_output_valid(int mdio_output)
> +{
> + return mdio_output >= 0 && mdio_output < SOCE_MAX_MDIO_OUTPUTS;
> +}
No inline functions in .c files. Let the compile decide.
> +static inline bool soce_mdio_addr_valid(int phy_addr)
> +{
> + return phy_addr >= 0 && phy_addr < SOCE_MAX_MDIO_ADDR;
> +}
> +
> +static inline bool soce_mdio_c22_reg_valid(int regnum)
> +{
> + return regnum >= 0 && regnum <= SOCE_MDIO_C22_REG_MAX;
> +}
> +
> +static inline bool soce_mdio_c45_params_valid(int devad, int regnum)
> +{
> + return devad >= 0 && devad <= SOCE_MDIO_C45_DEVAD_MAX &&
> + regnum >= 0 && regnum <= SOCE_MDIO_C45_REG_MAX;
> +}
Do you see any other MDIO driver doing this sort of checking?
> +static int soce_mdio_read(struct mii_bus *bus, int addr, int reg)
> +{
> + struct soce_mdio_bus *state = bus->priv;
> + struct soce_dsa_local *local;
> + struct soce_priv *priv;
> + int ret;
> +
> + priv = state->ds->priv;
> + local = &priv->local;
> +
> + if (!local->mdio_ops || !local->mdio_ops->phy_read)
> + return -EOPNOTSUPP;
> +
> + if (!soce_mdio_addr_valid(addr))
> + return -EINVAL;
> +
> + mutex_lock(&local->mdio_lock);
> + ret = local->mdio_ops->phy_read(state->ds, state->mdio_output, addr,
> + reg);
> + mutex_unlock(&local->mdio_lock);
What is the lock protecting?
> +static int soce_register_mdio_bus(struct soce_priv *priv, struct device *dev,
> + struct device_node *mdio_np,
> + u32 mdio_output)
> +{
> + struct soce_mdio_bus *state;
> + struct mii_bus *bus;
> +
> + bus = devm_mdiobus_alloc(dev);
> + if (!bus)
> + return -ENOMEM;
> +
> + state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
> + if (!state)
> + return -ENOMEM;
> +
> + state->ds = priv->ds;
> + state->mdio_output = mdio_output;
Can you think of a better name than mdio_output. It seems to be the
bus number?
> +
> + bus->priv = state;
> + bus->name = "soce mdio";
> + bus->read = soce_mdio_read;
> + bus->write = soce_mdio_write;
> + bus->read_c45 = soce_mdio_read_c45;
> + bus->write_c45 = soce_mdio_write_c45;
> + /* ds->dst can be NULL during probe, before dsa_register_switch() */
> + snprintf(bus->id, MII_BUS_ID_SIZE, "%s-mdio-%u", dev_name(dev),
> + mdio_output);
> + bus->parent = dev;
> +
> + return devm_of_mdiobus_register(dev, bus, mdio_np);
> +}
> +int soce_mdio_23_02_read_c45(struct dsa_switch *ds, int mdio_output,
> + int phy_addr, int devad, int regnum)
> +{
> + void __iomem *ctrl, *params, *read_reg, *write_reg;
> + struct soce_priv *priv = ds->priv;
> + struct soce_dsa_local *local;
> + u32 regvalue;
> + int ret;
> +
> + if (!soce_mdio_output_valid(mdio_output) ||
> + !soce_mdio_addr_valid(phy_addr) ||
> + !soce_mdio_c45_params_valid(devad, regnum))
> + return -EINVAL;
Hasn't this already been checked once?
Andrew
next prev parent reply other threads:[~2026-09-07 19:28 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 18:10 [PATCH net-next v2 0/4] net: dsa: Add SoC-e DSA driver Vasilij Strassheim
2026-09-03 18:10 ` [PATCH net-next v2 1/4] dt-bindings: vendor-prefixes: Add soce Vasilij Strassheim
2026-09-07 9:14 ` Krzysztof Kozlowski
2026-09-03 18:10 ` [PATCH net-next v2 2/4] dt-bindings: net: dsa: Add SoC-e SWIP switch Vasilij Strassheim
2026-09-07 9:21 ` Krzysztof Kozlowski
2026-09-07 14:01 ` Vasilij Strassheim
2026-09-07 18:56 ` Andrew Lunn
2026-09-08 10:16 ` Vasilij Strassheim
2026-09-08 10:29 ` Kurt Kanzenbach
2026-09-08 9:14 ` Krzysztof Kozlowski
2026-09-08 10:09 ` Vasilij Strassheim
2026-09-07 19:04 ` Andrew Lunn
2026-09-07 19:09 ` Andrew Lunn
2026-09-08 18:15 ` Vasilij Strassheim
2026-09-08 19:10 ` Andrew Lunn
2026-09-09 18:46 ` Vasilij Strassheim
2026-09-10 12:12 ` Andrew Lunn
2026-09-03 18:11 ` [PATCH net-next v2 3/4] net: dsa: Add tag handling for SoC-e switches Vasilij Strassheim
2026-09-09 12:12 ` netdev-bot+sashiko
2026-09-03 18:11 ` [PATCH net-next v2 4/4] net: dsa: soce: Add basic support for SoC-e switch IP cores Vasilij Strassheim
2026-09-07 19:28 ` Andrew Lunn [this message]
2026-09-08 18:44 ` Vasilij Strassheim
2026-09-08 19:20 ` Andrew Lunn
2026-09-09 19:28 ` Vasilij Strassheim
2026-09-10 12:18 ` Andrew Lunn
2026-09-08 0:37 ` Andrew Lunn
2026-09-10 13:01 ` Vasilij Strassheim
2026-09-10 15:07 ` Andrew Lunn
2026-09-11 13:39 ` Vasilij Strassheim
2026-09-08 8:25 ` Kurt Kanzenbach
2026-09-08 10:12 ` Vasilij Strassheim
2026-09-09 12:12 ` netdev-bot+sashiko
2026-09-07 9:10 ` [PATCH net-next v2 0/4] net: dsa: Add SoC-e DSA driver Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3c2c5b39-6a7d-4cb2-af1c-b5015b6bf1e8@lunn.ch \
--to=andrew@lunn.ch \
--cc=b.spranger@linutronix.de \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=martin.kaistra@linutronix.de \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=v.strassheim@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox