linux-kernel - Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines

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: <20130211125836.GN20996@sortiz-mobl>
Date:	Mon, 11 Feb 2013 13:58:36 +0100
From:	Samuel Ortiz <sameo@...ux.intel.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Tomas Winkler <tomas.winkler@...el.com>,
	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org
Subject: Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O
 routines

Hi Arnd,

On Mon, Feb 11, 2013 at 11:52:42AM +0000, Arnd Bergmann wrote:
> On Thursday 07 February 2013, Samuel Ortiz wrote:
> > On Thu, Feb 07, 2013 at 10:34:44PM +0000, Arnd Bergmann wrote:
> > > On Thursday 07 February 2013, Tomas Winkler wrote:
> > > > +
> > > > +struct mei_bus_ops {
> > > > +       int (*send)(struct mei_bus_client *client, u8 *buf, size_t length);
> > > > +       int (*recv)(struct mei_bus_client *client, u8 *buf, size_t length);
> > > > +};
> > > > +
> > > 
> > > Can you have more than one set of mei_bus_ops in a driver? 
> > You can have at most one mei_bus_ops per mei_bus_client.
> > 
> > > If not, how about adding the callbacks to the mei_bus_driver structure
> > > directly as a simplification? 
> > I can add the ops directly to the mei_bus_client structure, yes.
> 
> I looked at the new version, and it's not what I assumed it would be.
> I thought the operations were specific to a client driver and should
> be part of the /mei_bus_driver/ structure, not the /mei_bus_client/.
The ops should be part of mei_bus_client as they're specific to the MEI
protocol for a given IP block on the ME. You need to have MEI and HECI
knowledge to implement those ops and drivers (defining their mei_bus_driver
structure) should not have that kind of knowledge but rather focus on the
technology they're driving.
If we take the NFC example again, the drivers/nfc/ code will send NFC payloads
to the bus I/O routines and this is where the mei_bus_client ops will add the
ME specific protocol (command and request id for the NFC block) on top of it.
In practice, this is an additional header which handles a transport layer that's
specific not only to the ME but to the NFC block of it. So each ME block can
have its own protocol to send and receive technology specific payloads, that's
what those ops implement.
That's why I think that those ops should not be defined by the drivers/nfc/ code
and in fact should be opaque to it.


> Did I misunderstand what these functions do, or did you misunderstand
> what I was asking for?
Probably both. I really thought you were looking for a structure cleanup by
directly putting the ops into the mei_bus_client structure.

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/