[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200319171019.GJ27807@lunn.ch>
Date: Thu, 19 Mar 2020 18:10:19 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: Dejin Zheng <zhengdejin5@...il.com>, f.fainelli@...il.com,
linux@...linux.org.uk, davem@...emloft.net, tglx@...utronix.de,
broonie@...nel.org, corbet@....net, mchehab+samsung@...nel.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 3/7] net: phy: introduce
phy_read_mmd_poll_timeout macro
On Thu, Mar 19, 2020 at 05:56:39PM +0100, Heiner Kallweit wrote:
> On 19.03.2020 17:39, Dejin Zheng wrote:
> > it is sometimes necessary to poll a phy register by phy_read_mmd()
> > function until its value satisfies some condition. introduce
> > phy_read_mmd_poll_timeout() macros that do this.
> >
> > Signed-off-by: Dejin Zheng <zhengdejin5@...il.com>
> > ---
> > include/linux/phy.h | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/include/linux/phy.h b/include/linux/phy.h
> > index 36d9dea04016..a30e9008647f 100644
> > --- a/include/linux/phy.h
> > +++ b/include/linux/phy.h
> > @@ -24,6 +24,7 @@
> > #include <linux/mod_devicetable.h>
> > #include <linux/u64_stats_sync.h>
> > #include <linux/irqreturn.h>
> > +#include <linux/iopoll.h>
> >
> > #include <linux/atomic.h>
> >
> > @@ -784,6 +785,9 @@ static inline int __phy_modify_changed(struct phy_device *phydev, u32 regnum,
> > */
> > int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum);
> >
> > +#define phy_read_mmd_poll_timeout(val, cond, sleep_us, timeout_us, args...) \
> > + read_poll_timeout(phy_read_mmd, val, cond, sleep_us, timeout_us, args)
> > +
> > /**
> > * __phy_read_mmd - Convenience function for reading a register
> > * from an MMD on a given PHY.
> >
> I'm not fully convinced. Usage of the new macro with its lots of
> parameters makes the code quite hard to read. Therefore I'm also
> not a big fan of readx_poll_timeout.
One issue is that people often implement polling wrong. They don't
take into account where extra delays can happen, and return -ETIMEOUT
when in fact the operation was successful. readx_poll_timeout gives us
a core which is known to be good.
What i don't like here is phy_read_mmd_poll_timeout() takes args... We
know it should be passed a phydev, and device address and a reg. I
would prefer these to be explicit parameters. We can then get the
compiler to check the correct number of parameters are passed.
Andrew
Powered by blists - more mailing lists