[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230602101058.7faf94bf@kernel.org>
Date: Fri, 2 Jun 2023 10:10:58 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Dan Carpenter
<dan.carpenter@...aro.org>, Oleksij Rempel <linux@...pel-privat.de>,
netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: phylib: fix phy_read*_poll_timeout()
On Fri, 2 Jun 2023 17:34:31 +0100 Russell King (Oracle) wrote:
> On Fri, Jun 02, 2023 at 05:17:59PM +0100, Russell King (Oracle) wrote:
> > On Fri, Jun 02, 2023 at 09:05:39AM -0700, Jakub Kicinski wrote:
> > > Wait, did the version I proposed not work?
> > >
> > > https://lore.kernel.org/all/20230530121910.05b9f837@kernel.org/
> >
> > If we're into the business of throwing web URLs at each other for
> > messages we've already read, here's my one for you which contains
> > the explanation why your one is broken, and proposing my solution.
> >
> > https://lore.kernel.org/all/ZHZmBBDSVMf1WQWI@shell.armlinux.org.uk/
> >
> > To see exactly why yours is broken, see the paragraph starting
> > "The elephant in the room..."
Ah, yes, sorry, I'll admit I didn't get what you mean by the elephant
paragraph when I read that.
> If you don't like my solution, then I suppose another possibility would
> be:
>
> #define __phy_poll_read(phydev, regnum, val) \
> ({ \
> int __err; \
> __err = phy_read(phydev, regnum); \
> if (__err >= 0) \
> val = __err; \
> __err; \
> })
>
> #define phy_read_poll_timeout(phydev, regnum, val, cond, sleep_us, \
> timeout_us, sleep_before_read) \
> ({ \
> int __ret, __err; \
> __ret = read_poll_timeout(__phy_poll_read, __err, \
> __err < 0 || (cond), \
> sleep_us, timeout_us, sleep_before_read, phydev, regnum, val); \
> if (__err < 0) \
> __ret = __err; \
> ...
>
> but that brings with it the possibility of using an uninitialised
> "val" (e.g. if phy_read() returns an error on the first iteration.)
> and is way more horrid and even less easy to understand.
>
> Remember that we default to *not* warning about uninitialised variables
> when building the kernel, so this won't produce a warning - which I
> guess is probably why you didn't notice that your suggestion left "val"
> uninitialised.
Right :( Let's keep the patch as is.
Powered by blists - more mailing lists