All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Steve Douthit <stephend@silicom-usa.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	"intel-wired-lan@lists.osuosl.org"
	<intel-wired-lan@lists.osuosl.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH net-next v2 1/2] ixgbe: register a mdiobus
Date: Mon, 3 Dec 2018 18:21:16 +0100	[thread overview]
Message-ID: <20181203172116.GJ25748@lunn.ch> (raw)
In-Reply-To: <70350444-f05f-c57f-d4d8-0e059b4d896c@silicom-usa.com>

On Mon, Dec 03, 2018 at 05:02:40PM +0000, Steve Douthit wrote:
> On 12/3/18 11:54 AM, Andrew Lunn wrote:
> >> +static s32 ixgbe_x550em_a_mii_bus_read(struct mii_bus *bus, int addr,
> >> +				       int regnum)
> >> +{
> >> +	struct ixgbe_adapter *adapter = (struct ixgbe_adapter *)bus->priv;
> >> +	struct ixgbe_hw *hw = &adapter->hw;
> >> +	u32 gssr = hw->phy.phy_semaphore_mask | IXGBE_GSSR_TOKEN_SM;
> >> +
> >> +	if (hw->bus.lan_id)
> >> +		gssr |= IXGBE_GSSR_PHY1_SM;
> >> +	else
> >> +		gssr |= IXGBE_GSSR_PHY0_SM;
> > 
> > Hi Steve
> > 
> > If you only have one bus, do you still need this? One semaphore is all
> > you need. And i'm not even sure you need that. The MDIO layer will
> > perform locking, assuming everything goes through the MDIO layer.
> 
> AFAIK I still need part of it.  There's a PHY polling unit in the card
> that we need to sync with independent of the locking in the MDIO layer.
> I can drop the hw->bus.lan_id check though and unconditionally OR in the
> IXGBE_GSSR_PHY0_SM since we always register on function 0 now.

Hi Steve

In general, this is not enough to make a PHY polling unit safe. At
least not with C22 devices. They often have a register which can be
used to select a different page. The software driver can do a write to
swap the page at any time, e.g. to select the page with the
temperature sensor. After it releases the semaphore for that write
changing the page, the hardware could then poll the PHY, and read a
temperature sensor register instead of the link status, and then bad
things happen.

When using Intel's PHY drivers embedded within the Intel MAC driver,
this is not a problem. They can avoid swapping to different
pages. However, you are on the path to allow the Linux PHY drivers to
be used, and some of them will change the page. And with the embedded
SOC you are working on, i would not be too surprised to see somebody
build a system using a different PHY which the Intel PHY drivers don't
support, but does have a Linux PHY driver.

You also need to watch out for your use case of Marvell
mv88e6390. Polling that makes no sense. Does the hardware actually
recognise it is not a PHY?

	  Andrew

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH net-next v2 1/2] ixgbe: register a mdiobus
Date: Mon, 3 Dec 2018 18:21:16 +0100	[thread overview]
Message-ID: <20181203172116.GJ25748@lunn.ch> (raw)
In-Reply-To: <70350444-f05f-c57f-d4d8-0e059b4d896c@silicom-usa.com>

On Mon, Dec 03, 2018 at 05:02:40PM +0000, Steve Douthit wrote:
> On 12/3/18 11:54 AM, Andrew Lunn wrote:
> >> +static s32 ixgbe_x550em_a_mii_bus_read(struct mii_bus *bus, int addr,
> >> +				       int regnum)
> >> +{
> >> +	struct ixgbe_adapter *adapter = (struct ixgbe_adapter *)bus->priv;
> >> +	struct ixgbe_hw *hw = &adapter->hw;
> >> +	u32 gssr = hw->phy.phy_semaphore_mask | IXGBE_GSSR_TOKEN_SM;
> >> +
> >> +	if (hw->bus.lan_id)
> >> +		gssr |= IXGBE_GSSR_PHY1_SM;
> >> +	else
> >> +		gssr |= IXGBE_GSSR_PHY0_SM;
> > 
> > Hi Steve
> > 
> > If you only have one bus, do you still need this? One semaphore is all
> > you need. And i'm not even sure you need that. The MDIO layer will
> > perform locking, assuming everything goes through the MDIO layer.
> 
> AFAIK I still need part of it.  There's a PHY polling unit in the card
> that we need to sync with independent of the locking in the MDIO layer.
> I can drop the hw->bus.lan_id check though and unconditionally OR in the
> IXGBE_GSSR_PHY0_SM since we always register on function 0 now.

Hi Steve

In general, this is not enough to make a PHY polling unit safe. At
least not with C22 devices. They often have a register which can be
used to select a different page. The software driver can do a write to
swap the page at any time, e.g. to select the page with the
temperature sensor. After it releases the semaphore for that write
changing the page, the hardware could then poll the PHY, and read a
temperature sensor register instead of the link status, and then bad
things happen.

When using Intel's PHY drivers embedded within the Intel MAC driver,
this is not a problem. They can avoid swapping to different
pages. However, you are on the path to allow the Linux PHY drivers to
be used, and some of them will change the page. And with the embedded
SOC you are working on, i would not be too surprised to see somebody
build a system using a different PHY which the Intel PHY drivers don't
support, but does have a Linux PHY driver.

You also need to watch out for your use case of Marvell
mv88e6390. Polling that makes no sense. Does the hardware actually
recognise it is not a PHY?

	  Andrew


  reply	other threads:[~2018-12-03 17:21 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-03 16:32 [PATCH net-next v2 0/2] Add mii_bus to ixgbe driver for dsa devs Steve Douthit
2018-12-03 16:32 ` [Intel-wired-lan] " Steve Douthit
2018-12-03 16:32 ` [PATCH net-next v2 1/2] ixgbe: register a mdiobus Steve Douthit
2018-12-03 16:32   ` [Intel-wired-lan] " Steve Douthit
2018-12-03 16:54   ` Andrew Lunn
2018-12-03 16:54     ` [Intel-wired-lan] " Andrew Lunn
2018-12-03 17:02     ` Steve Douthit
2018-12-03 17:02       ` [Intel-wired-lan] " Steve Douthit
2018-12-03 17:21       ` Andrew Lunn [this message]
2018-12-03 17:21         ` Andrew Lunn
2018-12-03 17:59         ` Steve Douthit
2018-12-03 17:59           ` [Intel-wired-lan] " Steve Douthit
2018-12-03 18:18           ` Andrew Lunn
2018-12-03 18:18             ` [Intel-wired-lan] " Andrew Lunn
2018-12-03 18:38             ` Steve Douthit
2018-12-03 18:38               ` [Intel-wired-lan] " Steve Douthit
2018-12-03 18:54               ` Andrew Lunn
2018-12-03 18:54                 ` [Intel-wired-lan] " Andrew Lunn
2018-12-03 16:33 ` [PATCH net-next v2 2/2] ixgbe: use mii_bus to handle MII related ioctls Steve Douthit
2018-12-03 16:33   ` [Intel-wired-lan] " Steve Douthit
2018-12-03 18:55 ` [PATCH net-next v3 0/2] Add mii_bus to ixgbe driver for dsa devs Steve Douthit
2018-12-03 18:55   ` [Intel-wired-lan] " Steve Douthit
2018-12-03 18:55   ` [PATCH net-next v3 1/2] ixgbe: register a mdiobus Steve Douthit
2018-12-03 18:55     ` [Intel-wired-lan] " Steve Douthit
2018-12-03 19:00     ` Andrew Lunn
2018-12-03 19:00       ` [Intel-wired-lan] " Andrew Lunn
2018-12-03 19:07     ` Florian Fainelli
2018-12-03 19:07       ` [Intel-wired-lan] " Florian Fainelli
2018-12-03 19:44       ` Steve Douthit
2018-12-03 19:44         ` [Intel-wired-lan] " Steve Douthit
2018-12-03 19:45         ` Florian Fainelli
2018-12-03 19:45           ` [Intel-wired-lan] " Florian Fainelli
2018-12-03 18:55   ` [PATCH net-next v3 2/2] ixgbe: use mii_bus to handle MII related ioctls Steve Douthit
2018-12-03 18:55     ` [Intel-wired-lan] " Steve Douthit
2018-12-03 19:01     ` Andrew Lunn
2018-12-03 19:01       ` [Intel-wired-lan] " Andrew Lunn
2018-12-03 19:07     ` Florian Fainelli
2018-12-03 19:07       ` [Intel-wired-lan] " Florian Fainelli
2018-12-03 20:14 ` [PATCH net-next v4 0/2] Add mii_bus to ixgbe driver for dsa devs Steve Douthit
2018-12-03 20:14   ` [Intel-wired-lan] " Steve Douthit
2018-12-03 20:15   ` [PATCH net-next v4 1/2] ixgbe: register a mdiobus Steve Douthit
2018-12-03 20:15     ` [Intel-wired-lan] " Steve Douthit
2018-12-04 16:58     ` Bowers, AndrewX
2018-12-04 16:58       ` [Intel-wired-lan] " Bowers, AndrewX
2018-12-03 20:15   ` [PATCH net-next v4 2/2] ixgbe: use mii_bus to handle MII related ioctls Steve Douthit
2018-12-03 20:15     ` [Intel-wired-lan] " Steve Douthit
2018-12-04 16:59     ` Bowers, AndrewX
2018-12-04 16:59       ` [Intel-wired-lan] " Bowers, AndrewX
2018-12-03 20:51   ` [PATCH net-next v4 0/2] Add mii_bus to ixgbe driver for dsa devs Florian Fainelli
2018-12-03 20:51     ` [Intel-wired-lan] " Florian Fainelli
2018-12-03 23:42     ` Steve Douthit
2018-12-03 23:42       ` [Intel-wired-lan] " Steve Douthit
2018-12-03 23:46       ` Florian Fainelli
2018-12-03 23:46         ` [Intel-wired-lan] " Florian Fainelli
2018-12-04 10:40         ` Andrew Lunn
2018-12-04 10:40           ` [Intel-wired-lan] " Andrew Lunn
2018-12-04 16:02         ` Steve Douthit
2018-12-04 16:02           ` [Intel-wired-lan] " Steve Douthit
2018-12-06 15:50 ` [PATCH net-next v5 " Steve Douthit
2018-12-06 15:50   ` [Intel-wired-lan] " Steve Douthit
2018-12-06 15:50   ` [PATCH net-next v5 1/2] ixgbe: register a mdiobus Steve Douthit
2018-12-06 15:50     ` [Intel-wired-lan] " Steve Douthit
2018-12-06 15:50   ` [PATCH net-next v5 2/2] ixgbe: use mii_bus to handle MII related ioctls Steve Douthit
2018-12-06 15:50     ` [Intel-wired-lan] " Steve Douthit

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=20181203172116.GJ25748@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=stephend@silicom-usa.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.