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.osh...@microchip.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 >
