Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1315549 > unrolled thread

[PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"

Back to article view | Back to linux.kernel

Contents

  [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay" Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2016-01-23 10:30 +0100
    Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over  udelay" Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2016-01-25 05:40 +0100
    Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over  udelay" Dan Carpenter <dan.carpenter@oracle.com> - 2016-01-25 10:20 +0100
      Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over  udelay" Dan Carpenter <dan.carpenter@oracle.com> - 2016-01-25 10:40 +0100
      Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over  udelay" Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2016-01-25 10:50 +0100
        Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over  udelay" Dan Carpenter <dan.carpenter@oracle.com> - 2016-01-25 12:10 +0100
        Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over  udelay" Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2016-01-25 14:00 +0100
          Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay" Willy Tarreau <w@1wt.eu> - 2016-01-25 21:50 +0100
        Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay" "Huang\, Ying" <ying.huang@intel.com> - 2016-01-26 01:40 +0100
          Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over  udelay" Dan Carpenter <dan.carpenter@oracle.com> - 2016-01-26 02:40 +0100
            Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay" "Huang\, Ying" <ying.huang@intel.com> - 2016-01-26 03:10 +0100
        Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over  udelay" Dan Carpenter <dan.carpenter@oracle.com> - 2016-01-26 18:50 +0100
      Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over  udelay" Joe Perches <joe@perches.com> - 2016-01-25 13:50 +0100
        Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over  udelay" Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2016-01-25 14:00 +0100
          Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over  udelay" Joe Perches <joe@perches.com> - 2016-01-25 14:00 +0100

#1315549 — [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"

This reverts commit ebd43516d3879f882a403836bba8bc5791f26a28.

We should not be sleeping inside spin_lock.

Fixes: ebd43516d387 ("Staging: panel: usleep_range is preferred over udelay")
Cc: Sirnam Swetha <theonly.ultimate@gmail.com>
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
 drivers/staging/panel/panel.c | 34 +++++++++++++++-------------------
 1 file changed, 15 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/panel/panel.c b/drivers/staging/panel/panel.c
index 79ac192..70b8f4f 100644
--- a/drivers/staging/panel/panel.c
+++ b/drivers/staging/panel/panel.c
@@ -825,8 +825,7 @@ static void lcd_write_cmd_s(int cmd)
 	lcd_send_serial(0x1F);	/* R/W=W, RS=0 */
 	lcd_send_serial(cmd & 0x0F);
 	lcd_send_serial((cmd >> 4) & 0x0F);
-	/* the shortest command takes at least 40 us */
-	usleep_range(40, 100);
+	udelay(40);		/* the shortest command takes at least 40 us */
 	spin_unlock_irq(&pprt_lock);
 }
 
@@ -837,8 +836,7 @@ static void lcd_write_data_s(int data)
 	lcd_send_serial(0x5F);	/* R/W=W, RS=1 */
 	lcd_send_serial(data & 0x0F);
 	lcd_send_serial((data >> 4) & 0x0F);
-	/* the shortest data takes at least 40 us */
-	usleep_range(40, 100);
+	udelay(40);		/* the shortest data takes at least 40 us */
 	spin_unlock_irq(&pprt_lock);
 }
 
@@ -848,20 +846,19 @@ static void lcd_write_cmd_p8(int cmd)
 	spin_lock_irq(&pprt_lock);
 	/* present the data to the data port */
 	w_dtr(pprt, cmd);
-	/* maintain the data during 20 us before the strobe */
-	usleep_range(20, 100);
+	udelay(20);	/* maintain the data during 20 us before the strobe */
 
 	bits.e = BIT_SET;
 	bits.rs = BIT_CLR;
 	bits.rw = BIT_CLR;
 	set_ctrl_bits();
 
-	usleep_range(40, 100);	/* maintain the strobe during 40 us */
+	udelay(40);	/* maintain the strobe during 40 us */
 
 	bits.e = BIT_CLR;
 	set_ctrl_bits();
 
-	usleep_range(120, 500);	/* the shortest command takes at least 120 us */
+	udelay(120);	/* the shortest command takes at least 120 us */
 	spin_unlock_irq(&pprt_lock);
 }
 
@@ -871,20 +868,19 @@ static void lcd_write_data_p8(int data)
 	spin_lock_irq(&pprt_lock);
 	/* present the data to the data port */
 	w_dtr(pprt, data);
-	/* maintain the data during 20 us before the strobe */
-	usleep_range(20, 100);
+	udelay(20);	/* maintain the data during 20 us before the strobe */
 
 	bits.e = BIT_SET;
 	bits.rs = BIT_SET;
 	bits.rw = BIT_CLR;
 	set_ctrl_bits();
 
-	usleep_range(40, 100);	/* maintain the strobe during 40 us */
+	udelay(40);	/* maintain the strobe during 40 us */
 
 	bits.e = BIT_CLR;
 	set_ctrl_bits();
 
-	usleep_range(45, 100);	/* the shortest data takes at least 45 us */
+	udelay(45);	/* the shortest data takes at least 45 us */
 	spin_unlock_irq(&pprt_lock);
 }
 
@@ -894,7 +890,7 @@ static void lcd_write_cmd_tilcd(int cmd)
 	spin_lock_irq(&pprt_lock);
 	/* present the data to the control port */
 	w_ctr(pprt, cmd);
-	usleep_range(60, 120);
+	udelay(60);
 	spin_unlock_irq(&pprt_lock);
 }
 
@@ -904,7 +900,7 @@ static void lcd_write_data_tilcd(int data)
 	spin_lock_irq(&pprt_lock);
 	/* present the data to the data port */
 	w_dtr(pprt, data);
-	usleep_range(60, 120);
+	udelay(60);
 	spin_unlock_irq(&pprt_lock);
 }
 
@@ -947,7 +943,7 @@ static void lcd_clear_fast_s(void)
 		lcd_send_serial(0x5F);	/* R/W=W, RS=1 */
 		lcd_send_serial(' ' & 0x0F);
 		lcd_send_serial((' ' >> 4) & 0x0F);
-		usleep_range(40, 100);	/* the shortest data takes at least 40 us */
+		udelay(40);	/* the shortest data takes at least 40 us */
 	}
 	spin_unlock_irq(&pprt_lock);
 
@@ -971,7 +967,7 @@ static void lcd_clear_fast_p8(void)
 		w_dtr(pprt, ' ');
 
 		/* maintain the data during 20 us before the strobe */
-		usleep_range(20, 100);
+		udelay(20);
 
 		bits.e = BIT_SET;
 		bits.rs = BIT_SET;
@@ -979,13 +975,13 @@ static void lcd_clear_fast_p8(void)
 		set_ctrl_bits();
 
 		/* maintain the strobe during 40 us */
-		usleep_range(40, 100);
+		udelay(40);
 
 		bits.e = BIT_CLR;
 		set_ctrl_bits();
 
 		/* the shortest data takes at least 45 us */
-		usleep_range(45, 100);
+		udelay(45);
 	}
 	spin_unlock_irq(&pprt_lock);
 
@@ -1007,7 +1003,7 @@ static void lcd_clear_fast_tilcd(void)
 	for (pos = 0; pos < lcd.height * lcd.hwidth; pos++) {
 		/* present the data to the data port */
 		w_dtr(pprt, ' ');
-		usleep_range(60, 120);
+		udelay(60);
 	}
 
 	spin_unlock_irq(&pprt_lock);
-- 
1.9.1

[toc] | [next] | [standalone]

#1316198 — Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"

On Sat, Jan 23, 2016 at 02:49:20PM +0530, Sudip Mukherjee wrote:
> This reverts commit ebd43516d3879f882a403836bba8bc5791f26a28.
> 
> We should not be sleeping inside spin_lock.
> 
> Fixes: ebd43516d387 ("Staging: panel: usleep_range is preferred over udelay")
> Cc: Sirnam Swetha <theonly.ultimate@gmail.com>
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>

Reported-by: Huang, Ying <ying.huang@intel.com>

And can we also add
Tested-by: Huang, Ying <ying.huang@intel.com>

based on his test report and mail at
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1058239.html
and
https://lkml.org/lkml/2016/1/24/355

regards
sudip

[toc] | [prev] | [next] | [standalone]

#1316319 — Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"

Ugh...  Checkpatch told us to introduce bugs...  :(  We almost certainly
would have missed this bug in review, but it wasn't sent to the list so
I guess we'll never know.

regards,
dan carpenter

[toc] | [prev] | [next] | [standalone]

#1316327 — Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"

Anyway, I'll update Smatch to warn about these in the future.

regards,
dan carpenter

[toc] | [prev] | [next] | [standalone]

#1316346 — Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"

On Mon, Jan 25, 2016 at 12:16:01PM +0300, Dan Carpenter wrote:
> Ugh...  Checkpatch told us to introduce bugs...  :(  We almost certainly
> would have missed this bug in review, but it wasn't sent to the list so
> I guess we'll never know.

I can find the v1 of the patch in usb list.
http://permalink.gmane.org/gmane.linux.usb.general/132712

Apart from the mail which Ying Huang sent to me last week for another error
(which actually turned out to be this one), i saw the first report by
Ying Huang on November.
https://lkml.org/lkml/2015/11/2/93

I think i will start keeping a list of errors sent by 0day to check if
they are getting fixed or not.

Or maybe Ying Huang has some mechanism. do you?

regards
sudip

[toc] | [prev] | [next] | [standalone]

#1316481 — Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"

On Mon, Jan 25, 2016 at 03:13:21PM +0530, Sudip Mukherjee wrote:
> On Mon, Jan 25, 2016 at 12:16:01PM +0300, Dan Carpenter wrote:
> > Ugh...  Checkpatch told us to introduce bugs...  :(  We almost certainly
> > would have missed this bug in review, but it wasn't sent to the list so
> > I guess we'll never know.
> 
> I can find the v1 of the patch in usb list.
> http://permalink.gmane.org/gmane.linux.usb.general/132712

That's so weird.  Linux-usb is the wrong list.

gmane doesn't let me see the thread.  When I hit search archive it
doesn't find the email.
http://search.gmane.org/?query=Staging%3A+panel&group=gmane.linux.usb.general
Everything is such crap...  :(

Google works though...  The bug was detected in review that same day.
http://www.spinics.net/lists/linux-usb/msg131737.html

Ugh...  What a stinking pile of fail.

regards,
dan carpenter

[toc] | [prev] | [next] | [standalone]

#1316666 — Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"

On Mon, Jan 25, 2016 at 03:40:41PM +0300, Dan Carpenter wrote:
> On Mon, Jan 25, 2016 at 03:13:21PM +0530, Sudip Mukherjee wrote:
> > Apart from the mail which Ying Huang sent to me last week for another error
> > (which actually turned out to be this one), i saw the first report by
> > Ying Huang on November.
> > https://lkml.org/lkml/2015/11/2/93
> 
> Ying, could you CC the subsystem list for these reports?  This one was
> CC'd to Sirnam, Greg and LKML.  Sirnam is too new to understand what
> they mean, Greg is too busy, and only Sudip and Alan Cox read LKML.

I only read the mails whose subject is interesting and something which
I can understand. I am also still new to understand many of the things.
I am sure Alan, Greg, Linus, they will read all the mails.

I am setting up a filter in my lkml mails so that these reports are
saved in a separate folder and I will keep and track the reports i
understand.

regards
sudip

[toc] | [prev] | [next] | [standalone]

#1317294

On Mon, Jan 25, 2016 at 06:19:44PM +0530, Sudip Mukherjee wrote:
> On Mon, Jan 25, 2016 at 03:40:41PM +0300, Dan Carpenter wrote:
> > Ying, could you CC the subsystem list for these reports?  This one was
> > CC'd to Sirnam, Greg and LKML.  Sirnam is too new to understand what
> > they mean, Greg is too busy, and only Sudip and Alan Cox read LKML.
> 
> I only read the mails whose subject is interesting and something which
> I can understand. I am also still new to understand many of the things.
> I am sure Alan, Greg, Linus, they will read all the mails.

You could be disappointed then. Linus has always said that he doesn't
read it and even pretends he's not even subscribed. Greg probably doesn't
have the time given that he's flooded with the stable@ messages and
virtually every e-mail on the kernel where he's CC'd like this one. As
for Alan I'm not even sure he still manages to catch up with this volume.
I personally stopped 7 years ago after I didn't have this dedicated display
constantly on it anymore, and since then the traffic has doubled. And by
then I was only reading the subjects...

However LKML is great as a searchable public archive.

Willy

[toc] | [prev] | [next] | [standalone]

#1317429

Dan Carpenter <dan.carpenter@oracle.com> writes:

> On Mon, Jan 25, 2016 at 03:13:21PM +0530, Sudip Mukherjee wrote:
>> Apart from the mail which Ying Huang sent to me last week for another error
>> (which actually turned out to be this one), i saw the first report by
>> Ying Huang on November.
>> https://lkml.org/lkml/2015/11/2/93
>
> Ying, could you CC the subsystem list for these reports?  This one was
> CC'd to Sirnam, Greg and LKML.  Sirnam is too new to understand what
> they mean, Greg is too busy, and only Sudip and Alan Cox read LKML.

Sure.  But what is the best way to find the subsystem list for a patch?
Now we use author, committer, and the xxx-by: and Cc: list in patch to
find the recipient.

Best Regards,
Huang, Ying

[toc] | [prev] | [next] | [standalone]

#1317450 — Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"

On Tue, Jan 26, 2016 at 08:32:48AM +0800, Huang, Ying wrote:
> Dan Carpenter <dan.carpenter@oracle.com> writes:
> 
> > On Mon, Jan 25, 2016 at 03:13:21PM +0530, Sudip Mukherjee wrote:
> >> Apart from the mail which Ying Huang sent to me last week for another error
> >> (which actually turned out to be this one), i saw the first report by
> >> Ying Huang on November.
> >> https://lkml.org/lkml/2015/11/2/93
> >
> > Ying, could you CC the subsystem list for these reports?  This one was
> > CC'd to Sirnam, Greg and LKML.  Sirnam is too new to understand what
> > they mean, Greg is too busy, and only Sudip and Alan Cox read LKML.
> 
> Sure.  But what is the best way to find the subsystem list for a patch?
> Now we use author, committer, and the xxx-by: and Cc: list in patch to
> find the recipient.

For this one it's simple.  Get the filename from the git commit and
use ./scripts/get_maintainer.pl -f $file.  That should work generally,
the only issue is maybe some patches affect things across subsystems.

Also I don't know if netdev wants these emails?  Do you guys CC them on
0day warnings?

regards,
dan carpenter

[toc] | [prev] | [next] | [standalone]

#1317460

Dan Carpenter <dan.carpenter@oracle.com> writes:

> On Tue, Jan 26, 2016 at 08:32:48AM +0800, Huang, Ying wrote:
>> Dan Carpenter <dan.carpenter@oracle.com> writes:
>> 
>> > On Mon, Jan 25, 2016 at 03:13:21PM +0530, Sudip Mukherjee wrote:
>> >> Apart from the mail which Ying Huang sent to me last week for another error
>> >> (which actually turned out to be this one), i saw the first report by
>> >> Ying Huang on November.
>> >> https://lkml.org/lkml/2015/11/2/93
>> >
>> > Ying, could you CC the subsystem list for these reports?  This one was
>> > CC'd to Sirnam, Greg and LKML.  Sirnam is too new to understand what
>> > they mean, Greg is too busy, and only Sudip and Alan Cox read LKML.
>> 
>> Sure.  But what is the best way to find the subsystem list for a patch?
>> Now we use author, committer, and the xxx-by: and Cc: list in patch to
>> find the recipient.
>
> For this one it's simple.  Get the filename from the git commit and
> use ./scripts/get_maintainer.pl -f $file.  That should work generally,
> the only issue is maybe some patches affect things across subsystems.
>
> Also I don't know if netdev wants these emails?  Do you guys CC them on
> 0day warnings?

Only if it appears in Cc: list of the commit.

Best Regards,
Huang, Ying

[toc] | [prev] | [next] | [standalone]

#1318208 — Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"

On Mon, Jan 25, 2016 at 03:13:21PM +0530, Sudip Mukherjee wrote:
> Apart from the mail which Ying Huang sent to me last week for another error
> (which actually turned out to be this one), i saw the first report by
> Ying Huang on November.
> https://lkml.org/lkml/2015/11/2/93

Ying, could you CC the subsystem list for these reports?  This one was
CC'd to Sirnam, Greg and LKML.  Sirnam is too new to understand what
they mean, Greg is too busy, and only Sudip and Alan Cox read LKML.

regards,
dan carpenter

[toc] | [prev] | [next] | [standalone]

#1316646 — Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"

On Mon, 2016-01-25 at 12:16 +0300, Dan Carpenter wrote:
> Ugh...  Checkpatch told us to introduce bugs...  :(  We almost certainly
> would have missed this bug in review, but it wasn't sent to the list so
> I guess we'll never know.

So when isn't usleep_range preferred over udelay?

[toc] | [prev] | [next] | [standalone]

#1316671 — Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"

On Mon, Jan 25, 2016 at 04:47:26AM -0800, Joe Perches wrote:
> On Mon, 2016-01-25 at 12:16 +0300, Dan Carpenter wrote:
> > Ugh...  Checkpatch told us to introduce bugs...  :(  We almost certainly
> > would have missed this bug in review, but it wasn't sent to the list so
> > I guess we'll never know.
> 
> So when isn't usleep_range preferred over udelay?

inside a spin_lock or in some interrupt routine.

regards
sudip

[toc] | [prev] | [next] | [standalone]

#1316672 — Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"

On Mon, 2016-01-25 at 18:21 +0530, Sudip Mukherjee wrote:
> On Mon, Jan 25, 2016 at 04:47:26AM -0800, Joe Perches wrote:
> > On Mon, 2016-01-25 at 12:16 +0300, Dan Carpenter wrote:
> > > Ugh...  Checkpatch told us to introduce bugs...  :(  We almost certainly
> > > would have missed this bug in review, but it wasn't sent to the list so
> > > I guess we'll never know.
> > 
> > So when isn't usleep_range preferred over udelay?
> 
> inside a spin_lock or in some interrupt routine.

That's what timers-howto says and the checkpatch message
for this refers to it.

This message has been in checkpatch since 2010
commit 1a15a250862fda3fbdf8454cc7131e24de904e7c
Author: Patrick Pannuto <ppannuto@codeaurora.org>

Maybe the checkpatch message can have "when not atomic"
added or some such.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web