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.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
