Re: [PATCH 3/4] mmc: host: switch OF parser to use gpio descriptors

[Simon Baatz <gmbnomis@gmail.com>]

Hi Linus,

On Tue, Aug 12, 2014 at 07:25:54PM +0200, Linus Walleij wrote:
> This switches the central MMC OF parser to use gpio descriptors
> instead of grabbing GPIOs explicitly from the device tree.
> This strips out an unecessary use of the integer-based GPIO
> API that we want to get rid of, cuts down on code as the
> gpio descriptor code will handle active low flags.
> 
> As it is in no way a bug not to supply CD/WP GPIOs the messages
> about them not being specified have been depromoted from
> dev_err() to dev_dbg().

I think the intention of the current code is to issue an
error if a valid GPIO was specified but could not be obtained.  It
should not issue an error just because the CD/WP GPIOs are not
specified.

This patch changes this behaviour. If the GPIO is specified
explicitly but cannot be obtained for some reason, the driver's probe
calling mmc_of_parse() will probably be successful.  Since debug
level messages are usually not enabled, the problem with the GPIO may
not even be visible in the logs.  For example, if I specify the same
GPIO for CD and WP in the DTS:

[    2.093442] kirkwood-pinctrl f1010000.pin-controller: request pin
44 (PIN44) for mvebu-gpio:44
[    2.093459] mvsdio f1090000.mvsdio: Got CD GPIO
[    2.118734] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with
MAC address 00:50:43:c3:55:55

One can only infer from the missing "Got WP GPIO" that something went
wrong.  Previously, the driver would not even load:

...
[    1.973402] mvsdio f1090000.mvsdio: Failed to request WP GPIO: -16!
[    1.979831] mvsdio: probe of f1090000.mvsdio failed with error -16

One can argue whether the current behaviour is too strict (and we did
that in the past, leading to the current code), but issuing only a
debug message when allocating an explicitly requested resource fails
is too tolerant, IMHO.


- Simon