public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <ben@decadent.org.uk>
To: David Miller <davem@davemloft.net>
Cc: aparames@broadcom.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com, rjui@broadcom.com,
	sbranden@broadcom.com, jdzheng@broadcom.com
Subject: Re: [PATCH 1/1] net: core: 'ethtool' issue with querying phy settings
Date: Mon, 01 Jun 2015 19:05:31 +0100	[thread overview]
Message-ID: <1433181931.6319.176.camel@decadent.org.uk> (raw)
In-Reply-To: <20150531.171940.1635713770956335110.davem@davemloft.net>

[-- Attachment #1: Type: text/plain, Size: 2661 bytes --]

On Sun, 2015-05-31 at 17:19 -0700, David Miller wrote:
> From: Ben Hutchings <ben@decadent.org.uk>
> Date: Sun, 31 May 2015 20:54:06 +0100
> 
> > On Fri, 2015-05-22 at 16:15 -0400, David Miller wrote:
> >> From: Arun Parameswaran <aparames@broadcom.com>
> >> Date: Wed, 20 May 2015 14:35:30 -0700
> >> 
> >> > When trying to configure the settings for PHY1, using commands
> >> > like 'ethtool -s eth0 phyad 1 speed 100', the 'ethtool' seems to
> >> > modify other settings apart from the speed of the PHY1, in the
> >> > above case.
> >> > 
> >> > The ethtool seems to query the settings for PHY0, and use this
> >> > as the base to apply the new settings to the PHY1. This is
> >> > causing the other settings of the PHY 1 to be wrongly
> >> > configured.
> >> > 
> >> > The issue is caused by the '_ethtool_get_settings()' API, which
> >> > gets called because of the 'ETHTOOL_GSET' command, is clearing
> >> > the 'cmd' pointer (of type 'struct ethtool_cmd') by calling
> >> > memset. This clears all the parameters (if any) passed for the
> >> > 'ETHTOOL_GSET' cmd. So the driver's callback is always invoked
> >> > with 'cmd->phy_address' as '0'.
> >> > 
> >> > The '_ethtool_get_settings()' is called from other files in the
> >> > 'net/core'. So the fix is applied to the 'ethtool_get_settings()'
> >> > which is only called in the context of the 'ethtool'.
> >> > 
> >> > Signed-off-by: Arun Parameswaran <aparames@broadcom.com>
> >> > Reviewed-by: Ray Jui <rjui@broadcom.com>
> >> > Reviewed-by: Scott Branden <sbranden@broadcom.com>
> >> 
> >> Applied and queued up for -stable, thanks.
> > 
> > Please revert this.  This is an incompatible API change, not a bug fix.
> > The established semantics are that 'phyad' is filled in by the driver;
> > it is not a parameter to the ETHTOOL_GSET command.
> 
> But then how in the world can the user specify specific PHY ADs for
> a device that will respond to more than one?

ETHTOOL_SSET sets the current PHY address and ETHTOOL_GSET gets it.

If multiple PHYs need to be configured for a single link then the driver
should configure them all at the same time rather than making it the
administrator's problem.

What we can't support with the current API are:
- multiple physical links behind a single net device (different
  configuration possible for each link)
- multiple PHYs are needed for a single link, and the driver can't
  automatically decide which to use (multiple addresses to set)

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat.
                           - John Lehman, Secretary of the US Navy 1981-1987

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

  reply	other threads:[~2015-06-01 18:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-20 21:35 [PATCH 0/1] Fix an issue with 'ethtool' configuring PHYs Arun Parameswaran
2015-05-20 21:35 ` [PATCH 1/1] net: core: 'ethtool' issue with querying phy settings Arun Parameswaran
2015-05-22 20:15   ` David Miller
2015-05-31 19:54     ` Ben Hutchings
2015-06-01  0:19       ` David Miller
2015-06-01 18:05         ` Ben Hutchings [this message]
2015-06-01 21:41           ` Arun Parameswaran
2015-06-01 21:46             ` David Miller
2015-06-01 23:53               ` Arun Parameswaran
2015-06-01 23:55                 ` David Miller
2015-06-02  0:57                 ` Ben Hutchings

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=1433181931.6319.176.camel@decadent.org.uk \
    --to=ben@decadent.org.uk \
    --cc=aparames@broadcom.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=jdzheng@broadcom.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rjui@broadcom.com \
    --cc=sbranden@broadcom.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox