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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFGk_a0U=jSQD85UKC1e=pSWr8W9y_MMAFyPVFOcE-fUZry7-Q@mail.gmail.com>
Date: Fri, 31 Jan 2025 08:25:51 +0100
From: Maciej Borzęcki <maciej.borzecki@...onical.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
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 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