All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Oleksij Rempel <o.rempel@pengutronix.de>,
	Andrew Lunn <andrew@lunn.ch>,
	Woojung Huh <woojung.huh@microchip.com>,
	Arun Ramadoss <arun.ramadoss@microchip.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	netdev@vger.kernel.org, UNGLinuxDriver@microchip.com,
	Eric Dumazet <edumazet@google.com>,
	kernel@pengutronix.de, Jakub Kicinski <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: FWD: Re: [PATCH net-next v1 1/1] net: dsa: microchip: ksz8: Make flow control, speed, and duplex on CPU port configurable
Date: Tue, 11 Apr 2023 14:33:00 +0100	[thread overview]
Message-ID: <ZDVhjJgEUz7XCdBC@shell.armlinux.org.uk> (raw)
In-Reply-To: <20230411132617.nonvvtll7xxvadhr@skbuf>

On Tue, Apr 11, 2023 at 04:26:17PM +0300, Vladimir Oltean wrote:
> On Tue, Apr 11, 2023 at 01:00:43PM +0100, Russell King (Oracle) wrote:
> > 	ethtool --pause ... autoneg on
> > 	ethtool --pause ... autoneg off rx off tx off
> > 	ethtool --pause ... autoneg off rx on tx on
> > 
> > Anything else wouldn't give the result the user wants, because there's
> > no way to independently force rx and tx flow control per port.
> 
> Right.
> 
> > That said, phylink doesn't give enough information to make the above
> > possible since the force bit depends on (tx && rx &&!permit_pause_to_mac)
> 
> So, since the "permit_pause_to_mac" information is missing here, I guess
> the next logical step based on what you're saying is that it's a matter
> of not using the pcs_config() API, or am I misunderstanding again? :)

pcs_config() doesn't get the "tx" and "rx" above. mac_link_up() does,
but doesn't get the "permit_pause_to_mac" (since that's supposed to
be a "configuration" thing.)

Anyway, I think this is now moot since I think we've agreed on a way
forward for this hardware.

> > So, because this hardware is that crazy, I suggest that it *doesn't*
> > even attempt to support ethtool --pause, and either is programmed
> > at setup time to use autonegotiated pause (with the negotiation state
> > programmed via ethtool -s) or it's programmed to have pause globally
> > disabled. Essentially, I'm saying the hardware is too broken in its
> > design to be worth bothering trying to work around its weirdness.
> 
> Ok. How can this driver reject changes made through ethtool --pause?

We would need either something in DSA (dsa_slave_set_pauseparam()) to
prevent success, or something in phylink_ethtool_set_pauseparam() to
do the same.

At the phylink level, that could be a boolean in struct phylink_config.
Something like "disable_ethtool_set_pauseparam" (I'd prefer something
a tad shorter) which if set would make phylink_ethtool_set_pauseparam()
return -EOPNOTSUPP.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2023-04-11 13:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7055f8c2-3dba-49cd-b639-b4b507bc1249@lunn.ch>
2023-04-07 17:44 ` FWD: Re: [PATCH net-next v1 1/1] net: dsa: microchip: ksz8: Make flow control, speed, and duplex on CPU port configurable Russell King (Oracle)
2023-04-11  8:56   ` Oleksij Rempel
2023-04-11  9:17     ` Russell King (Oracle)
2023-04-11  9:55       ` Oleksij Rempel
2023-04-11 11:16       ` Vladimir Oltean
2023-04-11 11:35         ` Vladimir Oltean
2023-04-11 12:00           ` Russell King (Oracle)
2023-04-11 12:16             ` Andrew Lunn
2023-04-11 13:26             ` Vladimir Oltean
2023-04-11 13:33               ` Russell King (Oracle) [this message]
2023-04-11 14:28                 ` Vladimir Oltean
2023-04-11 11:50         ` Russell King (Oracle)
2023-04-11 13:12           ` Vladimir Oltean
2023-04-11 13:26             ` Russell King (Oracle)
2023-04-11 14:33   ` Vladimir Oltean

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=ZDVhjJgEUz7XCdBC@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=arun.ramadoss@microchip.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=woojung.huh@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.