[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=MfmMhZ0CS=e-YNHdH49rZ=Qgr8rQKd4aYCfS3jh8qKLdg@mail.gmail.com>
Date: Fri, 31 Jan 2025 18:07:50 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Maciej Borzęcki <maciej.borzecki@...onical.com>
Cc: Koichiro Den <koichiro.den@...onical.com>, linux-gpio@...r.kernel.org,
geert+renesas@...der.be, linus.walleij@...aro.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] Introduce configfs-based interface for gpio-aggregator
On Fri, Jan 31, 2025 at 8:26 AM Maciej Borzęcki
<maciej.borzecki@...onical.com> wrote:
>
> On Thu, 30 Jan 2025 at 21:48, Bartosz Golaszewski <brgl@...ev.pl> wrote:
> >
> > On Thu, Jan 30, 2025 at 7:40 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> > >
> > > While at it: there's no reason to impose a
> > > naming convention of lineX, lineY etc., the names don't matter for the
> > > aggregator setup (unlike gpio-sim where they indicate the offset of
> > > the line they concern).
> > >
> >
> > Scratch that part. There's a good reason for that - the ordering of
> > lines within the aggregator. I'm just not sure whether we should
> > impose a strict naming where - for an aggregator of 3 lines total - we
> > expect there to exist groups named line0, line1 and line2 or if we
> > should be more lenient and possibly sort whatever names the user
> > provides alphabetically?
>
> If I may jump in quickly (I provided some initial feedback on the
> configfs interfaces
> for the first internal patches). I think it's preferable to have
> strict and explicit, even
> If more verbose, line ordering in the aggregator.The motivator for
> this is that whoever
> sets up a new device through the aggregator does not have to second guess what
> the driver will do. Implicit ordering could perhaps be fine if the
> consumers were to
> impose some set of rules themselves, but I fear there would still be
> some ambiguity
> left if free form names were for e.g. [1, 02, 10]. In the end they
> would probably settle
> on some mechanism which would mimic what we could already do in the
> driver itself
> and avoid any further confusion for the user.
>
> Cheers,
> Maciej
Fair enough, I was thinking that just sorting the entries
alphabetically would both allow the lineX scheme AND leave some leeway
for non-standard naming but it may indeed end up being confusing with
no apparent advantage.
Bart
Powered by blists - more mailing lists