netdev - Re: [PATCH net-next] net: phy: let genphy_c45_read

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

Message-ID: <974f6bca-c938-aac9-28b4-291cca0734db@gmail.com>
Date:   Thu, 7 Feb 2019 22:54:51 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>,
        Russell King <linux@...linux.org.uk>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] net: phy: let genphy_c45_read_link manage the
 devices to check

On 07.02.2019 21:50, Andrew Lunn wrote:
>> Thanks, Andrew. Right, the Aquantia PHY doesn't seem to have the C22EXT
>> MMD. Because the Aquantia PHY has no device 29 in its package the code
>> should work.
> 
> It lists device 29 in its devices in package. So the current code does
> look there.
> 
I just looked for a description of a device 29. Strange that the device
list states it's there and then it's not there.

When checking that I was scratching my head because of the following code
in genphy_c45_read_link:

devad = __ffs(mmd_mask);
mmd_mask &= ~BIT(devad);

AFAIK __ffs() returns the posix bit number, means it returns 1 for bit 0.
Then this code piece seems to be wrong because I think the intention is
to clear the bit we just found. Instead we clear the next bit.

And device 0 isn't really a device but a flag "Clause 22 registers present".
So far we may have been lucky because to supported 10G PHY has this flag set.
But if this flag is set and we try to access a register 0.1 then we may be
in trouble again. Therefore I think we need to exclude also device 0.
Or do I miss something?

>> So it seems we have to exclude device C22EXT in general. I'll add that
>> and submit a v2.
> 
> Yes.
> 
> 	Andrew
> 
Heiner