On Thu, 24 Jul 2014, Greg Kroah-Hartman wrote:
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@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 :)
+99999