netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Marangi <ansuelsmth@gmail.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: "Andrew Lunn" <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Florian Fainelli" <florian.fainelli@broadcom.com>,
	"Broadcom internal kernel review list"
	<bcm-kernel-feedback-list@broadcom.com>,
	"Marek Behún" <kabel@kernel.org>,
	"Eric Woudstra" <ericwouds@gmail.com>,
	"Daniel Golle" <daniel@makrotopia.org>,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [net-next RFC PATCH v3 3/4] net: phy: Add support for Aeonsemi AS21xxx PHYs
Date: Thu, 27 Mar 2025 12:36:56 +0100	[thread overview]
Message-ID: <67e53859.050a0220.1a855c.24af@mx.google.com> (raw)
In-Reply-To: <67e536e4.df0a0220.52fd8.a470@mx.google.com>

On Thu, Mar 27, 2025 at 12:30:42PM +0100, Christian Marangi wrote:
> On Thu, Mar 27, 2025 at 11:24:26AM +0000, Russell King (Oracle) wrote:
> > On Thu, Mar 27, 2025 at 12:35:03AM +0100, Christian Marangi wrote:
> > > +static int as21xxx_match_phy_device(struct phy_device *phydev,
> > > +				    const struct phy_driver *phydrv)
> > > +{
> > > +	struct as21xxx_priv *priv;
> > > +	u32 phy_id;
> > > +	int ret;
> > > +
> > > +	/* Skip PHY that are not AS21xxx or already have firmware loaded */
> > > +	if (phydev->c45_ids.device_ids[MDIO_MMD_PCS] != PHY_ID_AS21XXX)
> > > +		return phydev->phy_id == phydrv->phy_id;
> > 
> > Isn't phydev->phy_id zero here for a clause 45 PHY? If the firmware
> > has been loaded, I believ eyou said that PHY_ID_AS21XXX won't be
> > used, so the if() will be true, and because we've read clause 45
> > IDs, phydev->phy_id will be zero meaning this will never match. So
> > a PHY with firmware loaded won't ever match any of these drivers.
> > This is probably not what you want.
> 
> You are right. I will generalize the function to skip having to redo the
> logic. With FW loaded either c45 and c22 ID are filled in.
> 
> > 
> > I'd suggest converting the tail of phy_bus_match() so that you can
> > call that to do the standard matching using either C22 or C45 IDs
> > as appropriate without duplicating that code.
> > 
> > > +
> > > +	/* Read PHY ID to handle firmware just loaded */
> > > +	ret = phy_read_mmd(phydev, MDIO_MMD_PCS, MII_PHYSID1);
> > > +	if (ret < 0)
> > > +		return ret;
> > > +	phy_id = ret << 16;
> > > +
> > > +	ret = phy_read_mmd(phydev, MDIO_MMD_PCS, MII_PHYSID2);
> > > +	if (ret < 0)
> > > +		return ret;
> > > +	phy_id |= ret;
> > > +
> > > +	/* With PHY ID not the generic AS21xxx one assume
> > > +	 * the firmware just loaded
> > > +	 */
> > > +	if (phy_id != PHY_ID_AS21XXX)
> > > +		return phy_id == phydrv->phy_id;
> > > +
> > > +	/* Allocate temp priv and load the firmware */
> > > +	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> > > +	if (!priv)
> > > +		return -ENOMEM;
> > > +
> > > +	mutex_init(&priv->ipc_lock);
> > > +
> > > +	ret = aeon_firmware_load(phydev);
> > > +	if (ret)
> > > +		return ret;
> > > +
> > > +	ret = aeon_ipc_sync_parity(phydev, priv);
> > > +	if (ret)
> > > +		return ret;
> > > +
> > > +	/* Enable PTP clk if not already Enabled */
> > > +	ret = phy_set_bits_mmd(phydev, MDIO_MMD_VEND1, VEND1_PTP_CLK,
> > > +			       VEND1_PTP_CLK_EN);
> > > +	if (ret)
> > > +		return ret;
> > > +
> > > +	ret = aeon_dpc_ra_enable(phydev, priv);
> > > +	if (ret)
> > > +		return ret;
> > > +
> > > +	mutex_destroy(&priv->ipc_lock);
> > > +	kfree(priv);
> > > +
> > > +	/* Return not maching anyway as PHY ID will change after
> > > +	 * firmware is loaded.
> > 
> > Also "This relies on the driver probe order."
> > 
> > > +	 */
> > > +	return 0;
> > > +}
> > > +
> > > +static struct phy_driver as21xxx_drivers[] = {
> > > +	{
> > > +		/* PHY expose in C45 as 0x7500 0x9410
> > > +		 * before firmware is loaded.
> > 
> > Also "This driver entry must be attempted first to load the firmware and
> > thus update the ID registers."
> > 
> > > +		 */
> > > +		PHY_ID_MATCH_EXACT(PHY_ID_AS21XXX),
> > > +		.name		= "Aeonsemi AS21xxx",
> > > +		.match_phy_device = as21xxx_match_phy_device,
> > > +	},
> > > +	{
> > > +		PHY_ID_MATCH_EXACT(PHY_ID_AS21011JB1),
> > > +		.name		= "Aeonsemi AS21011JB1",
> > > +		.probe		= as21xxx_probe,
> > > +		.match_phy_device = as21xxx_match_phy_device,
> > > +		.read_status	= as21xxx_read_status,
> > > +		.led_brightness_set = as21xxx_led_brightness_set,
> > > +		.led_hw_is_supported = as21xxx_led_hw_is_supported,
> > > +		.led_hw_control_set = as21xxx_led_hw_control_set,
> > > +		.led_hw_control_get = as21xxx_led_hw_control_get,
> > > +		.led_polarity_set = as21xxx_led_polarity_set,
> > 
> > If I'm reading these driver entries correctly, the only reason for
> > having separate entries is to be able to have a unique name printed
> > for each - the methods themselves are all identical.
> > 
> > My feeling is that is not a sufficient reason to duplicate the driver
> > entries, which adds bloat (not only in terms of static data, but also
> > the data structures necessary to support each entry in sysfs.) However,
> > lets see what Andrew says.
> >
> 
> If you remember that was one of my crazy project in trying to reduce the
> array but I remember it did end up bad or abbandoned with the problem of
> having to reinvent each PHY. Probably my changes caused too much patch
> delta.
> 
> The proposal was exactly to pack all the struct that have similar OPs
> with introducing an array of PHY ID for each driver.
>

Found the old series. [1]

[1] https://lore.kernel.org/all/20240218190034.15447-1-ansuelsmth@gmail.com/

-- 
	Ansuel

  reply	other threads:[~2025-03-27 11:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-26 23:35 [net-next RFC PATCH v3 0/4] net: phy: Add support for new Aeonsemi PHYs Christian Marangi
2025-03-26 23:35 ` [net-next RFC PATCH v3 1/4] net: phy: pass PHY driver to .match_phy_device OP Christian Marangi
2025-03-27 11:07   ` Russell King (Oracle)
2025-03-27 14:15     ` Christian Marangi
2025-03-26 23:35 ` [net-next RFC PATCH v3 2/4] net: phy: bcm87xx: simplify " Christian Marangi
2025-03-27 11:08   ` Russell King (Oracle)
2025-03-26 23:35 ` [net-next RFC PATCH v3 3/4] net: phy: Add support for Aeonsemi AS21xxx PHYs Christian Marangi
2025-03-27  8:24   ` Maxime Chevallier
2025-03-27 11:24     ` Christian Marangi
2025-03-27 11:24   ` Russell King (Oracle)
2025-03-27 11:26     ` Russell King (Oracle)
2025-03-27 11:30     ` Christian Marangi
2025-03-27 11:36       ` Christian Marangi [this message]
2025-03-26 23:35 ` [net-next RFC PATCH v3 4/4] dt-bindings: net: Document support for Aeonsemi PHYs Christian Marangi

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=67e53859.050a0220.1a855c.24af@mx.google.com \
    --to=ansuelsmth@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel@makrotopia.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=ericwouds@gmail.com \
    --cc=florian.fainelli@broadcom.com \
    --cc=hkallweit1@gmail.com \
    --cc=kabel@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).