On Friday 25 July 2014 00:04:58 Alexandre Courbot wrote: > 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? There is a trick that we sometime use in this situation, though it has to be done carefully: > diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt > index 7ff30d2..a3fb1d7 100644 > --- a/Documentation/gpio/consumer.txt > +++ b/Documentation/gpio/consumer.txt > @@ -29,13 +29,24 @@ gpiod_get() functions. Like many other kernel subsystems, gpiod_get() takes the > device that will use the GPIO and the function the requested GPIO is supposed to > fulfill: > > - struct gpio_desc *gpiod_get(struct device *dev, const char *con_id) > + struct gpio_desc *gpiod_get(struct device *dev, const char *con_id, > + enum gpio_flags flags) > > - struct gpio_desc *gpiod_get(struct device *dev, const char *con_id) + struct gpio_desc *__gpiod_get(struct device *dev, const char *con_id, + enum gpio_flags flags); + +#define __gpiod_get(dev, con_id, flags, ...) __gpiod_get(dev, con_id, flags) +#define gpiod_get(varargs ...) __gpiod_get(varargs, 0) This will allow both variants to be called, and any users of the three-argument version will pass zero as the fourth argument (or whatever you choose there). Once the conversion is complete, the macros can be removed. ARnd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
