staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
/*
|
|
|
|
*
|
|
|
|
* Intel Management Engine Interface (Intel MEI) Linux driver
|
2012-02-10 01:25:53 +08:00
|
|
|
* Copyright (c) 2003-2012, Intel Corporation.
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms and conditions of the GNU General Public License,
|
|
|
|
* version 2, as published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope it will be useful, but WITHOUT
|
|
|
|
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
|
|
|
|
* more details.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/fcntl.h>
|
|
|
|
#include <linux/aio.h>
|
|
|
|
#include <linux/pci.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/ioctl.h>
|
|
|
|
#include <linux/cdev.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/uuid.h>
|
|
|
|
#include <linux/jiffies.h>
|
|
|
|
#include <linux/uaccess.h>
|
|
|
|
|
|
|
|
|
|
|
|
#include "mei_dev.h"
|
|
|
|
#include "hw.h"
|
2012-05-09 21:38:59 +08:00
|
|
|
#include <linux/mei.h>
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
#include "interface.h"
|
|
|
|
|
2012-10-09 22:50:20 +08:00
|
|
|
/**
|
|
|
|
* mei_io_cb_free - free mei_cb_private related memory
|
|
|
|
*
|
|
|
|
* @cb: mei callback struct
|
|
|
|
*/
|
|
|
|
void mei_io_cb_free(struct mei_cl_cb *cb)
|
|
|
|
{
|
|
|
|
if (cb == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
kfree(cb->request_buffer.data);
|
|
|
|
kfree(cb->response_buffer.data);
|
|
|
|
kfree(cb);
|
|
|
|
}
|
2012-10-11 22:35:08 +08:00
|
|
|
/**
|
|
|
|
* mei_io_cb_init - allocate and initialize io callback
|
|
|
|
*
|
|
|
|
* @cl - mei client
|
|
|
|
* @file: pointer to file structure
|
|
|
|
*
|
|
|
|
* returns mei_cl_cb pointer or NULL;
|
|
|
|
*/
|
|
|
|
struct mei_cl_cb *mei_io_cb_init(struct mei_cl *cl, struct file *fp)
|
|
|
|
{
|
|
|
|
struct mei_cl_cb *cb;
|
|
|
|
|
|
|
|
cb = kzalloc(sizeof(struct mei_cl_cb), GFP_KERNEL);
|
|
|
|
if (!cb)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
mei_io_list_init(cb);
|
|
|
|
|
|
|
|
cb->file_object = fp;
|
2012-11-11 23:37:59 +08:00
|
|
|
cb->cl = cl;
|
2012-10-11 22:35:08 +08:00
|
|
|
cb->buf_idx = 0;
|
|
|
|
return cb;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_io_cb_alloc_req_buf - allocate request buffer
|
|
|
|
*
|
|
|
|
* @cb - io callback structure
|
|
|
|
* @size: size of the buffer
|
|
|
|
*
|
|
|
|
* returns 0 on success
|
|
|
|
* -EINVAL if cb is NULL
|
|
|
|
* -ENOMEM if allocation failed
|
|
|
|
*/
|
|
|
|
int mei_io_cb_alloc_req_buf(struct mei_cl_cb *cb, size_t length)
|
|
|
|
{
|
|
|
|
if (!cb)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (length == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
cb->request_buffer.data = kmalloc(length, GFP_KERNEL);
|
|
|
|
if (!cb->request_buffer.data)
|
|
|
|
return -ENOMEM;
|
|
|
|
cb->request_buffer.size = length;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
/**
|
|
|
|
* mei_io_cb_alloc_req_buf - allocate respose buffer
|
|
|
|
*
|
|
|
|
* @cb - io callback structure
|
|
|
|
* @size: size of the buffer
|
|
|
|
*
|
|
|
|
* returns 0 on success
|
|
|
|
* -EINVAL if cb is NULL
|
|
|
|
* -ENOMEM if allocation failed
|
|
|
|
*/
|
|
|
|
int mei_io_cb_alloc_resp_buf(struct mei_cl_cb *cb, size_t length)
|
|
|
|
{
|
|
|
|
if (!cb)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (length == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
cb->response_buffer.data = kmalloc(length, GFP_KERNEL);
|
|
|
|
if (!cb->response_buffer.data)
|
|
|
|
return -ENOMEM;
|
|
|
|
cb->response_buffer.size = length;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-10-09 22:50:20 +08:00
|
|
|
|
2012-07-23 19:05:39 +08:00
|
|
|
/**
|
|
|
|
* mei_me_cl_by_id return index to me_clients for client_id
|
|
|
|
*
|
|
|
|
* @dev: the device structure
|
|
|
|
* @client_id: me client id
|
|
|
|
*
|
|
|
|
* Locking: called under "dev->device_lock" lock
|
|
|
|
*
|
|
|
|
* returns index on success, -ENOENT on failure.
|
|
|
|
*/
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
|
2012-07-23 19:05:39 +08:00
|
|
|
int mei_me_cl_by_id(struct mei_device *dev, u8 client_id)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < dev->me_clients_num; i++)
|
|
|
|
if (dev->me_clients[i].client_id == client_id)
|
|
|
|
break;
|
|
|
|
if (WARN_ON(dev->me_clients[i].client_id != client_id))
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
if (i == dev->me_clients_num)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
return i;
|
|
|
|
}
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_ioctl_connect_client - the connect to fw client IOCTL function
|
|
|
|
*
|
|
|
|
* @dev: the device structure
|
|
|
|
* @data: IOCTL connect data, input and output parameters
|
|
|
|
* @file: private data of the file object
|
|
|
|
*
|
|
|
|
* Locking: called under "dev->device_lock" lock
|
|
|
|
*
|
|
|
|
* returns 0 on success, <0 on failure.
|
|
|
|
*/
|
|
|
|
int mei_ioctl_connect_client(struct file *file,
|
|
|
|
struct mei_connect_client_data *data)
|
|
|
|
{
|
|
|
|
struct mei_device *dev;
|
|
|
|
struct mei_cl_cb *cb;
|
|
|
|
struct mei_client *client;
|
|
|
|
struct mei_cl *cl;
|
2012-11-02 03:17:14 +08:00
|
|
|
long timeout = mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
int i;
|
|
|
|
int err;
|
|
|
|
int rets;
|
|
|
|
|
|
|
|
cl = file->private_data;
|
|
|
|
if (WARN_ON(!cl || !cl->dev))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
dev = cl->dev;
|
|
|
|
|
|
|
|
dev_dbg(&dev->pdev->dev, "mei_ioctl_connect_client() Entry\n");
|
|
|
|
|
|
|
|
/* buffered ioctl cb */
|
2012-10-11 22:35:08 +08:00
|
|
|
cb = mei_io_cb_init(cl, file);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
if (!cb) {
|
|
|
|
rets = -ENOMEM;
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
|
2012-11-11 23:38:00 +08:00
|
|
|
cb->fop_type = MEI_FOP_IOCTL;
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
|
2012-08-07 05:03:56 +08:00
|
|
|
if (dev->dev_state != MEI_DEV_ENABLED) {
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
rets = -ENODEV;
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
if (cl->state != MEI_FILE_INITIALIZING &&
|
|
|
|
cl->state != MEI_FILE_DISCONNECTED) {
|
|
|
|
rets = -EBUSY;
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* find ME client we're trying to connect to */
|
2012-07-23 19:05:39 +08:00
|
|
|
i = mei_me_cl_by_uuid(dev, &data->in_client_uuid);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
if (i >= 0 && !dev->me_clients[i].props.fixed_address) {
|
|
|
|
cl->me_client_id = dev->me_clients[i].client_id;
|
|
|
|
cl->state = MEI_FILE_CONNECTING;
|
|
|
|
}
|
|
|
|
|
|
|
|
dev_dbg(&dev->pdev->dev, "Connect to FW Client ID = %d\n",
|
|
|
|
cl->me_client_id);
|
|
|
|
dev_dbg(&dev->pdev->dev, "FW Client - Protocol Version = %d\n",
|
|
|
|
dev->me_clients[i].props.protocol_version);
|
|
|
|
dev_dbg(&dev->pdev->dev, "FW Client - Max Msg Len = %d\n",
|
|
|
|
dev->me_clients[i].props.max_msg_length);
|
|
|
|
|
2012-03-12 22:18:09 +08:00
|
|
|
/* if we're connecting to amthi client then we will use the
|
|
|
|
* existing connection
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
*/
|
|
|
|
if (uuid_le_cmp(data->in_client_uuid, mei_amthi_guid) == 0) {
|
|
|
|
dev_dbg(&dev->pdev->dev, "FW Client is amthi\n");
|
|
|
|
if (dev->iamthif_cl.state != MEI_FILE_CONNECTED) {
|
|
|
|
rets = -ENODEV;
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
clear_bit(cl->host_client_id, dev->host_clients_map);
|
2012-11-11 23:38:03 +08:00
|
|
|
mei_me_cl_unlink(dev, cl);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
|
|
|
|
kfree(cl);
|
|
|
|
cl = NULL;
|
|
|
|
file->private_data = &dev->iamthif_cl;
|
|
|
|
|
|
|
|
client = &data->out_client_properties;
|
|
|
|
client->max_msg_length =
|
|
|
|
dev->me_clients[i].props.max_msg_length;
|
|
|
|
client->protocol_version =
|
|
|
|
dev->me_clients[i].props.protocol_version;
|
|
|
|
rets = dev->iamthif_cl.status;
|
|
|
|
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cl->state != MEI_FILE_CONNECTING) {
|
|
|
|
rets = -ENODEV;
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* prepare the output buffer */
|
|
|
|
client = &data->out_client_properties;
|
|
|
|
client->max_msg_length = dev->me_clients[i].props.max_msg_length;
|
|
|
|
client->protocol_version = dev->me_clients[i].props.protocol_version;
|
|
|
|
dev_dbg(&dev->pdev->dev, "Can connect?\n");
|
|
|
|
if (dev->mei_host_buffer_is_empty
|
|
|
|
&& !mei_other_client_is_connecting(dev, cl)) {
|
|
|
|
dev_dbg(&dev->pdev->dev, "Sending Connect Message\n");
|
2011-05-25 22:28:22 +08:00
|
|
|
dev->mei_host_buffer_is_empty = false;
|
2012-03-14 20:39:42 +08:00
|
|
|
if (mei_connect(dev, cl)) {
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
dev_dbg(&dev->pdev->dev, "Sending connect message - failed\n");
|
|
|
|
rets = -ENODEV;
|
|
|
|
goto end;
|
|
|
|
} else {
|
|
|
|
dev_dbg(&dev->pdev->dev, "Sending connect message - succeeded\n");
|
|
|
|
cl->timer_count = MEI_CONNECT_TIMEOUT;
|
2012-10-15 18:06:48 +08:00
|
|
|
list_add_tail(&cb->list, &dev->ctrl_rd_list.list);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
} else {
|
|
|
|
dev_dbg(&dev->pdev->dev, "Queuing the connect request due to device busy\n");
|
|
|
|
dev_dbg(&dev->pdev->dev, "add connect cb to control write list.\n");
|
2012-10-15 18:06:48 +08:00
|
|
|
list_add_tail(&cb->list, &dev->ctrl_wr_list.list);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
}
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
err = wait_event_timeout(dev->wait_recvd_msg,
|
|
|
|
(MEI_FILE_CONNECTED == cl->state ||
|
2012-11-02 03:17:14 +08:00
|
|
|
MEI_FILE_DISCONNECTED == cl->state), timeout);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
|
|
|
|
mutex_lock(&dev->device_lock);
|
|
|
|
if (MEI_FILE_CONNECTED == cl->state) {
|
|
|
|
dev_dbg(&dev->pdev->dev, "successfully connected to FW client.\n");
|
|
|
|
rets = cl->status;
|
|
|
|
goto end;
|
|
|
|
} else {
|
|
|
|
dev_dbg(&dev->pdev->dev, "failed to connect to FW client.cl->state = %d.\n",
|
|
|
|
cl->state);
|
|
|
|
if (!err) {
|
|
|
|
dev_dbg(&dev->pdev->dev,
|
|
|
|
"wait_event_interruptible_timeout failed on client"
|
|
|
|
" connect message fw response message.\n");
|
|
|
|
}
|
|
|
|
rets = -EFAULT;
|
|
|
|
|
2011-06-06 15:44:34 +08:00
|
|
|
mei_io_list_flush(&dev->ctrl_rd_list, cl);
|
|
|
|
mei_io_list_flush(&dev->ctrl_wr_list, cl);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
rets = 0;
|
|
|
|
end:
|
|
|
|
dev_dbg(&dev->pdev->dev, "free connect cb memory.");
|
2012-10-09 22:50:20 +08:00
|
|
|
mei_io_cb_free(cb);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
return rets;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_start_read - the start read client message function.
|
|
|
|
*
|
|
|
|
* @dev: the device structure
|
|
|
|
* @if_num: minor number
|
|
|
|
* @cl: private data of the file object
|
|
|
|
*
|
|
|
|
* returns 0 on success, <0 on failure.
|
|
|
|
*/
|
|
|
|
int mei_start_read(struct mei_device *dev, struct mei_cl *cl)
|
|
|
|
{
|
|
|
|
struct mei_cl_cb *cb;
|
2012-10-11 22:35:08 +08:00
|
|
|
int rets;
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
int i;
|
|
|
|
|
|
|
|
if (cl->state != MEI_FILE_CONNECTED)
|
|
|
|
return -ENODEV;
|
|
|
|
|
2012-08-07 05:03:56 +08:00
|
|
|
if (dev->dev_state != MEI_DEV_ENABLED)
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (cl->read_pending || cl->read_cb) {
|
|
|
|
dev_dbg(&dev->pdev->dev, "read is pending.\n");
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
2012-10-11 22:35:08 +08:00
|
|
|
i = mei_me_cl_by_id(dev, cl->me_client_id);
|
|
|
|
if (i < 0) {
|
|
|
|
dev_err(&dev->pdev->dev, "no such me client %d\n",
|
|
|
|
cl->me_client_id);
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
|
2012-10-11 22:35:08 +08:00
|
|
|
cb = mei_io_cb_init(cl, NULL);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
if (!cb)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2012-10-11 22:35:08 +08:00
|
|
|
rets = mei_io_cb_alloc_resp_buf(cb,
|
|
|
|
dev->me_clients[i].props.max_msg_length);
|
|
|
|
if (rets)
|
|
|
|
goto err;
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
|
2012-11-11 23:38:00 +08:00
|
|
|
cb->fop_type = MEI_FOP_READ;
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
cl->read_cb = cb;
|
|
|
|
if (dev->mei_host_buffer_is_empty) {
|
2011-05-25 22:28:22 +08:00
|
|
|
dev->mei_host_buffer_is_empty = false;
|
2012-03-14 20:39:42 +08:00
|
|
|
if (mei_send_flow_control(dev, cl)) {
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
rets = -ENODEV;
|
2012-10-11 22:35:08 +08:00
|
|
|
goto err;
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
}
|
2012-10-15 18:06:48 +08:00
|
|
|
list_add_tail(&cb->list, &dev->read_list.list);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
} else {
|
2012-10-15 18:06:48 +08:00
|
|
|
list_add_tail(&cb->list, &dev->ctrl_wr_list.list);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
}
|
|
|
|
return rets;
|
2012-10-11 22:35:08 +08:00
|
|
|
err:
|
2012-10-09 22:50:20 +08:00
|
|
|
mei_io_cb_free(cb);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
return rets;
|
|
|
|
}
|
|
|
|
|