Message-ID: <xrllvn5tmshdbb2mjlxvoc4rpalnefy52wwd5p6s55ehhysl4l@k4w42cd7hxkn>
Date: Sat, 1 Feb 2025 21:26:27 +0900
From: Koichiro Den <koichiro.den@...onical.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: linux-gpio@...r.kernel.org, geert+renesas@...der.be, 
	linus.walleij@...aro.org, maciej.borzecki@...onical.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] Introduce configfs-based interface for
 gpio-aggregator

On Fri, Jan 31, 2025 at 06:22:50PM GMT, Bartosz Golaszewski wrote:
> On Fri, Jan 31, 2025 at 3:36 PM Koichiro Den <koichiro.den@...onical.com> wrote:
> >
> > On Thu, Jan 30, 2025 at 09:47:47PM GMT, Bartosz Golaszewski wrote:
> > > On Thu, Jan 30, 2025 at 7:40 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> > > >
> >
> > (Small reply to the previous comment:)
> > Yes, I understand your point about why you think 'num_lines' is
> > unnecessary. What I meant was more of a UX (User eXperience) consideration.
> >
> 
> If anything this sounds like worse user experience - having to provide
> duplicate information.
> 
> > > > 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. [...]
> >
> > You're right, that's exactly the intention of the strict naming, 'line0',
> > 'line1', ..., 'line<Y>'.
> >
> > > [...] 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?
> >
> > As Maciej pointed out:
> >
> >   (https://lore.kernel.org/all/CAFGk_a0U=jSQD85UKC1e=pSWr8W9y_MMAFyPVFOcE-fUZry7-Q@mail.gmail.com/#t)
> >   > [...] if free form names were for e.g. [1, 02, 10].
> >
> > we would need a well-defined rule to avoid ambiguity, which could
> > potentially unnecessarily impose burden on users to understand how to
> > properly use the interface.
> >
> >
> > Regardless, the point is that we need to make it clear to users which GPIO
> > line a specific line<Y> of an aggregator forwards operations to. Since
> > requiring users to explicitly set the offset within the aggregator for each
> > virtual line (e.g. besides 'key'/'offset'/'name' attributes, by adding
> > 'idx' attribute, which users would need to set explicitly) would be
> > cumbersome, this RFC implementation instead just makes use of directory
> > naming. I believe we agree on this approach (i.e., using directory naming
> > to establish ordering). Correct me if I'm wrong.
> >
> > So, to move forward, let me outline the possible approaches we can take:
> >
> > Option (a). Drop 'num_lines' attribute and:
> >
> >   (a-1). Impose strict naming rule for line directories
> >
> >          Users can only create directories with a predefined naming
> >          convention. This could be 'line0', 'line1', ... 'line<Y>' (as in
> >          the RFC implementation), or simply '0', '1', ..., '<Y>'.
> >
> >   (a-2). Allow arbitrary naming for line directories
> >
> >          This would require a well-defined rule to avoid ambiguity. As
> >          Maciej pointed out:
> >
> >          (from https://lore.kernel.org/all/CAFGk_a0U=jSQD85UKC1e=pSWr8W9y_MMAFyPVFOcE-fUZry7-Q@mail.gmail.com/#t)
> >          > if free form names were for e.g. [1, 02, 10]
> >
> >          Users would need to understand these rules, which might impose
> >          unnecessary burden on users.
> >
> > Option (b). Keep 'num_lines' attribute but:
> >
> >     (b-1). Prohibit manual creation of line directories
> >
> >            Users would no longer run 'mkdir line0', etc. Instead, writing
> >            <Y+1> (Y >= 0) to 'num_lines' would automatically set up the
> >            required directories.  convention. This could be 'line0',
> >            'line1', ... 'line<Y>' (as in this RFC implementation), or
> >            simply '0', '1', ..., '<Y>'.
> >
> >     (b-2). Keep manual 'mkdir' for each line, in the same manner as (a-1)
> >            (as in the RFC implementation) or (a-2). Seems that no-one is
> >            favor of this option.
> >
> >
> >     Note: (b-1) is a new idea. Considering what really needs to be
> >     configured by users, this could be the least burdensome and simplest,
> >     especially when configuring many lines. I'm including it here for
> >     broader discussion.
> >
> > Personally, now I'm inclined towards (a-1) with the simplest naming scheme:
> > non-zero-padded integers ('./0', './1', './2', ..., './<Y>'). Or even (b-1).
> >
> 
> I too think a-1 is the best option. However, I'd go for line0, line1
> etc. convention as for computers it doesn't make any difference while
> for humans it's more readable.

Thank you for the comments. I’ll address your feedbacks and send "v2"
later, Since we seem to agree on the overall approach, I’ll send it as
[PATCH v1] (i.e., without the "RFC").

-Koichiro

> 
> Bartosz
> 
> > Let me know your thoughts.
> >
> > Thanks.
> >
> > -Koichiro
> >
> > >
> > > Bart

Powered by blists - more mailing lists