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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to