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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2cadf598-1c5d-2d22-e7d3-5aed75a57917@gmail.com>
Date:   Tue, 20 Aug 2019 22:30:03 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>
Cc:     netdev@...r.kernel.org, andrew@...n.ch, f.fainelli@...il.com,
        kernel@...gutronix.de, Ravi.Hegde@...rochip.com,
        Tristram.Ha@...rochip.com, Yuiko.Oshino@...rochip.com
Subject: Re: net: micrel: confusion about phyids used in driver

On 20.08.2019 22:25, Uwe Kleine-König wrote:
> Hello Nicolas,
> 
> there are some open questions regarding details about some PHYs
> supported in the drivers/net/phy/micrel.c driver.
> 
> On Thu, Aug 08, 2019 at 10:36:37AM +0200, Uwe Kleine-König wrote:
>> On Tue, Jul 02, 2019 at 08:55:07PM +0000, Yuiko.Oshino@...rochip.com wrote:
>>>> On Fri, May 10, 2019 at 09:22:43AM +0200, Uwe Kleine-König wrote:
>>>>> On Thu, May 09, 2019 at 11:07:45PM +0200, Andrew Lunn wrote:
>>>>>> On Thu, May 09, 2019 at 10:55:29PM +0200, Heiner Kallweit wrote:
>>>>>>> On 09.05.2019 22:29, Uwe Kleine-König wrote:
>>>>>>>> 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.
> 
> The short version is that a phy with ID 0x00221556 matches two
> phy_driver entries in the driver:
> 
> 	{ .phy_id = PHY_ID_KSZ8031, .phy_id_mask = 0x00ffffff, ... },
> 	{ .phy_id = PHY_ID_KSZ8051, .phy_id_mask = MICREL_PHY_ID_MASK, ... }
> 

If two PHYs have same ID but need different drivers, then callback
match_phy_device may have to be implemented, provided that the PHYs
can be differentiated by some other register content.
See Realtek PHY driver for an example.

> The driver doesn't behave optimal for "my" KSZ8051MLL with both entries
> ... It seems to work, but not all features of the phy are used and the
> bootlog claims this was a KSZ8031 because that's the first match in the
> list.
> 
> So we're in need of someone who can get their hands on some more
> detailed documentation than publicly available to allow to make the
> driver handle the KSZ8051MLL correctly without breaking other stuff.
> 
> I assume you are in a different department of Microchip than the people
> caring for PHYs, but maybe you can still help finding someone who cares?
> 
>>>>>>> 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.
>>>>>
>>>>> From the vendor's POV it is even sensible to reuse the phy IDs iff the
>>>>> chips are "compatible".
>>>>>
>>>>> Assuming that the last nibble of the phy ID actually helps to
>>>>> distinguish the different (not completely) compatible chips, we need
>>>>> some more detailed information than available in the data sheets I have.
>>>>> There is one person in the recipents of this mail with an
>>>>> @microchip.com address (hint, hint!).
>>>>
>>>> can you give some input here or forward to a person who can?
>>>
>>> I forward this to the team.
>>
>> This thread still sits in my inbox waiting for some feedback. Did
>> something happen on your side?
> 
> This is still true, didn't hear back from Yuiko Oshino for some time
> now.
> 
> Best regards
> Uwe
>