From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: lee@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
tsbogend@alpha.franken.de, hkallweit1@gmail.com,
markus.stockhausen@gmx.de, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-mips@vger.kernel.org
Subject: Re: [PATCH 4/4] net: mdio: Add RTL9300 MDIO driver
Date: Thu, 12 Dec 2024 09:59:38 +0000 [thread overview]
Message-ID: <Z1q0CuDXe8VFuBfZ@shell.armlinux.org.uk> (raw)
In-Reply-To: <20241211235342.1573926-5-chris.packham@alliedtelesis.co.nz>
On Thu, Dec 12, 2024 at 12:53:42PM +1300, Chris Packham wrote:
> +#define SMI_GLB_CTRL 0x000
> +#define GLB_CTRL_INTF_SEL(intf) BIT(16 + (intf))
> +#define SMI_PORT0_15_POLLING_SEL 0x008
> +#define SMI_ACCESS_PHY_CTRL_0 0x170
> +#define SMI_ACCESS_PHY_CTRL_1 0x174
> +#define PHY_CTRL_RWOP BIT(2)
Presumably, reading the code, this bit is set when writing?
> +#define PHY_CTRL_TYPE BIT(1)
Presumably, reading the code, this bit indicates we want to use clause
45?
> +#define PHY_CTRL_CMD BIT(0)
> +#define PHY_CTRL_FAIL BIT(25)
> +#define SMI_ACCESS_PHY_CTRL_2 0x178
> +#define SMI_ACCESS_PHY_CTRL_3 0x17c
> +#define SMI_PORT0_5_ADDR_CTRL 0x180
> +
> +#define MAX_PORTS 32
> +#define MAX_SMI_BUSSES 4
> +
> +struct realtek_mdio_priv {
> + struct regmap *regmap;
> + u8 smi_bus[MAX_PORTS];
> + u8 smi_addr[MAX_PORTS];
> + bool smi_bus_isc45[MAX_SMI_BUSSES];
Not sure about the support for !C45 - you appear to set this if you
find a PHY as a child of this device which has the PHY C45 compatible,
but as you don't populate the C22 MDIO bus operations, I'm not sure
how a C22 PHY can work.
> + u32 reg_base;
> +};
> +
> +static int realtek_mdio_wait_ready(struct realtek_mdio_priv *priv)
> +{
> + u32 val;
> +
> + return regmap_read_poll_timeout(priv->regmap, priv->reg_base + SMI_ACCESS_PHY_CTRL_1,
> + val, !(val & PHY_CTRL_CMD), 10, 500);
> +}
> +
> +static int realtek_mdio_read_c45(struct mii_bus *bus, int phy_id, int dev_addr, int regnum)
> +{
> + struct realtek_mdio_priv *priv = bus->priv;
> + u32 val;
> + int err;
> +
> + err = realtek_mdio_wait_ready(priv);
> + if (err)
> + return err;
> +
> + err = regmap_write(priv->regmap, priv->reg_base + SMI_ACCESS_PHY_CTRL_2, phy_id << 16);
> + if (err)
> + return err;
> +
> + err = regmap_write(priv->regmap, priv->reg_base + SMI_ACCESS_PHY_CTRL_3,
> + dev_addr << 16 | (regnum & 0xffff));
> + if (err)
> + return err;
> +
> + err = regmap_write(priv->regmap, priv->reg_base + SMI_ACCESS_PHY_CTRL_1,
> + PHY_CTRL_TYPE | PHY_CTRL_CMD);
> + if (err)
> + return err;
Maybe consider using a local variable for "regmap" and "reg_base" to
reduce the line length/wrapping?
> +static int realtek_mdiobus_init(struct realtek_mdio_priv *priv)
> +{
> + u32 port_addr[5] = { };
> + u32 poll_sel[2] = { 0, 0 };
> + u32 glb_ctrl_mask = 0, glb_ctrl_val = 0;
Please use reverse Christmas tree order.
> + int i, err;
> +
> + for (i = 0; i < MAX_PORTS; i++) {
> + int pos;
> +
> + if (priv->smi_bus[i] > 3)
> + continue;
> +
> + pos = (i % 6) * 5;
> + port_addr[i / 6] |= priv->smi_addr[i] << pos;
s/ / /
> +
> + pos = (i % 16) * 2;
> + poll_sel[i / 16] |= priv->smi_bus[i] << pos;
> + }
> +
> + for (i = 0; i < MAX_SMI_BUSSES; i++) {
> + if (priv->smi_bus_isc45[i]) {
> + glb_ctrl_mask |= GLB_CTRL_INTF_SEL(i);
> + glb_ctrl_val |= GLB_CTRL_INTF_SEL(i);
> + }
> + }
> +
> + err = regmap_bulk_write(priv->regmap, priv->reg_base + SMI_PORT0_5_ADDR_CTRL,
> + port_addr, 5);
> + if (err)
> + return err;
> +
> + err = regmap_bulk_write(priv->regmap, priv->reg_base + SMI_PORT0_15_POLLING_SEL,
> + poll_sel, 2);
> + if (err)
> + return err;
> +
> + err = regmap_update_bits(priv->regmap, priv->reg_base + SMI_GLB_CTRL,
> + glb_ctrl_mask, glb_ctrl_val);
> + if (err)
> + return err;
> +
> + return 0;
> +}
> +
> +static int realtek_mdiobus_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct realtek_mdio_priv *priv;
> + struct fwnode_handle *child;
> + struct mii_bus *bus;
> + int err;
> +
> + bus = devm_mdiobus_alloc_size(dev, sizeof(*priv));
> + if (!bus)
> + return -ENOMEM;
> +
> + bus->name = "Reaktek Switch MDIO Bus";
> + bus->read_c45 = realtek_mdio_read_c45;
> + bus->write_c45 = realtek_mdio_write_c45;
> + bus->parent = dev;
> + priv = bus->priv;
> +
> + priv->regmap = syscon_node_to_regmap(dev->parent->of_node);
> + if (IS_ERR(priv->regmap))
> + return PTR_ERR(priv->regmap);
> +
> + err = device_property_read_u32(dev, "reg", &priv->reg_base);
> + if (err)
> + return err;
> +
> + snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
> +
> + device_for_each_child_node(dev, child) {
> + u32 pn, smi_addr[2];
> +
> + err = fwnode_property_read_u32(child, "reg", &pn);
> + if (err)
> + return err;
> +
> + if (pn > MAX_PORTS)
> + return dev_err_probe(dev, -EINVAL, "illegal port number %d\n", pn);
You validate the port number.
> +
> + err = fwnode_property_read_u32_array(child, "realtek,smi-address", smi_addr, 2);
> + if (err) {
> + smi_addr[0] = 0;
> + smi_addr[1] = pn;
> + }
You don't validate the "smi_addr", so:
realtek,smi-address = <4, ...>;
would silently overflow priv->smi_bus_isc45. However, I haven't checked
whether the binding would warn about this.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2024-12-12 10:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-11 23:53 [PATCH 0/4] RTL9300 MDIO driver Chris Packham
2024-12-11 23:53 ` [PATCH 1/4] dt-bindings: net: Add Realtek MDIO controller Chris Packham
2024-12-12 17:13 ` Andrew Lunn
2024-12-13 0:56 ` Chris Packham
2024-12-13 11:58 ` Andrew Lunn
2024-12-15 19:52 ` Chris Packham
2024-12-15 21:38 ` Andrew Lunn
2024-12-11 23:53 ` [PATCH 2/4] dt-bindings: mfd: Add MDIO interface to rtl9301-switch Chris Packham
2024-12-11 23:53 ` [PATCH 3/4] mips: dts: realtek: Add MDIO controller Chris Packham
2024-12-11 23:53 ` [PATCH 4/4] net: mdio: Add RTL9300 MDIO driver Chris Packham
2024-12-12 7:41 ` Andrew Lunn
2024-12-12 8:18 ` Christophe JAILLET
2024-12-12 9:59 ` Russell King (Oracle) [this message]
2024-12-13 0:51 ` Chris Packham
2024-12-13 19:59 ` Simon Horman
2024-12-15 20:27 ` Chris Packham
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=Z1q0CuDXe8VFuBfZ@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew+netdev@lunn.ch \
--cc=chris.packham@alliedtelesis.co.nz \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=markus.stockhausen@gmx.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=tsbogend@alpha.franken.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.