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) ? Thanks, Guenter -- 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
