linux-kernel - Re: [PATCH v5 21/21] regulator: s2mps11: enable-gpios is optional on s2mpg1x

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: <CAMRc=Mdz5FPPY1k73xU3tGJCuo4cgPLJYsaLH+gTy04DmdmA4g@mail.gmail.com>
Date: Fri, 2 Jan 2026 12:31:05 +0100
From: Bartosz Golaszewski <brgl@...nel.org>
To: André Draszik <andre.draszik@...aro.org>
Cc: Tudor Ambarus <tudor.ambarus@...aro.org>, Rob Herring <robh@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>, 
	Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, Lee Jones <lee@...nel.org>, 
	Linus Walleij <linus.walleij@...aro.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Linus Walleij <linusw@...nel.org>, Peter Griffin <peter.griffin@...aro.org>, 
	Will McVicker <willmcvicker@...gle.com>, Juan Yescas <jyescas@...gle.com>, kernel-team@...roid.com, 
	linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-gpio@...r.kernel.org
Subject: Re: [PATCH v5 21/21] regulator: s2mps11: enable-gpios is optional on s2mpg1x

On Fri, Jan 2, 2026 at 12:26 PM André Draszik <andre.draszik@...aro.org> wrote:
>
> On Fri, 2026-01-02 at 11:19 +0100, Bartosz Golaszewski wrote:
> > On Sat, Dec 27, 2025 at 1:24 PM André Draszik <andre.draszik@...aro.org> wrote:
> > >
> > > For s2mpg1x, enable-gpios is optional, but when not given, the driver
> > > is complaining quite verbosely about the missing property.
> > >
> > > Refactor the code slightly to avoid printing those messages to the
> > > kernel log in that case.
> > >
> >
> > I don't get the point of this - you added this function in the same
> > series, why can't it be done right the first time it's implemented?
>
> Sure, I can merge this patch into the refactoring patch 15 - the intention
> was to have incremental changes to simplify review.
>

I'm all for it but introducing issues in one patch and fixing it in
another is a bit too much. :)

Bartosz