From: Samuel Ortiz <sameo@linux.intel.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Tomas Winkler <tomas.winkler@intel.com>,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org
Subject: Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines
Date: Mon, 11 Feb 2013 13:58:36 +0100 [thread overview]
Message-ID: <20130211125836.GN20996@sortiz-mobl> (raw)
In-Reply-To: <201302111152.42483.arnd@arndb.de>
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/
next prev parent reply other threads:[~2013-02-11 12:58 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-07 21:03 [char-misc-next 00/11] Add MEI BUS and NFC Device Tomas Winkler
2013-02-07 21:03 ` [char-misc-next 01/11] mei: bus: Initial MEI bus type implementation Tomas Winkler
2013-02-07 22:29 ` Arnd Bergmann
2013-02-07 22:41 ` Arnd Bergmann
2013-02-07 22:59 ` Samuel Ortiz
2013-02-07 23:07 ` Winkler, Tomas
2013-02-07 21:03 ` [char-misc-next 02/11] mei: bus: Implement driver registration Tomas Winkler
2013-02-07 22:30 ` Arnd Bergmann
2013-02-07 21:03 ` [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines Tomas Winkler
2013-02-07 22:34 ` Arnd Bergmann
2013-02-07 22:55 ` Samuel Ortiz
2013-02-11 11:52 ` Arnd Bergmann
2013-02-11 12:58 ` Samuel Ortiz [this message]
2013-02-11 15:08 ` Arnd Bergmann
2013-02-11 15:48 ` Samuel Ortiz
2013-02-11 16:12 ` Arnd Bergmann
2013-02-07 21:03 ` [char-misc-next 04/11] mei: bus: Add bus related structures to mei_cl Tomas Winkler
2013-02-07 21:03 ` [char-misc-next 05/11] mei: bus: Call bus routines from the core code Tomas Winkler
2013-02-07 22:37 ` Arnd Bergmann
2013-02-07 22:57 ` Winkler, Tomas
2013-02-07 23:09 ` Arnd Bergmann
2013-02-07 22:57 ` Samuel Ortiz
2013-02-07 21:03 ` [char-misc-next 06/11] mei: bus: Synchronous API for the data transmission Tomas Winkler
2013-02-07 21:03 ` [char-misc-next 07/11] mei: bus: Implement bus driver data setter/getter Tomas Winkler
2013-02-07 22:38 ` Arnd Bergmann
2013-02-07 22:58 ` Samuel Ortiz
2013-02-07 23:57 ` Samuel Ortiz
2013-02-11 14:58 ` Arnd Bergmann
2013-02-11 15:29 ` Samuel Ortiz
2013-02-11 16:03 ` Greg KH
2013-02-11 16:05 ` Samuel Ortiz
2013-02-07 21:03 ` [char-misc-next 08/11] mei: nfc: Initial nfc implementation Tomas Winkler
2013-02-07 22:26 ` Arnd Bergmann
2013-02-07 22:41 ` Samuel Ortiz
2013-02-07 21:03 ` [char-misc-next 09/11] mei: nfc: Connect also the regular ME client Tomas Winkler
2013-02-07 21:03 ` [char-misc-next 10/11] mei: nfc: Add NFC device to the MEI bus Tomas Winkler
2013-02-07 21:03 ` [char-misc-next 11/11] mei: nfc: Implement MEI bus IO ops Tomas Winkler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130211125836.GN20996@sortiz-mobl \
--to=sameo@linux.intel.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tomas.winkler@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.