All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Wong Vee Khee <vee.khee.wong@linux.intel.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC net-next 0/2] Introduce MDIO probe order C45 over C22
Date: Wed, 2 Jun 2021 00:21:58 +0200	[thread overview]
Message-ID: <YLazBrpXbpsb6aXI@lunn.ch> (raw)
In-Reply-To: <20210601154423.GA27463@linux.intel.com>

On Tue, Jun 01, 2021 at 11:44:23PM +0800, Wong Vee Khee wrote:
> On Tue, Jun 01, 2021 at 03:04:51PM +0200, Andrew Lunn wrote:
> > On Tue, Jun 01, 2021 at 06:47:34PM +0800, Wong Vee Khee wrote:
> > > On Tue, May 25, 2021 at 03:34:34PM +0200, Andrew Lunn wrote:
> > > > On Tue, May 25, 2021 at 01:58:03PM +0800, Wong Vee Khee wrote:
> > > > > Synopsys MAC controller is capable of pairing with external PHY devices
> > > > > that accessible via Clause-22 and Clause-45.
> > > > > 
> > > > > There is a problem when it is paired with Marvell 88E2110 which returns
> > > > > PHY ID of 0 using get_phy_c22_id(). We can add this check in that
> > > > > function, but this will break swphy, as swphy_reg_reg() return 0. [1]
> > > > 
> > > > Is it possible to identify it is a Marvell PHY? Do any of the other
> > > > C22 registers return anything unique? I'm wondering if adding
> > > > .match_phy_device to genphy would work to identify it is a Marvell PHY
> > > > and not bind to it. Or we can turn it around, make the
> > > > .match_phy_device specifically look for the fixed-link device by
> > > > putting a magic number in one of the vendor registers.
> > > >
> > > 
> > > I checked the Marvell and did not see any unique register values.
> > > Also, since get_phy_c22_id() returns a *phy_id== 0, it is not bind to
> > > any PHY driver, so I don't think adding the match_phy_device check in
> > > getphy would help.
> > 
> > It has a Marvell ID in C45 space. So maybe we need to special case for
> > ID 0. If we get that, go look in C45 space. If we find a valid ID, use
> > it. If we get EOPNOTSUP because the MDIO bus is not C45 capable, or we
> > don't find a vendor ID in C45 space, keep with id == 0 and load
> > genphy?
> >
> 
> Make sense for me.
> Let me what you think of adding the checks in *get_phy_device():
> 
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 1539ea021ac0..ad9a87fadea1 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -862,11 +862,21 @@ struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45)
>         c45_ids.mmds_present = 0;
>         memset(c45_ids.device_ids, 0xff, sizeof(c45_ids.device_ids));
> 
> -       if (is_c45)
> +       if (is_c45) {
>                 r = get_phy_c45_ids(bus, addr, &c45_ids);
> -       else
> +       } else {
>                 r = get_phy_c22_id(bus, addr, &phy_id);
> 
> +               if (phy_id == 0) {
> +                       r = get_phy_c45_ids(bus, addr, &c45_ids);
> +                       if (r == -ENOTSUPP || r == -ENODEV)
> +                               return 0;

This bit is not correct. I said 'or we don't find a vendor ID in C45
space, keep with id == 0'. We need to keep backwards compatibility. If
get_phy_c22_id() did not return an error we should create a device
with phy_id 0, if get_phy_c45_ids() returns an error.

     Andrew

  reply	other threads:[~2021-06-01 22:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-25  5:58 [RFC net-next 0/2] Introduce MDIO probe order C45 over C22 Wong Vee Khee
2021-05-25 13:34 ` Andrew Lunn
2021-06-01 10:47   ` Wong Vee Khee
2021-06-01 13:04     ` Andrew Lunn
2021-06-01 15:44       ` Wong Vee Khee
2021-06-01 22:21         ` Andrew Lunn [this message]
2021-06-01 23:03           ` Wong Vee Khee
2021-06-02  2:19             ` Andrew Lunn
2021-06-02 14:15               ` Wong Vee Khee
2021-06-02 15:03                 ` Andrew Lunn
2021-06-02 23:51                   ` Wong Vee Khee
2021-06-05  0:37                     ` Wong Vee Khee
2021-06-05 18:36                       ` Andrew Lunn
2021-06-06  0:54                         ` Wong Vee Khee

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=YLazBrpXbpsb6aXI@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=vee.khee.wong@linux.intel.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.