[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.OSX.2.21.1812172039250.96577@macbook-pro.fritz.box>
Date: Mon, 17 Dec 2018 20:48:04 +0100 (CET)
From: Marc Dietrich <marvin24@....de>
To: Greg KH <gregkh@...uxfoundation.org>
cc: Amir Mahdi Ghorbanian <indigoomega021@...il.com>, marvin24@....de,
devel@...verdev.osuosl.org, linux-tegra@...r.kernel.org,
linux-kernel@...r.kernel.org, ac100@...ts.launchpad.net
Subject: Re: [PATCH 2/2] Staging: nvec: nvec: fixed check style issues
Hi,
On Mon, 17 Dec 2018, Greg KH wrote:
> On Sun, Dec 16, 2018 at 08:57:43AM -0800, Amir Mahdi Ghorbanian wrote:
>> @@ -626,7 +628,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>> break;
>> case 2: /* first byte after command */
>> if (status == (I2C_SL_IRQ | RNW | RCVD)) {
>> - udelay(33);
>> + usleep_range(0, 33);
>
> Why is this a valid range to sleep for for this device? Have you been
> able to verify/test this?
oh no, not again. Why does this come up again every half year? This udelay
is a workaround for a hw bug which only seldom triggers (if it triggers at
all). Secondly, this is in interrupt context, so *sleep timers are no go,
afaik.
Marc
Powered by blists - more mailing lists