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

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

Message-ID: <20190527083215.GB2594@t480s.localdomain>
Date:   Mon, 27 May 2019 08:32:15 -0400
From:   Vivien Didelot <vivien.didelot@...il.com>
To:     Rasmus Villemoes <rasmus.villemoes@...vas.dk>
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

Hi Rasmus,

On Mon, 27 May 2019 09:36:13 +0000, Rasmus Villemoes <rasmus.villemoes@...vas.dk> wrote:
> Looking through the data sheets comparing the mv88e6240 and 6250, I
> noticed that they have the exact same description of the G1_IEEE_PRI
> register (global1, offset 0x18). However, the current code used by 6240 does
> 
> int mv88e6085_g1_ieee_pri_map(struct mv88e6xxx_chip *chip)
> {
> 	/* Reset the IEEE Tag priorities to defaults */
> 	return mv88e6xxx_g1_write(chip, MV88E6XXX_G1_IEEE_PRI, 0xfa41);
> }
> 
> while if my reading of the data sheet is correct, the reset value is
> really 0xfa50 (fields 7:6 and 5:4 are RWS to 0x1, field 3:2 and 1:0 are
> RWR) - and this is also the value I read from the 6250 on our old BSP
> with an out-of-tree driver that doesn't touch that register. This seems
> to go way back (at least 3b1588593097). Should this be left alone for
> not risking breaking existing setups (just updating the comment), or can
> we make the code match the comment? Or am I just reading this all wrong?

If the reset value isn't the same, the bits are certainly differently
organized inside this register, so the proper way would be to add a
mv88e6240_g1_ieee_pri_map function, used by both 88E6240 and 88E6250.

I'm not a big fan of rewriting the default values, but that is the
way we chose until we make actually use of these tag priority bits.


Thanks,
Vivien