public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Christian Marangi <ansuelsmth@gmail.com>
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>,
	Russell King <linux@armlinux.org.uk>,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [net-next RFC PATCH v2 2/3] net: phy: Add support for Aeonsemi AS21xxx PHYs
Date: Wed, 26 Mar 2025 15:56:15 +0100	[thread overview]
Message-ID: <dfa78876-d4a6-4226-b3d4-dbf112e001ee@lunn.ch> (raw)
In-Reply-To: <20250326002404.25530-3-ansuelsmth@gmail.com>

> +#define PHY_ID_AS21XXX			0x75009410
> +/* AS21xxx ID Legend
> + * AS21x1xxB1
> + *     ^ ^^
> + *     | |J: Supports SyncE/PTP
> + *     | |P: No SyncE/PTP support
> + *     | 1: Supports 2nd Serdes
> + *     | 2: Not 2nd Serdes support
> + *     0: 10G, 5G, 2.5G
> + *     5: 5G, 2.5G
> + *     2: 2.5G
> + */
> +#define PHY_ID_AS21011JB1		0x75009402
> +#define PHY_ID_AS21011PB1		0x75009412
> +#define PHY_ID_AS21010JB1		0x75009422
> +#define PHY_ID_AS21010PB1		0x75009432
> +#define PHY_ID_AS21511JB1		0x75009442
> +#define PHY_ID_AS21511PB1		0x75009452
> +#define PHY_ID_AS21510JB1		0x75009462
> +#define PHY_ID_AS21510PB1		0x75009472
> +#define PHY_ID_AS21210JB1		0x75009482
> +#define PHY_ID_AS21210PB1		0x75009492
> +#define PHY_VENDOR_AEONSEMI		0x75009400

O.K. This helps.

> +static struct phy_driver as21xxx_drivers[] = {
> +	{
> +		/* PHY expose in C45 as 0x7500 0x9410
> +		 * before firmware is loaded.
> +		 */
> +		PHY_ID_MATCH_EXACT(PHY_ID_AS21XXX),
> +		.name		= "Aeonsemi AS21xxx",
> +		.probe		= as21xxx_probe,
> +	},
> +	{
> +		PHY_ID_MATCH_EXACT(PHY_ID_AS21011JB1),
> +		.name		= "Aeonsemi AS21011JB1",
> +		.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,
> +	},

It is guaranteed by the current code that these entries are tried in
the order listed here. If that was to change, other drivers would
break.

So what you can do is have the first entry for PHY_ID_AS21XXX with
as21xxx_probe, have the probe download the firmware and then return
-ENODEV. PHY_ID_AS21XXX tells us there is no firmware, so this is what
we need to do. The -ENODEV then tells the core that this driver entry
does not match the hardware, try the next.

After the firmware download, the phylib core will still have the wrong
ID values. So you cannot use PHY_ID_MATCH_EXACT(PHY_ID_AS21011JB1).
But what you can do is have a .match_phy_device function. It will get
called, and it can read the real ID from the device, and perform a
match. If it does not match return -ENODEV, and the core will try the
next entry.

You either need N match_phy_device functions, one per ID value, or you
can make use of the .driver_data in phy_driver, and place the matching
data there.

In the end you should have the correct phy_driver structure for the
device. The core will still have the wrong ID values, which you should
document with a comment. But that mostly only effects
/sys/class/bus/mdio-bus/...

	Andrew

  parent reply	other threads:[~2025-03-26 14:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-26  0:23 [net-next RFC PATCH v2 0/3] net: phy: Add support for new Aeonsemi PHYs Christian Marangi
2025-03-26  0:23 ` [net-next RFC PATCH v2 1/3] net: phy: permit PHYs to register a second time Christian Marangi
2025-03-26  0:23 ` [net-next RFC PATCH v2 2/3] net: phy: Add support for Aeonsemi AS21xxx PHYs Christian Marangi
2025-03-26 13:53   ` Russell King (Oracle)
2025-03-26 13:57     ` Andrew Lunn
2025-03-26 14:47       ` Christian Marangi
2025-03-26 14:43     ` Christian Marangi
2025-03-26 18:02       ` Russell King (Oracle)
2025-03-26 14:00   ` Simon Horman
2025-03-26 14:05     ` Simon Horman
2025-03-26 14:56   ` Andrew Lunn [this message]
2025-03-26 15:09     ` Christian Marangi
2025-03-26 18:08     ` Russell King (Oracle)
2025-03-26 18:18       ` Christian Marangi
2025-03-26 18:32         ` Russell King (Oracle)
2025-03-26  0:23 ` [net-next RFC PATCH v2 3/3] dt-bindings: net: Document support for Aeonsemi PHYs Christian Marangi
2025-03-26 15:08   ` Andrew Lunn
2025-03-26 15:16     ` 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=dfa78876-d4a6-4226-b3d4-dbf112e001ee@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=andrew+netdev@lunn.ch \
    --cc=ansuelsmth@gmail.com \
    --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=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