All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Majewski <lukma@denx.de>
To: Vladimir Oltean <olteanv@gmail.com>, Tristram.Ha@microchip.com
Cc: f.fainelli@gmail.com, andrew@lunn.ch, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, Woojung.Huh@microchip.com,
	pabeni@redhat.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, UNGLinuxDriver@microchip.com
Subject: Re: [PATCH 2/2] net: dsa: microchip: Provide Module 4 KSZ9477 errata (DS80000754C)
Date: Tue, 29 Aug 2023 10:35:33 +0200	[thread overview]
Message-ID: <20230829103533.7966f332@wsk> (raw)
In-Reply-To: <20230826104910.voaw3ndvs52yoy2v@skbuf>

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

Hi Vladimir,

> On Fri, Aug 25, 2023 at 06:48:41PM +0000, Tristram.Ha@microchip.com
> wrote:
> > > > IMHO adding functions to MMD modification would facilitate
> > > > further development (for example LED setup).  
> > > 
> > > We already have some KSZ9477 specific initialization done in the
> > > Micrel PHY driver under drivers/net/phy/micrel.c, can we converge
> > > on the PHY driver which has a reasonable amount of infrastructure
> > > for dealing with workarounds, indirect or direct MMD accesses
> > > etc.?  
> > 
> > Actually the internal PHY used in the KSZ9897/KSZ9477/KSZ9893
> > switches are special and only used inside those switches.  Putting
> > all the switch related code in Micrel PHY driver does not really
> > help.  When the switch is reset all those PHY registers need to be
> > set again, but the PHY driver only executes those code during PHY
> > initialization.  I do not know if there is a good way to tell the
> > PHY to re-initialize again.  
> 
> Suppose there was a method to tell the PHY driver to re-initialize
> itself. What would be the key points in which the DSA switch driver
> would need to trigger that method? Where is the switch reset at
> runtime?

Tristam has explained why adding the internal switch PHY errata to
generic PHY code is not optimal.

If adding MMD generic code is a problem - then I'm fine with just
clearing proper bits with just two indirect writes in the
drivers/net/dsa/microchip/ksz9477.c

I would also prefer to keep the separate ksz9477_errata() function, so
we could add other errata code there.

Just informative - without this patch the KSZ9477-EVB board's network
is useless when the other peer has EEE enabled by default (like almost
all non managed ETH switches).



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2023-08-29  8:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-24 15:48 [PATCH 1/2] net: dsa: microchip: KSZ9477: Provide functions to access MMD registers Lukasz Majewski
2023-08-24 15:48 ` [PATCH 2/2] net: dsa: microchip: Provide Module 4 KSZ9477 errata (DS80000754C) Lukasz Majewski
2023-08-24 15:54   ` Florian Fainelli
2023-08-25  7:42     ` Lukasz Majewski
2023-08-25  1:12   ` Tristram.Ha
2023-08-25  8:39     ` Lukasz Majewski
2023-08-25 15:26       ` Florian Fainelli
2023-08-25 18:48         ` Tristram.Ha
2023-08-26 10:49           ` Vladimir Oltean
2023-08-29  8:35             ` Lukasz Majewski [this message]
2023-08-29 10:18               ` Vladimir Oltean
2023-08-29 11:24                 ` Lukasz Majewski
2023-08-29 11:47                   ` Oleksij Rempel
2023-08-29 12:38                     ` Lukasz Majewski
2023-08-29 14:42                       ` Oleksij Rempel
2023-08-29 15:29                         ` Lukasz Majewski
2023-08-29 17:12                           ` Oleksij Rempel
2023-08-29 22:23                             ` Tristram.Ha
2023-08-30  6:16                               ` Oleksij Rempel
2023-08-30  8:13                                 ` Lukasz Majewski
2023-08-29 21:57             ` Tristram.Ha
2023-08-29 22:00               ` Florian Fainelli

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=20230829103533.7966f332@wsk \
    --to=lukma@denx.de \
    --cc=Tristram.Ha@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=Woojung.Huh@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.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.