Hello Geert,

On Mon, Mar 06, 2017 at 10:09:50AM +0100, Geert Uytterhoeven wrote:

On Mon, Mar 6, 2017 at 9:58 AM, Uwe Kleine-K?nig
[off-list ref] wrote:

quoted

On Mon, Mar 06, 2017 at 09:49:39AM +0100, Geert Uytterhoeven wrote:

quoted

quoted

Given that mctrl-gpio can be useful on legacy platforms, a device could
silently run without cts-gpio even there.

On platforms were CONFIG_GPIOLIB=n, this is not true, so the issue is moot.

All serial drivers using (optional) mctrl-gpio have this in Kconfig:

    select SERIAL_MCTRL_GPIO if GPIOLIB

So they will use mctrl-gpio when GPIOLIB is enabled.
If GPIOPLIB is disabled, no flow control GPIOs are expected, and the
driver should not break that case.

So it all boils down to the question: Is GPIOLIB=n enough to assume no
gpio is needed?

I'd say it is not.

How does the platform register these GPIOs when GPIOPLIB is not enabled by
the platform, and gpiod_add_lookup_table() is thus not available?

Obviously the platformcode cannot. In this case you could argue that
platformcode shouldn't register the device if a gpio is necessary. But
this reasoning doesn't work for (DT=y || ACPI=y) && GPIOLIB=n.

I wouldn't want to code this in each driver (something like:

	if (IS_ENABLED(GPIOLIB) || device_is_instantiated_by_dt(dev) || device_is_instantiated_by_acpi(dev))
		gpios = mctrl_gpio_init(...);
	else
		gpios = NULL;

). Putting this into GPIOLIB is the right approach, and so this is
another argument for HALFGPIOLIB. This would fix mctrl_gpio_init en
passant.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |