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: <dc2w6gxdp3rhlhy6hvwocp76zdjh4jhdljhoijbub5q76f4xgw@ulfvg2s3rvub>
Date: Mon, 17 Feb 2025 10:17:58 +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: [PATCH v3 00/13] Introduce configfs-based interface for
 gpio-aggregator

On Mon, Feb 17, 2025 at 10:07:03AM GMT, Koichiro Den wrote:
> On Sun, Feb 16, 2025 at 04:56:59PM GMT, Bartosz Golaszewski wrote:
> > On Sun, Feb 16, 2025 at 1:58 PM Koichiro Den <koichiro.den@...onical.com> wrote:
> > >
> > > This patch series introduces a configfs-based interface to gpio-aggregator
> > > to address limitations in the existing 'new_device' interface.
> > >
> > > The existing 'new_device' interface has several limitations:
> > >
> > >   Issue#1. No way to determine when GPIO aggregator creation is complete.
> > >   Issue#2. No way to retrieve errors when creating a GPIO aggregator.
> > >   Issue#3. No way to trace a GPIO line of an aggregator back to its
> > >            corresponding physical device.
> > >   Issue#4. The 'new_device' echo does not indicate which virtual
> > >            gpiochip<N> was created.
> > >   Issue#5. No way to assign names to GPIO lines exported through an
> > >            aggregator.
> > >
> > > Although Issue#1 to #3 could technically be resolved easily without
> > > configfs, using configfs offers a streamlined, modern, and extensible
> > > approach, especially since gpio-sim and gpio-virtuser already utilize
> > > configfs.
> > >
> > > This v3 patch series includes 13 patches:
> > >
> > >   Patch#1-7: Prepare for Patch#8
> > >              * #1: Prepare for the following patches.
> > >              * #2: Fix an issue that was spotted during v3 preparation.
> > >              * #3: Add gpio-pseudo.[ch] to reduce code duplications.
> > >              * #4: Update gpio-sim to use gpio-pseudo.[ch].
> > >              * #5: Update gpio-virtuser to use gpio-pseudo.[ch].
> > >              * #6: Update gpio-aggregator to use gpio-pseudo.[ch].
> > >              * #7: Add aggr_alloc() to reduce code duplication.
> > 
> > Please don't ram this new functionality into an unrelated series.
> > Split it into the gpio-pseudo code, factoring out common parts and
> > converting existing drivers, then send the aggregator series saying it
> > depends on the former. Otherwise it gets way too complex to review.
> 
> Ok, I'll do so.
> Thanks,

Should Patch#2 also be split off into another submission?

Koichiro

> 
> Koichiro
> 
> > 
> > Bartosz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ