[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130211134612.GO20996@sortiz-mobl>
Date: Mon, 11 Feb 2013 14:46:12 +0100
From: Samuel Ortiz <sameo@...ux.intel.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Greg KH <gregkh@...uxfoundation.org>,
Tomas Winkler <tomas.winkler@...el.com>,
linux-kernel@...r.kernel.org
Subject: Re: [char-misc-next 01/11 V2] mei: bus: Initial MEI bus type
implementation
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/
--
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