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

On 25.07.2012 18:29, Dmitry Torokhov wrote:

On Wed, Jul 25, 2012 at 06:07:24PM +0200, Daniel Mack wrote:

quoted

On 25.07.2012 18:05, Dmitry Torokhov wrote:

quoted

On Wed, Jul 25, 2012 at 09:43:47AM +0200, Daniel Mack wrote:

quoted

@@ -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.