Export a few functions so they can be used outside the phy subsystem:

get_phy_c22_id is useful when probing MDIO devices which present a
phy-like interface despite not using the Linux ethernet phy subsystem.

mdio_device_bus_match is useful when creating MDIO devices manually
(e.g. on non-devicetree platforms).

At the moment the only (future) user of these functions selects PHYLIB,
so we do not need fallbacks for when CONFIG_PHYLIB=n.

Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
---

(no changes since v1)

 drivers/net/phy/mdio_device.c | 1 +
 drivers/net/phy/phy_device.c  | 3 ++-
 include/linux/phy.h           | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/mdio_device.c b/drivers/net/phy/mdio_device.c
index e747ee63c665..cce3f405d1a4 100644
--- a/drivers/net/phy/mdio_device.c
+++ b/drivers/net/phy/mdio_device.c
@@ -45,6 +45,7 @@ int mdio_device_bus_match(struct device *dev, const struct device_driver *drv)
 
 	return strcmp(mdiodev->modalias, drv->name) == 0;
 }
+EXPORT_SYMBOL_GPL(mdio_device_bus_match);
 
 struct mdio_device *mdio_device_create(struct mii_bus *bus, int addr)
 {
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index cc6c209fe702..7548a274bcdb 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -899,7 +899,7 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr,
  * valid, %-EIO on bus access error, or %-ENODEV if no device responds
  * or invalid ID.
  */
-static int get_phy_c22_id(struct mii_bus *bus, int addr, u32 *phy_id)
+int get_phy_c22_id(struct mii_bus *bus, int addr, u32 *phy_id)
 {
 	int phy_reg;
 
@@ -927,6 +927,7 @@ static int get_phy_c22_id(struct mii_bus *bus, int addr, u32 *phy_id)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(get_phy_c22_id);
 
 /* Extract the phy ID from the compatible string of the form
  * ethernet-phy-idAAAA.BBBB.
diff --git a/include/linux/phy.h b/include/linux/phy.h
index fb755358d965..512ed1be4ec1 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1754,6 +1754,7 @@ struct phy_device *phy_device_create(struct mii_bus *bus, int addr, u32 phy_id,
 				     bool is_c45,
 				     struct phy_c45_device_ids *c45_ids);
 #if IS_ENABLED(CONFIG_PHYLIB)
+int get_phy_c22_id(struct mii_bus *bus, int addr, u32 *phy_id);
 int fwnode_get_phy_id(struct fwnode_handle *fwnode, u32 *phy_id);
 struct mdio_device *fwnode_mdio_find_device(struct fwnode_handle *fwnode);
 struct phy_device *fwnode_phy_find_device(struct fwnode_handle *phy_fwnode);
-- 
2.35.1.1320.gc452695387.dirty

On Mon, 12 May 2025 12:10:08 -0400 Sean Anderson wrote:
> Export a few functions so they can be used outside the phy subsystem:
> 
> get_phy_c22_id is useful when probing MDIO devices which present a
> phy-like interface despite not using the Linux ethernet phy subsystem.
> 
> mdio_device_bus_match is useful when creating MDIO devices manually
> (e.g. on non-devicetree platforms).
> 
> At the moment the only (future) user of these functions selects PHYLIB,
> so we do not need fallbacks for when CONFIG_PHYLIB=n.

This one does not apply cleanly.
-- 
pw-bot: cr

On 5/14/25 22:57, Jakub Kicinski wrote:
> On Mon, 12 May 2025 12:10:08 -0400 Sean Anderson wrote:
>> Export a few functions so they can be used outside the phy subsystem:
>> 
>> get_phy_c22_id is useful when probing MDIO devices which present a
>> phy-like interface despite not using the Linux ethernet phy subsystem.
>> 
>> mdio_device_bus_match is useful when creating MDIO devices manually
>> (e.g. on non-devicetree platforms).
>> 
>> At the moment the only (future) user of these functions selects PHYLIB,
>> so we do not need fallbacks for when CONFIG_PHYLIB=n.
> 
> This one does not apply cleanly.

Sorry, I forgot to rebase before sending this series.

--Sean

On Wed, May 14, 2025 at 07:57:16PM -0700, Jakub Kicinski wrote:
> On Mon, 12 May 2025 12:10:08 -0400 Sean Anderson wrote:
> > Export a few functions so they can be used outside the phy subsystem:
> > 
> > get_phy_c22_id is useful when probing MDIO devices which present a
> > phy-like interface despite not using the Linux ethernet phy subsystem.
> > 
> > mdio_device_bus_match is useful when creating MDIO devices manually
> > (e.g. on non-devicetree platforms).
> > 
> > At the moment the only (future) user of these functions selects PHYLIB,
> > so we do not need fallbacks for when CONFIG_PHYLIB=n.
> 
> This one does not apply cleanly.

In any case, we *still* have two competing implementations for PCS
support, and the authors have been asked to work together, but there's
been no sign of that with both authors posting their patch sets within
the last week.

Plus, I had asked for the patches to be posted as RFC because I'm not
going to have time to review them for a while (you may have noticed a
lack of patches from myself - because I don't have time to post them
as I'm working on stuff directed by my employer.)

Sadly, being employed means there will be times that I don't have the
bandwidth to look at mainline stuff.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

On 5/15/25 04:12, Russell King (Oracle) wrote:
> On Wed, May 14, 2025 at 07:57:16PM -0700, Jakub Kicinski wrote:
>> On Mon, 12 May 2025 12:10:08 -0400 Sean Anderson wrote:
>> > Export a few functions so they can be used outside the phy subsystem:
>> > 
>> > get_phy_c22_id is useful when probing MDIO devices which present a
>> > phy-like interface despite not using the Linux ethernet phy subsystem.
>> > 
>> > mdio_device_bus_match is useful when creating MDIO devices manually
>> > (e.g. on non-devicetree platforms).
>> > 
>> > At the moment the only (future) user of these functions selects PHYLIB,
>> > so we do not need fallbacks for when CONFIG_PHYLIB=n.
>> 
>> This one does not apply cleanly.
> 
> In any case, we *still* have two competing implementations for PCS
> support, and the authors have been asked to work together, but there's
> been no sign of that with both authors posting their patch sets within
> the last week.

I have commented on the other series with my feedback. You are welcome to
read it and decide if you agree or not.

> Plus, I had asked for the patches to be posted as RFC because I'm not
> going to have time to review them for a while (you may have noticed a
> lack of patches from myself - because I don't have time to post them
> as I'm working on stuff directed by my employer.)

I consider my series ready for mainline. I will not mark it RFC because
it's not an RFC.

> Sadly, being employed means there will be times that I don't have the
> bandwidth to look at mainline stuff.

Then perhaps some of the other netdev maintainers/reviewers could have
a look.

--Sean

Il giorno gio 15 mag 2025 alle ore 10:12 Russell King (Oracle)
<linux@armlinux.org.uk> ha scritto:
>
> On Wed, May 14, 2025 at 07:57:16PM -0700, Jakub Kicinski wrote:
> > On Mon, 12 May 2025 12:10:08 -0400 Sean Anderson wrote:
> > > Export a few functions so they can be used outside the phy subsystem:
> > >
> > > get_phy_c22_id is useful when probing MDIO devices which present a
> > > phy-like interface despite not using the Linux ethernet phy subsystem.
> > >
> > > mdio_device_bus_match is useful when creating MDIO devices manually
> > > (e.g. on non-devicetree platforms).
> > >
> > > At the moment the only (future) user of these functions selects PHYLIB,
> > > so we do not need fallbacks for when CONFIG_PHYLIB=n.
> >
> > This one does not apply cleanly.
>
> In any case, we *still* have two competing implementations for PCS
> support, and the authors have been asked to work together, but there's
> been no sign of that with both authors posting their patch sets within
> the last week.
>
> Plus, I had asked for the patches to be posted as RFC because I'm not
> going to have time to review them for a while (you may have noticed a
> lack of patches from myself - because I don't have time to post them
> as I'm working on stuff directed by my employer.)
>
> Sadly, being employed means there will be times that I don't have the
> bandwidth to look at mainline stuff.
>

Hi Russell,
my 2 cent on the topic, I'm more than happy to collaborate with Sean but
the implementation idea between the 2 is so different that we really need
some guidance on what is possible and what is not.

As said by Daniel, in my series we can totally introduce a compat layer
based on this and the all the PCS documentation for this is golden and
lovely.

For RFC, in my series I moved out of it to trigger some additional build test
and also because it seems to me sometimes RFC patch when net-next is
open gets ignored. (And also to stress that the thing works and is not only
an idea)

I know you are full busy with life and work, this is just to explain some
decisions from my side.

On 15.05.2025 04:57, Jakub Kicinski wrote:
> On Mon, 12 May 2025 12:10:08 -0400 Sean Anderson wrote:
>> Export a few functions so they can be used outside the phy subsystem:
>>
>> get_phy_c22_id is useful when probing MDIO devices which present a
>> phy-like interface despite not using the Linux ethernet phy subsystem.
>>
>> mdio_device_bus_match is useful when creating MDIO devices manually
>> (e.g. on non-devicetree platforms).
>>
>> At the moment the only (future) user of these functions selects PHYLIB,
>> so we do not need fallbacks for when CONFIG_PHYLIB=n.
> 
The functions should only be exported once there is a user.
Therefore I'd suggest to remove this patch from the series.

> This one does not apply cleanly.

On 5/15/25 01:38, Heiner Kallweit wrote:
> On 15.05.2025 04:57, Jakub Kicinski wrote:
>> On Mon, 12 May 2025 12:10:08 -0400 Sean Anderson wrote:
>>> Export a few functions so they can be used outside the phy subsystem:
>>>
>>> get_phy_c22_id is useful when probing MDIO devices which present a
>>> phy-like interface despite not using the Linux ethernet phy subsystem.
>>>
>>> mdio_device_bus_match is useful when creating MDIO devices manually
>>> (e.g. on non-devicetree platforms).
>>>
>>> At the moment the only (future) user of these functions selects PHYLIB,
>>> so we do not need fallbacks for when CONFIG_PHYLIB=n.
>> 
> The functions should only be exported once there is a user.
> Therefore I'd suggest to remove this patch from the series.

These functions are used in patches 5 (oops) and 7. I will split it up
and add it to those patches.

--Sean