All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Michael Walle <michael@walle.cc>,
	bcm-kernel-feedback-list@broadcom.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>
Subject: Re: [PATCH net-next] net: phy: introduce phydev->port
Date: Wed, 10 Feb 2021 11:01:49 +0000	[thread overview]
Message-ID: <20210210110148.GT1463@shell.armlinux.org.uk> (raw)
In-Reply-To: <YCM8JiO4FfKx5ECo@lunn.ch>

On Wed, Feb 10, 2021 at 02:51:34AM +0100, Andrew Lunn wrote:
> This is a general comment, not a problem specific to this patch.
> 
> There is some interesting race conditions here. The marvell driver
> first checks the fibre page and gets the status of the fiber port. As
> you can see from the hunk above, it clears out pause, duplex, speed,
> sets port to PORT_FIBRE, and then reads the PHY registers to set these
> values. If link is not detected on the fibre, it swaps page and does
> it all again, but for the copper port. So once per second,
> phydev->port is going to flip flop PORT_FIBER->PORT_TP, if copper has
> link.
> 
> Now, the read_status() call into the driver should be performed while
> holding the phydev->lock. So to the PHY state machine, this flip/flop
> does not matter, it is atomic with respect to the lock. But
> phy_ethtool_ksettings_get() is not talking the lock. It could see
> speed, duplex, and port while they have _UNKNOWN values, or port is
> part way through a flip flop. I think we need to take the lock here.
> phy_ethtool_ksettings_set() should also probably take the lock.

phy_ethtool_ksettings_get() needs to take the lock, otherwise it could
read the phy_device members in the middle of an update. This is likely
a long-standing phylib bug.

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

  reply	other threads:[~2021-02-10 11:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 16:38 [PATCH net-next] net: phy: introduce phydev->port Michael Walle
2021-02-09 23:01 ` Florian Fainelli
2021-02-10  1:51 ` Andrew Lunn
2021-02-10 11:01   ` Russell King - ARM Linux admin [this message]
2021-02-10  1:53 ` Andrew Lunn
2021-02-10 11:20 ` Michael Walle
2021-02-10 11:54   ` Russell King - ARM Linux admin
2021-02-10 12:10     ` Michael Walle
2021-02-10 18:34   ` Florian Fainelli

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=20210210110148.GT1463@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=netdev@vger.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 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.