Re: [PATCH 1/1] add ethtool loopback support

[Jeff Garzik <jeff@garzik.org>]

On 04/08/2010 06:43 PM, Laurent Chavey wrote:
> On Thu, Apr 8, 2010 at 12:35 PM, Ben Hutchings
> <bhutchings@solarflare.com>  wrote:
>> On Thu, 2010-04-08 at 12:17 -0700, Laurent Chavey wrote:
>>> On Thu, Apr 8, 2010 at 11:29 AM, Ben Hutchings
>>> <bhutchings@solarflare.com>  wrote:
>>>> On Thu, 2010-04-08 at 10:35 -0700, chavey@google.com wrote:
>> [...]
>>>>> +enum ethtool_loopback_type {
>>>>> +     ETH_MAC                 = 0x00000001,
>>>>> +     ETH_PHY_INT             = 0x00000002,
>>>>> +     ETH_PHY_EXT             = 0x00000004
>>>>> +};
>>>> [...]
>>>>
>>>> There are many different places you can loop back within a MAC or PHY,
>>>> not to mention bypassing the MAC altogether.  See
>>>> drivers/net/sfc/mcdi_pcol.h, starting from the line
>>>> '#define MC_CMD_LOOPBACK_NONE 0'.  I believe we implement all of those
>>>> loopback modes on at least one board.
>>>>
>>>> Also are these supposed to be an enumeration or flags?  In theory you
>>> those are enums that can be or together.
>>
>> I.e. they are flags.  So how do you answer this:
>>
>>>> could use wire-side and host-side loopback at the same time if they
>>>> don't overlap, but it's probably too much trouble to bother with.  Any
>>>> other combination is meaningless.
> since the intent is to enable the sending and receiving of packets at
> the hw/driver interfaces, a simple loopback mode on/off is sufficient
> and the ethtool_loopback_type are not necessary. the implementor can choose
> how to implement the loopback. From drivers/net/sfc/mcdi_pcol.h it is clear
> that unless ethtool_loopback_type as defined are meaningless.

If an off/on switch is sufficient, the existing ethtool flags interface 
should work just fine.

	Jeff