All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Mack <daniel@zonque.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: vivien.didelot@gmail.com, f.fainelli@gmail.com,
	davem@davemloft.net, netdev@vger.kernel.org
Subject: Re: [PATCH] net: dsa: mv88e6xxx: don't force settings on CPU port
Date: Fri, 27 Mar 2020 21:48:56 +0100	[thread overview]
Message-ID: <d101df30-5a9e-eac1-94b0-f171dbcd5b88@zonque.org> (raw)
In-Reply-To: <20200327200153.GR3819@lunn.ch>

Hi Andrew,

On 27/3/2020 9:01 pm, Andrew Lunn wrote:
> On Fri, Mar 27, 2020 at 08:51:56PM +0100, Daniel Mack wrote:
>> On hardware with a speed-reduced link to the CPU port, forcing the MAC
>> settings won't allow any packets to pass. The PHY will negotiate the
>> maximum possible speed, so let's allow the MAC to work with whatever
>> is available.
> 
> This will break board which rely on the CPU being forced to the
> maximum speed, which has been the default since forever.

Will it? Wouldn't the PHY negotiate the maximum speed, and the MAC would
follow?

> It sounds like you have the unusual situation of back to back PHYs?
> And i assume the SoC PHY is limited to Fast Ethernet?

Yes, exactly.

> What i think you can do is have a phy-handle in the cpu node which
> points to the PHY. That should then cause the PHY to be driven as a
> normal PHY, and the result of auto neg passed to the MAC.

Yes, this is what I have. The maximum speed the is negotiable on that
link is 100M, and the PHYs see each other just fine (according to the
status registers of the external PHY). The problem is that the MAC
inside the switch is forced to 1G, which doesn't match what the PHY
negotiated.

Not sure what else can be done to make such setups work instead of
lifting that particular constraint on the MAC side. Could you explain
why the settings are forced at all?


Thanks,
Daniel

  reply	other threads:[~2020-03-27 20:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-27 19:51 [PATCH] net: dsa: mv88e6xxx: don't force settings on CPU port Daniel Mack
2020-03-27 20:01 ` Andrew Lunn
2020-03-27 20:48   ` Daniel Mack [this message]
2020-03-27 21:18     ` Andrew Lunn
2020-03-27 21:26       ` Daniel Mack
2020-03-27 23:52         ` Andrew Lunn
2020-03-30  9:29           ` Daniel Mack
2020-03-30 13:40             ` Andrew Lunn
2020-03-30 18:04               ` Daniel Mack
2020-03-30 18:23                 ` Andrew Lunn
2020-03-30 18:37                   ` Daniel Mack
2020-03-30 18:45                     ` Andrew Lunn
2020-06-22 18:43               ` Daniel Mack

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=d101df30-5a9e-eac1-94b0-f171dbcd5b88@zonque.org \
    --to=daniel@zonque.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@gmail.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.