lkml.org 
[lkml]   [2022]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 02/13] leds: el15203000: Fix devm vs. non-devm ordering
From
Date
Hello Wang,

> 11 лист. 2022 р. о 11:21 wangyufen <wangyufen@huawei.com> написав(ла):
>
>
> 在 2022/11/9 18:43, Oleh Kravchenko 写道:
>>
>>
>>> 9 лист. 2022 р. о 12:25 wangyufen <wangyufen@huawei.com> написав(ла):
>>>
>>>
>>> 在 2022/11/9 17:39, Oleh Kravchenko 写道:
>>>
>>>>> -static void el15203000_remove(struct spi_device *spi)
>>>>>
>>>> Is remove() callback from struct spi_driver deprecated?
>>>>
>>> It is not that remove() callback is deprecated,
>>> it's that after wrapping mutex_destroy() call with devm_add_action_or_reset(),
>>> remove() callback is unnecessary here.
>>>
>> When remove() is called, the memory allocated by devm_*() is valid.
>> So what you try to fix here?
>
> Fix the &priv->lock used after destroy, for details, please see patch #0
> LKML: Wang Yufen: [PATCH 00/13] leds: Fix devm vs. non-devm ordering

It doesn’t make any sense for me.
You saying that remove() called before devm_* allocation
if it true then set_brightness_delayed() will crash the system in anyway.

LED device has a parent SPI device; LED device can’t exist without SPI device.

So deallocation order should be next:
1. LED device devm_*()
2. SPI device remove()

\
 
 \ /
  Last update: 2022-11-11 11:40    [W:0.068 / U:2.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site