Sorry, I'm traveling and it's been rather busy.
I thought about this some more, and I've realized that the devm_kfree()
calls are probably still a good idea. Those are associated with the
device, not the LED.
For instance, I noticed that on a failure in the probe code the probe
code would get ca
On Thu, Mar 26, 2015 at 8:08 PM, Corey Minyard wrote:
> On 03/26/2015 08:20 PM, Bryan Wu wrote:
>> On Mon, Mar 9, 2015 at 5:43 PM, wrote:
>>> From: Corey Minyard
>>>
>>> The leds-gpio driver would not clean up properly if it failed in some
>>> places, and it wasn't freeing its private data.
>>>
On 03/26/2015 08:20 PM, Bryan Wu wrote:
> On Mon, Mar 9, 2015 at 5:43 PM, wrote:
>> From: Corey Minyard
>>
>> The leds-gpio driver would not clean up properly if it failed in some
>> places, and it wasn't freeing its private data.
>>
>> Signed-off-by: Corey Minyard
>> ---
>> drivers/leds/leds-
On Mon, Mar 9, 2015 at 5:43 PM, wrote:
> From: Corey Minyard
>
> The leds-gpio driver would not clean up properly if it failed in some
> places, and it wasn't freeing its private data.
>
> Signed-off-by: Corey Minyard
> ---
> drivers/leds/leds-gpio.c | 13 +
> 1 file changed, 9 ins
Ping. This is a rather obvious fix and can result in an oops.
-corey
On 03/09/2015 07:43 PM, miny...@acm.org wrote:
> From: Corey Minyard
>
> The leds-gpio driver would not clean up properly if it failed in some
> places, and it wasn't freeing its private data.
>
> Signed-off-by: Corey Minyard
From: Corey Minyard
The leds-gpio driver would not clean up properly if it failed in some
places, and it wasn't freeing its private data.
Signed-off-by: Corey Minyard
---
drivers/leds/leds-gpio.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/leds/led
6 matches
Mail list logo
