lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 01 Jun 2015 20:29:23 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Arun Parameswaran <aparames@...adcom.com>
Cc:	Ben Hutchings <bwh@...nel.org>, netdev@...r.kernel.org,
	jdzheng@...adcom.com
Subject: Re: [PATCH 0/2] Fix couple of issues with 'ethtool' get/set API's

On Mon, 2015-06-01 at 12:12 -0700, Arun Parameswaran wrote:
> On 15-06-01 11:07 AM, Ben Hutchings wrote:
> > On Mon, 2015-06-01 at 10:14 -0700, Arun Parameswaran wrote:
> >> On 15-05-31 12:59 PM, Ben Hutchings wrote:
> >>> On Fri, 2015-05-22 at 15:43 -0700, Arun Parameswaran wrote:
> >>>> Hi,
> >>>> The patch fixes 2 issues with 'ethtool' getting/setting parametres in
> >>>> the do_gset() do_sset() API's.
> >>>>
> >>>> I have pushed a patch to the Kernel to fix an issue in the handling of
> >>>> the 'ethtool' commands which got accepted.
> >>>> This Kernel patch was based on Linux v4.1-rc4 and is available in:
> >>>> https://github.com/Broadcom/cygnus-linux/tree/net-core-ethtool-fix-v1
> >>>>
> >>>> The Kernel was always clearing the command from the 'ethtool' resulting
> >>>> in all operations to deal with PHY0. This prevents querying/setting
> >>>> PHY 1's settings.
> >>> [...]
> >>>
> >>> Each net device can be associated with a single PHY at a time, and the
> >>> ETHTOOL_GSET implementation should fill in the PHY address in the
> >>> ethtool_cmd::phy_address field.  Where there are multiple PHYs that can
> >>> be connected to the net device's MAC, an ETHTOOL_SSET operation can be
> >>> used to change that PHY address.
> >>>
> >> The above can be done by the driver when there is one PHY per MAC. In our
> >> case we have multiple PHYs controlled by the same MAC. I should have
> >> clarified this earlier, I apologize.
> > 
> > I understand that you can have multiple PHYs on the same MDIO bus, but
> > not how the MAC can use them at the same time.  Is this hardware level
> > bonding?  Or are multiple PHYs needed for a single link?
> > 
> We have an internal switch which manages the traffic to the PHY's (ports).
> There is 1 PHY per external port.
> The MAC is connected to the internal port of the switch.

Then you should create net devices for those external ports as well as
the internal port.

If I understand the switchdev API rightly, the external port devices
should implement the ethtool {get,set}_settings operations and the
ndo_switch_parent_id_get operation.  The existing net device should
expose only the internal link to the switch (which presumably isn't
configurable at all).

[...]
> But this prevents the 'ethtool' from being used to get/set data of
> specific PHY's.

That is fine because it is meant to manage the net device's own link (in
this case, the internal port), not other switch ports.

Ben.

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

Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ