All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Yuiko Oshino" <yuiko.oshino@microchip.com>
Cc: netdev@vger.kernel.org, kernel@pengutronix.de
Subject: Re: net: micrel: confusion about phyids used in driver
Date: Thu, 9 May 2019 22:55:29 +0200	[thread overview]
Message-ID: <da599967-c423-80dd-945d-5b993c041e90@gmail.com> (raw)
In-Reply-To: <20190509202929.wg3slwnrfhu4f6no@pengutronix.de>

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).

Obviously best would be get some input from Microchip.

> When enabling the micrel driver it successfully binds and claims to have
> detected a "Micrel KSZ8031" because phyid & 0x00ffffff ==
> PHY_ID_KSZ8031 (with PHY_ID_KSZ8031 = 0x00221556). I found a datasheet
> for KSZ8021RNL and KSZ8031RNL in our collection, there the phyid is
> documented as 0x0022155x, too. (So there is a deviation between driver
> and data sheet.)
> 
> A difference between these two parts are register bits 0x16.9 and
> 0x1f.7. (I didn't check systematically and there are definitely more
> differences, for example 0x16.7 which isn't handled at all in the
> driver.)
> 
> The driver does the right thing with KSZ8051MLL for bit 0x16.9 (which is
> setting a reserved bit on KSZ8021RNL/KSZ8031RNL) and for 0x1f.7 it's the
> other way round.
> 
> To make the situation still more interesting there is another phy entry
> "Micrel KSZ8051" that has .phy_id = 0x00221550 and .phy_id_mask =
> 0x00fffff0, which just judging from the name would be the better match.
> (This isn't used however because even though it matches "Micrel KSZ8031"
> is listed before and so is preferred.) With this the handling of the
> register bit 0x16.9 isn't right for the KSZ8051MLL. (I think it would if
> ksz8051_type had .has_broadcast_disable = true.)
> 
> I'm unclear what the right approach is to fix this muddle, maybe someone
> with more insight in the driver and maybe also in possession of more
> data sheets and hardware can tell?
> 
> My impression is that it is not possible to determine all features by
> just using the phyid. Would it be sensible to not difference between
> KSZ8031 and KSZ8051 and assume that writing to a reserved register bit
> does nothing?
> 
> Best regards
> Uwe
> 
Heiner


  reply	other threads:[~2019-05-09 20:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-09 20:29 net: micrel: confusion about phyids used in driver Uwe Kleine-König
2019-05-09 20:55 ` Heiner Kallweit [this message]
2019-05-09 21:07   ` Andrew Lunn
2019-05-10  7:22     ` Uwe Kleine-König
2019-07-02 20:31       ` Uwe Kleine-König
2019-07-02 20:55         ` Yuiko.Oshino
2019-08-08  8:36           ` Uwe Kleine-König
2019-08-20 20:25             ` Uwe Kleine-König
2019-08-20 20:30               ` Heiner Kallweit
2019-08-21 17:24               ` Florian Fainelli
2019-08-21 18:49                 ` allan.nielsen
2019-08-21 19:53                   ` Woojung.Huh
2019-10-16  9:09                     ` Uwe Kleine-König
2019-10-16 11:45                       ` Yuiko.Oshino
2019-05-11 14:00     ` Heiner Kallweit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=da599967-c423-80dd-945d-5b993c041e90@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=f.fainelli@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=yuiko.oshino@microchip.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.