linux-kernel - Re: [RFC 03/10] base: swnode: use fwnode_get_match

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YhZNMkwN3o40jDP5@paasikivi.fi.intel.com>
Date:   Wed, 23 Feb 2022 17:05:22 +0200
From:   Sakari Ailus <sakari.ailus@...ux.intel.com>
To:     Clément Léger <clement.leger@...tlin.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Daniel Scally <djrscally@...il.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Wolfram Sang <wsa@...nel.org>, Peter Rosin <peda@...ntia.se>,
        Russell King <linux@...linux.org.uk>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org, linux-i2c@...r.kernel.org,
        netdev@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>
Subject: Re: [RFC 03/10] base: swnode: use fwnode_get_match_data()

Hi Clément,

On Tue, Feb 22, 2022 at 09:39:21AM +0100, Clément Léger wrote:
> Le Mon, 21 Feb 2022 19:48:00 +0200,
> Andy Shevchenko <andriy.shevchenko@...ux.intel.com> a écrit :
> 
> > On Mon, Feb 21, 2022 at 05:26:45PM +0100, Clément Léger wrote:
> > > In order to allow matching devices with software node with
> > > device_get_match_data(), use fwnode_get_match_data() for
> > > .device_get_match_data operation.  
> > 
> > ...
> > 
> > > +	.device_get_match_data = fwnode_get_match_data,  
> > 
> > Huh? It should be other way around, no?
> > I mean that each of the resource providers may (or may not) provide a
> > method for the specific fwnode abstraction.
> > 
> 
> Indeed, it should be the other way. But since this function is generic
> and uses only fwnode API I guessed it would be more convenient to
> define it in the fwnode generic part and use it for specific
> implementation. I could have modified device_get_match_data to call it
> if there was no .device_get_match_data operation like this:
> 
> const void *device_get_match_data(struct device *dev)
> {
> 	if (!fwnode_has_op(fwnode, device_get_match_data)
> 		return fwnode_get_match_data(dev);
> 	return fwnode_call_ptr_op(dev_fwnode(dev),device_get_match_data, dev);
> }
> 
> But I thought it was more convenient to do it by setting the
> .device_get_match_data field of software_node operations.

Should this function be called e.g. software_node_get_match_data() instead,
as it seems to be specific to software nodes?

-- 
Regards,

Sakari Ailus