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/pci.h>
|
|
|
|
#include <linux/sched.h>
|
2013-01-09 05:07:13 +08:00
|
|
|
#include <linux/wait.h>
|
|
|
|
#include <linux/delay.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
|
|
|
|
2012-05-09 21:38:59 +08:00
|
|
|
#include <linux/mei.h>
|
2012-12-26 01:06:03 +08:00
|
|
|
|
|
|
|
#include "mei_dev.h"
|
2013-01-09 05:07:12 +08:00
|
|
|
#include "hbm.h"
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 18:43:41 +08:00
|
|
|
#include "interface.h"
|
|
|
|
|
2013-01-09 05:07:13 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_io_list_flush - removes list entry belonging to cl.
|
|
|
|
*
|
|
|
|
* @list: An instance of our list structure
|
|
|
|
* @cl: host client
|
|
|
|
*/
|
|
|
|
void mei_io_list_flush(struct mei_cl_cb *list, struct mei_cl *cl)
|
|
|
|
{
|
|
|
|
struct mei_cl_cb *cb;
|
|
|
|
struct mei_cl_cb *next;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(cb, next, &list->list, list) {
|
|
|
|
if (cb->cl && mei_cl_cmp_id(cl, cb->cl))
|
|
|
|
list_del(&cb->list);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
}
|
2013-01-09 05:07:13 +08:00
|
|
|
|
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
|
|
|
|
2013-01-09 05:07:13 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_cl_flush_queues - flushes queue lists belonging to cl.
|
|
|
|
*
|
|
|
|
* @dev: the device structure
|
|
|
|
* @cl: host client
|
|
|
|
*/
|
|
|
|
int mei_cl_flush_queues(struct mei_cl *cl)
|
|
|
|
{
|
|
|
|
if (!cl || !cl->dev)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
dev_dbg(&cl->dev->pdev->dev, "remove list entry belonging to cl\n");
|
|
|
|
mei_io_list_flush(&cl->dev->read_list, cl);
|
|
|
|
mei_io_list_flush(&cl->dev->write_list, cl);
|
|
|
|
mei_io_list_flush(&cl->dev->write_waiting_list, cl);
|
|
|
|
mei_io_list_flush(&cl->dev->ctrl_wr_list, cl);
|
|
|
|
mei_io_list_flush(&cl->dev->ctrl_rd_list, cl);
|
|
|
|
mei_io_list_flush(&cl->dev->amthif_cmd_list, cl);
|
|
|
|
mei_io_list_flush(&cl->dev->amthif_rd_complete_list, cl);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_me_cl_by_uuid - locate index of me client
|
|
|
|
*
|
|
|
|
* @dev: mei device
|
|
|
|
* returns me client index or -ENOENT if not found
|
|
|
|
*/
|
|
|
|
int mei_me_cl_by_uuid(const struct mei_device *dev, const uuid_le *uuid)
|
|
|
|
{
|
|
|
|
int i, res = -ENOENT;
|
|
|
|
|
|
|
|
for (i = 0; i < dev->me_clients_num; ++i)
|
|
|
|
if (uuid_le_cmp(*uuid,
|
|
|
|
dev->me_clients[i].props.protocol_name) == 0) {
|
|
|
|
res = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2013-01-09 05:07:13 +08:00
|
|
|
/**
|
|
|
|
* mei_cl_init - initializes intialize cl.
|
|
|
|
*
|
|
|
|
* @cl: host client to be initialized
|
|
|
|
* @dev: mei device
|
|
|
|
*/
|
|
|
|
void mei_cl_init(struct mei_cl *cl, struct mei_device *dev)
|
|
|
|
{
|
|
|
|
memset(cl, 0, sizeof(struct mei_cl));
|
|
|
|
init_waitqueue_head(&cl->wait);
|
|
|
|
init_waitqueue_head(&cl->rx_wait);
|
|
|
|
init_waitqueue_head(&cl->tx_wait);
|
|
|
|
INIT_LIST_HEAD(&cl->link);
|
|
|
|
cl->reading_state = MEI_IDLE;
|
|
|
|
cl->writing_state = MEI_IDLE;
|
|
|
|
cl->dev = dev;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_cl_allocate - allocates cl structure and sets it up.
|
|
|
|
*
|
|
|
|
* @dev: mei device
|
|
|
|
* returns The allocated file or NULL on failure
|
|
|
|
*/
|
|
|
|
struct mei_cl *mei_cl_allocate(struct mei_device *dev)
|
|
|
|
{
|
|
|
|
struct mei_cl *cl;
|
|
|
|
|
|
|
|
cl = kmalloc(sizeof(struct mei_cl), GFP_KERNEL);
|
|
|
|
if (!cl)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
mei_cl_init(cl, dev);
|
|
|
|
|
|
|
|
return cl;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_me_cl_link - create link between host and me clinet and add
|
|
|
|
* me_cl to the list
|
|
|
|
*
|
|
|
|
* @dev: the device structure
|
|
|
|
* @cl: link between me and host client assocated with opened file descriptor
|
|
|
|
* @uuid: uuid of ME client
|
|
|
|
* @client_id: id of the host client
|
|
|
|
*
|
|
|
|
* returns ME client index if ME client
|
|
|
|
* -EINVAL on incorrect values
|
|
|
|
* -ENONET if client not found
|
|
|
|
*/
|
|
|
|
int mei_me_cl_link(struct mei_device *dev, struct mei_cl *cl,
|
|
|
|
const uuid_le *uuid, u8 host_cl_id)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!dev || !cl || !uuid)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* check for valid client id */
|
|
|
|
i = mei_me_cl_by_uuid(dev, uuid);
|
|
|
|
if (i >= 0) {
|
|
|
|
cl->me_client_id = dev->me_clients[i].client_id;
|
|
|
|
cl->state = MEI_FILE_CONNECTING;
|
|
|
|
cl->host_client_id = host_cl_id;
|
|
|
|
|
|
|
|
list_add_tail(&cl->link, &dev->file_list);
|
|
|
|
return (u8)i;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
/**
|
|
|
|
* mei_me_cl_unlink - remove me_cl from the list
|
|
|
|
*
|
|
|
|
* @dev: the device structure
|
|
|
|
* @host_client_id: host client id to be removed
|
|
|
|
*/
|
|
|
|
void mei_me_cl_unlink(struct mei_device *dev, struct mei_cl *cl)
|
|
|
|
{
|
|
|
|
struct mei_cl *pos, *next;
|
|
|
|
list_for_each_entry_safe(pos, next, &dev->file_list, link) {
|
|
|
|
if (cl->host_client_id == pos->host_client_id) {
|
|
|
|
dev_dbg(&dev->pdev->dev, "remove host client = %d, ME client = %d\n",
|
|
|
|
pos->host_client_id, pos->me_client_id);
|
|
|
|
list_del_init(&pos->link);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void mei_host_client_init(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct mei_device *dev = container_of(work,
|
|
|
|
struct mei_device, init_work);
|
|
|
|
struct mei_client_properties *client_props;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
mutex_lock(&dev->device_lock);
|
|
|
|
|
|
|
|
bitmap_zero(dev->host_clients_map, MEI_CLIENTS_MAX);
|
|
|
|
dev->open_handle_count = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Reserving the first three client IDs
|
|
|
|
* 0: Reserved for MEI Bus Message communications
|
|
|
|
* 1: Reserved for Watchdog
|
|
|
|
* 2: Reserved for AMTHI
|
|
|
|
*/
|
|
|
|
bitmap_set(dev->host_clients_map, 0, 3);
|
|
|
|
|
|
|
|
for (i = 0; i < dev->me_clients_num; i++) {
|
|
|
|
client_props = &dev->me_clients[i].props;
|
|
|
|
|
|
|
|
if (!uuid_le_cmp(client_props->protocol_name, mei_amthi_guid))
|
|
|
|
mei_amthif_host_init(dev);
|
|
|
|
else if (!uuid_le_cmp(client_props->protocol_name, mei_wd_guid))
|
|
|
|
mei_wd_host_init(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
dev->dev_state = MEI_DEV_ENABLED;
|
|
|
|
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_disconnect_host_client - sends disconnect message to fw from host client.
|
|
|
|
*
|
|
|
|
* @dev: the device structure
|
|
|
|
* @cl: private data of the file object
|
|
|
|
*
|
|
|
|
* Locking: called under "dev->device_lock" lock
|
|
|
|
*
|
|
|
|
* returns 0 on success, <0 on failure.
|
|
|
|
*/
|
|
|
|
int mei_disconnect_host_client(struct mei_device *dev, struct mei_cl *cl)
|
|
|
|
{
|
|
|
|
struct mei_cl_cb *cb;
|
|
|
|
int rets, err;
|
|
|
|
|
|
|
|
if (!dev || !cl)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (cl->state != MEI_FILE_DISCONNECTING)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
cb = mei_io_cb_init(cl, NULL);
|
|
|
|
if (!cb)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
cb->fop_type = MEI_FOP_CLOSE;
|
|
|
|
if (dev->mei_host_buffer_is_empty) {
|
|
|
|
dev->mei_host_buffer_is_empty = false;
|
|
|
|
if (mei_hbm_cl_disconnect_req(dev, cl)) {
|
|
|
|
rets = -ENODEV;
|
|
|
|
dev_err(&dev->pdev->dev, "failed to disconnect.\n");
|
|
|
|
goto free;
|
|
|
|
}
|
|
|
|
mdelay(10); /* Wait for hardware disconnection ready */
|
|
|
|
list_add_tail(&cb->list, &dev->ctrl_rd_list.list);
|
|
|
|
} else {
|
|
|
|
dev_dbg(&dev->pdev->dev, "add disconnect cb to control write list\n");
|
|
|
|
list_add_tail(&cb->list, &dev->ctrl_wr_list.list);
|
|
|
|
|
|
|
|
}
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
|
|
|
|
err = wait_event_timeout(dev->wait_recvd_msg,
|
|
|
|
MEI_FILE_DISCONNECTED == cl->state,
|
|
|
|
mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT));
|
|
|
|
|
|
|
|
mutex_lock(&dev->device_lock);
|
|
|
|
if (MEI_FILE_DISCONNECTED == cl->state) {
|
|
|
|
rets = 0;
|
|
|
|
dev_dbg(&dev->pdev->dev, "successfully disconnected from FW client.\n");
|
|
|
|
} else {
|
|
|
|
rets = -ENODEV;
|
|
|
|
if (MEI_FILE_DISCONNECTED != cl->state)
|
|
|
|
dev_dbg(&dev->pdev->dev, "wrong status client disconnect.\n");
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
dev_dbg(&dev->pdev->dev,
|
|
|
|
"wait failed disconnect err=%08x\n",
|
|
|
|
err);
|
|
|
|
|
|
|
|
dev_dbg(&dev->pdev->dev, "failed to disconnect from FW client.\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
mei_io_list_flush(&dev->ctrl_rd_list, cl);
|
|
|
|
mei_io_list_flush(&dev->ctrl_wr_list, cl);
|
|
|
|
free:
|
|
|
|
mei_io_cb_free(cb);
|
|
|
|
return rets;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_other_client_is_connecting - checks if other
|
|
|
|
* client with the same client id is connected.
|
|
|
|
*
|
|
|
|
* @dev: the device structure
|
|
|
|
* @cl: private data of the file object
|
|
|
|
*
|
|
|
|
* returns 1 if other client is connected, 0 - otherwise.
|
|
|
|
*/
|
|
|
|
int mei_other_client_is_connecting(struct mei_device *dev,
|
|
|
|
struct mei_cl *cl)
|
|
|
|
{
|
|
|
|
struct mei_cl *cl_pos = NULL;
|
|
|
|
struct mei_cl *cl_next = NULL;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(cl_pos, cl_next, &dev->file_list, link) {
|
|
|
|
if ((cl_pos->state == MEI_FILE_CONNECTING) &&
|
|
|
|
(cl_pos != cl) &&
|
|
|
|
cl->me_client_id == cl_pos->me_client_id)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_flow_ctrl_creds - checks flow_control credentials.
|
|
|
|
*
|
|
|
|
* @dev: the device structure
|
|
|
|
* @cl: private data of the file object
|
|
|
|
*
|
|
|
|
* returns 1 if mei_flow_ctrl_creds >0, 0 - otherwise.
|
|
|
|
* -ENOENT if mei_cl is not present
|
|
|
|
* -EINVAL if single_recv_buf == 0
|
|
|
|
*/
|
|
|
|
int mei_flow_ctrl_creds(struct mei_device *dev, struct mei_cl *cl)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!dev->me_clients_num)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (cl->mei_flow_ctrl_creds > 0)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
for (i = 0; i < dev->me_clients_num; i++) {
|
|
|
|
struct mei_me_client *me_cl = &dev->me_clients[i];
|
|
|
|
if (me_cl->client_id == cl->me_client_id) {
|
|
|
|
if (me_cl->mei_flow_ctrl_creds) {
|
|
|
|
if (WARN_ON(me_cl->props.single_recv_buf == 0))
|
|
|
|
return -EINVAL;
|
|
|
|
return 1;
|
|
|
|
} else {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_flow_ctrl_reduce - reduces flow_control.
|
|
|
|
*
|
|
|
|
* @dev: the device structure
|
|
|
|
* @cl: private data of the file object
|
|
|
|
* @returns
|
|
|
|
* 0 on success
|
|
|
|
* -ENOENT when me client is not found
|
|
|
|
* -EINVAL when ctrl credits are <= 0
|
|
|
|
*/
|
|
|
|
int mei_flow_ctrl_reduce(struct mei_device *dev, struct mei_cl *cl)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!dev->me_clients_num)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
for (i = 0; i < dev->me_clients_num; i++) {
|
|
|
|
struct mei_me_client *me_cl = &dev->me_clients[i];
|
|
|
|
if (me_cl->client_id == cl->me_client_id) {
|
|
|
|
if (me_cl->props.single_recv_buf != 0) {
|
|
|
|
if (WARN_ON(me_cl->mei_flow_ctrl_creds <= 0))
|
|
|
|
return -EINVAL;
|
|
|
|
dev->me_clients[i].mei_flow_ctrl_creds--;
|
|
|
|
} else {
|
|
|
|
if (WARN_ON(cl->mei_flow_ctrl_creds <= 0))
|
|
|
|
return -EINVAL;
|
|
|
|
cl->mei_flow_ctrl_creds--;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
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-12-26 01:06:11 +08:00
|
|
|
if (mei_hbm_cl_connect_req(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-12-26 01:06:11 +08:00
|
|
|
if (mei_hbm_cl_flow_control_req(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;
|
|
|
|
}
|
|
|
|
|