All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: "Voon, Weifeng" <weifeng.voon@intel.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jose Abreu <joabreu@synopsys.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"Ong, Boon Leong" <boon.leong.ong@intel.com>
Subject: Re: [PATCH v1 net-next] net: phy: mdio_bus: make mdiobus_scan also cover PHY that only talks C45
Date: Tue, 27 Aug 2019 17:49:18 +0200	[thread overview]
Message-ID: <20190827154918.GO2168@lunn.ch> (raw)
In-Reply-To: <D6759987A7968C4889FDA6FA91D5CBC814758ED8@PGSMSX103.gar.corp.intel.com>

On Tue, Aug 27, 2019 at 03:23:34PM +0000, Voon, Weifeng wrote:
> > > > Make mdiobus_scan() to try harder to look for any PHY that only
> > talks C45.
> > > If you are not using Device Tree or ACPI, and you are letting the MDIO
> > > bus be scanned, it sounds like there should be a way for you to
> > > provide a hint as to which addresses should be scanned (that's
> > > mii_bus::phy_mask) and possibly enhance that with a mask of possible
> > > C45 devices?
> > 
> > Yes, i don't like this unconditional c45 scanning. A lot of MDIO bus
> > drivers don't look for the MII_ADDR_C45. They are going to do a C22
> > transfer, and maybe not mask out the MII_ADDR_C45 from reg, causing an
> > invalid register write. Bad things can then happen.
> > 
> > With DT and ACPI, we have an explicit indication that C45 should be used,
> > so we know on this platform C45 is safe to use. We need something
> > similar when not using DT or ACPI.
> > 
> > 	  Andrew
> 
> Florian and Andrew,
> The mdio c22 is using the start-of-frame ST=01 while mdio c45 is using ST=00
> as identifier. So mdio c22 device will not response to mdio c45 protocol.
> As in IEEE 802.1ae-2002 Annex 45A.3 mention that:
> " Even though the Clause 45 MDIO frames using the ST=00 frame code
> will also be driven on to the Clause 22 MII Management interface,
> the Clause 22 PHYs will ignore the frames. "
> 
> Hence, I am not seeing any concern that the c45 scanning will mess up with 
> c22 devices.

Hi Voon

Take for example mdio-hisi-femac.c 

static int hisi_femac_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
{
        struct hisi_femac_mdio_data *data = bus->priv;
        int ret;

        ret = hisi_femac_mdio_wait_ready(data);
        if (ret)
                return ret;

        writel((mii_id << BIT_PHY_ADDR_OFFSET) | regnum,
               data->membase + MDIO_RWCTRL);


There is no check here for MII_ADDR_C45. So it will perform a C22
transfer. And regnum will still have MII_ADDR_C45 in it, so the
writel() is going to set bit 30, since #define MII_ADDR_C45
(1<<30). What happens on this hardware under these conditions?

You cannot unconditionally ask an MDIO driver to do a C45
transfer. Some drivers are going to do bad things.

	  Andrew


  parent reply	other threads:[~2019-08-27 16:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-27  1:52 [PATCH v1 net-next] net: phy: mdio_bus: make mdiobus_scan also cover PHY that only talks C45 Voon Weifeng
2019-08-26 18:27 ` Florian Fainelli
2019-08-26 18:54   ` Andrew Lunn
2019-08-27 15:23     ` Voon, Weifeng
2019-08-27 15:37       ` Florian Fainelli
2019-08-27 15:49       ` Andrew Lunn [this message]
2019-08-28 15:41         ` Ong, Boon Leong
2019-08-28 17:00           ` Florian Fainelli
2019-08-28 17:36             ` Voon, Weifeng
2019-08-26 21:28 ` David Miller
2019-08-27 10:25   ` Voon, Weifeng

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=20190827154918.GO2168@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=boon.leong.ong@intel.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=joabreu@synopsys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=weifeng.voon@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.