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  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:	Sun, 27 Jul 2014 09:09:54 -0700
From:	John Fastabend <>
To:	Ben Hutchings <>,
	Mugunthan V N <>
Subject: Re: [RFC PATCH 1/1] ethtool: adding support for multiple slave port

On 07/26/2014 07:47 PM, Ben Hutchings wrote:
> On Fri, 2014-07-25 at 17:58 +0530, Mugunthan V N wrote:
>> Some Ethernet Swtich controllers like CPSW in AM335x, TI814x, DRA7x and
>> AM43xx SoCs, Network Coprocessor in AM5K2E0x, Realtek Switch controllers
>> etc has to capability of conneting multiple networks using L2 switching
>> and has multiple phys. With the existing code, ethtool can communicate
>> only to one phy.
>> To enable user to communicate multiple phy connected to single Ethernet
>> Switch controller, intoducing a optional new parameter in Ethtool interface
>> to pass which slave to set/get the phy configuration.
> There was some discussion about configuration APIs for hardware/firmware
> bridges earlier this year and I thought there was a consensus for
> assigning a network device to each port.  This would remove the need to
> identify ports within a device.  But I may have misremembered.

I like the approach of creating a network device for each port over
having to use ethtool to program/discover them. I am currently looking
at writing management applications for this and IMO it is much easier
to discover and listen for events on network devices vs polling ethtool
and iterating through slave indexs. Also you miss a lot of functionality
that may be useful MTU for example that is not available configured via

One of the sticking points in earlier discussions was how to handle
devices that have limited support for slave devices. When we create a
netdev we expect the stack can bind to it and TX/RX packets which as
I understand is not always possible? (I missed why we couldn't recv the
packets over a switch port though with some skb->dev manipulation). In
this case a feature flag could be used to resolve the feature


John Fastabend         Intel Corporation
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists