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: <ZSELRvVk3G1y258L@smile.fi.intel.com>
Date:   Sat, 7 Oct 2023 10:39:50 +0300
From:   Andy Shevchenko <andy@...nel.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Bartosz Golaszewski <brgl@...ev.pl>, linux-gpio@...r.kernel.org,
        linux-kernel@...r.kernel.org, Dipen Patel <dipenp@...dia.com>,
        Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [RFC/RFT PATCH] gpiolib: reverse-assign the fwnode to struct
 gpio_chip

On Sat, Oct 07, 2023 at 12:22:01AM +0200, Linus Walleij wrote:
> On Fri, Oct 6, 2023 at 9:08 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> > I don't see any good reason for it not having the fwnode assigned.

> > User calling gpio_device_find() will have to jump through hoops in
> > order to match the device by fwnode
> 
> Yeah I would add
> 
> struct fwnode_handle *gpiochip_get_fwnode(struct gpio_chip *gc)
> {
>    return dev_fwnode(&gc->gpiodev->dev);
> }
> 
> so it's easy for external users to get the fwnode if they really need it.
> This and a few more changes and we can drop gc->fwnode altogether
> can't we?

This would work, but the problem here is to understand which fwnode
(semantically) the caller wants to use.

One is the GPIO device's, and the other is what provider explicitly assigned.
Currently the latter case is transparent in a sense that GPIO device will get
the same fwnode as GPIO chip submitted by the provider.

Internally GPIOLIB must use GPIO device fwnode and rely only on it.
Externally it depends. Basically it's provider's business to know if it
is safe to use gc->fwnode or not and when.

-- 
With Best Regards,
Andy Shevchenko


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ