[PATCH 4/8] leds: mlxreg: explicitly unregister LEDs at module's shutdown

. 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

[PATCH 5/8] leds: aw200xx: explicitly unregister LEDs at module's shutdown

. 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-

[PATCH 7/8] leds: lp3952: explicitly unregister LEDs at module's shutdown

. 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.

[PATCH 0/8] devm_led_classdev_register() usage problem

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 (

[PATCH 6/8] leds: aw2013: explicitly unregister LEDs at module's shutdown

. 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.

[PATCH 2/8] leds: nic78bx: explicitly unregister LEDs at module's shutdown

. 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-

[PATCH 1/8] leds: powernv: explicitly unregister LEDs at module's shutdown

. 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-

[PATCH 3/8] leds: an30259a: explicitly unregister LEDs at module's shutdown

. 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

Re: [PATCH 0/8] devm_led_classdev_register() usage problem

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

Re: [PATCH 2/8] leds: nic78bx: explicitly unregister LEDs at module's shutdown

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

Re: [PATCH 0/8] devm_led_classdev_register() usage problem

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

[PATCH v2 02/10] leds: aw2013: unlock mutex before destroying it

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

[PATCH v2 01/10] devm-helpers: introduce devm_mutex_init

() 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

[PATCH v2 04/10] leds: aw200xx: use devm API to cleanup module's resources

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

[PATCH v2 03/10] leds: aw2013: use devm API to cleanup module's resources

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

[PATCH v2 05/10] leds: lp3952: use devm API to cleanup module's resources

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(+

[PATCH v2 00/10] devm_led_classdev_register() usage problem

] 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

Re: [PATCH v2 01/10] devm-helpers: introduce devm_mutex_init

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

Re: [PATCH v2 02/10] leds: aw2013: unlock mutex before destroying it

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

Re: [PATCH v2 01/10] devm-helpers: introduce devm_mutex_init

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

Re: [PATCH v2 01/10] devm-helpers: introduce devm_mutex_init

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

Re: [PATCH v2 01/10] devm-helpers: introduce devm_mutex_init

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

Re: [PATCH v2 01/10] devm-helpers: introduce devm_mutex_init

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

Re: [PATCH v2 01/10] devm-helpers: introduce devm_mutex_init

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

[PATCH v3 03/11] devm-helpers: introduce devm_mutex_init

() 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

[PATCH v3 02/11] locking: add define if mutex_destroy() is not an empty function

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

[PATCH v3 04/11] leds: aw2013: use devm API to cleanup module's resources

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

[PATCH v3 01/11] leds: aw2013: unlock mutex before destroying it

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

[PATCH v3 00/11] devm_led_classdev_register() usage problem

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

[PATCH v3 11/11] leds: powernv: use LED_RETAIN_AT_SHUTDOWN flag for leds

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

[PATCH v3 07/11] leds: lm3532: use devm API to cleanup module's resources

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

[PATCH v3 05/11] leds: aw200xx: use devm API to cleanup module's resources

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

[PATCH v3 06/11] leds: lp3952: use devm API to cleanup module's resources

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(+

[PATCH v3 10/11] leds: an30259a: use devm_mutext_init for mutext initialization

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 ---

[PATCH v3 09/11] leds: mlxreg: use devm_mutex_init for mutex initializtion

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

[PATCH v3 08/11] leds: nic78bx: use devm API to cleanup module's resources

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

Re: [PATCH v3 03/11] devm-helpers: introduce devm_mutex_init

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 +++

Re: [PATCH v3 04/11] leds: aw2013: use devm API to cleanup module's resources

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

[PATCH v4 04/10] leds: aw200xx: use devm API to cleanup module's resources

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

[PATCH v4 02/10] locking: introduce devm_mutex_init

() 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

[PATCH v4 09/10] leds: an30259a: use devm_mutext_init for mutext initialization

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 ---

[PATCH v4 00/10] devm_led_classdev_register() usage problem

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

[PATCH v4 01/10] leds: aw2013: unlock mutex before destroying it

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

[PATCH v4 05/10] leds: lp3952: use devm API to cleanup module's resources

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(+

[PATCH v4 03/10] leds: aw2013: use devm API to cleanup module's resources

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

[PATCH v4 07/10] leds: nic78bx: use devm API to cleanup module's resources

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

[PATCH v4 10/10] leds: powernv: use LED_RETAIN_AT_SHUTDOWN flag for leds

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

[PATCH v4 08/10] leds: mlxreg: use devm_mutex_init for mutex initializtion

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

[PATCH v4 06/10] leds: lm3532: use devm API to cleanup module's resources

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

Re: [PATCH v4 02/10] locking: introduce devm_mutex_init

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

Re: [PATCH v4 02/10] locking: introduce devm_mutex_init

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

Re: [DMARC error][SPF error] Re: [PATCH v4 00/10] devm_led_classdev_register() usage problem

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()

Re: [DMARC error][SPF error] Re: [PATCH v4 00/10] devm_led_classdev_register() usage problem

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

Re: [DMARC error][SPF error] Re: [PATCH v4 00/10] devm_led_classdev_register() usage problem

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

[PATCH v5 02/10] locking/mutex: introduce devm_mutex_init

() 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

[PATCH v5 00/10] devm_led_classdev_register() usage problem

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

[PATCH v5 07/10] leds: nic78bx: use devm API to cleanup module's resources

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

[PATCH v5 05/10] leds: lp3952: use devm API to cleanup module's resources

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(+

[PATCH v5 09/10] leds: an30259a: use devm_mutext_init for mutext initialization

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 ---

[PATCH v5 04/10] leds: aw200xx: use devm API to cleanup module's resources

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

[PATCH v5 06/10] leds: lm3532: use devm API to cleanup module's resources

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

[PATCH v5 08/10] leds: mlxreg: use devm_mutex_init for mutex initializtion

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

[PATCH v5 03/10] leds: aw2013: use devm API to cleanup module's resources

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

[PATCH v5 01/10] locking/mutex: move mutex_destroy() definition lower

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

[PATCH v5 10/10] leds: powernv: use LED_RETAIN_AT_SHUTDOWN flag for leds

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

Re: [PATCH v5 02/10] locking/mutex: introduce devm_mutex_init

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

Re: [PATCH v5 02/10] locking/mutex: introduce devm_mutex_init

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

Re: [PATCH v5 02/10] locking/mutex: introduce devm_mutex_init

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

Re: [PATCH v5 02/10] locking/mutex: introduce devm_mutex_init

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

Re: [PATCH v5 02/10] locking/mutex: introduce devm_mutex_init

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

[PATCH v6 2/9] leds: aw2013: use devm API to cleanup module's resources

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

[PATCH v6 0/9] devm_led_classdev_register() usage problem

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

[PATCH v6 4/9] leds: lp3952: use devm API to cleanup module's resources

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(+

[PATCH v6 1/9] locking/mutex: introduce devm_mutex_init

() 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

[PATCH v6 6/9] leds: nic78bx: use devm API to cleanup module's resources

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

[PATCH v6 3/9] leds: aw200xx: use devm API to cleanup module's resources

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

[PATCH v6 5/9] leds: lm3532: use devm API to cleanup module's resources

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

[PATCH v6 8/9] leds: an30259a: use devm_mutext_init for mutext initialization

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 ---

[PATCH v6 7/9] leds: mlxreg: use devm_mutex_init for mutex initializtion

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

[PATCH v6 9/9] leds: powernv: use LED_RETAIN_AT_SHUTDOWN flag for leds

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