| Message ID | 20180508082638.5707-1-nsekhar@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, May 08, 2018 at 01:56:38PM +0530, Sekhar Nori wrote: > A well timed kernel preemption in the time_after() loop > in wait_for_idle() can result in a spurious timeout > error to be returned. > > Fix it by checking for status of hardware before returning > timeout error. > > Signed-off-by: Sekhar Nori <nsekhar@ti.com> I've seen this with other drivers as well. I suggest you make use of readx_poll_timeout(), or one of its cousins. They get this right. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 08 May 2018 06:18 PM, Andrew Lunn wrote: > On Tue, May 08, 2018 at 01:56:38PM +0530, Sekhar Nori wrote: >> A well timed kernel preemption in the time_after() loop >> in wait_for_idle() can result in a spurious timeout >> error to be returned. >> >> Fix it by checking for status of hardware before returning >> timeout error. >> >> Signed-off-by: Sekhar Nori <nsekhar@ti.com> > > I've seen this with other drivers as well. > > I suggest you make use of readx_poll_timeout(), or one of its > cousins. They get this right. Thanks for pointing me to these. I somehow thought these helpers are only available with regmap. Sending a version using readl_poll_timeout(). I know __raw_readl() is used elsewhere in the driver, but I think that should be cleaned up sometime to use readl_relaxed() at least. So not sure if there is benefit in persisting with existing accessor. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c index 3c33f4504d8e..4fbd04fd38cf 100644 --- a/drivers/net/ethernet/ti/davinci_mdio.c +++ b/drivers/net/ethernet/ti/davinci_mdio.c @@ -231,10 +231,16 @@ static inline int wait_for_idle(struct davinci_mdio_data *data) while (time_after(timeout, jiffies)) { if (__raw_readl(®s->control) & CONTROL_IDLE) - return 0; + goto out; } - dev_err(data->dev, "timed out waiting for idle\n"); - return -ETIMEDOUT; + + if (!(__raw_readl(®s->control) & CONTROL_IDLE)) { + dev_err(data->dev, "timed out waiting for idle\n"); + return -ETIMEDOUT; + } + +out: + return 0; } static int davinci_mdio_read(struct mii_bus *bus, int phy_id, int phy_reg)
A well timed kernel preemption in the time_after() loop in wait_for_idle() can result in a spurious timeout error to be returned. Fix it by checking for status of hardware before returning timeout error. Signed-off-by: Sekhar Nori <nsekhar@ti.com> --- The issue has not been personally observed by me, but has been reported by users. Sending for next-next given the non-critical nature. There is seems to be no easy way to reproduce this. drivers/net/ethernet/ti/davinci_mdio.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)