netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Marek Behún" <kabel@kernel.org>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	netdev@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
	"David S . Miller" <davem@davemloft.net>,
	Florian Fainelli <f.fainelli@gmail.com>,
	kuba@kernel.org
Subject: Re: [PATCH net-next v2 11/12] net: phy: marvell10g: print exact model
Date: Thu, 25 Mar 2021 21:54:14 +0100	[thread overview]
Message-ID: <20210325215414.23fffe6c@thinkpad> (raw)
In-Reply-To: <418e86fb-dd7b-acbb-e648-1641f06b254b@gmail.com>

On Thu, 25 Mar 2021 21:44:21 +0100
Heiner Kallweit <hkallweit1@gmail.com> wrote:

> On 25.03.2021 21:29, Marek Behún wrote:
> > On Thu, 25 Mar 2021 15:54:52 +0000
> > Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> >   
> >> The 88X3310 and 88X3340 can be differentiated by bit 3 in the revision.
> >> In other words, 88X3310 is 0x09a0..0x09a7, and 88X3340 is
> >> 0x09a8..0x09af. We could add a separate driver structure, which would
> >> then allow the kernel to print a more specific string via standard
> >> methods, like we do for other PHYs. Not sure whether that would work
> >> for the 88X21x0 family though.  
> > 
> > According to release notes it seems that we can also differentiate
> > 88E211X from 88E218X (via bit 3 in register 1.3):
> >  88E211X has 0x09B9
> >  88E218X has 0x09B1
> > 
> > but not 88E2110 from 88E2111
> >     nor 88E2180 from 88E2181.
> > 
> > These can be differentiated via register
> >   3.0004.7
> > (bit 7 of MDIO_MMD_PCS.MDIO_SPEED., which says whether device is capable
> >  of 5g speed)
> >   
> 
> If the PHY ID's are the same but you can use this register to
> differentiate the two versions, then you could implement the
> match_phy_device callback. This would allow you to have separate
> PHY drivers. This is just meant to say you have this option, I don't
> know the context good enough to state whether it's the better one.

Nice, didn't know about that. But I fear whether this would always work
for the 88X3310 vs 88X3310P, it is possible that this feature is only
recognizable if the firmware in the PHY is already running.

I shall look into this.

Marek

  reply	other threads:[~2021-03-25 20:55 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-25 13:12 [PATCH net-next v2 00/12] net: phy: marvell10g updates Marek Behún
2021-03-25 13:12 ` [PATCH net-next v2 01/12] net: phy: marvell10g: rename register Marek Behún
2021-03-25 13:12 ` [PATCH net-next v2 02/12] net: phy: marvell10g: fix typo Marek Behún
2021-03-25 13:12 ` [PATCH net-next v2 03/12] net: phy: marvell10g: allow 5gbase-r and usxgmii Marek Behún
2021-03-25 13:12 ` [PATCH net-next v2 04/12] net: phy: marvell10g: indicate 88X33X0 only port control registers Marek Behún
2021-03-25 13:12 ` [PATCH net-next v2 05/12] net: phy: marvell10g: add MACTYPE definitions for 88X33X0/88X33X0P Marek Behún
2021-03-25 13:12 ` [PATCH net-next v2 06/12] net: phy: marvell10g: add MACTYPE definitions for 88E21XX Marek Behún
2021-03-25 13:12 ` [PATCH net-next v2 07/12] net: phy: marvell10g: add code to determine number of ports Marek Behún
2021-03-25 13:12 ` [PATCH net-next v2 08/12] net: phy: marvell10g: support all rate matching modes Marek Behún
2021-03-25 13:12 ` [PATCH net-next v2 09/12] net: phy: marvell10g: support other MACTYPEs Marek Behún
2021-03-25 13:12 ` [PATCH net-next v2 10/12] net: phy: add constants for 2.5G and 5G speed in PCS speed register Marek Behún
2021-03-25 13:12 ` [PATCH net-next v2 11/12] net: phy: marvell10g: print exact model Marek Behún
2021-03-25 15:36   ` Marek Behún
2021-03-25 15:54   ` Russell King - ARM Linux admin
2021-03-25 16:56     ` Marek Behún
2021-03-25 20:29     ` Marek Behún
2021-03-25 20:44       ` Heiner Kallweit
2021-03-25 20:54         ` Marek Behún [this message]
2021-03-26  9:07           ` Russell King - ARM Linux admin
2021-03-26 11:11             ` Marek Behún
2021-03-25 13:12 ` [PATCH net-next v2 12/12] net: phy: marvell10g: better check for compatible interface Marek Behún

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=20210325215414.23fffe6c@thinkpad \
    --to=kabel@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).