linux-kernel - Re: [PATCH v4 1/4] gpio: vf610: allow disabling the vf610 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] [day] [month] [year] [list]

Date: Tue, 6 Feb 2024 15:05:23 +0100
From: Martin Kaiser <martin@...ser.cx>
To: Francesco Dolcini <francesco@...cini.it>
Cc: Shawn Guo <shawnguo@...nel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Bartosz Golaszewski <brgl@...ev.pl>, Peng Fan <peng.fan@....com>,
	Andrew Lunn <andrew@...n.ch>, linux-gpio@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/4] gpio: vf610: allow disabling the vf610 driver

Thus wrote Francesco Dolcini (francesco@...cini.it):

> On Mon, Jan 29, 2024 at 10:26:16PM +0100, Martin Kaiser wrote:
> > Thus wrote Francesco Dolcini (francesco@...cini.it):

> > > On Wed, Jan 24, 2024 at 09:58:57PM +0100, Martin Kaiser wrote:
> > > > The vf610 gpio driver is enabled by default for all i.MX machines,
> > > > without any option to disable it in a board-specific config file.

> > > > Most i.MX chipsets have no hardware for this driver. Change the default
> > > > to enable GPIO_VF610 for SOC_VF610 and disable it otherwise.

> > > > Add a text description after the bool type, this makes the driver
> > > > selectable by make config etc.

> > > > Fixes: 30a35c07d9e9 ("gpio: vf610: drop the SOC_VF610 dependency for GPIO_VF610")
> > > > Signed-off-by: Martin Kaiser <martin@...ser.cx>
> > > > ---

> > > >  config GPIO_VF610
> > > > -	def_bool y
> > > > +	bool "VF610 GPIO support"
> > > > +	default y if SOC_VF610

> > > any reason for having this default y for SOC_VF610, but not for the
> > > other SOC that uses the same variant (i.MX7ULP, ... ?).

> > Ok, it's probably not as consistent as it could be.

> ...

> > Does this make sense?
> sounds fair to me.

Sorry for the delay, other tasks got in the way.

The maintainers have meanwhile merged v4.

Basically, the conclusion of my last mail was that imx7ulp and soc_vf610 could
be configured in the same way to make things a bit clearer. This wouldn't be
much of an improvement compared to the v4 set, I'd suggest keeping the current
state.

Thanks,
Martin