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]
Date:	Mon, 11 Feb 2013 17:05:50 +0100
From:	Samuel Ortiz <sameo@...ux.intel.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Tomas Winkler <tomas.winkler@...el.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [char-misc-next 07/11] mei: bus: Implement bus driver data
 setter/getter

On Mon, Feb 11, 2013 at 08:03:46AM -0800, Greg KH wrote:
> On Mon, Feb 11, 2013 at 04:29:29PM +0100, Samuel Ortiz wrote:
> > Hi Arnd,
> > 
> > On Mon, Feb 11, 2013 at 02:58:37PM +0000, Arnd Bergmann wrote:
> > > On Thursday 07 February 2013, Samuel Ortiz wrote:
> > > > 
> > > > On Thu, Feb 07, 2013 at 11:58:09PM +0100, Samuel Ortiz wrote:
> > > > > On Thu, Feb 07, 2013 at 10:38:44PM +0000, Arnd Bergmann wrote:
> > > > > > On Thursday 07 February 2013, Tomas Winkler wrote:
> > > > > > > 
> > > > > > > +inline void *mei_bus_get_clientdata(const struct mei_bus_client *client)
> > > > > > > +{
> > > > > > > +       return dev_get_drvdata(&client->dev);
> > > > > > > +}
> > > > > > > +EXPORT_SYMBOL(mei_bus_get_clientdata);
> > > > > > > +
> > > > > > 
> > > > > > Did you really mean to export an inline function?
> > > > > > 
> > > > > > Can you make this a static inline function in a header file instead?
> > > > > Sure, will do.
> > > > Actually, I'd like to keep the mei_bus_client structure opaque to the MEI bus
> > > > drivers. So I'll still export those symbols without inlining them.
> > > 
> > > Ok, makes sense. I assume when you say "bus driver" you mean what other
> > > subsystems call a "device driver".
> > That's correct, yes.
> 
> Thanks for clearing that up.  So, in your next revision, can you use the
> "proper" names for everything so that we all can understand the code
> easier as it will follow the normal standards for kernel driver model
> interaction?
I will certainly do that, yes.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ