netdev - Re: net: micrel: confusion about phyids used in driver

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: <20190509210745.GD11588@lunn.ch>
Date:   Thu, 9 May 2019 23:07:45 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        Florian Fainelli <f.fainelli@...il.com>,
        Yuiko Oshino <yuiko.oshino@...rochip.com>,
        netdev@...r.kernel.org, kernel@...gutronix.de
Subject: Re: net: micrel: confusion about phyids used in driver

On Thu, May 09, 2019 at 10:55:29PM +0200, Heiner Kallweit wrote:
> On 09.05.2019 22:29, Uwe Kleine-König wrote:
> > Hello,
> > 
> > I have a board here that has a KSZ8051MLL (datasheet:
> > http://ww1.microchip.com/downloads/en/DeviceDoc/ksz8051mll.pdf, phyid:
> > 0x0022155x) assembled. The actual phyid is 0x00221556.
> > 
> I think the datasheets are the source of the confusion. If the
> datasheets for different chips list 0x0022155x as PHYID each, and
> authors of support for additional chips don't check the existing code,
> then happens what happened.
> However it's not a rare exception and not Microchip-specific that
> sometimes vendors use the same PHYID for different chips.
> 
> And it seems you even missed one: KSZ8795
> It's a switch and the internal PHY's have id 0x00221550.
> 
> If the drivers for the respective chips are actually different then we
> may change the driver to match the exact model number only.
> However, if there should be a PHY with e.g. id 0x00221554 out there,
> it wouldn't be supported any longer and the generic PHY driver would
> be used (what may work or not).

Hi Heiner

We might also want to take a look at the code which matches a driver
to a PHY ID. Ideally we want the most specific match when looking at
the mask. We can then have device specific matches, and then a more
general fallback match using a wider mask.

No idea how to actually implement that :-(

   Andrew