[PATCH] gpio: extend gpiod_get*() with flags parameter

Greg Kroah-Hartman gregkh at linuxfoundation.org
Thu Jul 24 09:10:52 PDT 2014


On Fri, Jul 25, 2014 at 12:04:58AM +0900, Alexandre Courbot wrote:
> The huge majority of GPIOs have their direction and initial value set
> right after being obtained by one of the gpiod_get() functions. The
> integer GPIO API had gpio_request_one() that took a convenience flags
> parameter allowing to specify an direction and value applied to the
> returned GPIO. This feature greatly simplifies client code and ensures
> errors are always handled properly.
> 
> A similar feature has been requested for the gpiod API. Since GPIOs need
> a direction to be used anyway, we prefer to extend the existing
> functions instead of introducing new functions that would raise the
> number of gpiod getters to 16 (!).
> 
> The drawback of this approach is that all gpiod clients need to be
> updated, but there aren't that many and the moment and this results in
> smaller (and hopefully safer) code.
> 
> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com>
> ---
> This change will be difficult to apply without breaking things, but
> let's try to do it right. Hopefully the benefit will outweight the
> disturbance.
> 
> This is a patch against -next to list and update all current gpiod
> consumers. Updates are trivial at first sight, but it would be nice to
> get as many acks as possible from the respective subsystem maintainers.
> 
> I'm not sure how this could be applied harmlessly though - maybe through
> a dedicated branch for -next? Problem is that a lot of new code is not
> yet merged into mainline, and conflicts are very likely to occur. Linus,
> do you have any suggestion as to how this can be done without blood being
> spilled?

Do this in 3 steps, not all at once.

Make a new function that takes the new argument, get that merged

Submit patches that convert drivers over to use the new function.

Once all of those are merged, remove the old function.

That way there are no "flag days" needed, and everyone is happy you
don't send out emails with 40+ people in the To: and Cc: lines :)

thanks,

greg k-h


More information about the dri-devel mailing list