Re: [PATCH v2 1/2] input: rotary-encoder: switch to devm_* allocation of GPIOs and IRQs

[Daniel Mack <zonque@gmail.com>]

On 25.07.2012 18:29, Dmitry Torokhov wrote:
> On Wed, Jul 25, 2012 at 06:07:24PM +0200, Daniel Mack wrote:
>> On 25.07.2012 18:05, Dmitry Torokhov wrote:
>>> On Wed, Jul 25, 2012 at 09:43:47AM +0200, Daniel Mack wrote:
>>>> @@ -263,12 +243,7 @@ exit_free_mem:
>>>>  static int __devexit rotary_encoder_remove(struct platform_device *pdev)
>>>>  {
>>>>  	struct rotary_encoder *encoder = platform_get_drvdata(pdev);
>>>> -	struct rotary_encoder_platform_data *pdata = pdev->dev.platform_data;
>>>>  
>>>> -	free_irq(encoder->irq_a, encoder);
>>>> -	free_irq(encoder->irq_b, encoder);
>>>> -	gpio_free(pdata->gpio_a);
>>>> -	gpio_free(pdata->gpio_b);
>>>>  	input_unregister_device(encoder->input);
>>>
>>> Another botched devm_ conversion. *sigh*
>>>
>>> Input device gone, IRQ arrives, kernel goes oops, machine hangs hard.
>>>
>>> Please, do not use devm_ interfaces unless... Actually, just do not use
>>> nor suggest devm_interfaces until all resources are devm-ized. Mixing 2
>>> styles of releasing resources leads to trouble.
>>
>> Ok, makes sense. Thanks for noticing. Are you happy with the first
>> version I submitted then?
> 
> I have a few issues with that version as well:
> 
> 1. It writes over platform_data field in the device which does nto
> belong to the driver (this field belongs to the platform/board code);
> 
> 2. I believe we should favor kernel supplied data over firmware
> allowing users to override DT bindings, if needed;

Ok, this is different from what I saw in other drivers, but I'm fine
with that.

> 3. It still uses devm_* to allocate memory and as I said I do not like
> mixing 2 styles of managign resources in one driver.

Ok, sorry again. I didn't closely follow that new development, hence I
wasn't aware of these pitfalls.

New patch series coming up.