Hi Andrew,
Andrew Lunn <and...@lunn.ch> writes:
> [Reducing the Cc: list a bit to networking people]
>
>> Okay. Frames sent from the port are EDSA-tagged (which isn't exactly
>> surprising), but I'm yet to see the switch receive 0xdada frames.
>> Even with the net-next branch which uses DSA_TAG_PROTO_EDSA for all
>> chip types.
>>
>> However, the ethertype is reflecting the port:-
>>
>> lan1/5 : ethertype Unknown (0xc028), length 176:
>> lan2/7 : ethertype Unknown (0xc038), length 176:
>> lan3/0 : ethertype Unknown (0xc000), length 176:
>> lan4/1 : ethertype Unknown (0xc008), length 176:
>> wan/2 : ethertype Unknown (0xc010), length 176:
>
> O.K, we broke it :-(
>
> The 6185 does not support EDSA, only DSA.
I'm wondering if EDSA could be simulated on 6185 (only) with the
CoreTagType register (0x19) and DoubleTag bit in Port Control (0x04)...
> Or we do something more radical, like add a driver callback to return
> the tagging protocol, rather than hard code it in the structure? We
> can then use a capability flag.
The driver callback is the way to go. The supported tag format is
identifiable via the register layout. 6352 and newer have a 2-bit
FrameMode in Port Control (0x04), while 6185 has a single DSA_Tag bit.
A new switch operation can return the tag protocol enum, or an exposed
xmit/recv pair from net/dsa/tag_*.c, which must be used by the CPU.
Note: 88E6060 (which is likely to be supported by mv88e6xxx) has the
same issue and requires this, since it uses the Trailer tagging format.
Thanks,
Vivien
