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 +, 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 = 0x00ff, ... },
> > { .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
