[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFLxGvzBBon3uJ_WyD95UgbT6sORB4mRci6v4PN=5cz34T6xmA@mail.gmail.com>
Date: Sat, 31 Aug 2024 09:32:48 +0200
From: Richard Weinberger <richard.weinberger@...il.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, Andreas Kemnade <andreas@...nade.info>, grygorii.strashko@...com,
ssantosh@...nel.org, khilman@...nel.org, linux-omap@...r.kernel.org,
linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gpio: omap: use dynamic allocation of base
Linus,
On Sat, Aug 31, 2024 at 12:47 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Thu, Aug 29, 2024 at 10:52 AM Richard Weinberger
> <richard.weinberger@...il.com> wrote:
>
> > > This could potentially break some legacy user-space programs using
> > > sysfs but whatever, let's apply it and see if anyone complains.
> >
> > FWIW, this broke users pace on my side.
> > Not a super big deal, I'll just revert this patch for now.
> > Maybe the application in question can get rewritten to find the gpio by label.
>
> Ugh we might need to back this out if the userspace is critical
> and you need it.
>
> Ideally userspace should use libgpiod for GPIO access, but I understand
> if it's a higher bar.
In the meanwhile I've explained to everyone involved on the project
that gpiod is the way
to go and the application will get changed. So, no worries. :-)
But I'm not sure about other applications in the wild, writing a
number to /sys/class/gpio/export is just too easy
and people assume the numbers are stable.
--
Thanks,
//richard
Powered by blists - more mailing lists