lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YqmVdj4X5101PC1u@shell.armlinux.org.uk>
Date:   Wed, 15 Jun 2022 09:16:54 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Marek BehĂșn <kabel@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org,
        Paolo Abeni <pabeni@...hat.com>,
        Robert Hancock <robert.hancock@...ian.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Vladimir Oltean <olteanv@...il.com>
Subject: Re: [PATCH net-next 02/15] net: phylink: add phylink_pcs_inband()

On Tue, Jun 14, 2022 at 10:46:52PM -0700, Jakub Kicinski wrote:
> On Mon, 13 Jun 2022 14:00:31 +0100 Russell King (Oracle) wrote:
> > +	if (phylink_autoneg_inband(mode) &&
> > +	    (interface == PHY_INTERFACE_MODE_SGMII ||
> > +	     interface == PHY_INTERFACE_MODE_QSGMII ||
> > +	     linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, advertising)))
> > +		return true;
> > +	else
> > +		return false;
> 
> Okay, let me be a little annoying...

No, not annoying!

> Could you run thru checkpatch --strict and fix the few whitespace
> issues it points out? There's a handful of spaces instead of tabs,
> unaligned continuation lines and an unnecessary bracket.

That somewhat surprises me... will fix most of the strict errors,
except this one:

WARNING: function definition argument 'struct mv88e639x_pcs *' should also have
an identifier name
#337: FILE: drivers/net/dsa/mv88e6xxx/pcs-639x.c:93:
+       irqreturn_t (*handler)(struct mv88e639x_pcs *);

because its utterly pointless. What extra information would adding "pcs"
give to the reader? I can Understand it for standard C types because they
are opaque, but not for this.

> Patch 1 does not need to be backported so I presume it can lose the
> fixes tag?

As the commit talks about fixing something, in my experience the commit
will get automatically selected for backporting to stable trees whether
or not it has a fixes tag on it. The only way to stop that happening is
not through avoiding a fixes tag, but to keep on top of the stable tree
emails to stop patches being backported that don't need to be.

If you still want me to remove it, I will, but I predict it will still
be backported.

> The quoted code can be converted into a direct return of the condition,
> I don't really care but I think there are bots out there which will
> send a "fix" soon if we commit this.
> 
> And patch 10 generates a transient "function should be static" warning.
> I think you need a __maybe_unused on mv88e6xxx_pcs_select() as well.

Gah, I did build-test each patch individually, but I guess because of
the time it takes to do so I must have not looked at the results
properly - will fix.

Thanks!

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ