linux-kernel - Re: [PATCH v3 2/3] gpio: vortex: add new GPIO device driver

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: <20250822154718.GA685150@bhelgaas>
Date: Fri, 22 Aug 2025 10:47:18 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Marcos Del Sol Vives <marcos@...a.pet>
Cc: linux-kernel@...r.kernel.org, Linus Walleij <linus.walleij@...aro.org>,
	Bartosz Golaszewski <brgl@...ev.pl>,
	Michael Walle <mwalle@...nel.org>, Lee Jones <lee@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>, linux-gpio@...r.kernel.org,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH v3 2/3] gpio: vortex: add new GPIO device driver

On Thu, Aug 21, 2025 at 07:05:16PM +0200, Marcos Del Sol Vives wrote:
> El 21/08/2025 a las 12:18, Marcos Del Sol Vives escribió:
> > +#include <linux/types.h>
> > +#include <linux/errno.h>
> > +#include <linux/module.h>
> > +#include <linux/ioport.h>
> > +#include <linux/spinlock.h>
> > +#include <linux/gpio/driver.h>
> > +#include <linux/gpio/regmap.h>
> > +#include <linux/regmap.h>
> > +#include <linux/ioport.h>
> > +#include <linux/types.h>
> > +#include <linux/platform_device.h>
> 
> I realized now that, despite checking over and over the patches before
> sending to the mailing list, I forgot to clean up leftover includes from
> previous versions of the driver.
> 
> I am fairly new to this procedure of merging patches. Should I later, after
> a send a sensible amount of time has passed to let everyone voice their
> opinion, send a new v4 version of the patch to fix these (and also clarify
> the commit message on the regmap-gpio, as requested in another email),
> or if accepted would maybe the person merging it sort this out?

I'm not the person to merge this, but my advice is to wait a few days
and post a v4 that cleans up the includes and updates the commit
messages.  It makes the process cleaner if the patch you post is the
same as the one that gets merged.