Hello,
On Fri, Apr 08, 2016 at 08:07:51AM +0200, Yegor Yefremov wrote:
> We have basically two issues, where up->gpios is NULL could be very useful.
>
> 1. the problem with console, i.e. when mctrl API is used before
> mctrl_gpio_init()
Either mctrl_gpio should be able to control the handshaking lines, or
it's not important and can be skipped. In the first case you have to
ensure that mctrl_gpio_init is called before. In the second, don't even
try and don't use mctrl_gpio.
> 2. systems configured without GPIOLIB. In this case mctrl_gpio_init()
> returns ERR_PTR(-ENOSYS)
>
> static inline
> struct mctrl_gpios *mctrl_gpio_init(struct uart_port *port, unsigned int idx)
> {
> return ERR_PTR(-ENOSYS);
> }
>
> And this is deadly for a console device.
And consequently so. If it's important that the handshaking lines are
working in console mode and you don't know if they do (because GPIOLIB
is off), what do you suggest?
Maybe select GPIOLIB (but that won't work for all platforms I think)?
> I'd suggest, that mctrl_gpio_init() returns either NULL or real
> pointer, if everything could be initialized properly.
It does always return a real pointer then. (If GPIOLIB is off,
mctrl_gpio_init cannot be sure that everything was properly initialized,
so it returns an error code. The same holds true for the gpiod functions
btw.)
> mctrl_gpio_init() should report all errors via dev_err. This way, if
> mctrl API is not working, one can at least find the cause in dmesg.
I'm open for patches that implement this.
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
