Hi Greg, Arnd, On Wed, Feb 20, 2013 at 11:57:31AM +0100, Samuel Ortiz wrote: > On Tue, Feb 19, 2013 at 03:32:44PM +0200, Tomas Winkler wrote: > > On Wed, Feb 13, 2013 at 11:39 AM, Samuel Ortiz <sa...@linux.intel.com> > > wrote: > > > > > > On Tue, Feb 12, 2013 at 11:09:00PM +0000, Arnd Bergmann wrote: > > > > On Tuesday 12 February 2013, gre...@linuxfoundation.org wrote: > > > > > > > > > > > > > Please let's find something that makes both hw and Linux happy > > > > > > I still believe it makes sense to use mei_device for what we add to > > > > > > the MEI > > > > > > bus. I'd be fine with mei_bus_device as well, but that would > > > > > > somehow look > > > > > > a bit awkward. Greg, Arnd, any preference ? > > > > > > > > > > "mei_device" works the best for me. Tomas, what you think of as a > > > > > "MEI > > > > > Device" really is a "MEI Controller", it bridges the difference > > > > > between > > > > > the PCI bus and your new MEI bus, so you will need to start thinking > > > > > of > > > > > these things a bit differently now that you have created your own > > > > > little > > > > > virtual bus. > > > > > > > > Yes, I agree. mei_bus_device would also work as the name for the > > > > controller, > > > > but not for the devices attached to it IMO. > > > Tomas, I propose to switch to mei_controller instead of mei_host and keep > > > the > > > mei_device name for the devices we attach to the MEI bus. > > > Does that work for you ? > > > > > > > The issue is that when we added our virtual bus we haven't gave up on > > /dev/mei backed by mei_device > > This is the interface, defined in linux/mei.h which user space > > applications use to connect to ME Clients within ME device. > > Any ME client can be connected through this interface and we have few > > legacy applications running for few years that use this interface so > > we are not going to break them. > > > > What we've done now is we added a virtual bus so also in-kernel > > applications/subsystems can more naturally connect to the ME Clients, > > this connection is client specific. So the device that connect to the > > bus is not an mei device but mei client device hence the name I've > > proposed mei_cl_device. > I don't have a strong opinion here, so that would be fine with me. > Greg, Arnd, would mei_cl_device and mei_cl_driver be an acceptable compromise? I'm re-opening this topic now that the merge window is closed: So would you guys take mei_cl_device and mei_cl_driver as an acceptable solution or (as you hinted earlier) are mei_device and mei_driver the only naming scheme that you'd accept ?
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
