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'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
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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
