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]
Date:   Wed, 17 Jun 2020 13:51:28 +0100
From:   Lee Jones <lee.jones@...aro.org>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Serge Semin <fancer.lancer@...il.com>, linux-gpio@...r.kernel.org,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        linux-kernel@...r.kernel.org,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Subject: Re: [PATCH v1 3/6] mfd: core: Propagate software node group to the
 sub devices

On Tue, 09 Jun 2020, Andy Shevchenko wrote:

> On Mon, Jun 08, 2020 at 08:25:24PM +0100, Lee Jones wrote:
> > On Mon, 08 Jun 2020, Andy Shevchenko wrote:
> > 
> > > From: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
> > > 
> > > When ever device properties are supplied for a sub device, a software node
> > > (fwnode) is actually created and then associated with that device. By allowing
> > > the drivers to supply the complete software node group instead of just the
> > > properties in it, the drivers can take advantage of the other features the
> > > software nodes have on top of supplying the device properties.
> > > 
> > > Signed-off-by: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> > > ---
> > >  drivers/mfd/mfd-core.c   | 31 +++++++++++++++++++++++++++----
> > >  include/linux/mfd/core.h |  3 +++
> > >  2 files changed, 30 insertions(+), 4 deletions(-)
> > 
> > I'm not sure a change to the API is justified presently (same does go
> > for 'properties' really, but as it was only a couple of lines, it
> > didn't seem too intrusive).
> 
> This is better and comprehensive API, but I heard you.
> 
> > My recommendation is to handle this in-house (i.e. locally in-driver)
> > for now.
> 
> I think you understand that this is not gonna work (we need to attach fwnode
> to the child device before it's registration.
> 
> > When (if) more users adopt the practice, then we should
> > consider to draw down on line numbers and repetition and make it part
> > of the API.
> 
> I briefly looked at the current state of affairs and found that properties are
> used only for MFD LPSS driver. Would the conversion of that driver to swnodes
> work for you?
> 
> Note, the long prospective is to get rid of platform_add_properties() API
> completely.

That's a shame.  Do you plan on replacing it with something else?

MFD tends to only interact with the platform_device API, and even
platform_device_add_properties() doesn't get involved in the nitty
gritty of fwnodes.  Instead it acts as a pass-through straight to
device_add_properties() which is where the magic happens.

For this to be acceptable you would need to add support into
platform_device i.e. platform_device_add_property_group() or some
such.  I really do not want the MFD API to have knowledge about
regarding the particulars i.e. software node registration, secondary
fwnodes and the like.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ