2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-24 13:13:57 +08:00
linux-next/drivers/misc/mei/mei_dev.h

533 lines
13 KiB
C
Raw Normal View History

staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/*
*
* Intel Management Engine Interface (Intel MEI) Linux driver
* Copyright (c) 2003-2012, Intel Corporation.
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
* version 2, as published by the Free Software Foundation.
*
* This program is distributed in the hope it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
* more details.
*
*/
#ifndef _MEI_DEV_H_
#define _MEI_DEV_H_
#include <linux/types.h>
#include <linux/watchdog.h>
#include <linux/poll.h>
#include <linux/mei.h>
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
#include "hw.h"
#include "hw-me.h"
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/*
* watch dog definition
*/
#define MEI_WD_HDR_SIZE 4
#define MEI_WD_STOP_MSG_SIZE MEI_WD_HDR_SIZE
#define MEI_WD_START_MSG_SIZE (MEI_WD_HDR_SIZE + 16)
#define MEI_WD_DEFAULT_TIMEOUT 120 /* seconds */
#define MEI_WD_MIN_TIMEOUT 120 /* seconds */
#define MEI_WD_MAX_TIMEOUT 65535 /* seconds */
#define MEI_WD_STOP_TIMEOUT 10 /* msecs */
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
#define MEI_WD_STATE_INDEPENDENCE_MSG_SENT (1 << 0)
#define MEI_RD_MSG_BUF_SIZE (128 * sizeof(u32))
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/*
* AMTHI Client UUID
*/
extern const uuid_le mei_amthi_guid;
/*
* Watchdog Client UUID
*/
extern const uuid_le mei_wd_guid;
/*
* Watchdog independence state message
*/
extern const u8 mei_wd_state_independence_msg[3][4];
/*
* Number of Maximum MEI Clients
*/
#define MEI_CLIENTS_MAX 256
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/*
* Number of File descriptors/handles
* that can be opened to the driver.
*
* Limit to 253: 256 Total Clients
* minus internal client for MEI Bus Messags
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
* minus internal client for AMTHI
* minus internal client for Watchdog
*/
#define MEI_MAX_OPEN_HANDLE_COUNT (MEI_CLIENTS_MAX - 3)
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/*
* Internal Clients Number
*/
#define MEI_WD_HOST_CLIENT_ID 1
#define MEI_IAMTHIF_HOST_CLIENT_ID 2
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/* File state */
enum file_state {
MEI_FILE_INITIALIZING = 0,
MEI_FILE_CONNECTING,
MEI_FILE_CONNECTED,
MEI_FILE_DISCONNECTING,
MEI_FILE_DISCONNECTED
};
/* MEI device states */
enum mei_dev_state {
MEI_DEV_INITIALIZING = 0,
MEI_DEV_INIT_CLIENTS,
MEI_DEV_ENABLED,
MEI_DEV_RESETING,
MEI_DEV_DISABLED,
MEI_DEV_RECOVERING_FROM_RESET,
MEI_DEV_POWER_DOWN,
MEI_DEV_POWER_UP
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
};
const char *mei_dev_state_str(int state);
/* init clients states*/
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
enum mei_init_clients_states {
MEI_START_MESSAGE = 0,
MEI_ENUM_CLIENTS_MESSAGE,
MEI_CLIENT_PROPERTIES_MESSAGE
};
enum iamthif_states {
MEI_IAMTHIF_IDLE,
MEI_IAMTHIF_WRITING,
MEI_IAMTHIF_FLOW_CONTROL,
MEI_IAMTHIF_READING,
MEI_IAMTHIF_READ_COMPLETE
};
enum mei_file_transaction_states {
MEI_IDLE,
MEI_WRITING,
MEI_WRITE_COMPLETE,
MEI_FLOW_CONTROL,
MEI_READING,
MEI_READ_COMPLETE
};
enum mei_wd_states {
MEI_WD_IDLE,
MEI_WD_RUNNING,
MEI_WD_STOPPING,
};
/**
* enum mei_cb_file_ops - file operation associated with the callback
* @MEI_FOP_READ - read
* @MEI_FOP_WRITE - write
* @MEI_FOP_IOCTL - ioctl
* @MEI_FOP_OPEN - open
* @MEI_FOP_CLOSE - close
*/
enum mei_cb_file_ops {
MEI_FOP_READ = 0,
MEI_FOP_WRITE,
MEI_FOP_IOCTL,
MEI_FOP_OPEN,
MEI_FOP_CLOSE
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
};
/*
* Intel MEI message data struct
*/
struct mei_message_data {
u32 size;
unsigned char *data;
};
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/**
* struct mei_me_client - representation of me (fw) client
*
* @props - client properties
* @client_id - me client id
* @mei_flow_ctrl_creds - flow control credits
*/
struct mei_me_client {
struct mei_client_properties props;
u8 client_id;
u8 mei_flow_ctrl_creds;
};
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
struct mei_cl;
/**
* struct mei_cl_cb - file operation callback structure
*
* @cl - file client who is running this operation
* @fop_type - file operation type
*/
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
struct mei_cl_cb {
struct list_head list;
struct mei_cl *cl;
enum mei_cb_file_ops fop_type;
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
struct mei_message_data request_buffer;
struct mei_message_data response_buffer;
unsigned long buf_idx;
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
unsigned long read_time;
struct file *file_object;
};
/* MEI client instance carried as file->pirvate_data*/
struct mei_cl {
struct list_head link;
struct mei_device *dev;
enum file_state state;
wait_queue_head_t tx_wait;
wait_queue_head_t rx_wait;
wait_queue_head_t wait;
int read_pending;
int status;
/* ID of client connected */
u8 host_client_id;
u8 me_client_id;
u8 mei_flow_ctrl_creds;
u8 timer_count;
enum mei_file_transaction_states reading_state;
enum mei_file_transaction_states writing_state;
int sm_state;
struct mei_cl_cb *read_cb;
};
/**
* struct mei_device - MEI private device struct
* @mem_addr - mem mapped base register address
* @hbuf_depth - depth of host(write) buffer
* @wr_ext_msg - buffer for hbm control responses (set in read cycle)
*/
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
struct mei_device {
struct pci_dev *pdev; /* pointer to pci device struct */
/*
* lists of queues
*/
/* array of pointers to aio lists */
struct mei_cl_cb read_list; /* driver read queue */
struct mei_cl_cb write_list; /* driver write queue */
struct mei_cl_cb write_waiting_list; /* write waiting queue */
struct mei_cl_cb ctrl_wr_list; /* managed write IOCTL list */
struct mei_cl_cb ctrl_rd_list; /* managed read IOCTL list */
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/*
* list of files
*/
struct list_head file_list;
long open_handle_count;
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
void __iomem *mem_addr;
/*
* lock for the device
*/
struct mutex device_lock; /* device lock */
struct delayed_work timer_work; /* MEI timer delayed work (timeouts) */
bool recvd_msg;
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/*
* hw states of host and fw(ME)
*/
u32 host_hw_state;
u32 me_hw_state;
u8 hbuf_depth;
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/*
* waiting queue for receive message from FW
*/
wait_queue_head_t wait_recvd_msg;
wait_queue_head_t wait_stop_wd;
/*
* mei device states
*/
enum mei_dev_state dev_state;
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
enum mei_init_clients_states init_clients_state;
u16 init_clients_timer;
bool need_reset;
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
unsigned char rd_msg_buf[MEI_RD_MSG_BUF_SIZE]; /* control messages */
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
u32 rd_msg_hdr;
u32 wr_msg_buf[128]; /* used for control messages */
struct {
struct mei_msg_hdr hdr;
unsigned char data[4]; /* All HBM messages are 4 bytes */
} wr_ext_msg; /* for control responses */
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
struct hbm_version version;
struct mei_me_client *me_clients; /* Note: memory has to be allocated */
DECLARE_BITMAP(me_clients_map, MEI_CLIENTS_MAX);
DECLARE_BITMAP(host_clients_map, MEI_CLIENTS_MAX);
u8 me_clients_num;
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
u8 me_client_presentation_num;
u8 me_client_index;
bool mei_host_buffer_is_empty;
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
struct mei_cl wd_cl;
enum mei_wd_states wd_state;
bool wd_pending;
u16 wd_timeout;
unsigned char wd_data[MEI_WD_START_MSG_SIZE];
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/* amthif list for cmd waiting */
struct mei_cl_cb amthif_cmd_list;
/* driver managed amthif list for reading completed amthif cmd data */
struct mei_cl_cb amthif_rd_complete_list;
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
struct file *iamthif_file_object;
struct mei_cl iamthif_cl;
struct mei_cl_cb *iamthif_current_cb;
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
int iamthif_mtu;
unsigned long iamthif_timer;
u32 iamthif_stall_timer;
unsigned char *iamthif_msg_buf; /* Note: memory has to be allocated */
u32 iamthif_msg_buf_size;
u32 iamthif_msg_buf_index;
enum iamthif_states iamthif_state;
bool iamthif_flow_control_pending;
bool iamthif_ioctl;
bool iamthif_canceled;
struct work_struct init_work;
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
};
static inline unsigned long mei_secs_to_jiffies(unsigned long sec)
{
return msecs_to_jiffies(sec * MSEC_PER_SEC);
}
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/*
* mei init function prototypes
*/
struct mei_device *mei_device_init(struct pci_dev *pdev);
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
void mei_reset(struct mei_device *dev, int interrupts);
int mei_hw_init(struct mei_device *dev);
int mei_task_initialize_clients(void *data);
int mei_initialize_clients(struct mei_device *dev);
int mei_disconnect_host_client(struct mei_device *dev, struct mei_cl *cl);
void mei_allocate_me_clients_storage(struct mei_device *dev);
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
int mei_me_cl_link(struct mei_device *dev, struct mei_cl *cl,
const uuid_le *cguid, u8 host_client_id);
void mei_me_cl_unlink(struct mei_device *dev, struct mei_cl *cl);
int mei_me_cl_by_uuid(const struct mei_device *dev, const uuid_le *cuuid);
int mei_me_cl_by_id(struct mei_device *dev, u8 client_id);
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/*
* MEI IO Functions
*/
struct mei_cl_cb *mei_io_cb_init(struct mei_cl *cl, struct file *fp);
void mei_io_cb_free(struct mei_cl_cb *priv_cb);
int mei_io_cb_alloc_req_buf(struct mei_cl_cb *cb, size_t length);
int mei_io_cb_alloc_resp_buf(struct mei_cl_cb *cb, size_t length);
/**
* mei_io_list_init - Sets up a queue list.
*
* @list: An instance cl callback structure
*/
static inline void mei_io_list_init(struct mei_cl_cb *list)
{
INIT_LIST_HEAD(&list->list);
}
void mei_io_list_flush(struct mei_cl_cb *list, struct mei_cl *cl);
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/*
* MEI ME Client Functions
*/
struct mei_cl *mei_cl_allocate(struct mei_device *dev);
void mei_cl_init(struct mei_cl *cl, struct mei_device *dev);
int mei_cl_flush_queues(struct mei_cl *cl);
/**
* mei_cl_cmp_id - tells if file private data have same id
*
* @fe1: private data of 1. file object
* @fe2: private data of 2. file object
*
* returns true - if ids are the same and not NULL
*/
static inline bool mei_cl_cmp_id(const struct mei_cl *cl1,
const struct mei_cl *cl2)
{
return cl1 && cl2 &&
(cl1->host_client_id == cl2->host_client_id) &&
(cl1->me_client_id == cl2->me_client_id);
}
/*
* MEI Host Client Functions
*/
void mei_host_start_message(struct mei_device *dev);
void mei_host_enum_clients_message(struct mei_device *dev);
int mei_host_client_enumerate(struct mei_device *dev);
void mei_host_client_init(struct work_struct *work);
/*
* MEI interrupt functions prototype
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
*/
irqreturn_t mei_interrupt_quick_handler(int irq, void *dev_id);
irqreturn_t mei_interrupt_thread_handler(int irq, void *dev_id);
void mei_timer(struct work_struct *work);
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/*
* MEI input output function prototype
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
*/
int mei_ioctl_connect_client(struct file *file,
struct mei_connect_client_data *data);
int mei_start_read(struct mei_device *dev, struct mei_cl *cl);
/*
* AMTHIF - AMT Host Interface Functions
*/
void mei_amthif_reset_params(struct mei_device *dev);
void mei_amthif_host_init(struct mei_device *dev);
int mei_amthif_write(struct mei_device *dev, struct mei_cl_cb *priv_cb);
int mei_amthif_read(struct mei_device *dev, struct file *file,
char __user *ubuf, size_t length, loff_t *offset);
unsigned int mei_amthif_poll(struct mei_device *dev,
struct file *file, poll_table *wait);
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
int mei_amthif_release(struct mei_device *dev, struct file *file);
struct mei_cl_cb *mei_amthif_find_read_list_entry(struct mei_device *dev,
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
struct file *file);
void mei_amthif_run_next_cmd(struct mei_device *dev);
int mei_amthif_read_message(struct mei_cl_cb *complete_list,
struct mei_device *dev, struct mei_msg_hdr *mei_hdr);
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
int mei_amthif_irq_write_complete(struct mei_device *dev, s32 *slots,
struct mei_cl_cb *cb, struct mei_cl_cb *cmpl_list);
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
void mei_amthif_complete(struct mei_device *dev, struct mei_cl_cb *cb);
int mei_amthif_irq_read_message(struct mei_cl_cb *complete_list,
struct mei_device *dev, struct mei_msg_hdr *mei_hdr);
int mei_amthif_irq_read(struct mei_device *dev, s32 *slots);
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
/*
* Register Access Function
*/
/**
* mei_reg_read - Reads 32bit data from the mei device
*
* @dev: the device structure
* @offset: offset from which to read the data
*
* returns register value (u32)
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
*/
static inline u32 mei_reg_read(const struct mei_device *dev,
unsigned long offset)
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
{
return ioread32(dev->mem_addr + offset);
}
/**
* mei_reg_write - Writes 32bit data to the mei device
*
* @dev: the device structure
* @offset: offset from which to write the data
* @value: register value to write (u32)
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
*/
static inline void mei_reg_write(const struct mei_device *dev,
unsigned long offset, u32 value)
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
{
iowrite32(value, dev->mem_addr + offset);
}
/**
* mei_hcsr_read - Reads 32bit data from the host CSR
*
* @dev: the device structure
*
* returns the byte read.
*/
static inline u32 mei_hcsr_read(const struct mei_device *dev)
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
{
return mei_reg_read(dev, H_CSR);
}
/**
* mei_mecsr_read - Reads 32bit data from the ME CSR
*
* @dev: the device structure
*
* returns ME_CSR_HA register value (u32)
*/
static inline u32 mei_mecsr_read(const struct mei_device *dev)
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
{
return mei_reg_read(dev, ME_CSR_HA);
}
/**
* get_me_cb_rw - Reads 32bit data from the mei ME_CB_RW register
*
* @dev: the device structure
*
* returns ME_CB_RW register value (u32)
*/
static inline u32 mei_mecbrw_read(const struct mei_device *dev)
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
{
return mei_reg_read(dev, ME_CB_RW);
}
/*
* mei interface function prototypes
*/
void mei_hcsr_set(struct mei_device *dev);
void mei_csr_clear_his(struct mei_device *dev);
void mei_enable_interrupts(struct mei_device *dev);
void mei_disable_interrupts(struct mei_device *dev);
static inline struct mei_msg_hdr *mei_hbm_hdr(u32 *buf, size_t length)
{
struct mei_msg_hdr *hdr = (struct mei_msg_hdr *)buf;
hdr->host_addr = 0;
hdr->me_addr = 0;
hdr->length = length;
hdr->msg_complete = 1;
hdr->reserved = 0;
return hdr;
}
#define MEI_HDR_FMT "hdr:host=%02d me=%02d len=%d comp=%1d"
#define MEI_HDR_PRM(hdr) \
(hdr)->host_addr, (hdr)->me_addr, \
(hdr)->length, (hdr)->msg_complete
staging/mei: PCI device and char driver support. contains module entries and PCI driver and char device definitions (using file_operations, pci_driver struts). The HW interface is exposed on PCI interface. PCI: The MEI HW resources are memory map 32 bit registers (Host and ME Status Registers and Data Registers) and interrupt (shared, with Intel GFX on some chipsets and USB2 controller on others). The device is part of the chipsets and cannot be hotplugged. The MEI device present is determined by BIOS configuration. Probe: The driver starts the init MEI flow, that is explained in the patch "MEI driver init flow" [06/10], then schedules a timer that handles timeouts and watchdog heartbeats. Remove: The driver closes all connections and stops the watchdog. The driver expose char device that supports: open, release, write, read, ioctl, poll. Open: Upon open the driver allocates HOST data structure on behalf of application which will resides in the file's private data and assign a host ID number which will identify messages between driver client instance and MEI client. The driver also checks readiness of the device. The number of simultaneously opened instances is limited to 253. (255 - (amthi + watchdog)) Release: In release the driver sends a Disconnect Command to ME feature and clean all the data structs. IOCTL: MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT) The IOCTL links the current file descriptor to ME feature. This is done by sending MEI Bus command: 'hbm_client_connect_request' to the ME and waiting for an answer :'hbm_client_connect_response'. Upon answer reception the driver updates its and HOST data structures in file structure to indicate that the file descriptor is associated to ME feature. Each ME feature is represented by UUID which is given as an input parameter to the IOCTL, upon success connect command the IOCTL will return the ME feature properties. ME can reject CONNECT commands due to several reasons, most common are: Invalid UUID ME or feature does not exists in ME. No More Connection allowed to this is feature, usually only one connection is allowed. Write: Upon write, the driver splits the user data into several MEI messages up to 512 bytes each and sends it to the HW. If the user wants to write data to AMTHI ME feature then the drivers routes the messages through AMTHI queues. Read: In read the driver checks is a connection exists to current file descriptor and then wait until a data is available. Message might be received (by interrupt from ME) in multiple chunks. Only complete message is released to the application. Poll: Nothing special here. Waiting for see if we have data available for reading. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com> Signed-off-by: Oren Weil <oren.jer.weil@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
#endif