The 08/21/2019 10:24, Florian Fainelli wrote: > +Allan, > > On 8/20/19 1:25 PM, 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, ... } > > > > 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? > > Allan, is this something you could help with? Thanks! Sorry, I'm new in Microchip (was aquired through Microsemi), and I know next to nothing about the Micrel stuff.
Woojung: Can you comment on this, or try to direct this to someone who knows something... > >>>>>>> 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 > > > > > -- > Florian -- /Allan
