[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55AEC50E.3030202@roeck-us.net>
Date: Tue, 21 Jul 2015 15:17:50 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.com>, linux-serial@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-cris-kernel@...s.com,
Jesper Nilsson <jesper.nilsson@...s.com>
Subject: Re: [PATCH -next] serial: etraxfs-uart: Update gpiod API
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@...gutronix.de>
>> Signed-off-by: Guenter Roeck <linux@...ck-us.net>
> 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) ?
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists