linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Jiawen Wu <jiawenwu@trustnetic.com>,
	Jose Abreu <joabreu@synopsys.com>,
	Jose Abreu <Jose.Abreu@synopsys.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Mengyuan Lou <mengyuanlou@net-swift.com>,
	netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>
Subject: Re: [PATCH RFC net-next 06/10] net: dsa: sja1105: simplify static configuration reload
Date: Thu, 26 Sep 2024 13:02:35 +0100	[thread overview]
Message-ID: <ZvVNWxIRhKyNLM/J@shell.armlinux.org.uk> (raw)
In-Reply-To: <20240925211613.lmi2kh6hublkutbb@skbuf>

On Thu, Sep 26, 2024 at 12:16:13AM +0300, Vladimir Oltean wrote:
> On Wed, Sep 25, 2024 at 08:38:23PM +0100, Russell King (Oracle) wrote:
> > > There are 2 more changes which I believe should be made in sja1105_set_port_speed():
> > > - since it isn't called from mac_config() anymore but from mac_link_up()
> > >   (change which happened quite a while ago), it mustn't handle SPEED_UNKNOWN
> > > - we can trust that phylink will not call mac_link_up() with a speed
> > >   outside what we provided in mac_capabilities, so we can remove the
> > >   -EINVAL "default" speed_mbps case, and make this method return void,
> > >   as it can never truly cause an error
> > > 
> > > But I believe these are incremental changes which should be done after
> > > this patch. I've made a note of them and will create 2 patches on top
> > > when I have the spare time.
> > 
> > ... if we were to make those changes prior to this patch, then the
> > dev_err() will no longer be there and thus this becomes a non-issue.
> > So I'd suggest a patch prior to this one to make the changes you state
> > here, thus eliminating the need for this hunk in this patch.
> 
> That sounds good. Are you suggesting you will write up such a patch for v2?

Actually, the three patches become interdependent.

Let's say we want to eliminate SPEED_UNKNOWN. Prior to my patch in this
sub-thread, we have this:

                speed_mbps[i] = sja1105_port_speed_to_ethtool(priv,
                                                              mac[i].speed);
...
                rc = sja1105_adjust_port_config(priv, i, speed_mbps[i]);

sja1105_port_speed_to_ethtool() can return SPEED_UNKNOWN if
mac[i].speed is not one of the four encodings. If we can't guarantee
that it is one of the four encodings, then SPEED_UNKNOWN may be
passed into sja1105_adjust_port_config().

Similarly, as for the default case, we can't simply delete that,
because that'll leave "speed" uninitialised and we'll get a build
warning without my changes. We could change the default case to
simply:

	default:
		return 0;

but that just looks perverse.

So, I think rather than trying to do your suggestion before my patch,
my patch needs to stand as it currently is, and then your suggestion
must happen after it - otherwise we end up introducing more complexity
or weirdness.

Hmm?

-- 
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:[~2024-09-26 12:04 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-23 14:00 [PATCH RFC 00/10] net: pcs: xpcs: cleanups batch 1 Russell King (Oracle)
2024-09-23 14:00 ` [PATCH RFC net-next 01/10] net: pcs: xpcs: move PCS reset to .pcs_pre_config() Russell King (Oracle)
2024-09-25 12:44   ` Vladimir Oltean
2024-09-29 22:16   ` Serge Semin
2024-09-30 10:14     ` Russell King (Oracle)
2024-10-01 20:20       ` Serge Semin
2024-09-23 14:01 ` [PATCH RFC net-next 02/10] net: pcs: xpcs: drop interface argument from internal functions Russell King (Oracle)
2024-09-25 12:47   ` Vladimir Oltean
2024-09-23 14:01 ` [PATCH RFC net-next 03/10] net: pcs: xpcs: get rid of xpcs_init_iface() Russell King (Oracle)
2024-09-25 12:48   ` Vladimir Oltean
2024-09-23 14:01 ` [PATCH RFC net-next 04/10] net: pcs: xpcs: add xpcs_destroy_pcs() and xpcs_create_pcs_mdiodev() Russell King (Oracle)
2024-09-25 12:50   ` Vladimir Oltean
2024-09-23 14:01 ` [PATCH RFC net-next 05/10] net: wangxun: txgbe: use phylink_pcs internally Russell King (Oracle)
2024-09-23 14:01 ` [PATCH RFC net-next 06/10] net: dsa: sja1105: simplify static configuration reload Russell King (Oracle)
2024-09-25 13:15   ` Vladimir Oltean
2024-09-25 19:38     ` Russell King (Oracle)
2024-09-25 21:16       ` Vladimir Oltean
2024-09-26 12:02         ` Russell King (Oracle) [this message]
2024-09-26 14:06           ` Vladimir Oltean
2024-09-23 14:01 ` [PATCH RFC net-next 07/10] net: dsa: sja1105: call PCS config/link_up via pcs_ops structure Russell King (Oracle)
2024-09-25 13:30   ` Vladimir Oltean
2024-09-23 14:01 ` [PATCH RFC net-next 08/10] net: dsa: sja1105: use phylink_pcs internally Russell King (Oracle)
2024-09-25 13:34   ` Vladimir Oltean
2024-09-23 14:01 ` [PATCH RFC net-next 09/10] net: pcs: xpcs: drop interface argument from xpcs_create*() Russell King (Oracle)
2024-09-25 13:36   ` Vladimir Oltean
2024-09-23 14:01 ` [PATCH RFC net-next 10/10] net: pcs: xpcs: make xpcs_do_config() and xpcs_link_up() internal Russell King (Oracle)
2024-09-25 13:38   ` Vladimir Oltean
2024-09-23 15:02 ` [PATCH RFC 00/10] net: pcs: xpcs: cleanups batch 1 Maxime Chevallier
2024-09-25 13:43 ` Vladimir Oltean
2024-09-26 11:41   ` Russell King (Oracle)
2024-09-26 13:49     ` 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=ZvVNWxIRhKyNLM/J@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=Jose.Abreu@synopsys.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=jiawenwu@trustnetic.com \
    --cc=joabreu@synopsys.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=mengyuanlou@net-swift.com \
    --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 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).