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
| ||
|
Date: Tue, 26 Jan 2021 10:16:25 -0800 From: Saravana Kannan <saravanak@...gle.com> To: Andy Shevchenko <andy.shevchenko@...il.com> Cc: Linus Walleij <linus.walleij@...aro.org>, Bartosz Golaszewski <bgolaszewski@...libre.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Marc Zyngier <maz@...nel.org>, Jisheng Zhang <Jisheng.Zhang@...aptics.com>, Kever Yang <kever.yang@...k-chips.com>, "kernel-team@...roid.com" <kernel-team@...roid.com>, "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v2] gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default On Tue, Jan 26, 2021 at 1:40 AM Andy Shevchenko <andy.shevchenko@...il.com> wrote: > > > > On Friday, January 22, 2021, Saravana Kannan <saravanak@...gle.com> wrote: >> >> There are multiple instances of GPIO device tree nodes of the form: >> >> foo { >> compatible = "acme,foo"; >> ... >> >> gpio0: gpio0@...xxxxx { >> compatible = "acme,bar"; >> ... >> gpio-controller; >> }; >> >> gpio1: gpio1@...xxxxx { >> compatible = "acme,bar"; >> ... >> gpio-controller; >> }; >> >> ... >> } >> >> bazz { >> my-gpios = <&gpio0 ...>; >> } >> >> Case 1: The driver for "foo" populates struct device for these gpio* >> nodes and then probes them using a driver that binds with "acme,bar". >> This driver for "acme,bar" then registers the gpio* nodes with gpiolib. >> This lines up with how DT nodes with the "compatible" property are >> typically converted to struct devices and then registered with driver >> core to probe them. This also allows the gpio* devices to hook into all >> the driver core capabilities like runtime PM, probe deferral, >> suspend/resume ordering, device links, etc. >> >> Case 2: The driver for "foo" doesn't populate struct devices for these >> gpio* nodes before registering them with gpiolib. Instead it just loops >> through its child nodes and directly registers the gpio* nodes with >> gpiolib. >> >> Drivers that follow case 2 cause problems with fw_devlink=on. This is >> because fw_devlink will prevent bazz from probing until there's a struct >> device that has gpio0 as its fwnode (because bazz lists gpio0 as a GPIO >> supplier). Once the struct device is available, fw_devlink will create a >> device link with gpio0 device as the supplier and bazz device as the >> consumer. After this point, since the gpio0 device will never bind to a >> driver, the device link will prevent bazz device from ever probing. >> >> Finding and refactoring all the instances of drivers that follow case 2 >> will cause a lot of code churn and it is not something that can be done >> in one shot. In some instances it might not even be possible to refactor >> them cleanly. Examples of such instances are [1] [2]. >> >> This patch works around this problem and avoids all the code churn by >> simply setting the fwnode of the gpio_device and creating a stub driver >> to bind to the gpio_device. This allows all the consumers to continue >> probing when the driver follows case 2. >> > > Do we need to unregister it at __exit initcall? > What side effects would be of the stub driver presence on the GPIO bus? Any traverse on it will work as before? I checked. There is no __exit initcall. -Saravana
Powered by blists - more mailing lists