Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
On Monday 11 March 2013, Samuel Ortiz wrote: > > 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 ? I'd prefer the latter, but I wouldn't insist on it if you have good reasons to use the former. Arnd -- 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/
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
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 > > wrote: > > > > > > On Tue, Feb 12, 2013 at 11:09:00PM +, 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/
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
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 +, 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/
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
On Monday 11 March 2013, Samuel Ortiz wrote: 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 ? I'd prefer the latter, but I wouldn't insist on it if you have good reasons to use the former. Arnd -- 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/
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
On Tue, Feb 19, 2013 at 03:32:44PM +0200, Tomas Winkler wrote: > On Wed, Feb 13, 2013 at 11:39 AM, Samuel Ortiz wrote: > > > > On Tue, Feb 12, 2013 at 11:09:00PM +, 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? 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/
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
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 +, 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? 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/
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
On Wed, Feb 13, 2013 at 11:39 AM, Samuel Ortiz wrote: > > On Tue, Feb 12, 2013 at 11:09:00PM +, 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. Does it make sense? Thanks > > 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/ -- 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/
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
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 +, 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. Does it make sense? Thanks 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/ -- 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/
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
On Tue, Feb 12, 2013 at 11:09:00PM +, 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 ? 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/
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
On Tue, Feb 12, 2013 at 11:09:00PM +, 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 ? 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/
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
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. Arnd -- 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/
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
On Tue, Feb 12, 2013 at 10:29:35PM +0100, Samuel Ortiz wrote: > Hi Tomas, > > On Tue, Feb 12, 2013 at 09:17:21PM +, Winkler, Tomas wrote: > > > > > > > In preparation for the MEI bus code merge, we rename the mei_device > > > structure to mei_host. > > > struct mei_device will be used for devices on the MEI bus in order to > > > follow > > > exisiting driver model implementations practices. > > > > > I'd like to NACK this name, we use 'host' for the host part of the MEI > > protocol, > > > > You can use the mei_controller, mei_adapter, and I'm not sure what else > > can come into mind. > mei_controller sounds good to me. > > > > I prefer not to break the HW spec language. I prefer to leave it > > mei_device as after all it's a device on pci bus it's not a pure host > > controller. > > And call what is on the mei bus mei_cl_dev or mei_app_dev . From the HW > > perspective it actually > > talks to a client/application residing inside MEI device, it is not always > > a physical device like NFC. > > > The bus is not physical neither. It's really items that we add to this bus, > watchdog could be the next candidate for example. > > > 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. thanks, greg k-h -- 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/
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
Hi Tomas, On Tue, Feb 12, 2013 at 09:17:21PM +, Winkler, Tomas wrote: > > > > In preparation for the MEI bus code merge, we rename the mei_device > > structure to mei_host. > > struct mei_device will be used for devices on the MEI bus in order to follow > > exisiting driver model implementations practices. > > > I'd like to NACK this name, we use 'host' for the host part of the MEI > protocol, > > You can use the mei_controller, mei_adapter, and I'm not sure what else can > come into mind. mei_controller sounds good to me. > I prefer not to break the HW spec language. I prefer to leave it mei_device > as after all it's a device on pci bus it's not a pure host controller. > And call what is on the mei bus mei_cl_dev or mei_app_dev . From the HW > perspective it actually > talks to a client/application residing inside MEI device, it is not always a > physical device like NFC. > The bus is not physical neither. It's really items that we add to this bus, watchdog could be the next candidate for example. > 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 ? >From the MEI core code readers perspective, this will mostly be transparent as only the technology specific parts of the MEI driver (e.g. nfc.c) will use that mei_device 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 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/
RE: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
> In preparation for the MEI bus code merge, we rename the mei_device
> structure to mei_host.
> struct mei_device will be used for devices on the MEI bus in order to follow
> exisiting driver model implementations practices.
>
I'd like to NACK this name, we use 'host' for the host part of the MEI
protocol,
You can use the mei_controller, mei_adapter, and I'm not sure what else can
come into mind.
I prefer not to break the HW spec language. I prefer to leave it mei_device as
after all it's a device on pci bus it's not a pure host controller.
And call what is on the mei bus mei_cl_dev or mei_app_dev . From the HW
perspective it actually
talks to a client/application residing inside MEI device, it is not always a
physical device like NFC.
Please let's find something that makes both hw and Linux happy
Thanks
Tomas
> Signed-off-by: Samuel Ortiz
> ---
> drivers/misc/mei/amthif.c| 30 ++--
> drivers/misc/mei/client.c| 36 +++---
> drivers/misc/mei/client.h| 14 +++---
> drivers/misc/mei/hbm.c | 28 +--
> drivers/misc/mei/hbm.h | 10 ++--
> drivers/misc/mei/hw-me.c | 42
> drivers/misc/mei/hw-me.h |2 +-
> drivers/misc/mei/init.c |6 +--
> drivers/misc/mei/interrupt.c | 18 +++
> drivers/misc/mei/main.c | 14 +++---
> drivers/misc/mei/mei_dev.h | 110 +---
> --
> drivers/misc/mei/pci-me.c|8 +--
> drivers/misc/mei/wd.c| 20
> 13 files changed, 169 insertions(+), 169 deletions(-)
>
> diff --git a/drivers/misc/mei/amthif.c b/drivers/misc/mei/amthif.c index
> c86d7e3..6f67a0a 100644
> --- a/drivers/misc/mei/amthif.c
> +++ b/drivers/misc/mei/amthif.c
> @@ -47,7 +47,7 @@ const uuid_le mei_amthif_guid = UUID_LE(0x12f80028,
> 0xb4b7, 0x4b2d,
> *
> * @dev: the device structure
> */
> -void mei_amthif_reset_params(struct mei_device *dev)
> +void mei_amthif_reset_params(struct mei_host *dev)
> {
> /* reset iamthif parameters. */
> dev->iamthif_current_cb = NULL;
> @@ -65,7 +65,7 @@ void mei_amthif_reset_params(struct mei_device
> *dev)
> * @dev: the device structure
> *
> */
> -int mei_amthif_host_init(struct mei_device *dev)
> +int mei_amthif_host_init(struct mei_host *dev)
> {
> struct mei_cl *cl = >iamthif_cl;
> unsigned char *msg_buf;
> @@ -129,7 +129,7 @@ int mei_amthif_host_init(struct mei_device *dev)
> *
> * returns returned a list entry on success, NULL on failure.
> */
> -struct mei_cl_cb *mei_amthif_find_read_list_entry(struct mei_device
> *dev,
> +struct mei_cl_cb *mei_amthif_find_read_list_entry(struct mei_host *dev,
> struct file *file)
> {
> struct mei_cl_cb *pos = NULL;
> @@ -162,7 +162,7 @@ struct mei_cl_cb
> *mei_amthif_find_read_list_entry(struct mei_device *dev,
> * zero if no data to read,
> * negative on failure.
> */
> -int mei_amthif_read(struct mei_device *dev, struct file *file,
> +int mei_amthif_read(struct mei_host *dev, struct file *file,
> char __user *ubuf, size_t length, loff_t *offset) {
> int rets;
> @@ -274,7 +274,7 @@ out:
> * returns 0 on success, <0 on failure.
> *
> */
> -static int mei_amthif_send_cmd(struct mei_device *dev, struct mei_cl_cb
> *cb)
> +static int mei_amthif_send_cmd(struct mei_host *dev, struct mei_cl_cb
> +*cb)
> {
> struct mei_msg_hdr mei_hdr;
> int ret;
> @@ -348,7 +348,7 @@ static int mei_amthif_send_cmd(struct mei_device
> *dev, struct mei_cl_cb *cb)
> * returns 0 on success, <0 on failure.
> *
> */
> -int mei_amthif_write(struct mei_device *dev, struct mei_cl_cb *cb)
> +int mei_amthif_write(struct mei_host *dev, struct mei_cl_cb *cb)
> {
> int ret;
>
> @@ -378,7 +378,7 @@ int mei_amthif_write(struct mei_device *dev, struct
> mei_cl_cb *cb)
> *
> * returns 0 on success, <0 on failure.
> */
> -void mei_amthif_run_next_cmd(struct mei_device *dev)
> +void mei_amthif_run_next_cmd(struct mei_host *dev)
> {
> struct mei_cl_cb *pos = NULL;
> struct mei_cl_cb *next = NULL;
> @@ -414,7 +414,7 @@ void mei_amthif_run_next_cmd(struct mei_device
> *dev) }
>
>
> -unsigned int mei_amthif_poll(struct mei_device *dev,
> +unsigned int mei_amthif_poll(struct mei_host *dev,
> struct file *file, poll_table *wait)
> {
> unsigned int mask = 0;
> @@ -443,7 +443,7 @@ unsigned int mei_amthif_poll(struct mei_device
> *dev,
> *
> * returns 0, OK; otherwise, error.
> */
> -int mei_amthif_irq_write_complete(struct mei_device *dev, s32 *slots,
> +int mei_amthif_irq_write_complete(struct mei_host *dev, s32 *slots,
> struct mei_cl_cb *cb, struct mei_cl_cb *cmpl_list) {
> struct mei_msg_hdr mei_hdr;
> @@ -512,7 +512,7 @@ int mei_amthif_irq_write_complete(struct
> mei_device *dev, s32 *slots,
> * returns 0 on success, <0 on failure.
> */
> int
RE: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
In preparation for the MEI bus code merge, we rename the mei_device
structure to mei_host.
struct mei_device will be used for devices on the MEI bus in order to follow
exisiting driver model implementations practices.
I'd like to NACK this name, we use 'host' for the host part of the MEI
protocol,
You can use the mei_controller, mei_adapter, and I'm not sure what else can
come into mind.
I prefer not to break the HW spec language. I prefer to leave it mei_device as
after all it's a device on pci bus it's not a pure host controller.
And call what is on the mei bus mei_cl_dev or mei_app_dev . From the HW
perspective it actually
talks to a client/application residing inside MEI device, it is not always a
physical device like NFC.
Please let's find something that makes both hw and Linux happy
Thanks
Tomas
Signed-off-by: Samuel Ortiz sa...@linux.intel.com
---
drivers/misc/mei/amthif.c| 30 ++--
drivers/misc/mei/client.c| 36 +++---
drivers/misc/mei/client.h| 14 +++---
drivers/misc/mei/hbm.c | 28 +--
drivers/misc/mei/hbm.h | 10 ++--
drivers/misc/mei/hw-me.c | 42
drivers/misc/mei/hw-me.h |2 +-
drivers/misc/mei/init.c |6 +--
drivers/misc/mei/interrupt.c | 18 +++
drivers/misc/mei/main.c | 14 +++---
drivers/misc/mei/mei_dev.h | 110 +---
--
drivers/misc/mei/pci-me.c|8 +--
drivers/misc/mei/wd.c| 20
13 files changed, 169 insertions(+), 169 deletions(-)
diff --git a/drivers/misc/mei/amthif.c b/drivers/misc/mei/amthif.c index
c86d7e3..6f67a0a 100644
--- a/drivers/misc/mei/amthif.c
+++ b/drivers/misc/mei/amthif.c
@@ -47,7 +47,7 @@ const uuid_le mei_amthif_guid = UUID_LE(0x12f80028,
0xb4b7, 0x4b2d,
*
* @dev: the device structure
*/
-void mei_amthif_reset_params(struct mei_device *dev)
+void mei_amthif_reset_params(struct mei_host *dev)
{
/* reset iamthif parameters. */
dev-iamthif_current_cb = NULL;
@@ -65,7 +65,7 @@ void mei_amthif_reset_params(struct mei_device
*dev)
* @dev: the device structure
*
*/
-int mei_amthif_host_init(struct mei_device *dev)
+int mei_amthif_host_init(struct mei_host *dev)
{
struct mei_cl *cl = dev-iamthif_cl;
unsigned char *msg_buf;
@@ -129,7 +129,7 @@ int mei_amthif_host_init(struct mei_device *dev)
*
* returns returned a list entry on success, NULL on failure.
*/
-struct mei_cl_cb *mei_amthif_find_read_list_entry(struct mei_device
*dev,
+struct mei_cl_cb *mei_amthif_find_read_list_entry(struct mei_host *dev,
struct file *file)
{
struct mei_cl_cb *pos = NULL;
@@ -162,7 +162,7 @@ struct mei_cl_cb
*mei_amthif_find_read_list_entry(struct mei_device *dev,
* zero if no data to read,
* negative on failure.
*/
-int mei_amthif_read(struct mei_device *dev, struct file *file,
+int mei_amthif_read(struct mei_host *dev, struct file *file,
char __user *ubuf, size_t length, loff_t *offset) {
int rets;
@@ -274,7 +274,7 @@ out:
* returns 0 on success, 0 on failure.
*
*/
-static int mei_amthif_send_cmd(struct mei_device *dev, struct mei_cl_cb
*cb)
+static int mei_amthif_send_cmd(struct mei_host *dev, struct mei_cl_cb
+*cb)
{
struct mei_msg_hdr mei_hdr;
int ret;
@@ -348,7 +348,7 @@ static int mei_amthif_send_cmd(struct mei_device
*dev, struct mei_cl_cb *cb)
* returns 0 on success, 0 on failure.
*
*/
-int mei_amthif_write(struct mei_device *dev, struct mei_cl_cb *cb)
+int mei_amthif_write(struct mei_host *dev, struct mei_cl_cb *cb)
{
int ret;
@@ -378,7 +378,7 @@ int mei_amthif_write(struct mei_device *dev, struct
mei_cl_cb *cb)
*
* returns 0 on success, 0 on failure.
*/
-void mei_amthif_run_next_cmd(struct mei_device *dev)
+void mei_amthif_run_next_cmd(struct mei_host *dev)
{
struct mei_cl_cb *pos = NULL;
struct mei_cl_cb *next = NULL;
@@ -414,7 +414,7 @@ void mei_amthif_run_next_cmd(struct mei_device
*dev) }
-unsigned int mei_amthif_poll(struct mei_device *dev,
+unsigned int mei_amthif_poll(struct mei_host *dev,
struct file *file, poll_table *wait)
{
unsigned int mask = 0;
@@ -443,7 +443,7 @@ unsigned int mei_amthif_poll(struct mei_device
*dev,
*
* returns 0, OK; otherwise, error.
*/
-int mei_amthif_irq_write_complete(struct mei_device *dev, s32 *slots,
+int mei_amthif_irq_write_complete(struct mei_host *dev, s32 *slots,
struct mei_cl_cb *cb, struct mei_cl_cb *cmpl_list) {
struct mei_msg_hdr mei_hdr;
@@ -512,7 +512,7 @@ int mei_amthif_irq_write_complete(struct
mei_device *dev, s32 *slots,
* returns 0 on success, 0 on failure.
*/
int mei_amthif_irq_read_message(struct mei_cl_cb *complete_list,
- struct mei_device *dev, struct mei_msg_hdr
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
Hi Tomas, On Tue, Feb 12, 2013 at 09:17:21PM +, Winkler, Tomas wrote: In preparation for the MEI bus code merge, we rename the mei_device structure to mei_host. struct mei_device will be used for devices on the MEI bus in order to follow exisiting driver model implementations practices. I'd like to NACK this name, we use 'host' for the host part of the MEI protocol, You can use the mei_controller, mei_adapter, and I'm not sure what else can come into mind. mei_controller sounds good to me. I prefer not to break the HW spec language. I prefer to leave it mei_device as after all it's a device on pci bus it's not a pure host controller. And call what is on the mei bus mei_cl_dev or mei_app_dev . From the HW perspective it actually talks to a client/application residing inside MEI device, it is not always a physical device like NFC. The bus is not physical neither. It's really items that we add to this bus, watchdog could be the next candidate for example. 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 ? From the MEI core code readers perspective, this will mostly be transparent as only the technology specific parts of the MEI driver (e.g. nfc.c) will use that mei_device 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 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/
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
On Tue, Feb 12, 2013 at 10:29:35PM +0100, Samuel Ortiz wrote: Hi Tomas, On Tue, Feb 12, 2013 at 09:17:21PM +, Winkler, Tomas wrote: In preparation for the MEI bus code merge, we rename the mei_device structure to mei_host. struct mei_device will be used for devices on the MEI bus in order to follow exisiting driver model implementations practices. I'd like to NACK this name, we use 'host' for the host part of the MEI protocol, You can use the mei_controller, mei_adapter, and I'm not sure what else can come into mind. mei_controller sounds good to me. I prefer not to break the HW spec language. I prefer to leave it mei_device as after all it's a device on pci bus it's not a pure host controller. And call what is on the mei bus mei_cl_dev or mei_app_dev . From the HW perspective it actually talks to a client/application residing inside MEI device, it is not always a physical device like NFC. The bus is not physical neither. It's really items that we add to this bus, watchdog could be the next candidate for example. 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. thanks, greg k-h -- 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/
Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
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. Arnd -- 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/
