From: Samuel Ortiz <sameo@linux.intel.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Tomas Winkler <tomas.winkler@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [char-misc-next 01/11 V2] mei: bus: Initial MEI bus type implementation
Date: Mon, 11 Feb 2013 14:46:12 +0100 [thread overview]
Message-ID: <20130211134612.GO20996@sortiz-mobl> (raw)
In-Reply-To: <201302111150.26785.arnd@arndb.de>
Hi Arnd,
On Mon, Feb 11, 2013 at 11:50:26AM +0000, Arnd Bergmann wrote:
> On Sunday 10 February 2013, Samuel Ortiz wrote:
> > > >
> > > > /**
> > > > + * mei_bus_client
> > >
> > > I don't really understand this structure, please explain it better.
> > This is a structure that links the MEI bus client pointer passed to the driver
> > with the actual ME client. It also allows the ME driver to implement
> > technology specific ME protocol through the send/recv hooks.
>
> I think part of the confusion is that this is what in other subsystems
> is called a device, not a client. I believe I'm still confused in the
> same way that Greg is.
Ok, I understand where the confusion comes from now. Yes, for most of the
other subsystems, this is a device. Initially I tried to keep the MEI bus code
as little intrusive as possible and I didn't want to rename mei_device to
something else.
> You already have a 'struct mei_device', which refers to the PCI device
> that owns the bus, and has clients attached to it. While it may be
> a little confusing to people that already worked with the current
> mei code, I think it would help to rename the existing 'mei_device'
> to 'mei_host' or something else that feels appropriate, and introduce
> the new structure as 'mei_device' derived from 'struct device', again
> matching what most other subsystems do.
I understand, and I agree it would make sense. As we're aiming at having this
patchset merged during the next merge window, would it be ok to have this
renaming phase as a follow up patch ?
> Similarly, you can then rename 'mei_bus_driver' to 'mei_driver' to fit
> that logic, since I would consider a 'bus_driver' to be something
> that is responsible for the entire bus, not just for one device.
That would make sense as well, and I can have this done through patchset v4.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
next prev parent reply other threads:[~2013-02-11 13:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-08 12:28 [char-misc-next 00/11 V2] Add MEI BUS and NFC Device Tomas Winkler
2013-02-08 12:28 ` [char-misc-next 01/11 V2] mei: bus: Initial MEI bus type implementation Tomas Winkler
2013-02-08 23:53 ` Greg KH
2013-02-10 3:25 ` Samuel Ortiz
2013-02-11 11:50 ` Arnd Bergmann
2013-02-11 13:46 ` Samuel Ortiz [this message]
2013-02-11 14:30 ` Greg KH
2013-02-11 15:58 ` Samuel Ortiz
2013-02-11 16:05 ` Greg KH
2013-02-08 12:28 ` [char-misc-next 02/11 V2] mei: bus: Implement driver registration Tomas Winkler
2013-02-08 13:36 ` Arnd Bergmann
2013-02-08 23:55 ` Greg KH
2013-02-10 3:32 ` Samuel Ortiz
2013-02-10 16:36 ` Greg KH
2013-02-11 11:03 ` Samuel Ortiz
2013-02-08 12:28 ` [char-misc-next 03/11 V2] mei: bus: Initial implementation for I/O routines Tomas Winkler
2013-02-08 12:28 ` [char-misc-next 04/11 V2] mei: bus: Add bus related structures to mei_cl Tomas Winkler
2013-02-08 12:28 ` [char-misc-next 05/11 V2] mei: bus: Call bus routines from the core code Tomas Winkler
2013-02-08 13:34 ` Arnd Bergmann
2013-02-08 12:28 ` [char-misc-next 06/11 V2] mei: bus: Synchronous API for the data transmission Tomas Winkler
2013-02-08 12:28 ` [char-misc-next 07/11 V2] mei: bus: Implement bus driver data setter/getter Tomas Winkler
2013-02-08 12:28 ` [char-misc-next 08/11 V2] mei: nfc: Initial nfc implementation Tomas Winkler
2013-02-08 12:28 ` [char-misc-next 09/11 V2] mei: nfc: Connect also the regular ME client Tomas Winkler
2013-02-08 12:28 ` [char-misc-next 10/11] mei: nfc: Add NFC device to the MEI bus Tomas Winkler
2013-02-08 12:28 ` [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=20130211134612.GO20996@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox