This driver wants to keep its LEDs state after module is removed
and implemented it in its own way. LED subsystem supports dedicated
flag LED_RETAIN_AT_SHUTDOWN for the same purpose so use the flag
instead of custom implementation.
Signed-off-by: George Stark
---
drivers/leds/leds-powernv.c
n module's remove() so use devm API instead.
Signed-off-by: George Stark
---
drivers/leds/leds-mlxreg.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/leds/leds-mlxreg.c b/drivers/leds/leds-mlxreg.c
index d8e3d5d8d2d0..b1510cd32e47 100644
--- a/dr
n module's remove() so use devm API instead.
Signed-off-by: George Stark
---
drivers/leds/leds-an30259a.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/leds/leds-an30259a.c b/drivers/leds/leds-an30259a.c
index 0216afed3b6e..decfca447d8a 100644
---
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-lm3532.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/leds/leds-lm3532.c b/drivers/leds/leds-lm3532.c
index 13662a4aa1f
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-aw200xx.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/leds/leds-aw200xx.c b/drivers/leds/leds-aw200xx.c
ind
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-nic78bx.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/leds/leds-nic78bx.c b/drivers/leds/leds-nic78bx.c
index a86b43dd995
() actually does nothing in non-debug builds
frequently calling mutex_destroy() is just ignored which is safe for now
but wrong formally and can lead to a problem if mutex_destroy() will be
extended so introduce devm_mutex_init()
Signed-off-by: George Stark
Suggested by-by: Christophe Leroy
n module's remove() so use devm API instead of remove().
Also drop explicit turning LEDs off from remove() due to they will be off
anyway by led_classdev_unregister().
Signed-off-by: George Stark
---
drivers/leds/leds-lp3952.c | 21 +++--
1 file changed, 11 insertions(+
034.1548605-2-gnst...@salutedevices.com/
[12]
https://lore.kernel.org/lkml/20240307024034.1548605-3-gnst...@salutedevices.com/
George Stark (9):
locking/mutex: introduce devm_mutex_init
leds: aw2013: use devm API to cleanup module's resources
leds: aw200xx: use devm API to cleanup
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
Tested-by: Nikita Travkin
---
drivers/leds/leds-aw2013.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/leds/leds-aw2013.c b/drivers/leds/leds
Hello Christophe
On 3/12/24 14:51, Christophe Leroy wrote:
Le 12/03/2024 à 12:39, George Stark a écrit :
[Vous ne recevez pas souvent de courriers de gnst...@salutedevices.com.
Découvrez pourquoi ceci est important à
https://aka.ms/LearnAboutSenderIdentification ]
...
You don't need
Hello Christophe
Thanks for the review
You were right about typecheck - it was meant to check errors even if
CONFIG_DEBUG_MUTEXES was off.
Here's new version based on the comments:
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 67edc4ca2bee..9193b163038f 100644
--- a/include
Hello Andy
On 3/7/24 13:34, Andy Shevchenko wrote:
On Thu, Mar 7, 2024 at 4:40 AM George Stark wrote:
Using of devm API leads to a certain order of releasing resources.
So all dependent resources which are not devm-wrapped should be deleted
with respect to devm-release order. Mutex is one of
patch with moving down
mutex_destroy. devm block is big enough to be declared standalone.
On 3/7/24 19:44, Marek Behún wrote:
On Thu, 7 Mar 2024 08:39:46 -0500
Waiman Long wrote:
On 3/7/24 04:56, Marek Behún wrote:
On Thu, Mar 07, 2024 at 05:40:26AM +0300, George Stark wrote:
Using of devm
Hello Christophe
On 3/7/24 16:50, Christophe Leroy wrote:
Le 07/03/2024 à 03:40, George Stark a écrit :
[Vous ne recevez pas souvent de courriers de gnst...@salutedevices.com.
Découvrez pourquoi ceci est important à
https://aka.ms/LearnAboutSenderIdentification ]
Using of devm API leads
This driver wants to keep its LEDs state after module is removed
and implemented it in its own way. LED subsystem supports dedicated
flag LED_RETAIN_AT_SHUTDOWN for the same purpose so use the flag
instead of custom implementation.
Signed-off-by: George Stark
---
drivers/leds/leds-powernv.c
mutex_destroy() definition is located in the middle of the code related
purely to mutex initialization so place it separately after mutex_init()
Signed-off-by: George Stark
---
Hello Waiman. This is helper patch to make resulting mutex.h look like we
discussed
it in December. It was in you
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
Tested-by: Nikita Travkin
---
drivers/leds/leds-aw2013.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/leds/leds-aw2013.c b/drivers/leds/leds
n module's remove() so use devm API instead.
Signed-off-by: George Stark
---
drivers/leds/leds-mlxreg.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/leds/leds-mlxreg.c b/drivers/leds/leds-mlxreg.c
index d8e3d5d8d2d0..b1510cd32e47 100644
--- a/dr
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-lm3532.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/leds/leds-lm3532.c b/drivers/leds/leds-lm3532.c
index 13662a4aa1f
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-aw200xx.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/leds/leds-aw200xx.c b/drivers/leds/leds-aw200xx.c
ind
n module's remove() so use devm API instead.
Signed-off-by: George Stark
---
drivers/leds/leds-an30259a.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/leds/leds-an30259a.c b/drivers/leds/leds-an30259a.c
index 0216afed3b6e..decfca447d8a 100644
---
n module's remove() so use devm API instead of remove().
Also drop explicit turning LEDs off from remove() due to they will be off
anyway by led_classdev_unregister().
Signed-off-by: George Stark
---
drivers/leds/leds-lp3952.c | 21 +++--
1 file changed, 11 insertions(+
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-nic78bx.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/leds/leds-nic78bx.c b/drivers/leds/leds-nic78bx.c
index a86b43dd995
d1fc04c560012c1e27418e3156d0c9306dd84
[10]
https://lore.kernel.org/lkml/20231213223020.2713164-1-gnst...@salutedevices.com/T/#m63126025f5d1bdcef69bcad50f2e58274d42e2d
George Stark (10):
locking/mutex: move mutex_destroy() definition lower
locking/mutex: introduce devm_mutex_init
leds: aw2013: use dev
() actually does nothing in non-debug builds
frequently calling mutex_destroy() is just ignored which is safe for now
but wrong formally and can lead to a problem if mutex_destroy() will be
extended so introduce devm_mutex_init()
Signed-off-by: George Stark
Signed-off-by: Christophe Leroy
---
Hello
Hello Andy
On 2/13/24 13:55, Andy Shevchenko wrote:
On Tue, Feb 13, 2024 at 2:14 AM George Stark wrote:
Hello Andy
On 2/12/24 12:53, Andy Shevchenko wrote:
On Mon, Feb 12, 2024 at 1:52 AM George Stark wrote:
I haven't lose hope for the devm_mutex thing and keep pinging those guys
Hello Andy
On 2/12/24 12:53, Andy Shevchenko wrote:
On Mon, Feb 12, 2024 at 1:52 AM George Stark wrote:
I haven't lose hope for the devm_mutex thing and keep pinging those guys
from time to time.
I don't understand. According to v4 thread Christophe proposed on how
the patch s
4 Dec 2023, George Stark wrote:
This patch series fixes the problem of devm_led_classdev_register misusing.
The basic problem is described in [1]. Shortly when devm_led_classdev_register()
is used then led_classdev_unregister() called after driver's remove() callback.
led_classdev_unregister()
Hello Christophe
On 12/17/23 12:31, Christophe Leroy wrote:
...
---
include/linux/mutex.h | 23 +++
kernel/locking/mutex-debug.c | 22 ++
2 files changed, 45 insertions(+)
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
in
Hello Christophe
On 12/15/23 08:46, Christophe Leroy wrote:
Le 14/12/2023 à 22:48, Waiman Long a écrit :
On 12/14/23 14:53, Christophe Leroy wrote:
Le 14/12/2023 à 19:48, Waiman Long a écrit :
On 12/14/23 12:36, George Stark wrote:
Using of devm API leads to a certain order of releasing
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-lm3532.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/leds/leds-lm3532.c b/drivers/leds/leds-lm3532.c
index 13662a4aa1f
n module's remove() so use devm API instead.
Signed-off-by: George Stark
---
drivers/leds/leds-mlxreg.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/leds/leds-mlxreg.c b/drivers/leds/leds-mlxreg.c
index b7855c93bd72..64a78eff05c7 100644
--- a/dr
This driver wants to keep its LEDs state after module is removed
and implemented it in its own way. LED subsystem supports dedicated
flag LED_RETAIN_AT_SHUTDOWN for the same purpose so use the flag
instead of custom implementation.
Signed-off-by: George Stark
---
drivers/leds/leds-powernv.c
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-nic78bx.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/leds/leds-nic78bx.c b/drivers/leds/leds-nic78bx.c
index f196f52eec1
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
Tested-by: Nikita Travkin
---
drivers/leds/leds-aw2013.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/leds/leds-aw2013.c b/drivers/leds/leds
n module's remove() so use devm API instead of remove().
Also drop explicit turning LEDs off from remove() due to they will be off
anyway by led_classdev_unregister().
Signed-off-by: George Stark
---
drivers/leds/leds-lp3952.c | 21 +++--
1 file changed, 11 insertions(+
In the probe() callback in case of error mutex is destroyed being locked
which is not allowed so unlock the mutex before destroying.
Fixes: 59ea3c9faf32 ("leds: add aw2013 driver")
Signed-off-by: George Stark
Reviewed-by: Andy Shevchenko
---
drivers/leds/leds-aw2013.c | 1 +
1 file
0bcd69...@redhat.com/T/#m5f84a4a2f387d49678783e652b9e658e02c27450
[9]
https://lore.kernel.org/lkml/20231213223020.2713164-1-gnst...@salutedevices.com/T/#m19ad1fc04c560012c1e27418e3156d0c9306dd84
[10]
https://lore.kernel.org/lkml/20231213223020.2713164-1-gnst...@salutedevices.com/T/#m63126025f5d
n module's remove() so use devm API instead.
Signed-off-by: George Stark
---
drivers/leds/leds-an30259a.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/leds/leds-an30259a.c b/drivers/leds/leds-an30259a.c
index 24b1041213c2..8f62c012c81a 100644
---
() actually does nothing in non-debug builds
frequently calling mutex_destroy() is just ignored which is safe for now
but wrong formally and can lead to a problem if mutex_destroy() will be
extended so introduce devm_mutex_init()
Signed-off-by: George Stark
---
include/linux/mutex.h| 23
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-aw200xx.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/leds/leds-aw200xx.c b/drivers/leds/leds-aw200xx.c
ind
Hello Nikita
Thanks for the review and testing.
On 12/14/23 08:42, Nikita Travkin wrote:
George Stark писал(а) 14.12.2023 03:30:
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is
se it works the other way round, so I will just go undetected.
For me the best solution remains to use mutex.h and have
devm_mutex_init() defined or declared at the same place as mutex_destroy().
Signed-off-by: George Stark
---
include/linux/devm-helpers.h | 27 +++
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-nic78bx.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/leds/leds-nic78bx.c b/drivers/leds/leds-nic78bx.c
index f196f52eec1
n module's remove() so use devm API instead.
Signed-off-by: George Stark
---
drivers/leds/leds-mlxreg.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/leds/leds-mlxreg.c b/drivers/leds/leds-mlxreg.c
index b7855c93bd72..64a78eff05c7 100644
--- a/dr
n module's remove() so use devm API instead.
Signed-off-by: George Stark
---
drivers/leds/leds-an30259a.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/leds/leds-an30259a.c b/drivers/leds/leds-an30259a.c
index 24b1041213c2..8f62c012c81a 100644
---
n module's remove() so use devm API instead of remove().
Also drop explicit turning LEDs off from remove() due to they will be off
anyway by led_classdev_unregister().
Signed-off-by: George Stark
---
drivers/leds/leds-lp3952.c | 21 +++--
1 file changed, 11 insertions(+
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-aw200xx.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/leds/leds-aw200xx.c b/drivers/leds/leds-aw200xx.c
ind
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-lm3532.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/leds/leds-lm3532.c b/drivers/leds/leds-lm3532.c
index 13662a4aa1f
This driver wants to keep its LEDs state after module is removed
and implemented it in its own way. LED subsystem supports dedicated
flag LED_RETAIN_AT_SHUTDOWN for the same purpose so use the flag
instead of custom implementation.
Signed-off-by: George Stark
---
drivers/leds/leds-powernv.c
7d681
[7]
https://lore.kernel.org/lkml/20231204180603.470421-1-gnst...@salutedevices.com/T/#m8e5c65e0c6b137c91fa00bb9320ad581164d1d0b
[8]
https://lore.kernel.org/lkml/377e4437-7051-4d88-ae68-1460bcd69...@redhat.com/T/#m5f84a4a2f387d49678783e652b9e658e02c27450
George Stark (11):
leds: aw2013: unlock mutex before des
In the probe() callback in case of error mutex is destroyed being locked
which is not allowed so unlock the mutex before destroying.
Fixes: 59ea3c9faf32 ("leds: add aw2013 driver")
Signed-off-by: George Stark
Reviewed-by: Andy Shevchenko
---
drivers/leds/leds-aw2013.c | 1 +
1 file
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-aw2013.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/leds/leds-aw2013.c b/drivers/leds/leds-aw2013.c
index c2bc0782c0c
ex_destroy() really does something in the current configuration
and it's should be called or skipped otherwise for the sake of
optimization so add dedicated define to recognize these cases.
Signed-off-by: George Stark
---
include/linux/mutex.h | 3 +++
1 file changed, 3 insertions(+)
diff
() actually does nothing in non-debug builds
frequently calling mutex_destroy() is just ignored which is safe for now
but wrong formally and can lead to a problem if mutex_destroy() is
extended so introduce devm_mutex_init().
Signed-off-by: George Stark
---
include/linux/devm-helpers.h | 27
On 12/7/23 16:01, Christophe Leroy wrote:
Le 07/12/2023 à 13:51, George Stark a écrit :
On 12/7/23 15:28, Christophe Leroy wrote:
Le 07/12/2023 à 13:02, Andy Shevchenko a écrit :
On Thu, Dec 7, 2023 at 1:23 AM George Stark
wrote:
On 12/7/23 01:37, Christophe Leroy wrote:
Le 06/12
On 12/7/23 15:28, Christophe Leroy wrote:
Le 07/12/2023 à 13:02, Andy Shevchenko a écrit :
On Thu, Dec 7, 2023 at 1:23 AM George Stark wrote:
On 12/7/23 01:37, Christophe Leroy wrote:
Le 06/12/2023 à 23:14, Christophe Leroy a écrit :
...
Looking at it closer, I have the feeling that
Hello Waiman
Thanks for the review.
On 12/7/23 00:02, Waiman Long wrote:
On 12/6/23 14:55, Hans de Goede wrote:
Hi,
On 12/6/23 19:58, George Stark wrote:
Hello Hans
Thanks for the review.
On 12/6/23 18:01, Hans de Goede wrote:
Hi George,
...
mutex_destroy() only actually does anything
Hello Christophe
On 12/7/23 01:37, Christophe Leroy wrote:
Le 06/12/2023 à 23:14, Christophe Leroy a écrit :
Le 06/12/2023 à 19:58, George Stark a écrit :
[Vous ne recevez pas souvent de courriers de
gnst...@salutedevices.com. Découvrez pourquoi ceci est important à
https://aka.ms
Hello Hans
Thanks for the review.
On 12/6/23 18:01, Hans de Goede wrote:
Hi George,
On 12/4/23 19:05, George Stark wrote:
Using of devm API leads to certain order of releasing resources.
So all dependent resources which are not devm-wrapped should be deleted
with respect to devm-release
Hello Christophe
Thanks for the review
On 12/5/23 02:09, Christophe Leroy wrote:
Le 04/12/2023 à 19:05, George Stark a écrit :
In the probe() callback in case of error mutex is destroyed being locked
which is not allowed so unlock the mute before destroying.
Should there be a fixes: tag
Hello Andy
Thanks for the review.
On 12/4/23 21:11, Andy Shevchenko wrote:
On Mon, Dec 4, 2023 at 8:07 PM George Stark wrote:
Using of devm API leads to certain order of releasing resources.
So all dependent resources which are not devm-wrapped should be deleted
with respect to devm-release
]
https://lore.kernel.org/lkml/8704539b-ed3b-44e6-aa82-586e2f895...@salutedevices.com/T/#mc132b9b350fa51931b4fcfe14705d9f06e91421f
[3]
https://lore.kernel.org/lkml/8704539b-ed3b-44e6-aa82-586e2f895...@salutedevices.com/T/#mdbf572a85c33f869a553caf986b6228bb65c8383
George Stark (10):
devm-h
n module's remove() so use devm API instead of remove().
Also drop explicit turning LEDs off from remove() due to they will be off
anyway by led_classdev_unregister().
Signed-off-by: George Stark
---
drivers/leds/leds-lp3952.c | 21 +++--
1 file changed, 11 insertions(+
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-aw2013.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/leds/leds-aw2013.c b/drivers/leds/leds-aw2013.c
index c2bc0782c0c
n module's remove() so use devm API instead of remove().
Signed-off-by: George Stark
---
drivers/leds/leds-aw200xx.c | 36 +---
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/leds/leds-aw200xx.c b/drivers/leds/leds-aw200xx.c
ind
() actually does nothing in non-debug builds
frequently calling mutex_destroy() is just ignored which is safe for now
but wrong formally and can lead to a problem if mutex_destroy() is
extended so introduce devm_mutex_init().
Signed-off-by: George Stark
---
include/linux/devm-helpers.h | 18
In the probe() callback in case of error mutex is destroyed being locked
which is not allowed so unlock the mute before destroying.
Signed-off-by: George Stark
---
drivers/leds/leds-aw2013.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/leds/leds-aw2013.c b/drivers/leds/leds
Hello Andy
Thanks for the review.
On 11/24/23 18:28, Andy Shevchenko wrote:
On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
Lots of drivers use devm_led_classdev_register() to register their led objects
and let the kernel free those leds at the driver's remove stage.
It can
Hello Christophe.
Thanks for the review.
On 11/6/23 11:13, Christophe Leroy wrote:
>
>
> Le 25/10/2023 à 15:07, George Stark a écrit :
>> LEDs are registered using devm_led_classdev_register() and automatically
>> unregistered after module's remove(). led_c
Hello Andy
Could you please take a look at this patch series?
I've just found your post on habr about devres API misusing and I think
this is just another case.
On 10/25/23 16:07, George Stark wrote:
Lots of drivers use devm_led_classdev_register() to register their led objects
and le
.
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark
---
drivers/leds/leds-an30259a.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/leds/leds-an30259a.c b/drivers/leds/leds-an30259a.c
index 24b1041213c2..4209a407d802 100644
--- a/drivers/leds/leds-a
.
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark
---
drivers/leds/leds-powernv.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
index 743e2cdd0891..7c7f696c8265 100644
--- a/drivers/leds/leds-
.
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark
---
drivers/leds/leds-nic78bx.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/leds/leds-nic78bx.c b/drivers/leds/leds-nic78bx.c
index f196f52eec1e..12b70fcad37f 100644
--- a/drivers/leds/leds-
.
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark
---
drivers/leds/leds-aw2013.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/leds/leds-aw2013.c b/drivers/leds/leds-aw2013.c
index 59765640b70f..bd233500aa2d 100644
--- a/drivers/leds/leds-aw2013.
ot.
Actually in many cases it doesn't really need to turn off the leds manually
one-by-one
if driver shutdowns whole led controller. For the last case to disable the
warning
new flag can be brought in e.g LED_AUTO_OFF_AT_SHUTDOWN (similar to
LED_RETAIN_AT_SHUTDOWN).
George Stark (
.
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark
---
drivers/leds/leds-lp3952.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/leds/leds-lp3952.c b/drivers/leds/leds-lp3952.c
index 3bd55652a706..2de49192011a 100644
--- a/drivers/leds/leds-lp3952.
.
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark
---
drivers/leds/leds-aw200xx.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/leds/leds-aw200xx.c b/drivers/leds/leds-aw200xx.c
index 96979b8e09b7..3da0923507ec 100644
--- a/drivers/leds/leds-
.
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark
---
drivers/leds/leds-mlxreg.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/leds/leds-mlxreg.c b/drivers/leds/leds-mlxreg.c
index b7855c93bd72..6d65e39c3372 100644
--- a/dr
80 matches
Mail list logo
