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;
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.
Thanks.
--
Dmitry
--
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
