On 07/22/2015 09:06 AM, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Jul 21, 2015 at 03:17:50PM -0700, Guenter Roeck wrote:
>> On 07/21/2015 02:01 PM, Uwe Kleine-König wrote:
>>> On Tue, Jul 21, 2015 at 01:34:52PM -0700, Guenter Roeck wrote:
>>>> Commit b17d1bf16cc7 ("gpio: make flags mandatory for gpiod_get functions")
>>>> makes the flags argument to devm_gpiod_get_optional mandatory but does not
>>>> update all users. This results in the following build error.
>>>>
>>>> drivers/tty/serial/etraxfs-uart.c:933:16: error:
>>>> too few arguments to function ‘devm_gpiod_get_optional’
>>>>
>>>> Fixes: b17d1bf16cc7 ("gpio: make flags mandatory for gpiod_get functions")
>>>> Cc: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
>>>> Signed-off-by: Guenter Roeck <linux@xxxxxxxxxxxx>
>>> We discussed this driver while I worked on updating the gpiod API. I
>>> don't care much about this driver, but if you want to do something about
>>> the build failure, I'd prefer:
>>>
>>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>>> index 76e65b714471..3a6a7c235f09 100644
>>> --- a/drivers/tty/serial/Kconfig
>>> +++ b/drivers/tty/serial/Kconfig
>>> @@ -1066,6 +1066,7 @@ config SERIAL_VT8500_CONSOLE
>>> config SERIAL_ETRAXFS
>>> bool "ETRAX FS serial port support"
>>> depends on ETRAX_ARCH_V32 && OF
>>> + depends on BROKEN
>>> select SERIAL_CORE
>>>
>>> config SERIAL_ETRAXFS_CONSOLE
>>>
>>> Best regards
>>> Uwe
>>>
>>
>> Uwe,
>>
>> I understand the value of BROKEN, but I do not think it would be
>> appropriate here. It would be appropriate for a driver which is really
>> broken, not one that doesn't build anymore because an API it uses
>> was updated and the driver code wasn't updated for some reason.
>>
>> With your suggested patch I would no longer be able to run my qemu tests
>> for this architecture, which I would not entirely be happy about.
>>
>> You may not care, but maybe others do.
>>
>> Makes me wonder: It used to be that API changes were handled by those
>> making the API changes, not by those responsible for the code using
>> the API. Has this changed recently, ie is it now acceptable to not
>> update all callers of a modified API (on purpose, as it looks like
>> it was done here) ?
> While I stumbled over the calls to gpiod_get variants in the etraxfs
> serial driver I noticed several problems with that driver. I pointed
> them out in
>
> http://www.spinics.net/lists/linux-serial/msg17794.html
>
> . If you read the follow-ups Jesper Nilsson then said:
>
> I can push a patch that just drops all signal handling (since
> it's bogus ATM), or you can ignore the driver as currently
> implemented.
>
> I explicitly did the latter. Apart from that single driver I fixed all
> users. @Jesper: You said you poked Niklas to care for that. Any news
> from that front?
I've talked to Rabin Vincent, who has created an extraxfs gpio driver
that supports gpiolib (will come with 4.2).
Because of that, it might be nice to keep the modem control stuff.
The proper fix is probably to remove the devm_gpiod_get_optional calls
and instead use the serial_mctrl_gpio.c API.
I'll cook a patch this weekend.
>
> I'm all for the usual habit that API changes should be handled by the
> API changer. But if the code was already relying on undefined behaviour
> before the change and fixing that needs testing on the respective
> hardware, I think pushing the needed work back to the driver owner is
> fine. IMHO a simple build fix that doesn't fix the brokeness isn't that
> helpful here.
>
> Having said that I don't care for that driver. So if you say it's good
> enough for you to simply add GPIOD_ASIS and the responsible maintainers
> are ok, too, I won't stand in the way.
>
> Best regards
> Uwe
>
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
