[PATCH 1/2] mmc: slot-gpio: use devm_* managed functions to ease users

[Shawn Guo]

On Fri, Dec 07, 2012 at 02:49:43PM +0100, Guennadi Liakhovetski wrote:
> Hi Shawn
> 
> On Fri, 7 Dec 2012, Shawn Guo wrote:
> 
> > Use devm_* managed functions, so that slot-gpio users do not have to
> > call mmc_gpio_free_ro/cd to free up resources requested in
> > mmc_gpio_request_ro/cd.
> > 
> > Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> 
> Thanks for the patch, but I'm not sure this is a good idea. Firstly, using 
> devm_* allocation functions means, that normally you don't have to free 
> these resources explicitly any more. So, actually you would have to remove 
> free_irq() and gpio_free() calls completely from the API instead of 
> replacing them with devm_* analogs.

With the changes, most of the slot-gpio users will only need to call
mmc_gpio_request_* functions at probe time, nothing else.  That said,
they will not call mmc_gpio_free_* functions at all.  I patched
mmc_gpio_free_* functions replacing free_irq() and gpio_free() with
devm_* versions to 1) ease the migration of exiting users calling
mmc_gpio_free_*; 2) provide a mean for users to manually free resources
for whatever reasons.

> Secondly, I do use devm_kzalloc() in 
> the API because I really want that allocated memory to just be allocated 
> once and stay there until the device is freed. Whereas with with card 
> detection and write-protect pins - usually you're right, you would only 
> allocate those once during the lifetime of your host device. But - are we 
> sure there cannot be exceptions? What if someone decides to switch between 
> CD-IRQ and CD-polling at runtime? Or do something equally weird with their 
> GPIOs... At least I personally don't think I have sufficient knowledge of 
> all possible configurations to make such a decision. Think about pinctrl 
> etc. What if at runtime the CD pin has to be released by mmc to be used 
> by some other device?

mmc_gpio_request_* and mmc_gpio_free_* pair are still there anyway.
Users can manually call them in any way they want.

> Anyway, I'm fine either way, but I'm just not sure 
> how reasonable this change is.

My intension is to save slot-gpio users from checking GPIO CD/WP cases
and calling mmc_gpio_request_* functions, so that we can have a cleaner
.probe error path and .remove function.

Shawn