Re: [RFC PATCH 0/2] Introduce configfs-based interface for gpio-aggregator

[Bartosz Golaszewski]

On Fri, Jan 31, 2025 at 8:26 AM Maciej Borzęcki
<maciej.borzecki@xxxxxxxxxxxxx> wrote:
>
> On Thu, 30 Jan 2025 at 21:48, Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> >
> > On Thu, Jan 30, 2025 at 7:40 PM Bartosz Golaszewski <brgl@xxxxxxxx> 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