netdev - Re: [PATCH v0 00/10] Convert Netgear WNR854T to devicetree

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 19 Jul 2016 11:04:44 -0400
From:	Vivien Didelot <vivien.didelot@...oirfairelinux.com>
To:	Andrew Lunn <andrew@...n.ch>, Jamie Lentin <jm@...tin.co.uk>
Cc:	Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH v0 00/10] Convert Netgear WNR854T to devicetree

Hi Andrew,

Andrew Lunn <andrew@...n.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