linux-kernel - Re: [PATCH 1/4] gpiolib: add opt-out for existing drivers with static GPIO base

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]

Message-ID: <f1b00285-4afb-4a3b-9918-46fbfc8ce4a8@pengutronix.de>
Date: Tue, 21 Jan 2025 12:34:04 +0100
From: Ahmad Fatoum <a.fatoum@...gutronix.de>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: imx@...ts.linux.dev, linux-gpio@...r.kernel.org,
 Dwaipayan Ray <dwaipayanray1@...il.com>, Bartosz Golaszewski
 <brgl@...ev.pl>, linux-kernel@...r.kernel.org,
 Shawn Guo <shawnguo@...nel.org>, Joe Perches <joe@...ches.com>,
 Andy Shevchenko <andy.shevchenko@...il.com>, Haibo Chen
 <haibo.chen@....com>, Pengutronix Kernel Team <kernel@...gutronix.de>,
 Andy Whitcroft <apw@...onical.com>, Lukas Bulwahn <lukas.bulwahn@...il.com>,
 Catalin Popescu <catalin.popescu@...ca-geosystems.com>,
 Dario Binacchi <dario.binacchi@...rulasolutions.com>,
 Fabio Estevam <festevam@...il.com>, Sascha Hauer <s.hauer@...gutronix.de>,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/4] gpiolib: add opt-out for existing drivers with static
 GPIO base

Hi Linus,

On 15.01.25 13:00, Linus Walleij wrote:
> On Mon, Jan 13, 2025 at 11:19 PM Ahmad Fatoum <a.fatoum@...gutronix.de> wrote:
> 
>> As these concerns won't go away until the sysfs interface is removed,
>> let's add a new struct gpio_chip::legacy_static_base member that can be
>> used by existing drivers that have been grandfathered in to suppress
>> the warning currently being printed:
> 
> I think entire drivers, pertaining to in worst case several generations
> of SoCs is not the way to approach this. It could be a SoC or, more
> likely, single systems using a SoC, that has a problem with this.
> 
> If you want to safeguard this I would use some code loop in the
> gpiolib(-sysfs) that looks at of_machine_is_compatible("foo,bar-machine")
> to match the top-level compatible for known problematic machines
> so we can be fine-grained of this so when that machines retires
> the driver can start using dynamic GPIO number allotment.

It's meant to apply to all existing i.MX SoCs, but not for new ones using
the same driver.

Filtering by board is not practical and doesn't address the problem of
a kernel update leading to toggling of arbitrary GPIOs.

I am wondering, what remaining _users_ of the GPIO base do we have.
Is it just SysFS and legacy board code?

Cheers,
Ahmad

> 
> Yours,
> Linus Walleij
> 
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |