2019-03-12 01:10:41 +03:00
/* SPDX-License-Identifier: GPL-2.0 */
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 14:43:41 +04:00
/*
2019-11-07 01:38:41 +03:00
* Copyright ( c ) 2003 - 2019 , Intel Corporation . All rights reserved .
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 14:43:41 +04:00
* Intel Management Engine Interface ( Intel MEI ) Linux driver
*/
# ifndef _MEI_DEV_H_
# define _MEI_DEV_H_
# include <linux/types.h>
2016-01-08 01:49:21 +03:00
# include <linux/cdev.h>
2012-11-11 19:38:02 +04:00
# include <linux/poll.h>
2012-05-09 17:38:59 +04:00
# include <linux/mei.h>
2013-03-27 19:29:53 +04:00
# include <linux/mei_cl_bus.h>
2012-12-25 21:06:02 +04:00
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 14:43:41 +04:00
# include "hw.h"
2013-04-19 00:03:48 +04:00
# include "hbm.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 14:43:41 +04:00
2018-07-23 13:21:22 +03:00
# define MEI_SLOT_SIZE sizeof(u32)
# define MEI_RD_MSG_BUF_SIZE (128 * MEI_SLOT_SIZE)
2012-08-24 01:35:58 +04:00
/*
* Number of Maximum MEI Clients
*/
# define MEI_CLIENTS_MAX 256
2014-01-12 02:36:10 +04:00
/*
* maximum number of consecutive resets
*/
# define MEI_MAX_CONSEC_RESET 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 14:43:41 +04:00
/*
* Number of File descriptors / handles
* that can be opened to the driver .
*
2013-01-09 01:07:22 +04:00
* Limit to 255 : 256 Total Clients
2014-01-09 00:31:46 +04:00
* minus internal client for MEI Bus 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 14:43:41 +04:00
*/
2013-01-09 01:07:22 +04:00
# define MEI_MAX_OPEN_HANDLE_COUNT (MEI_CLIENTS_MAX - 1)
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 14:43:41 +04:00
/* File state */
enum file_state {
2016-11-16 23:51:27 +03:00
MEI_FILE_UNINITIALIZED = 0 ,
MEI_FILE_INITIALIZING ,
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 14:43:41 +04:00
MEI_FILE_CONNECTING ,
MEI_FILE_CONNECTED ,
MEI_FILE_DISCONNECTING ,
2015-05-04 09:43:52 +03:00
MEI_FILE_DISCONNECT_REPLY ,
2015-07-23 21:37:13 +03:00
MEI_FILE_DISCONNECT_REQUIRED ,
2015-05-04 09:43:52 +03:00
MEI_FILE_DISCONNECTED ,
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 14:43:41 +04:00
} ;
/* MEI device states */
2012-08-07 01:03:56 +04:00
enum mei_dev_state {
MEI_DEV_INITIALIZING = 0 ,
MEI_DEV_INIT_CLIENTS ,
MEI_DEV_ENABLED ,
2013-04-19 23:01:36 +04:00
MEI_DEV_RESETTING ,
2012-08-07 01:03:56 +04:00
MEI_DEV_DISABLED ,
2021-02-06 17:43:21 +03:00
MEI_DEV_POWERING_DOWN ,
2012-08-07 01:03:56 +04:00
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 14:43:41 +04:00
} ;
2012-08-07 01:03:56 +04:00
const char * mei_dev_state_str ( int 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 14:43:41 +04:00
enum mei_file_transaction_states {
MEI_IDLE ,
MEI_WRITING ,
MEI_WRITE_COMPLETE ,
} ;
2012-11-11 19:38:00 +04:00
/**
* enum mei_cb_file_ops - file operation associated with the callback
2014-09-29 17:31:50 +04:00
* @ MEI_FOP_READ : read
* @ MEI_FOP_WRITE : write
* @ MEI_FOP_CONNECT : connect
* @ MEI_FOP_DISCONNECT : disconnect
* @ MEI_FOP_DISCONNECT_RSP : disconnect response
2015-07-26 09:54:16 +03:00
* @ MEI_FOP_NOTIFY_START : start notification
* @ MEI_FOP_NOTIFY_STOP : stop notification
2012-11-11 19:38:00 +04:00
*/
enum mei_cb_file_ops {
MEI_FOP_READ = 0 ,
MEI_FOP_WRITE ,
2014-02-12 23:41:51 +04:00
MEI_FOP_CONNECT ,
2014-08-21 15:29:17 +04:00
MEI_FOP_DISCONNECT ,
2014-02-12 23:41:52 +04:00
MEI_FOP_DISCONNECT_RSP ,
2015-07-26 09:54:16 +03:00
MEI_FOP_NOTIFY_START ,
MEI_FOP_NOTIFY_STOP ,
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 14:43:41 +04:00
} ;
2016-11-08 19:26:08 +03:00
/**
* enum mei_cl_io_mode - io mode between driver and fw
*
* @ MEI_CL_IO_TX_BLOCKING : send is blocking
* @ MEI_CL_IO_TX_INTERNAL : internal communication between driver and FW
2016-12-03 01:15:25 +03:00
*
* @ MEI_CL_IO_RX_NONBLOCK : recv is non - blocking
2016-11-08 19:26:08 +03:00
*/
enum mei_cl_io_mode {
MEI_CL_IO_TX_BLOCKING = BIT ( 0 ) ,
MEI_CL_IO_TX_INTERNAL = BIT ( 1 ) ,
2016-12-03 01:15:25 +03:00
MEI_CL_IO_RX_NONBLOCK = BIT ( 2 ) ,
2016-11-08 19:26:08 +03:00
} ;
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 14:43:41 +04:00
/*
* Intel MEI message data struct
*/
2013-04-08 22:56:37 +04:00
struct mei_msg_data {
2016-02-08 00:35:19 +03:00
size_t size ;
2012-02-09 21:25:54 +04:00
unsigned char * data ;
2012-09-11 01:43:21 +04:00
} ;
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 14:43:41 +04:00
2018-11-22 14:11:36 +03:00
/**
* struct mei_dma_dscr - dma address descriptor
*
* @ vaddr : dma buffer virtual address
* @ daddr : dma buffer physical address
* @ size : dma buffer size
*/
struct mei_dma_dscr {
void * vaddr ;
dma_addr_t daddr ;
size_t size ;
} ;
2014-03-31 18:59:23 +04:00
/* Maximum number of processed FW status registers */
2014-11-19 18:01:38 +03:00
# define MEI_FW_STATUS_MAX 6
/* Minimal buffer for FW status string (8 bytes in dw + space or '\0') */
# define MEI_FW_STATUS_STR_SZ (MEI_FW_STATUS_MAX * (8 + 1))
2014-03-31 18:59:23 +04:00
/*
* struct mei_fw_status - storage of FW status data
*
2014-09-29 17:31:49 +04:00
* @ count : number of actually available elements in array
* @ status : FW status registers
2014-03-31 18:59:23 +04:00
*/
struct mei_fw_status {
int count ;
u32 status [ MEI_FW_STATUS_MAX ] ;
} ;
2012-12-25 21:06:05 +04:00
/**
* struct mei_me_client - representation of me ( fw ) client
*
2014-09-29 17:31:49 +04:00
* @ list : link in me client list
2015-01-11 01:07:16 +03:00
* @ refcnt : struct reference count
2014-09-29 17:31:49 +04:00
* @ props : client properties
* @ client_id : me client id
2016-07-26 01:06:04 +03:00
* @ tx_flow_ctrl_creds : flow control credits
2015-05-04 09:43:55 +03:00
* @ connect_count : number connections to this client
2015-07-23 15:08:42 +03:00
* @ bus_added : added to bus
2012-12-25 21:06:05 +04:00
*/
struct mei_me_client {
2014-08-21 15:29:13 +04:00
struct list_head list ;
2015-01-11 01:07:16 +03:00
struct kref refcnt ;
2012-12-25 21:06:05 +04:00
struct mei_client_properties props ;
u8 client_id ;
2016-07-26 01:06:04 +03:00
u8 tx_flow_ctrl_creds ;
2015-05-04 09:43:55 +03:00
u8 connect_count ;
2015-07-23 15:08:42 +03:00
u8 bus_added ;
2012-12-25 21:06:05 +04:00
} ;
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 14:43:41 +04:00
2012-11-11 19:37:59 +04:00
struct mei_cl ;
2012-11-11 19:38:00 +04:00
/**
2012-11-11 19:37:59 +04:00
* struct mei_cl_cb - file operation callback structure
*
2014-09-29 17:31:49 +04:00
* @ list : link in callback queue
* @ cl : file client who is running this operation
* @ fop_type : file operation type
2015-02-10 11:39:42 +03:00
* @ buf : buffer for data associated with the callback
2014-09-29 17:31:50 +04:00
* @ buf_idx : last read index
2020-08-18 14:51:38 +03:00
* @ vtag : virtual tag
2016-02-08 00:35:24 +03:00
* @ fp : pointer to file structure
2015-02-10 11:39:36 +03:00
* @ status : io status of the cb
2014-09-29 17:31:50 +04:00
* @ internal : communication between driver and FW flag
2016-11-08 19:26:08 +03:00
* @ blocking : transmission blocking mode
2012-11-11 19:37:59 +04:00
*/
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 14:43:41 +04:00
struct mei_cl_cb {
2012-10-15 14:06:48 +04:00
struct list_head list ;
2012-11-11 19:37:59 +04:00
struct mei_cl * cl ;
2012-11-11 19:38:00 +04:00
enum mei_cb_file_ops fop_type ;
2015-02-10 11:39:42 +03:00
struct mei_msg_data buf ;
2016-02-08 00:35:19 +03:00
size_t buf_idx ;
2020-08-18 14:51:38 +03:00
u8 vtag ;
2016-02-08 00:35:24 +03:00
const struct file * fp ;
2015-02-10 11:39:36 +03:00
int status ;
2013-12-17 17:56:56 +04:00
u32 internal : 1 ;
2016-11-08 19:26:08 +03:00
u32 blocking : 1 ;
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 14:43:41 +04:00
} ;
2020-08-18 14:51:41 +03:00
/**
* struct mei_cl_vtag - file pointer to vtag mapping structure
*
* @ list : link in map queue
* @ fp : file pointer
* @ vtag : corresponding vtag
* @ pending_read : the read is pending on this file
*/
struct mei_cl_vtag {
struct list_head list ;
const struct file * fp ;
u8 vtag ;
u8 pending_read : 1 ;
} ;
2014-09-29 17:31:50 +04:00
/**
* struct mei_cl - me client host representation
* carried in file - > private_data
*
* @ link : link in the clients list
* @ dev : mei parent device
* @ state : file operation state
* @ tx_wait : wait queue for tx completion
* @ rx_wait : wait queue for rx completion
* @ wait : wait queue for management operation
2015-07-26 09:54:19 +03:00
* @ ev_wait : notification wait queue
2015-07-26 09:54:22 +03:00
* @ ev_async : event async notification
2014-09-29 17:31:50 +04:00
* @ status : connection status
2015-05-04 09:43:54 +03:00
* @ me_cl : fw client connected
2016-06-16 17:58:57 +03:00
* @ fp : file associated with client
2014-09-29 17:31:50 +04:00
* @ host_client_id : host id
2020-08-18 14:51:41 +03:00
* @ vtag_map : vtag map
2016-07-26 01:06:04 +03:00
* @ tx_flow_ctrl_creds : transmit flow credentials
2016-07-26 01:06:03 +03:00
* @ rx_flow_ctrl_creds : receive flow credentials
2014-09-29 17:31:50 +04:00
* @ timer_count : watchdog timer for operation completion
2015-07-26 09:54:16 +03:00
* @ notify_en : notification - enabled / disabled
* @ notify_ev : pending notification event
2018-02-25 21:07:05 +03:00
* @ tx_cb_queued : number of tx callbacks in queue
2014-09-29 17:31:50 +04:00
* @ writing_state : state of the tx
2015-02-10 11:39:46 +03:00
* @ rd_pending : pending read credits
2020-08-18 14:51:40 +03:00
* @ rd_completed_lock : protects rd_completed queue
2015-02-10 11:39:46 +03:00
* @ rd_completed : completed read
2014-09-29 17:31:50 +04:00
*
2015-07-23 15:08:33 +03:00
* @ cldev : device on the mei client bus
2014-09-29 17:31:50 +04:00
*/
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 14:43:41 +04:00
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 ;
2015-07-26 09:54:19 +03:00
wait_queue_head_t ev_wait ;
2015-07-26 09:54:22 +03:00
struct fasync_struct * ev_async ;
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 14:43:41 +04:00
int status ;
2015-05-04 09:43:54 +03:00
struct mei_me_client * me_cl ;
2016-06-16 17:58:57 +03:00
const struct file * fp ;
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 14:43:41 +04:00
u8 host_client_id ;
2020-08-18 14:51:41 +03:00
struct list_head vtag_map ;
2016-07-26 01:06:04 +03:00
u8 tx_flow_ctrl_creds ;
2016-07-26 01:06:03 +03:00
u8 rx_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 14:43:41 +04:00
u8 timer_count ;
2015-07-26 09:54:16 +03:00
u8 notify_en ;
u8 notify_ev ;
2018-02-25 21:07:05 +03:00
u8 tx_cb_queued ;
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 14:43:41 +04:00
enum mei_file_transaction_states writing_state ;
2015-02-10 11:39:46 +03:00
struct list_head rd_pending ;
2020-08-18 14:51:40 +03:00
spinlock_t rd_completed_lock ; /* protects rd_completed queue */
2015-02-10 11:39:46 +03:00
struct list_head rd_completed ;
2013-03-27 19:29:56 +04:00
2015-07-23 15:08:33 +03:00
struct mei_cl_device * cldev ;
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 14:43:41 +04:00
} ;
2018-02-25 21:07:05 +03:00
# define MEI_TX_QUEUE_LIMIT_DEFAULT 50
# define MEI_TX_QUEUE_LIMIT_MAX 255
# define MEI_TX_QUEUE_LIMIT_MIN 30
2015-10-13 15:02:39 +03:00
/**
* struct mei_hw_ops - hw specific ops
2013-02-06 16:06:41 +04:00
*
2014-09-29 17:31:49 +04:00
* @ host_is_ready : query for host readiness
2015-10-13 15:02:39 +03:00
*
2014-09-29 17:31:49 +04:00
* @ hw_is_ready : query if hw is ready
* @ hw_reset : reset hw
* @ hw_start : start hw after reset
* @ hw_config : configure hw
2015-10-13 15:02:39 +03:00
*
2014-09-29 17:31:49 +04:00
* @ fw_status : get fw status registers
2019-11-07 13:44:45 +03:00
* @ trc_status : get trc status register
2014-09-29 17:31:49 +04:00
* @ pg_state : power gating state of the device
2015-06-13 08:51:17 +03:00
* @ pg_in_transition : is device now in pg transition
2014-09-29 17:31:49 +04:00
* @ pg_is_enabled : is power gating enabled
2015-10-13 15:02:39 +03:00
*
2014-09-29 17:31:49 +04:00
* @ intr_clear : clear pending interrupts
* @ intr_enable : enable interrupts
* @ intr_disable : disable interrupts
2016-12-04 16:22:58 +03:00
* @ synchronize_irq : synchronize irqs
2015-10-13 15:02:39 +03:00
*
2014-09-29 17:31:49 +04:00
* @ hbuf_free_slots : query for write buffer empty slots
* @ hbuf_is_ready : query if write buffer is empty
2018-07-23 13:21:23 +03:00
* @ hbuf_depth : query for write buffer depth
2015-10-13 15:02:39 +03:00
*
2014-09-29 17:31:49 +04:00
* @ write : write a message to FW
2015-10-13 15:02:39 +03:00
*
2014-09-29 17:31:49 +04:00
* @ rdbuf_full_slots : query how many slots are filled
2015-10-13 15:02:39 +03:00
*
2014-09-29 17:31:49 +04:00
* @ read_hdr : get first 4 bytes ( header )
* @ read : read a buffer from the FW
2013-02-06 16:06:41 +04:00
*/
struct mei_hw_ops {
2014-03-16 16:35:54 +04:00
bool ( * host_is_ready ) ( struct mei_device * dev ) ;
2013-02-06 16:06:41 +04:00
2014-03-16 16:35:54 +04:00
bool ( * hw_is_ready ) ( struct mei_device * dev ) ;
int ( * hw_reset ) ( struct mei_device * dev , bool enable ) ;
int ( * hw_start ) ( struct mei_device * dev ) ;
2019-11-07 01:38:41 +03:00
int ( * hw_config ) ( struct mei_device * dev ) ;
2013-02-06 16:06:41 +04:00
2014-09-29 17:31:43 +04:00
int ( * fw_status ) ( struct mei_device * dev , struct mei_fw_status * fw_sts ) ;
2019-11-07 13:44:45 +03:00
int ( * trc_status ) ( struct mei_device * dev , u32 * trc ) ;
2014-03-19 00:51:59 +04:00
enum mei_pg_state ( * pg_state ) ( struct mei_device * dev ) ;
2015-06-13 08:51:17 +03:00
bool ( * pg_in_transition ) ( struct mei_device * dev ) ;
2014-03-19 00:51:58 +04:00
bool ( * pg_is_enabled ) ( struct mei_device * dev ) ;
2014-03-16 16:35:54 +04:00
void ( * intr_clear ) ( struct mei_device * dev ) ;
void ( * intr_enable ) ( struct mei_device * dev ) ;
void ( * intr_disable ) ( struct mei_device * dev ) ;
2016-12-04 16:22:58 +03:00
void ( * synchronize_irq ) ( struct mei_device * dev ) ;
2013-02-06 16:06:41 +04:00
2014-03-16 16:35:54 +04:00
int ( * hbuf_free_slots ) ( struct mei_device * dev ) ;
bool ( * hbuf_is_ready ) ( struct mei_device * dev ) ;
2018-07-23 13:21:23 +03:00
u32 ( * hbuf_depth ) ( const struct mei_device * dev ) ;
2013-02-06 16:06:41 +04:00
int ( * write ) ( struct mei_device * dev ,
2018-07-31 09:35:33 +03:00
const void * hdr , size_t hdr_len ,
const void * data , size_t data_len ) ;
2013-02-06 16:06:41 +04:00
int ( * rdbuf_full_slots ) ( struct mei_device * dev ) ;
u32 ( * read_hdr ) ( const struct mei_device * dev ) ;
2014-03-16 16:35:54 +04:00
int ( * read ) ( struct mei_device * dev ,
2013-02-06 16:06:41 +04:00
unsigned char * buf , unsigned long len ) ;
} ;
2013-03-27 19:29:53 +04:00
/* MEI bus API*/
2016-02-08 00:35:41 +03:00
void mei_cl_bus_rescan_work ( struct work_struct * work ) ;
2015-09-10 10:18:06 +03:00
void mei_cl_bus_dev_fixup ( struct mei_cl_device * dev ) ;
2020-11-16 15:56:11 +03:00
ssize_t __mei_cl_send ( struct mei_cl * cl , u8 * buf , size_t length , u8 vtag ,
2016-11-08 19:26:08 +03:00
unsigned int mode ) ;
2020-11-16 15:56:11 +03:00
ssize_t __mei_cl_recv ( struct mei_cl * cl , u8 * buf , size_t length , u8 * vtag ,
2018-06-25 00:11:40 +03:00
unsigned int mode , unsigned long timeout ) ;
2016-02-08 00:35:30 +03:00
bool mei_cl_bus_rx_event ( struct mei_cl * cl ) ;
2016-02-08 00:35:31 +03:00
bool mei_cl_bus_notify_event ( struct mei_cl * cl ) ;
2015-07-23 15:08:33 +03:00
void mei_cl_bus_remove_devices ( struct mei_device * bus ) ;
2013-03-27 19:29:57 +04:00
int mei_cl_bus_init ( void ) ;
void mei_cl_bus_exit ( void ) ;
2014-09-29 17:31:50 +04:00
/**
2014-03-19 00:51:59 +04:00
* enum mei_pg_event - power gating transition events
*
* @ MEI_PG_EVENT_IDLE : the driver is not in power gating transition
* @ MEI_PG_EVENT_WAIT : the driver is waiting for a pg event to complete
* @ MEI_PG_EVENT_RECEIVED : the driver received pg event
2015-06-13 08:51:17 +03:00
* @ MEI_PG_EVENT_INTR_WAIT : the driver is waiting for a pg event interrupt
* @ MEI_PG_EVENT_INTR_RECEIVED : the driver received pg event interrupt
2014-03-19 00:51:59 +04:00
*/
enum mei_pg_event {
MEI_PG_EVENT_IDLE ,
MEI_PG_EVENT_WAIT ,
MEI_PG_EVENT_RECEIVED ,
2015-06-13 08:51:17 +03:00
MEI_PG_EVENT_INTR_WAIT ,
MEI_PG_EVENT_INTR_RECEIVED ,
2014-03-19 00:51:59 +04:00
} ;
/**
* enum mei_pg_state - device internal power gating state
*
* @ MEI_PG_OFF : device is not power gated - it is active
* @ MEI_PG_ON : device is power gated - it is in lower power state
*/
enum mei_pg_state {
MEI_PG_OFF = 0 ,
MEI_PG_ON = 1 ,
} ;
2014-09-29 17:31:33 +04:00
const char * mei_pg_state_str ( enum mei_pg_state state ) ;
2018-06-25 00:11:41 +03:00
/**
* struct mei_fw_version - MEI FW version struct
*
* @ platform : platform identifier
* @ major : major version field
* @ minor : minor version field
* @ buildno : build number version field
* @ hotfix : hotfix number version field
*/
struct mei_fw_version {
u8 platform ;
u8 major ;
u16 minor ;
u16 buildno ;
u16 hotfix ;
} ;
# define MEI_MAX_FW_VER_BLOCKS 3
2012-06-26 00:46:27 +04:00
/**
2012-11-18 17:13:15 +04:00
* struct mei_device - MEI private device struct
2014-09-29 17:31:50 +04:00
*
2014-09-29 17:31:49 +04:00
* @ dev : device on a bus
* @ cdev : character device
* @ minor : minor number allocated for device
2014-06-23 16:10:35 +04:00
*
2014-09-29 17:31:50 +04:00
* @ write_list : write pending list
* @ write_waiting_list : write completion list
* @ ctrl_wr_list : pending control write list
* @ ctrl_rd_list : pending control read list
2018-02-25 21:07:05 +03:00
* @ tx_queue_limit : tx queues per client linit
2014-08-21 15:29:21 +04:00
*
2014-09-29 17:31:50 +04:00
* @ file_list : list of opened handles
* @ open_handle_count : number of opened handles
*
* @ device_lock : big device lock
* @ timer_work : MEI timer delayed work ( timeouts )
*
* @ recvd_hw_ready : hw ready message received flag
*
* @ wait_hw_ready : wait queue for receive HW ready message form FW
* @ wait_pg : wait queue for receive PG message from FW
* @ wait_hbm_start : wait queue for receive HBM start message from FW
*
* @ reset_count : number of consecutive resets
* @ dev_state : device state
* @ hbm_state : state of host bus message protocol
* @ init_clients_timer : HBM init handshake timeout
2014-08-21 15:29:21 +04:00
*
2014-09-29 17:31:49 +04:00
* @ pg_event : power gating event
2014-09-29 17:31:50 +04:00
* @ pg_domain : runtime PM domain
*
* @ rd_msg_buf : control messages buffer
* @ rd_msg_hdr : read message header storage
2020-08-18 14:51:38 +03:00
* @ rd_msg_hdr_count : how many dwords were already read from header
2014-09-29 17:31:50 +04:00
*
2014-09-29 17:31:49 +04:00
* @ hbuf_is_ready : query if the host host / write buffer is ready
2018-11-22 14:11:36 +03:00
* @ dr_dscr : DMA ring descriptors : TX , RX , and CTRL
2014-09-29 17:31:50 +04:00
*
* @ version : HBM protocol version in use
2015-07-23 21:37:13 +03:00
* @ hbm_f_pg_supported : hbm feature pgi protocol
* @ hbm_f_dc_supported : hbm feature dynamic clients
* @ hbm_f_dot_supported : hbm feature disconnect on timeout
2015-07-26 09:54:17 +03:00
* @ hbm_f_ev_supported : hbm feature event notification
2016-02-08 00:35:38 +03:00
* @ hbm_f_fa_supported : hbm feature fixed address client
2016-02-08 00:35:42 +03:00
* @ hbm_f_ie_supported : hbm feature immediate reply to enum request
2017-01-11 02:27:21 +03:00
* @ hbm_f_os_supported : hbm feature support OS ver message
2018-07-31 09:35:36 +03:00
* @ hbm_f_dr_supported : hbm feature dma ring supported
2020-08-18 14:51:36 +03:00
* @ hbm_f_vt_supported : hbm feature vtag supported
2020-08-18 14:51:35 +03:00
* @ hbm_f_cap_supported : hbm feature capabilities message supported
2021-02-06 17:43:22 +03:00
* @ hbm_f_cd_supported : hbm feature client dma supported
2014-09-29 17:31:50 +04:00
*
2018-06-25 00:11:41 +03:00
* @ fw_ver : FW versions
*
2019-10-04 21:17:22 +03:00
* @ fw_f_fw_ver_supported : fw feature : fw version supported
*
2015-02-10 11:39:31 +03:00
* @ me_clients_rwsem : rw lock over me_clients list
2014-09-29 17:31:50 +04:00
* @ me_clients : list of FW clients
* @ me_clients_map : FW clients bit map
* @ host_clients_map : host clients id pool
*
2015-05-04 09:43:57 +03:00
* @ allow_fixed_address : allow user space to connect a fixed client
2016-02-08 00:35:38 +03:00
* @ override_fixed_address : force allow fixed address behavior
2015-05-04 09:43:57 +03:00
*
2014-09-29 17:31:50 +04:00
* @ reset_work : work item for the device reset
2016-02-08 00:35:41 +03:00
* @ bus_rescan_work : work item for the bus rescan
2014-09-29 17:31:50 +04:00
*
* @ device_list : mei client bus list
2015-07-23 15:08:42 +03:00
* @ cl_bus_lock : client bus list lock
2014-09-29 17:31:50 +04:00
*
2020-07-28 22:22:42 +03:00
* @ kind : kind of mei device
*
2014-09-29 17:31:50 +04:00
* @ dbgfs_dir : debugfs mei root directory
*
* @ ops : : hw specific operations
* @ hw : hw specific data
2012-06-26 00:46:27 +04:00
*/
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 14:43:41 +04:00
struct mei_device {
2014-09-29 17:31:41 +04:00
struct device * dev ;
2014-06-23 16:10:35 +04:00
struct cdev cdev ;
int minor ;
2017-01-27 17:32:45 +03:00
struct list_head write_list ;
struct list_head write_waiting_list ;
struct list_head ctrl_wr_list ;
struct list_head ctrl_rd_list ;
2018-02-25 21:07:05 +03:00
u8 tx_queue_limit ;
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 14:43:41 +04:00
struct list_head file_list ;
2011-05-25 18:28:22 +04:00
long open_handle_count ;
2012-12-25 21:06:04 +04:00
2014-09-29 17:31:50 +04:00
struct mutex device_lock ;
struct delayed_work timer_work ;
2013-03-11 20:27:03 +04:00
bool recvd_hw_ready ;
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 14:43:41 +04:00
/*
* waiting queue for receive message from FW
*/
2013-03-11 20:27:03 +04:00
wait_queue_head_t wait_hw_ready ;
2014-03-19 00:51:55 +04:00
wait_queue_head_t wait_pg ;
2014-08-21 15:29:19 +04:00
wait_queue_head_t wait_hbm_start ;
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 14:43:41 +04:00
/*
* mei device states
*/
2014-01-12 02:36:10 +04:00
unsigned long reset_count ;
2012-08-07 01:03:56 +04:00
enum mei_dev_state dev_state ;
2013-04-19 00:03:48 +04:00
enum mei_hbm_state hbm_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 14:43:41 +04:00
u16 init_clients_timer ;
2014-03-19 00:51:59 +04:00
/*
* Power Gating support
*/
enum mei_pg_event pg_event ;
2014-12-05 00:43:07 +03:00
# ifdef CONFIG_PM
2014-03-19 00:52:05 +04:00
struct dev_pm_domain pg_domain ;
2014-12-05 00:43:07 +03:00
# endif /* CONFIG_PM */
2014-03-19 00:51:59 +04:00
2014-09-29 17:31:50 +04:00
unsigned char rd_msg_buf [ MEI_RD_MSG_BUF_SIZE ] ;
2020-08-18 14:51:38 +03:00
u32 rd_msg_hdr [ MEI_RD_MSG_BUF_SIZE ] ;
int rd_msg_hdr_count ;
2012-12-25 21:06:10 +04:00
2013-02-06 16:06:43 +04:00
/* write buffer */
bool hbuf_is_ready ;
2018-11-22 14:11:36 +03:00
struct mei_dma_dscr dr_dscr [ DMA_DSCR_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 14:43:41 +04:00
struct hbm_version version ;
2014-08-21 15:29:21 +04:00
unsigned int hbm_f_pg_supported : 1 ;
2015-07-23 21:37:12 +03:00
unsigned int hbm_f_dc_supported : 1 ;
2015-07-23 21:37:13 +03:00
unsigned int hbm_f_dot_supported : 1 ;
2015-07-26 09:54:17 +03:00
unsigned int hbm_f_ev_supported : 1 ;
2016-02-08 00:35:38 +03:00
unsigned int hbm_f_fa_supported : 1 ;
2016-02-08 00:35:42 +03:00
unsigned int hbm_f_ie_supported : 1 ;
2017-01-11 02:27:21 +03:00
unsigned int hbm_f_os_supported : 1 ;
2018-07-31 09:35:36 +03:00
unsigned int hbm_f_dr_supported : 1 ;
2020-08-18 14:51:36 +03:00
unsigned int hbm_f_vt_supported : 1 ;
2020-08-18 14:51:35 +03:00
unsigned int hbm_f_cap_supported : 1 ;
2021-02-06 17:43:22 +03:00
unsigned int hbm_f_cd_supported : 1 ;
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 14:43:41 +04:00
2018-06-25 00:11:41 +03:00
struct mei_fw_version fw_ver [ MEI_MAX_FW_VER_BLOCKS ] ;
2019-10-04 21:17:22 +03:00
unsigned int fw_f_fw_ver_supported : 1 ;
2015-02-10 11:39:31 +03:00
struct rw_semaphore me_clients_rwsem ;
2014-08-21 15:29:13 +04:00
struct list_head me_clients ;
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 14:43:41 +04:00
DECLARE_BITMAP ( me_clients_map , MEI_CLIENTS_MAX ) ;
DECLARE_BITMAP ( host_clients_map , MEI_CLIENTS_MAX ) ;
2015-09-27 01:04:07 +03:00
bool allow_fixed_address ;
2016-02-08 00:35:38 +03:00
bool override_fixed_address ;
2015-05-04 09:43:57 +03:00
2014-01-08 22:19:21 +04:00
struct work_struct reset_work ;
2016-02-08 00:35:41 +03:00
struct work_struct bus_rescan_work ;
2013-02-06 16:06:41 +04:00
2013-03-27 19:29:56 +04:00
/* List of bus devices */
struct list_head device_list ;
2015-07-23 15:08:42 +03:00
struct mutex cl_bus_lock ;
2013-03-27 19:29:56 +04:00
2020-07-28 22:22:42 +03:00
const char * kind ;
2013-04-05 23:10:34 +04:00
# if IS_ENABLED(CONFIG_DEBUG_FS)
struct dentry * dbgfs_dir ;
# endif /* CONFIG_DEBUG_FS */
2013-02-06 16:06:41 +04:00
const struct mei_hw_ops * ops ;
2020-02-27 01:22:40 +03:00
char hw [ ] __aligned ( sizeof ( void * ) ) ;
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 14:43:41 +04:00
} ;
2012-11-01 23:17:14 +04:00
static inline unsigned long mei_secs_to_jiffies ( unsigned long sec )
{
return msecs_to_jiffies ( sec * MSEC_PER_SEC ) ;
}
2013-03-11 20:27:02 +04:00
/**
2018-07-31 09:35:33 +03:00
* mei_data2slots - get slots number from a message length
2014-09-29 17:31:50 +04:00
*
2014-09-29 17:31:49 +04:00
* @ length : size of the messages in bytes
*
* Return : number of slots
2013-03-11 20:27:02 +04:00
*/
static inline u32 mei_data2slots ( size_t length )
2018-07-31 09:35:33 +03:00
{
return DIV_ROUND_UP ( length , MEI_SLOT_SIZE ) ;
}
/**
* mei_hbm2slots - get slots number from a hbm message length
* length + size of the mei message header
*
* @ length : size of the messages in bytes
*
* Return : number of slots
*/
static inline u32 mei_hbm2slots ( size_t length )
2013-03-11 20:27:02 +04:00
{
2018-07-23 13:21:22 +03:00
return DIV_ROUND_UP ( sizeof ( struct mei_msg_hdr ) + length , MEI_SLOT_SIZE ) ;
2013-03-11 20:27:02 +04:00
}
2013-11-11 15:26:08 +04:00
/**
2014-09-29 17:31:50 +04:00
* mei_slots2data - get data in slots - bytes from slots
*
2014-09-29 17:31:49 +04:00
* @ slots : number of available slots
2014-09-29 17:31:50 +04:00
*
2014-09-29 17:31:49 +04:00
* Return : number of bytes in slots
2013-11-11 15:26:08 +04:00
*/
static inline u32 mei_slots2data ( int slots )
{
2018-07-23 13:21:22 +03:00
return slots * MEI_SLOT_SIZE ;
2013-11-11 15:26:08 +04:00
}
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 14:43:41 +04:00
/*
* mei init function prototypes
*/
2014-09-29 17:31:41 +04:00
void mei_device_init ( struct mei_device * dev ,
struct device * device ,
const struct mei_hw_ops * hw_ops ) ;
2014-01-12 02:36:09 +04:00
int mei_reset ( struct mei_device * dev ) ;
2013-03-27 18:58:28 +04:00
int mei_start ( struct mei_device * dev ) ;
2014-01-12 02:36:09 +04:00
int mei_restart ( struct mei_device * dev ) ;
2013-03-10 15:56:08 +04:00
void mei_stop ( struct mei_device * dev ) ;
2013-11-11 15:26:06 +04:00
void mei_cancel_work ( struct mei_device * dev ) ;
2011-05-25 18:28:21 +04:00
2019-04-22 09:51:07 +03:00
void mei_set_devstate ( struct mei_device * dev , enum mei_dev_state state ) ;
2018-11-22 14:11:36 +03:00
int mei_dmam_ring_alloc ( struct mei_device * dev ) ;
void mei_dmam_ring_free ( struct mei_device * dev ) ;
bool mei_dma_ring_is_allocated ( struct mei_device * dev ) ;
2018-11-22 14:11:38 +03:00
void mei_dma_ring_reset ( struct mei_device * dev ) ;
2018-11-22 14:11:39 +03:00
void mei_dma_ring_read ( struct mei_device * dev , unsigned char * buf , u32 len ) ;
2018-11-22 14:11:40 +03:00
void mei_dma_ring_write ( struct mei_device * dev , unsigned char * buf , u32 len ) ;
u32 mei_dma_ring_empty_slots ( struct mei_device * dev ) ;
2018-11-22 14:11:36 +03:00
2011-05-25 18:28:21 +04:00
/*
* 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 14:43:41 +04:00
*/
2013-02-06 16:06:42 +04:00
2011-09-07 10:03:13 +04:00
void mei_timer ( struct work_struct * work ) ;
2016-09-25 13:25:31 +03:00
void mei_schedule_stall_timer ( struct mei_device * dev ) ;
2013-02-06 16:06:42 +04:00
int mei_irq_read_handler ( struct mei_device * dev ,
2017-01-27 17:32:45 +03:00
struct list_head * cmpl_list , s32 * slots ) ;
2013-02-06 16:06:42 +04:00
2017-01-27 17:32:45 +03:00
int mei_irq_write_handler ( struct mei_device * dev , struct list_head * cmpl_list ) ;
void mei_irq_compl_handler ( struct mei_device * dev , struct list_head * 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 14:43:41 +04:00
/*
* Register Access Function
*/
2014-05-13 02:30:53 +04:00
2019-11-07 01:38:41 +03:00
static inline int mei_hw_config ( struct mei_device * dev )
2013-02-06 16:06:41 +04:00
{
2019-11-07 01:38:41 +03:00
return dev - > ops - > hw_config ( dev ) ;
2013-02-06 16:06:41 +04:00
}
2014-03-19 00:51:58 +04:00
2014-03-19 00:51:59 +04:00
static inline enum mei_pg_state mei_pg_state ( struct mei_device * dev )
{
return dev - > ops - > pg_state ( dev ) ;
}
2015-06-13 08:51:17 +03:00
static inline bool mei_pg_in_transition ( struct mei_device * dev )
{
return dev - > ops - > pg_in_transition ( dev ) ;
}
2014-03-19 00:51:58 +04:00
static inline bool mei_pg_is_enabled ( struct mei_device * dev )
{
return dev - > ops - > pg_is_enabled ( dev ) ;
}
2013-06-23 11:42:49 +04:00
static inline int mei_hw_reset ( struct mei_device * dev , bool enable )
2013-02-06 16:06:41 +04:00
{
2013-06-23 11:42:49 +04:00
return dev - > ops - > hw_reset ( dev , enable ) ;
2013-02-06 16:06:41 +04:00
}
2013-06-23 23:49:04 +04:00
static inline int mei_hw_start ( struct mei_device * dev )
2013-03-11 20:27:03 +04:00
{
2013-06-23 23:49:04 +04:00
return dev - > ops - > hw_start ( dev ) ;
2013-03-11 20:27:03 +04:00
}
2013-02-06 16:06:41 +04:00
static inline void mei_clear_interrupts ( struct mei_device * dev )
{
dev - > ops - > intr_clear ( dev ) ;
}
static inline void mei_enable_interrupts ( struct mei_device * dev )
{
dev - > ops - > intr_enable ( 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 14:43:41 +04:00
2013-02-06 16:06:41 +04:00
static inline void mei_disable_interrupts ( struct mei_device * dev )
{
dev - > ops - > intr_disable ( 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 14:43:41 +04:00
2016-12-04 16:22:58 +03:00
static inline void mei_synchronize_irq ( struct mei_device * dev )
{
dev - > ops - > synchronize_irq ( dev ) ;
}
2013-02-06 16:06:41 +04:00
static inline bool mei_host_is_ready ( struct mei_device * dev )
{
return dev - > ops - > host_is_ready ( dev ) ;
}
static inline bool mei_hw_is_ready ( struct mei_device * dev )
{
return dev - > ops - > hw_is_ready ( dev ) ;
}
2013-01-09 01:07:31 +04:00
2013-02-06 16:06:41 +04:00
static inline bool mei_hbuf_is_ready ( struct mei_device * dev )
{
return dev - > ops - > hbuf_is_ready ( 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 14:43:41 +04:00
2013-02-06 16:06:41 +04:00
static inline int mei_hbuf_empty_slots ( struct mei_device * dev )
{
return dev - > ops - > hbuf_free_slots ( dev ) ;
}
2013-01-09 01:07:29 +04:00
2018-07-23 13:21:23 +03:00
static inline u32 mei_hbuf_depth ( const struct mei_device * dev )
2013-02-06 16:06:41 +04:00
{
2018-07-23 13:21:23 +03:00
return dev - > ops - > hbuf_depth ( dev ) ;
2013-02-06 16:06:41 +04:00
}
2012-12-25 21:06:06 +04:00
2013-02-06 16:06:41 +04:00
static inline int mei_write_message ( struct mei_device * dev ,
2018-07-31 09:35:33 +03:00
const void * hdr , size_t hdr_len ,
const void * data , size_t data_len )
2013-02-06 16:06:41 +04:00
{
2018-07-31 09:35:33 +03:00
return dev - > ops - > write ( dev , hdr , hdr_len , data , data_len ) ;
2013-02-06 16:06:41 +04:00
}
static inline u32 mei_read_hdr ( const struct mei_device * dev )
{
return dev - > ops - > read_hdr ( dev ) ;
}
static inline void mei_read_slots ( struct mei_device * dev ,
unsigned char * buf , unsigned long len )
{
dev - > ops - > read ( dev , buf , len ) ;
}
static inline int mei_count_full_read_slots ( struct mei_device * dev )
{
return dev - > ops - > rdbuf_full_slots ( dev ) ;
}
2012-11-18 17:13:14 +04:00
2019-11-07 13:44:45 +03:00
static inline int mei_trc_status ( struct mei_device * dev , u32 * trc )
{
if ( dev - > ops - > trc_status )
return dev - > ops - > trc_status ( dev , trc ) ;
return - EOPNOTSUPP ;
}
2014-09-29 17:31:43 +04:00
static inline int mei_fw_status ( struct mei_device * dev ,
struct mei_fw_status * fw_status )
{
return dev - > ops - > fw_status ( dev , fw_status ) ;
}
2014-03-31 18:59:23 +04:00
2014-02-19 19:35:47 +04:00
bool mei_hbuf_acquire ( struct mei_device * dev ) ;
2014-03-19 00:52:01 +04:00
bool mei_write_is_idle ( struct mei_device * dev ) ;
2013-04-05 23:10:34 +04:00
# if IS_ENABLED(CONFIG_DEBUG_FS)
2019-06-11 21:38:16 +03:00
void mei_dbgfs_register ( struct mei_device * dev , const char * name ) ;
2013-04-05 23:10:34 +04:00
void mei_dbgfs_deregister ( struct mei_device * dev ) ;
# else
2019-06-11 21:38:16 +03:00
static inline void mei_dbgfs_register ( struct mei_device * dev , const char * name ) { }
2013-04-05 23:10:34 +04:00
static inline void mei_dbgfs_deregister ( struct mei_device * dev ) { }
# endif /* CONFIG_DEBUG_FS */
2014-06-23 16:10:35 +04:00
int mei_register ( struct mei_device * dev , struct device * parent ) ;
2013-04-05 23:10:34 +04:00
void mei_deregister ( struct mei_device * dev ) ;
2013-02-06 16:06:39 +04:00
2020-08-18 14:51:38 +03:00
# define MEI_HDR_FMT "hdr:host=%02d me=%02d len=%d dma=%1d ext=%1d internal=%1d comp=%1d"
2012-12-25 21:06:00 +04:00
# define MEI_HDR_PRM(hdr) \
( hdr ) - > host_addr , ( hdr ) - > me_addr , \
2020-08-18 14:51:38 +03:00
( hdr ) - > length , ( hdr ) - > dma_ring , ( hdr ) - > extended , \
( hdr ) - > internal , ( hdr ) - > msg_complete
2012-12-25 21:06:00 +04:00
2014-11-19 18:01:38 +03:00
ssize_t mei_fw_status2str ( struct mei_fw_status * fw_sts , char * buf , size_t len ) ;
/**
* mei_fw_status_str - fetch and convert fw status registers to printable string
*
* @ dev : the device structure
* @ buf : string buffer at minimal size MEI_FW_STATUS_STR_SZ
* @ len : buffer len must be > = MEI_FW_STATUS_STR_SZ
*
* Return : number of bytes written or < 0 on failure
*/
static inline ssize_t mei_fw_status_str ( struct mei_device * dev ,
char * buf , size_t len )
{
struct mei_fw_status fw_status ;
int ret ;
buf [ 0 ] = ' \0 ' ;
ret = mei_fw_status ( dev , & fw_status ) ;
if ( ret )
return ret ;
ret = mei_fw_status2str ( & fw_status , buf , MEI_FW_STATUS_STR_SZ ) ;
return ret ;
}
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 14:43:41 +04:00
# endif
