netdev - Re: reset value of MV88E6XXX_G1_IEEE

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] [day] [month] [year] [list]

Message-ID: <3a016cd4-ee15-7365-347e-69dfc20c04de@prevas.dk>
Date:   Mon, 3 Jun 2019 11:14:39 +0000
From:   Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To:     Vivien Didelot <vivien.didelot@...il.com>
CC:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: reset value of MV88E6XXX_G1_IEEE_PRI

On 27/05/2019 16.20, Vivien Didelot wrote:
> Hi Rasmus,
> 
>>
>> Based on the very systematic description [ieee tags 7 and 6 are mapped
>> to 3, 5 and 4 to 2, 3 and 2 to 1, and 1 and 0 to 0], I strongly believe
>> that 0xfa50 is also the reset value for the 6085, so this is most likely
>> wrong for all the current chips - though I don't have a 6085 data sheet.
>>
>> I can certainly add a 6250 variant that does the right thing for the
>> 6250, and I probably will - this is more a question about the current code.
> 
> Good catch, I double checked 88E6085 and 88E6352 and both describe
> a reset value of 0xFA50. Fixing mv88e6085_g1_ieee_pri_map should
> be enough.

Urgh, yes, but now that I got access to other data sheets I also checked
88e6095, and that actually does describe a reset value of 0xfa41. So
that value is not taken out of thin air, though it does not apply to the
chip variant that the current mv88e6085_g1_ieee_pri_map helper is named
after :(

So I think I'll add a mv88e6250_g1_ieee_pri_map for the chip I'm working
on, then other chips that have 0xfa50 as the reset value can be switched
over to use that one by one, double-checking the data sheet (and ideally
also the actual hardware...) for each one.

Rasmus