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:30:42 +0100	[thread overview]
Message-ID: <67e536e4.df0a0220.52fd8.a470@mx.google.com> (raw)
In-Reply-To: <Z-U1anj6IbSdPGoD@shell.armlinux.org.uk>

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.

-- 
	Ansuel

  parent reply	other threads:[~2025-03-27 11:30 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 [this message]
2025-03-27 11:36       ` Christian Marangi
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=67e536e4.df0a0220.52fd8.a470@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).