Linux USB
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Yury Norov <yury.norov@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Raju Rangoju <Raju.Rangoju@amd.com>,
	Prashanth Kumar K R <PrashanthKumar.K.R@amd.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	Jian Shen <shenjian15@huawei.com>,
	Jijie Shao <shaojijie@huawei.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	intel-wired-lan@lists.osuosl.org, linux-usb@vger.kernel.org,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 7/9] net: phy: use linkmode operation return values in phy_device.c
Date: Wed, 9 Sep 2026 14:15:14 +0200	[thread overview]
Message-ID: <3fcc6c7e-a9c6-46c4-8393-1abe7d12dea6@lunn.ch> (raw)
In-Reply-To: <aqAnd1gpXne2lqCT@yury>

On Tue, Sep 08, 2026 at 11:19:19AM -0400, Yury Norov wrote:
> On Tue, Sep 08, 2026 at 03:52:09PM +0200, Andrew Lunn wrote:
> > > -	linkmode_and(sfp_support, port->supported, caps->link_modes);
> > > -	if (linkmode_empty(sfp_support)) {
> > > +	if (!linkmode_and(sfp_support, port->supported, caps->link_modes)) {
> > >  		dev_err(&phydev->mdio.dev, "incompatible SFP module inserted, no common linkmode\n");
> > 
> > From a readability perspective, i like linkmode_empty(). It is more
> > obvious than !linkmode_and().
> 
> OK, a function returning 2 values is not something obvious in C. What
> about this?
> 
>         
> 	sfp_supported = linkmode_and(sfp_support, port->supported, caps->link_modes);
>         if (!sfp_supported)
> 		dev_err(&phydev->mdio.dev, "incompatible SFP module inserted, no common linkmode\n");

Why not keep it as it is? If the link mode is empty, we know we have a
problem. 


> 
> > None of this code is in the hot path. So we should put readability
> > above performance. 
> > 
> > >  	/* Some PHYs may advertise, by default, not support EEE modes. So,
> > >  	 * we need to clean them. In addition remove all disabled EEE modes.
> > >  	 */
> > > -	linkmode_and(phydev->advertising_eee, phydev->supported_eee,
> > > -		     phydev->advertising_eee);
> > > -	linkmode_andnot(phydev->advertising_eee, phydev->advertising_eee,
> > > -			phydev->eee_disabled_modes);
> > > -
> > >  	/* There is no "enabled" flag. If PHY is advertising, assume it is
> > >  	 * kind of enabled.
> > >  	 */
> > > -	phydev->eee_cfg.eee_enabled = !linkmode_empty(phydev->advertising_eee);
> > > +	phydev->eee_cfg.eee_enabled =
> > > +		linkmode_and_andnot(phydev->advertising_eee,
> > > +				    phydev->advertising_eee,
> > > +				    phydev->supported_eee,
> > > +				    phydev->eee_disabled_modes);
> > 
> > So, which is more readable, the original or this?
> 
> The new version is more readable to me. What about this:
>         
>         eee_advertised = linkmode_and_andnot(phydev->advertising_eee,
> 	                                     phydev->advertising_eee,
>                                              phydev->supported_eee,
> 		                             phydev->eee_disabled_modes);

I still prefer the original version.

Where do you stop with these functions? Why not add
linkmode_and_andnot_or()?  linkmode_and_nand_xor_nor()?

If complex expressions were used on the fast path, every packet
needing some bitmap logic, i can see the benefit of such complex
functions, if they can be optimised. But this is slow path, probe
time, or when the link goes up. Human readability comes first.

Just out of interest, did you look at the disassembly for both
versions? Isn't it the inline linkmode_ wrapper function which drops
the return value, which you are adding back. But the
compiler/optimizer sees it and could make use of it? Is gcc/clang
clever enough to do that?

	Andrew

  reply	other threads:[~2026-09-09 12:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-07 21:54 [PATCH 0/9] linkmode: better use bitmap API Yury Norov
2026-09-07 21:54 ` [PATCH 1/9] bitmap: add bitmap_and_and() and bitmap_and_andnot() Yury Norov
2026-09-07 21:54 ` [PATCH 2/9] linkmode: make linkmode_and() return boolean Yury Norov
2026-09-08 13:04   ` Loktionov, Aleksandr
2026-09-07 21:54 ` [PATCH 3/9] net: amd: xgbe: use linkmode_and() return value in xgbe_set_link_ksettings() Yury Norov
2026-09-08 13:04   ` Loktionov, Aleksandr
2026-09-07 21:54 ` [PATCH 4/9] ixgbe: use linkmode_and() return value in ixgbe_get_eee_fw() Yury Norov
2026-09-08  9:09   ` Temerkhanov, Sergey
2026-09-08 13:06   ` Loktionov, Aleksandr
2026-09-07 21:54 ` [PATCH 5/9] net: phy: use linkmode_and() return value in genphy_c45_eee_is_active() Yury Norov
2026-09-08 13:06   ` Loktionov, Aleksandr
2026-09-07 21:54 ` [PATCH 6/9] net: avoid copies before linkmode_and() Yury Norov
2026-09-08 13:07   ` Loktionov, Aleksandr
2026-09-09 11:06   ` Jijie Shao
2026-09-07 21:54 ` [PATCH 7/9] net: phy: use linkmode operation return values in phy_device.c Yury Norov
2026-09-08 13:07   ` Loktionov, Aleksandr
2026-09-08 13:52   ` Andrew Lunn
2026-09-08 15:19     ` Yury Norov
2026-09-09 12:15       ` Andrew Lunn [this message]
2026-09-09  8:09   ` Loktionov, Aleksandr
2026-09-07 21:54 ` [PATCH 8/9] r8152: use linkmode_and_and() in EEE checks Yury Norov
2026-09-08 13:12   ` Loktionov, Aleksandr
2026-09-07 21:54 ` [PATCH 9/9] MAINTAINERS: co-maintain linkmode.h under BITMAP Yury Norov
2026-09-08 20:44   ` Jakub Kicinski

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=3fcc6c7e-a9c6-46c4-8393-1abe7d12dea6@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=PrashanthKumar.K.R@amd.com \
    --cc=Raju.Rangoju@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linux@rasmusvillemoes.dk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=shaojijie@huawei.com \
    --cc=shenjian15@huawei.com \
    --cc=yury.norov@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox