* [bug report] leds: ns2: Remove work queue
@ 2021-12-10 13:52 Dan Carpenter
2021-12-15 20:39 ` Pavel Machek
0 siblings, 1 reply; 6+ messages in thread
From: Dan Carpenter @ 2021-12-10 13:52 UTC (permalink / raw)
To: linux-leds; +Cc: j.anaszewski
Hello LED devs,
The patch c29e650b3af2: "leds: ns2: Remove work queue" from Nov 20,
2015, leads to the following Smatch static checker warning:
drivers/leds/leds-ns2.c:96 ns2_led_set_mode()
warn: sleeping in atomic context
drivers/leds/leds-ns2.c
76 static void ns2_led_set_mode(struct ns2_led *led, enum ns2_led_modes mode)
77 {
78 int i;
79 unsigned long flags;
80
81 for (i = 0; i < led->num_modes; i++)
82 if (mode == led->modval[i].mode)
83 break;
84
85 if (i == led->num_modes)
86 return;
87
88 write_lock_irqsave(&led->rw_lock, flags);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Holding a write lock (spin lock).
89
90 if (!led->can_sleep) {
^^^^^^^^^^^^^^^
Even if the led->can_sleep flag is set, we are not actually allowed to
sleep when the preempt count is non-zero. Presumably we should make
this unconditional.
91 gpiod_set_value(led->cmd, led->modval[i].cmd_level);
92 gpiod_set_value(led->slow, led->modval[i].slow_level);
93 goto exit_unlock;
94 }
95
--> 96 gpiod_set_value_cansleep(led->cmd, led->modval[i].cmd_level);
97 gpiod_set_value_cansleep(led->slow, led->modval[i].slow_level);
^^^^^^^^^^^^^^^^^^^^^^^^^
These functions can sleep.
98
99 exit_unlock:
100 write_unlock_irqrestore(&led->rw_lock, flags);
101 }
regards,
dan carpenter
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [bug report] leds: ns2: Remove work queue
2021-12-10 13:52 [bug report] leds: ns2: Remove work queue Dan Carpenter
@ 2021-12-15 20:39 ` Pavel Machek
2021-12-15 21:04 ` Marek Behún
2021-12-16 10:28 ` Simon Guinot
0 siblings, 2 replies; 6+ messages in thread
From: Pavel Machek @ 2021-12-15 20:39 UTC (permalink / raw)
To: Dan Carpenter, simon.guinot, kabel; +Cc: linux-leds, j.anaszewski
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
Hi!
> Hello LED devs,
>
> The patch c29e650b3af2: "leds: ns2: Remove work queue" from Nov 20,
> 2015, leads to the following Smatch static checker warning:
>
> drivers/leds/leds-ns2.c:96 ns2_led_set_mode()
> warn: sleeping in atomic context
Yup, this looks wrong.
Plus, the code is quite crazy.
Not sure what the write_lock in that function is supposed to protect
against. Perhaps it can be just removed?
Hmm. led_set_mode uses custom interface for hardware accelerated
LED. Ideally there's more fixing to be done there :-(.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bug report] leds: ns2: Remove work queue
2021-12-15 20:39 ` Pavel Machek
@ 2021-12-15 21:04 ` Marek Behún
2021-12-16 10:30 ` Simon Guinot
2021-12-20 17:00 ` Ian Pilcher
2021-12-16 10:28 ` Simon Guinot
1 sibling, 2 replies; 6+ messages in thread
From: Marek Behún @ 2021-12-15 21:04 UTC (permalink / raw)
To: Pavel Machek; +Cc: Dan Carpenter, simon.guinot, linux-leds, j.anaszewski
On Wed, 15 Dec 2021 21:39:55 +0100
Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> > Hello LED devs,
> >
> > The patch c29e650b3af2: "leds: ns2: Remove work queue" from Nov 20,
> > 2015, leads to the following Smatch static checker warning:
> >
> > drivers/leds/leds-ns2.c:96 ns2_led_set_mode()
> > warn: sleeping in atomic context
>
> Yup, this looks wrong.
>
> Plus, the code is quite crazy.
>
> Not sure what the write_lock in that function is supposed to protect
> against. Perhaps it can be just removed?
>
> Hmm. led_set_mode uses custom interface for hardware accelerated
> LED. Ideally there's more fixing to be done there :-(.
The last time we discussed this, Simon said that he is willing to
convert once we have trigger offloading API. But we will also need
blkdev trigger. Time to review Ian Pilcher's last attempt at blkdev?
[RESEND PATCH v8 0/2] Introduce block device LED trigger
https://lore.kernel.org/linux-leds/20211119212733.286427-1-arequipeno@gmail.com/
Marek
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bug report] leds: ns2: Remove work queue
2021-12-15 21:04 ` Marek Behún
@ 2021-12-16 10:30 ` Simon Guinot
2021-12-20 17:00 ` Ian Pilcher
1 sibling, 0 replies; 6+ messages in thread
From: Simon Guinot @ 2021-12-16 10:30 UTC (permalink / raw)
To: Marek Behún; +Cc: Pavel Machek, Dan Carpenter, linux-leds, j.anaszewski
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
On Wed, Dec 15, 2021 at 10:04:41PM +0100, Marek Behún wrote:
> On Wed, 15 Dec 2021 21:39:55 +0100
> Pavel Machek <pavel@ucw.cz> wrote:
>
> > Hi!
> >
> > > Hello LED devs,
> > >
> > > The patch c29e650b3af2: "leds: ns2: Remove work queue" from Nov 20,
> > > 2015, leads to the following Smatch static checker warning:
> > >
> > > drivers/leds/leds-ns2.c:96 ns2_led_set_mode()
> > > warn: sleeping in atomic context
> >
> > Yup, this looks wrong.
> >
> > Plus, the code is quite crazy.
> >
> > Not sure what the write_lock in that function is supposed to protect
> > against. Perhaps it can be just removed?
> >
> > Hmm. led_set_mode uses custom interface for hardware accelerated
> > LED. Ideally there's more fixing to be done there :-(.
>
> The last time we discussed this, Simon said that he is willing to
> convert once we have trigger offloading API. But we will also need
> blkdev trigger. Time to review Ian Pilcher's last attempt at blkdev?
> [RESEND PATCH v8 0/2] Introduce block device LED trigger
> https://lore.kernel.org/linux-leds/20211119212733.286427-1-arequipeno@gmail.com/
Hi Marek,
I kind of remembering that :)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bug report] leds: ns2: Remove work queue
2021-12-15 21:04 ` Marek Behún
2021-12-16 10:30 ` Simon Guinot
@ 2021-12-20 17:00 ` Ian Pilcher
1 sibling, 0 replies; 6+ messages in thread
From: Ian Pilcher @ 2021-12-20 17:00 UTC (permalink / raw)
To: Marek Behún; +Cc: linux-leds
On 12/15/21 15:04, Marek Behún wrote:
> The last time we discussed this, Simon said that he is willing to
> convert once we have trigger offloading API. But we will also need
> blkdev trigger. Time to review Ian Pilcher's last attempt at blkdev?
> [RESEND PATCH v8 0/2] Introduce block device LED trigger
> https://lore.kernel.org/linux-leds/20211119212733.286427-1-arequipeno@gmail.com/
I support this. ;-)
Let me know if you'd like me to resend, have any questions, etc.
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bug report] leds: ns2: Remove work queue
2021-12-15 20:39 ` Pavel Machek
2021-12-15 21:04 ` Marek Behún
@ 2021-12-16 10:28 ` Simon Guinot
1 sibling, 0 replies; 6+ messages in thread
From: Simon Guinot @ 2021-12-16 10:28 UTC (permalink / raw)
To: Pavel Machek; +Cc: Dan Carpenter, kabel, linux-leds, j.anaszewski
[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]
Hi
On Wed, Dec 15, 2021 at 09:39:55PM +0100, Pavel Machek wrote:
> Hi!
>
> > Hello LED devs,
> >
> > The patch c29e650b3af2: "leds: ns2: Remove work queue" from Nov 20,
> > 2015, leads to the following Smatch static checker warning:
> >
> > drivers/leds/leds-ns2.c:96 ns2_led_set_mode()
> > warn: sleeping in atomic context
>
> Yup, this looks wrong.
It's been a very long time since I watched this pilot or even the LED
subsystem.
The "can_sleep" code seems to me quite the same as for the led_gpio
driver. If can_sleep is set (because for example the GPIO controller
uses I2C), then the brightness_set_blocking function should be used and
then ns2_led_set() can't be called in atomic context. And also the
gpiod_set_value_cansleep variants are used.
Where is it wrong ?
>
> Plus, the code is quite crazy.
Well, there has been many changes since the version I wrote.
>
> Not sure what the write_lock in that function is supposed to protect
> against. Perhaps it can be just removed?
At the time it was possible for brightness_set() to be called in user
context (through the sysfs interface) or in interrupt/timer context
(from a trigger). And because the LED is controlled through two GPIOs,
then ns2_led_set_mode() needs to be protected against reentrancy. That's
why the write_{lock_irqsave,unlock_irqrestore} functions have been used
here.
I have no idea about what is the context situation now.
>
> Hmm. led_set_mode uses custom interface for hardware accelerated
> LED. Ideally there's more fixing to be done there :-(.
At the time, nothing else was available and the LED API was crazy.
Simon
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-12-20 17:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-12-10 13:52 [bug report] leds: ns2: Remove work queue Dan Carpenter
2021-12-15 20:39 ` Pavel Machek
2021-12-15 21:04 ` Marek Behún
2021-12-16 10:30 ` Simon Guinot
2021-12-20 17:00 ` Ian Pilcher
2021-12-16 10:28 ` Simon Guinot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox