Re: [PATCH][RESEND] gpiolib: rename gpiod_set_array to gpiod_set_array_value

[Alexandre Courbot <gnurou@xxxxxxxxx>]

On Mon, Jun 8, 2015 at 4:17 PM, Rojhalat Ibrahim <imr@xxxxxxxxxxx> wrote:
> On Monday 08 June 2015 15:46:44 Alexandre Courbot wrote:
>> On Mon, Jun 8, 2015 at 2:37 PM, Alexandre Courbot <gnurou@xxxxxxxxx> wrote:
>> > On Mon, Jun 1, 2015 at 8:41 PM, Rojhalat Ibrahim <imr@xxxxxxxxxxx> wrote:
>> >> There have been concerns that the function names gpiod_set_array() and
>> >> gpiod_get_array() might be confusing to users. One might expect
>> >> gpiod_get_array() to return array values, while it is actually the array
>> >> counterpart of gpiod_get(). To be consistent with the single descriptor API
>> >> gpiod_set_array() is renamed to gpiod_set_array_value().
>> >
>> > Linus, if you are ok with this change I suggest we merge it early in
>> > order to avoid conflicts as more people start using these APIs! :)
>>
>> Actually, Rojhalat: could you define temporary macros to ease the
>> transition? Something like
>>
>> #define gpiod_set_raw_array gpiod_set_raw_array_value
>>
>> We would then take them out around 4.2, once all consumers are converted.
>>
>
> Hi Alexandre,
>
> Linus already applied the patch. (He replied to my original RFC mail.)

Ah, that's perfect then. Sorry for the noise.

> I am not sure those temporary macros are justified. Do you really think
> there are that many out-of-tree consumers? And if so, how would we know
> when all of them have converted to the new interface? After all with those
> macros around, they might not even notice they are using a deprecated
> interface.

My intention was to avoid in-tree breakage with linux-next (we do not
worry about out-of-tree consumers since they can easily update their
code. And they are out-of-tree anyway). But if the patch has already
been merged and is working, then I have no concern at all.

Thanks for keeping up with this!
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html