From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Tristram.Ha@microchip.com
Cc: Woojung Huh <woojung.huh@microchip.com>,
Andrew Lunn <andrew@lunn.ch>, Vladimir Oltean <olteanv@gmail.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
UNGLinuxDriver@microchip.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC net-next 2/2] net: dsa: microchip: Add SGMII port support to KSZ9477 switch
Date: Tue, 28 Jan 2025 09:38:54 +0000 [thread overview]
Message-ID: <Z5ilrp1c6lbMGqbl@shell.armlinux.org.uk> (raw)
In-Reply-To: <20250128033226.70866-3-Tristram.Ha@microchip.com>
On Mon, Jan 27, 2025 at 07:32:26PM -0800, Tristram.Ha@microchip.com wrote:
> @@ -161,6 +161,113 @@ static int ksz9477_wait_alu_sta_ready(struct ksz_device *dev)
> 10, 1000);
> }
>
> +static void port_sgmii_s(struct ksz_device *dev, uint port, u16 devid, u16 reg,
> + u16 len)
> +{
> + u32 data;
> +
> + data = (devid & MII_MMD_CTRL_DEVAD_MASK) << 16;
> + data |= reg;
> + if (len > 1)
> + data |= PORT_SGMII_AUTO_INCR;
> + ksz_pwrite32(dev, port, REG_PORT_SGMII_ADDR__4, data);
> +}
> +
> +static void port_sgmii_r(struct ksz_device *dev, uint port, u16 devid, u16 reg,
> + u16 *buf, u16 len)
> +{
> + u32 data;
> +
> + mutex_lock(&dev->sgmii_mutex);
You won't need sgmii_mutex if all accesses go through the MDIO bus
accessors (please do so and get rid of this mutex.)
> + port_sgmii_s(dev, port, devid, reg, len);
> + while (len) {
> + ksz_pread32(dev, port, REG_PORT_SGMII_DATA__4, &data);
> + *buf++ = (u16)data;
> + len--;
> + }
> + mutex_unlock(&dev->sgmii_mutex);
> +}
> +
> +static void port_sgmii_w(struct ksz_device *dev, uint port, u16 devid, u16 reg,
> + u16 *buf, u16 len)
> +{
> + u32 data;
> +
> + mutex_lock(&dev->sgmii_mutex);
> + port_sgmii_s(dev, port, devid, reg, len);
> + while (len) {
> + data = *buf++;
> + ksz_pwrite32(dev, port, REG_PORT_SGMII_DATA__4, data);
> + len--;
> + }
> + mutex_unlock(&dev->sgmii_mutex);
> +}
I don't see any need for any of the above complexity for writing
multiple registers. All your calls to the above two functions only
pass a value of 1 for len.
> +
> +static void port_sgmii_reset(struct ksz_device *dev, uint p)
> +{
> + u16 ctrl = BMCR_RESET;
> +
> + port_sgmii_w(dev, p, MDIO_MMD_VEND2, MII_BMCR, &ctrl, 1);
> +}
doesn't xpcs_create() result in xpcs->need_reset being set true, and
thus when the XPCS is used, cause xpcs_pre_config() to do a soft reset
of the XPCS? More importantly, the XPCS driver waits for the reset
to complete...
> @@ -978,6 +1085,13 @@ void ksz9477_get_caps(struct ksz_device *dev, int port,
>
> if (dev->info->gbit_capable[port])
> config->mac_capabilities |= MAC_1000FD;
> +
> + if (ksz_is_sgmii_port(dev, port)) {
> + __set_bit(PHY_INTERFACE_MODE_1000BASEX,
> + config->supported_interfaces);
> + __set_bit(PHY_INTERFACE_MODE_SGMII,
> + config->supported_interfaces);
> + }
f (ksz_is_sgmii_port(dev, port))
phy_interface_or(config->supported_interfaces,
config->supported_interfaces,
xpcs_to_phylink_pcs(port->xpcs)->supported_interfaces);
If xpcs_to_phylink_pcs(port->xpcs)->supported_interfaces does not
accurately indicate the interfaces that are supported on your XPCS
model, then you need further xpcs driver changes.
> +static inline int ksz_get_sgmii_port(struct ksz_device *dev)
> +{
> + return (dev->info->sgmii_port - 1);
> +}
> +
> +static inline bool ksz_has_sgmii_port(struct ksz_device *dev)
> +{
> + return (dev->info->sgmii_port > 0);
> +}
> +
> +static inline bool ksz_is_sgmii_port(struct ksz_device *dev, int port)
> +{
> + return (dev->info->sgmii_port == port + 1);
> +}
No need for the parens in any of the above three.
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:[~2025-01-28 9:39 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-28 3:32 [PATCH RFC net-next 0/2] Add SGMII port support to KSZ9477 switch Tristram.Ha
2025-01-28 3:32 ` [PATCH RFC net-next 1/2] net: pcs: xpcs: Add special code to operate in Microchip " Tristram.Ha
2025-01-28 9:24 ` Russell King (Oracle)
2025-01-28 10:21 ` Vladimir Oltean
2025-01-28 12:33 ` Russell King (Oracle)
2025-01-28 15:23 ` Vladimir Oltean
2025-01-28 16:32 ` Russell King (Oracle)
2025-01-28 18:26 ` Vladimir Oltean
2025-01-29 0:31 ` Tristram.Ha
2025-01-29 21:12 ` Vladimir Oltean
2025-01-29 22:05 ` Russell King (Oracle)
2025-01-29 23:05 ` Vladimir Oltean
2025-01-30 12:44 ` Russell King (Oracle)
2025-01-30 17:42 ` Russell King (Oracle)
2025-01-30 4:50 ` [WARNING: ATTACHMENT UNSCANNED]Re: " Tristram.Ha
2025-01-30 10:02 ` Vladimir Oltean
2025-01-30 11:02 ` Russell King (Oracle)
2025-01-30 11:20 ` Jose Abreu
2025-01-31 14:36 ` Jose Abreu
2025-01-31 15:49 ` Russell King (Oracle)
2025-02-01 1:12 ` [WARNING: ATTACHMENT UNSCANNED]Re: " Tristram.Ha
2025-02-01 9:20 ` Russell King (Oracle)
2025-01-31 2:35 ` Tristram.Ha
2025-01-30 10:15 ` Russell King (Oracle)
2025-01-31 2:35 ` Tristram.Ha
2025-01-31 13:35 ` Andrew Lunn
2025-02-01 1:11 ` Tristram.Ha
2025-01-30 4:50 ` Tristram.Ha
2025-01-30 9:59 ` Russell King (Oracle)
2025-01-31 2:24 ` Tristram.Ha
2025-01-31 9:43 ` Russell King (Oracle)
2025-01-30 13:24 ` Andrew Lunn
2025-01-31 2:21 ` Tristram.Ha
2025-01-28 12:40 ` Russell King (Oracle)
2025-01-28 13:16 ` Andrew Lunn
2025-01-28 13:39 ` Russell King (Oracle)
2025-01-28 15:43 ` Vladimir Oltean
2025-01-29 0:31 ` Tristram.Ha
2025-01-28 3:32 ` [PATCH RFC net-next 2/2] net: dsa: microchip: Add SGMII port support to " Tristram.Ha
2025-01-28 9:38 ` Russell King (Oracle) [this message]
2025-01-28 12:50 ` kernel test robot
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=Z5ilrp1c6lbMGqbl@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=Tristram.Ha@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=woojung.huh@microchip.com \
/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.