It's been two years since we introduced the v2 uAPI and
the major consumer libgpiod is at v2.1.

What about discouraging the old uAPI?

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/gpio/Kconfig | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 913948876c93..65c9914ee3fa 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -85,7 +85,7 @@ config GPIO_CDEV
 
 config GPIO_CDEV_V1
 	bool "Support GPIO ABI Version 1"
-	default y
+	default n
 	depends on GPIO_CDEV
 	help
 	  Say Y here to support version 1 of the GPIO CDEV ABI.
@@ -93,8 +93,6 @@ config GPIO_CDEV_V1
 	  This ABI version is deprecated.
 	  Please use the latest ABI for new developments.
 
-	  If unsure, say Y.
-
 config GPIO_GENERIC
 	depends on HAS_IOMEM # Only for IOMEM drivers
 	tristate

---
base-commit: e392ea4d4d00880bf94550151b1ace4f88a4b17a
change-id: 20231103-no-y-uapi1-default-4204e86c04a3

Best regards,
-- 
Linus Walleij <linus.walleij@linaro.org>

On Sat, Nov 04, 2023 at 11:54:40PM +0100, Linus Walleij wrote:
> It's been two years since we introduced the v2 uAPI and
> the major consumer libgpiod is at v2.1.

> What about discouraging the old uAPI?

...

> -	default y
> +	default n

'n' _is_ the default 'default', just drop a line.

-- 
With Best Regards,
Andy Shevchenko

On Sat, Nov 04, 2023 at 11:54:40PM +0100, Linus Walleij wrote:
> It's been two years since we introduced the v2 uAPI and
> the major consumer libgpiod is at v2.1.
>

Believe it or not, it is nearly three years.  But libgpiod support for
it, added in v2.x, is less than one year old, and migrating from libgpiod
v1 to v2 is non-trivial as their APIs are very different.
So I would not be surprised to find that the major consumer of the uAPI
remains users of libgpiod v1.x - which requires the old uAPI.

> What about discouraging the old uAPI?
>

If you want to provide the end user with two years to migrate, and given
that libgpiod is the major consumer, you might want to hold off for
another year.

OTOH, if distros/users want to continue including/using libgpiod v1 they
can always re-enable GPIO_CDEV_V1, so I'm not completely against the idea
- just be aware that it may be more disruptive than you might expect.

Cheers,
Kent.

On Sun, Nov 5, 2023 at 2:12 AM Kent Gibson <warthog618@gmail.com> wrote:

> If you want to provide the end user with two years to migrate, and given
> that libgpiod is the major consumer, you might want to hold off for
> another year.

OK then, just testing the waters.

Probably we need to encourage libgpiod 2.x a bit.

Yours,
Linus Walleij

On Sun, Nov 5, 2023 at 4:39 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Sun, Nov 5, 2023 at 2:12 AM Kent Gibson <warthog618@gmail.com> wrote:
>
> > If you want to provide the end user with two years to migrate, and given
> > that libgpiod is the major consumer, you might want to hold off for
> > another year.
>
> OK then, just testing the waters.
>
> Probably we need to encourage libgpiod 2.x a bit.
>

Thanks to Phil Howard's work on python bindings, they should soon be
more widely adopted. They are now the first thing that pops up in
google when searching for "libgpiod python" and now have a proper
homepage in pypi. Running 'pip3 install gpiod' will now work on
systems with no libgpiod installed too as it's vendored with libgpiod
v2.1 sources. I also plan to finally get around to using breathe and
exhale to produce proper sphinx docs. So hopefully we'll start getting
traction soon.

Bart