2019-03-12 01:10:41 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
/*
|
2020-07-23 17:59:23 +03:00
|
|
|
* Copyright (c) 2003-2020, Intel Corporation. All rights reserved.
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
* Intel Management Engine Interface (Intel MEI) Linux driver
|
|
|
|
*/
|
2019-03-12 01:10:41 +03:00
|
|
|
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/moduleparam.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/device.h>
|
2014-09-29 17:31:46 +04:00
|
|
|
#include <linux/slab.h>
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/fcntl.h>
|
|
|
|
#include <linux/poll.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/ioctl.h>
|
|
|
|
#include <linux/cdev.h>
|
2017-02-02 21:15:33 +03:00
|
|
|
#include <linux/sched/signal.h>
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
#include <linux/uuid.h>
|
|
|
|
#include <linux/compat.h>
|
|
|
|
#include <linux/jiffies.h>
|
|
|
|
#include <linux/interrupt.h>
|
|
|
|
|
2012-05-09 17:38:59 +04:00
|
|
|
#include <linux/mei.h>
|
2012-12-25 21:06:03 +04:00
|
|
|
|
|
|
|
#include "mei_dev.h"
|
2013-01-09 01:07:14 +04:00
|
|
|
#include "client.h"
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|
2019-04-22 09:51:07 +03:00
|
|
|
static struct class *mei_class;
|
|
|
|
static dev_t mei_devt;
|
|
|
|
#define MEI_MAX_DEVS MINORMASK
|
|
|
|
static DEFINE_MUTEX(mei_minor_lock);
|
|
|
|
static DEFINE_IDR(mei_idr);
|
|
|
|
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
/**
|
|
|
|
* mei_open - the open function
|
|
|
|
*
|
|
|
|
* @inode: pointer to inode structure
|
|
|
|
* @file: pointer to file structure
|
2014-01-09 00:31:46 +04:00
|
|
|
*
|
2014-09-29 17:31:49 +04:00
|
|
|
* Return: 0 on success, <0 on error
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
*/
|
|
|
|
static int mei_open(struct inode *inode, struct file *file)
|
|
|
|
{
|
|
|
|
struct mei_device *dev;
|
2014-06-23 16:10:35 +04:00
|
|
|
struct mei_cl *cl;
|
2013-02-06 16:06:39 +04:00
|
|
|
|
2011-11-13 11:41:15 +04:00
|
|
|
int 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 14:43:41 +04:00
|
|
|
|
2014-06-23 16:10:35 +04:00
|
|
|
dev = container_of(inode->i_cdev, struct mei_device, cdev);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|
|
|
|
mutex_lock(&dev->device_lock);
|
2013-09-17 00:44:46 +04:00
|
|
|
|
2012-08-07 01:03:56 +04:00
|
|
|
if (dev->dev_state != MEI_DEV_ENABLED) {
|
2014-09-29 17:31:42 +04:00
|
|
|
dev_dbg(dev->dev, "dev_state != MEI_ENABLED dev_state = %s\n",
|
2012-08-07 01:03:56 +04:00
|
|
|
mei_dev_state_str(dev->dev_state));
|
2015-02-10 11:39:44 +03:00
|
|
|
err = -ENODEV;
|
2013-09-17 00:44:46 +04:00
|
|
|
goto err_unlock;
|
2012-09-11 01:43:20 +04:00
|
|
|
}
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|
2016-02-08 00:35:40 +03:00
|
|
|
cl = mei_cl_alloc_linked(dev);
|
2015-02-10 11:39:44 +03:00
|
|
|
if (IS_ERR(cl)) {
|
|
|
|
err = PTR_ERR(cl);
|
2013-09-17 00:44:46 +04:00
|
|
|
goto err_unlock;
|
2015-02-10 11:39:44 +03:00
|
|
|
}
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|
2016-06-16 17:58:57 +03:00
|
|
|
cl->fp = 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 14:43:41 +04:00
|
|
|
file->private_data = cl;
|
2013-09-17 00:44:46 +04:00
|
|
|
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
|
2011-11-13 11:41:14 +04:00
|
|
|
return nonseekable_open(inode, 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 14:43:41 +04:00
|
|
|
|
2013-09-17 00:44:46 +04:00
|
|
|
err_unlock:
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2020-08-18 14:51:41 +03:00
|
|
|
/**
|
|
|
|
* mei_cl_vtag_remove_by_fp - remove vtag that corresponds to fp from list
|
|
|
|
*
|
|
|
|
* @cl: host client
|
|
|
|
* @fp: pointer to file structure
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
static void mei_cl_vtag_remove_by_fp(const struct mei_cl *cl,
|
|
|
|
const struct file *fp)
|
|
|
|
{
|
|
|
|
struct mei_cl_vtag *vtag_l, *next;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(vtag_l, next, &cl->vtag_map, list) {
|
|
|
|
if (vtag_l->fp == fp) {
|
|
|
|
list_del(&vtag_l->list);
|
|
|
|
kfree(vtag_l);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
/**
|
|
|
|
* mei_release - the release function
|
|
|
|
*
|
|
|
|
* @inode: pointer to inode structure
|
|
|
|
* @file: pointer to file structure
|
|
|
|
*
|
2014-09-29 17:31:49 +04:00
|
|
|
* Return: 0 on success, <0 on error
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
*/
|
|
|
|
static int mei_release(struct inode *inode, struct file *file)
|
|
|
|
{
|
|
|
|
struct mei_cl *cl = file->private_data;
|
|
|
|
struct mei_device *dev;
|
2015-05-04 09:43:52 +03: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 14:43:41 +04:00
|
|
|
|
|
|
|
if (WARN_ON(!cl || !cl->dev))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
dev = cl->dev;
|
|
|
|
|
|
|
|
mutex_lock(&dev->device_lock);
|
2017-03-20 16:04:03 +03:00
|
|
|
|
2020-08-18 14:51:41 +03:00
|
|
|
mei_cl_vtag_remove_by_fp(cl, file);
|
|
|
|
|
|
|
|
if (!list_empty(&cl->vtag_map)) {
|
|
|
|
cl_dbg(dev, cl, "not the last vtag\n");
|
|
|
|
mei_cl_flush_queues(cl, file);
|
|
|
|
rets = 0;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2015-05-04 09:43:52 +03:00
|
|
|
rets = mei_cl_disconnect(cl);
|
2020-08-18 14:51:41 +03:00
|
|
|
/*
|
|
|
|
* Check again: This is necessary since disconnect releases the lock
|
|
|
|
* and another client can connect in the meantime.
|
|
|
|
*/
|
|
|
|
if (!list_empty(&cl->vtag_map)) {
|
|
|
|
cl_dbg(dev, cl, "not the last vtag after disconnect\n");
|
|
|
|
mei_cl_flush_queues(cl, file);
|
|
|
|
goto out;
|
|
|
|
}
|
2015-05-04 09:43:52 +03:00
|
|
|
|
2020-08-18 14:51:41 +03:00
|
|
|
mei_cl_flush_queues(cl, NULL);
|
2014-03-16 16:35:55 +04:00
|
|
|
cl_dbg(dev, cl, "removing\n");
|
2012-11-11 19:38:01 +04:00
|
|
|
|
2013-01-09 01:07:14 +04:00
|
|
|
mei_cl_unlink(cl);
|
2020-08-18 14:51:41 +03:00
|
|
|
kfree(cl);
|
2012-11-11 19:38:01 +04:00
|
|
|
|
2020-08-18 14:51:41 +03:00
|
|
|
out:
|
2012-11-11 19:38:01 +04:00
|
|
|
file->private_data = 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 14:43:41 +04:00
|
|
|
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
return rets;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_read - the read function.
|
|
|
|
*
|
|
|
|
* @file: pointer to file structure
|
|
|
|
* @ubuf: pointer to user buffer
|
|
|
|
* @length: buffer length
|
|
|
|
* @offset: data offset in buffer
|
|
|
|
*
|
2014-09-29 17:31:49 +04:00
|
|
|
* Return: >=0 data length on success , <0 on error
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
*/
|
|
|
|
static ssize_t mei_read(struct file *file, char __user *ubuf,
|
2011-12-14 01:39:34 +04:00
|
|
|
size_t length, loff_t *offset)
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
{
|
|
|
|
struct mei_cl *cl = file->private_data;
|
|
|
|
struct mei_device *dev;
|
2015-02-10 11:39:46 +03:00
|
|
|
struct mei_cl_cb *cb = NULL;
|
2016-07-26 01:06:06 +03:00
|
|
|
bool nonblock = !!(file->f_flags & O_NONBLOCK);
|
2018-07-12 17:10:10 +03:00
|
|
|
ssize_t 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 14:43:41 +04:00
|
|
|
|
|
|
|
if (WARN_ON(!cl || !cl->dev))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
dev = cl->dev;
|
|
|
|
|
2013-09-02 04:11:04 +04:00
|
|
|
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
mutex_lock(&dev->device_lock);
|
2012-08-07 01:03:56 +04: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 14:43:41 +04:00
|
|
|
rets = -ENODEV;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2013-09-02 04:11:04 +04:00
|
|
|
if (length == 0) {
|
|
|
|
rets = 0;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2016-01-07 15:46:37 +03:00
|
|
|
if (ubuf == NULL) {
|
|
|
|
rets = -EMSGSIZE;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2015-02-10 11:39:46 +03:00
|
|
|
cb = mei_cl_read_cb(cl, file);
|
2016-01-07 15:46:37 +03:00
|
|
|
if (cb)
|
|
|
|
goto copy_buffer;
|
|
|
|
|
|
|
|
if (*offset > 0)
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
*offset = 0;
|
|
|
|
|
2016-07-26 01:06:06 +03:00
|
|
|
rets = mei_cl_read_start(cl, length, file);
|
|
|
|
if (rets && rets != -EBUSY) {
|
2018-07-12 17:10:10 +03:00
|
|
|
cl_dbg(dev, cl, "mei start read failure status = %zd\n", 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 14:43:41 +04:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2016-07-26 01:06:06 +03:00
|
|
|
if (nonblock) {
|
|
|
|
rets = -EAGAIN;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2017-02-08 01:41:45 +03:00
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
if (wait_event_interruptible(cl->rx_wait,
|
2020-08-18 14:51:40 +03:00
|
|
|
mei_cl_read_cb(cl, file) ||
|
2017-02-08 01:41:45 +03:00
|
|
|
!mei_cl_is_connected(cl))) {
|
|
|
|
if (signal_pending(current))
|
|
|
|
return -EINTR;
|
|
|
|
return -ERESTARTSYS;
|
|
|
|
}
|
|
|
|
mutex_lock(&dev->device_lock);
|
2013-09-02 14:29:46 +04:00
|
|
|
|
2017-02-08 01:41:45 +03:00
|
|
|
if (!mei_cl_is_connected(cl)) {
|
|
|
|
rets = -ENODEV;
|
|
|
|
goto out;
|
|
|
|
}
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|
2017-02-08 01:41:45 +03:00
|
|
|
cb = mei_cl_read_cb(cl, file);
|
|
|
|
if (!cb) {
|
|
|
|
rets = 0;
|
|
|
|
goto out;
|
|
|
|
}
|
2015-02-10 11:39:36 +03:00
|
|
|
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
copy_buffer:
|
2015-02-10 11:39:36 +03:00
|
|
|
/* now copy the data to user space */
|
|
|
|
if (cb->status) {
|
|
|
|
rets = cb->status;
|
2018-07-12 17:10:10 +03:00
|
|
|
cl_dbg(dev, cl, "read operation failed %zd\n", rets);
|
2015-02-10 11:39:36 +03:00
|
|
|
goto free;
|
|
|
|
}
|
|
|
|
|
2016-02-17 19:27:34 +03:00
|
|
|
cl_dbg(dev, cl, "buf.size = %zu buf.idx = %zu offset = %lld\n",
|
2016-01-07 15:46:37 +03:00
|
|
|
cb->buf.size, cb->buf_idx, *offset);
|
|
|
|
if (*offset >= cb->buf_idx) {
|
|
|
|
rets = 0;
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
goto free;
|
|
|
|
}
|
|
|
|
|
2012-10-09 18:50:16 +04:00
|
|
|
/* length is being truncated to PAGE_SIZE,
|
|
|
|
* however buf_idx may point beyond that */
|
|
|
|
length = min_t(size_t, length, cb->buf_idx - *offset);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|
2015-02-10 11:39:42 +03:00
|
|
|
if (copy_to_user(ubuf, cb->buf.data + *offset, length)) {
|
2014-09-29 17:31:42 +04:00
|
|
|
dev_dbg(dev->dev, "failed to copy data to userland\n");
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
rets = -EFAULT;
|
|
|
|
goto free;
|
|
|
|
}
|
|
|
|
|
|
|
|
rets = length;
|
|
|
|
*offset += length;
|
2016-02-08 00:35:19 +03:00
|
|
|
/* not all data was read, keep the cb */
|
|
|
|
if (*offset < cb->buf_idx)
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
goto out;
|
|
|
|
|
|
|
|
free:
|
2020-08-18 14:51:40 +03:00
|
|
|
mei_cl_del_rd_completed(cl, cb);
|
2016-01-07 15:46:37 +03:00
|
|
|
*offset = 0;
|
2015-02-10 11:39:45 +03:00
|
|
|
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
out:
|
2018-07-12 17:10:10 +03:00
|
|
|
cl_dbg(dev, cl, "end mei read rets = %zd\n", 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 14:43:41 +04:00
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
return rets;
|
|
|
|
}
|
2020-08-18 14:51:41 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_cl_vtag_by_fp - obtain the vtag by file pointer
|
|
|
|
*
|
|
|
|
* @cl: host client
|
|
|
|
* @fp: pointer to file structure
|
|
|
|
*
|
|
|
|
* Return: vtag value on success, otherwise 0
|
|
|
|
*/
|
|
|
|
static u8 mei_cl_vtag_by_fp(const struct mei_cl *cl, const struct file *fp)
|
|
|
|
{
|
|
|
|
struct mei_cl_vtag *cl_vtag;
|
|
|
|
|
|
|
|
if (!fp)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
list_for_each_entry(cl_vtag, &cl->vtag_map, list)
|
|
|
|
if (cl_vtag->fp == fp)
|
|
|
|
return cl_vtag->vtag;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
/**
|
|
|
|
* mei_write - the write function.
|
|
|
|
*
|
|
|
|
* @file: pointer to file structure
|
|
|
|
* @ubuf: pointer to user buffer
|
|
|
|
* @length: buffer length
|
|
|
|
* @offset: data offset in buffer
|
|
|
|
*
|
2014-09-29 17:31:49 +04:00
|
|
|
* Return: >=0 data length on success , <0 on error
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
*/
|
|
|
|
static ssize_t mei_write(struct file *file, const char __user *ubuf,
|
2011-12-14 01:39:34 +04:00
|
|
|
size_t length, loff_t *offset)
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
{
|
|
|
|
struct mei_cl *cl = file->private_data;
|
2016-02-11 00:57:26 +03:00
|
|
|
struct mei_cl_cb *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 14:43:41 +04:00
|
|
|
struct mei_device *dev;
|
2018-07-12 17:10:10 +03:00
|
|
|
ssize_t 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 14:43:41 +04:00
|
|
|
|
|
|
|
if (WARN_ON(!cl || !cl->dev))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
dev = cl->dev;
|
|
|
|
|
|
|
|
mutex_lock(&dev->device_lock);
|
|
|
|
|
2012-08-07 01:03:56 +04:00
|
|
|
if (dev->dev_state != MEI_DEV_ENABLED) {
|
2012-10-09 18:50:18 +04:00
|
|
|
rets = -ENODEV;
|
2013-04-08 22:56:37 +04:00
|
|
|
goto out;
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
}
|
|
|
|
|
2015-05-04 09:43:54 +03:00
|
|
|
if (!mei_cl_is_connected(cl)) {
|
|
|
|
cl_err(dev, cl, "is not connected");
|
|
|
|
rets = -ENODEV;
|
2013-04-08 22:56:37 +04:00
|
|
|
goto out;
|
2012-10-09 18:50:18 +04:00
|
|
|
}
|
2013-09-02 04:11:04 +04:00
|
|
|
|
2015-05-04 09:43:54 +03:00
|
|
|
if (!mei_me_cl_is_active(cl->me_cl)) {
|
|
|
|
rets = -ENOTTY;
|
2013-09-02 04:11:04 +04:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2015-05-04 09:43:54 +03:00
|
|
|
if (length > mei_cl_mtu(cl)) {
|
2013-09-02 04:11:04 +04:00
|
|
|
rets = -EFBIG;
|
2013-04-08 22:56:37 +04:00
|
|
|
goto out;
|
2012-10-09 18:50:18 +04:00
|
|
|
}
|
|
|
|
|
2015-05-04 09:43:54 +03:00
|
|
|
if (length == 0) {
|
|
|
|
rets = 0;
|
2013-04-08 22:56:37 +04:00
|
|
|
goto out;
|
2012-10-09 18:50:18 +04:00
|
|
|
}
|
2015-05-04 09:43:54 +03:00
|
|
|
|
2018-02-25 21:07:05 +03:00
|
|
|
while (cl->tx_cb_queued >= dev->tx_queue_limit) {
|
|
|
|
if (file->f_flags & O_NONBLOCK) {
|
|
|
|
rets = -EAGAIN;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
rets = wait_event_interruptible(cl->tx_wait,
|
|
|
|
cl->writing_state == MEI_WRITE_COMPLETE ||
|
|
|
|
(!mei_cl_is_connected(cl)));
|
|
|
|
mutex_lock(&dev->device_lock);
|
|
|
|
if (rets) {
|
|
|
|
if (signal_pending(current))
|
|
|
|
rets = -EINTR;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
if (!mei_cl_is_connected(cl)) {
|
|
|
|
rets = -ENODEV;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-02-11 00:57:26 +03:00
|
|
|
cb = mei_cl_alloc_cb(cl, length, MEI_FOP_WRITE, file);
|
|
|
|
if (!cb) {
|
2012-10-09 18:50:17 +04:00
|
|
|
rets = -ENOMEM;
|
2013-04-08 22:56:37 +04:00
|
|
|
goto out;
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
}
|
2020-08-18 14:51:41 +03:00
|
|
|
cb->vtag = mei_cl_vtag_by_fp(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 14:43:41 +04:00
|
|
|
|
2016-02-11 00:57:26 +03:00
|
|
|
rets = copy_from_user(cb->buf.data, ubuf, length);
|
2013-09-02 04:11:02 +04:00
|
|
|
if (rets) {
|
2014-09-29 17:31:42 +04:00
|
|
|
dev_dbg(dev->dev, "failed to copy data from userland\n");
|
2013-09-02 04:11:02 +04:00
|
|
|
rets = -EFAULT;
|
2016-02-11 00:57:26 +03:00
|
|
|
mei_io_cb_free(cb);
|
2013-04-08 22:56:37 +04:00
|
|
|
goto out;
|
2013-09-02 04:11:02 +04:00
|
|
|
}
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|
2016-11-08 19:26:08 +03:00
|
|
|
rets = mei_cl_write(cl, cb);
|
2012-11-01 23:17:13 +04:00
|
|
|
out:
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
return rets;
|
|
|
|
}
|
|
|
|
|
2013-01-09 01:07:15 +04:00
|
|
|
/**
|
|
|
|
* mei_ioctl_connect_client - the connect to fw client IOCTL function
|
|
|
|
*
|
|
|
|
* @file: private data of the file object
|
2020-08-18 14:51:45 +03:00
|
|
|
* @in_client_uuid: requested UUID for connection
|
|
|
|
* @client: IOCTL connect data, output parameters
|
2013-01-09 01:07:15 +04:00
|
|
|
*
|
|
|
|
* Locking: called under "dev->device_lock" lock
|
|
|
|
*
|
2014-09-29 17:31:49 +04:00
|
|
|
* Return: 0 on success, <0 on failure.
|
2013-01-09 01:07:15 +04:00
|
|
|
*/
|
|
|
|
static int mei_ioctl_connect_client(struct file *file,
|
2020-08-18 14:51:45 +03:00
|
|
|
const uuid_le *in_client_uuid,
|
|
|
|
struct mei_client *client)
|
2013-01-09 01:07:15 +04:00
|
|
|
{
|
|
|
|
struct mei_device *dev;
|
2014-08-24 13:08:55 +04:00
|
|
|
struct mei_me_client *me_cl;
|
2013-01-09 01:07:15 +04:00
|
|
|
struct mei_cl *cl;
|
|
|
|
int rets;
|
|
|
|
|
|
|
|
cl = file->private_data;
|
|
|
|
dev = cl->dev;
|
|
|
|
|
|
|
|
if (cl->state != MEI_FILE_INITIALIZING &&
|
2015-01-11 01:07:16 +03:00
|
|
|
cl->state != MEI_FILE_DISCONNECTED)
|
|
|
|
return -EBUSY;
|
2013-01-09 01:07:15 +04:00
|
|
|
|
|
|
|
/* find ME client we're trying to connect to */
|
2020-08-18 14:51:45 +03:00
|
|
|
me_cl = mei_me_cl_by_uuid(dev, in_client_uuid);
|
2016-02-08 00:35:38 +03:00
|
|
|
if (!me_cl) {
|
2014-09-29 17:31:42 +04:00
|
|
|
dev_dbg(dev->dev, "Cannot connect to FW Client UUID = %pUl\n",
|
2020-08-18 14:51:45 +03:00
|
|
|
in_client_uuid);
|
2016-02-08 00:35:38 +03:00
|
|
|
rets = -ENOTTY;
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (me_cl->props.fixed_address) {
|
|
|
|
bool forbidden = dev->override_fixed_address ?
|
|
|
|
!dev->allow_fixed_address : !dev->hbm_f_fa_supported;
|
|
|
|
if (forbidden) {
|
|
|
|
dev_dbg(dev->dev, "Connection forbidden to FW Client UUID = %pUl\n",
|
2020-08-18 14:51:45 +03:00
|
|
|
in_client_uuid);
|
2016-02-08 00:35:38 +03:00
|
|
|
rets = -ENOTTY;
|
|
|
|
goto end;
|
|
|
|
}
|
2013-01-09 01:07:15 +04:00
|
|
|
}
|
|
|
|
|
2014-09-29 17:31:42 +04:00
|
|
|
dev_dbg(dev->dev, "Connect to FW Client ID = %d\n",
|
2015-05-04 09:43:54 +03:00
|
|
|
me_cl->client_id);
|
2014-09-29 17:31:42 +04:00
|
|
|
dev_dbg(dev->dev, "FW Client - Protocol Version = %d\n",
|
2014-08-24 13:08:55 +04:00
|
|
|
me_cl->props.protocol_version);
|
2014-09-29 17:31:42 +04:00
|
|
|
dev_dbg(dev->dev, "FW Client - Max Msg Len = %d\n",
|
2014-08-24 13:08:55 +04:00
|
|
|
me_cl->props.max_msg_length);
|
2013-01-09 01:07:15 +04:00
|
|
|
|
|
|
|
/* prepare the output buffer */
|
2014-08-24 13:08:55 +04:00
|
|
|
client->max_msg_length = me_cl->props.max_msg_length;
|
|
|
|
client->protocol_version = me_cl->props.protocol_version;
|
2014-09-29 17:31:42 +04:00
|
|
|
dev_dbg(dev->dev, "Can connect?\n");
|
2013-01-09 01:07:15 +04:00
|
|
|
|
2015-05-04 09:43:54 +03:00
|
|
|
rets = mei_cl_connect(cl, me_cl, file);
|
2013-01-09 01:07:15 +04:00
|
|
|
|
|
|
|
end:
|
2015-01-11 01:07:16 +03:00
|
|
|
mei_me_cl_put(me_cl);
|
2013-01-09 01:07:15 +04:00
|
|
|
return rets;
|
|
|
|
}
|
|
|
|
|
2020-08-18 14:51:45 +03:00
|
|
|
/**
|
|
|
|
* mei_vt_support_check - check if client support vtags
|
|
|
|
*
|
|
|
|
* Locking: called under "dev->device_lock" lock
|
|
|
|
*
|
|
|
|
* @dev: mei_device
|
|
|
|
* @uuid: client UUID
|
|
|
|
*
|
|
|
|
* Return:
|
|
|
|
* 0 - supported
|
|
|
|
* -ENOTTY - no such client
|
|
|
|
* -EOPNOTSUPP - vtags are not supported by client
|
|
|
|
*/
|
|
|
|
static int mei_vt_support_check(struct mei_device *dev, const uuid_le *uuid)
|
|
|
|
{
|
|
|
|
struct mei_me_client *me_cl;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!dev->hbm_f_vt_supported)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
me_cl = mei_me_cl_by_uuid(dev, uuid);
|
|
|
|
if (!me_cl) {
|
|
|
|
dev_dbg(dev->dev, "Cannot connect to FW Client UUID = %pUl\n",
|
|
|
|
uuid);
|
|
|
|
return -ENOTTY;
|
|
|
|
}
|
|
|
|
ret = me_cl->props.vt_supported ? 0 : -EOPNOTSUPP;
|
|
|
|
mei_me_cl_put(me_cl);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_ioctl_connect_vtag - connect to fw client with vtag IOCTL function
|
|
|
|
*
|
|
|
|
* @file: private data of the file object
|
|
|
|
* @in_client_uuid: requested UUID for connection
|
|
|
|
* @client: IOCTL connect data, output parameters
|
|
|
|
* @vtag: vm tag
|
|
|
|
*
|
|
|
|
* Locking: called under "dev->device_lock" lock
|
|
|
|
*
|
|
|
|
* Return: 0 on success, <0 on failure.
|
|
|
|
*/
|
|
|
|
static int mei_ioctl_connect_vtag(struct file *file,
|
|
|
|
const uuid_le *in_client_uuid,
|
|
|
|
struct mei_client *client,
|
|
|
|
u8 vtag)
|
|
|
|
{
|
|
|
|
struct mei_device *dev;
|
|
|
|
struct mei_cl *cl;
|
|
|
|
struct mei_cl *pos;
|
|
|
|
struct mei_cl_vtag *cl_vtag;
|
|
|
|
|
|
|
|
cl = file->private_data;
|
|
|
|
dev = cl->dev;
|
|
|
|
|
|
|
|
dev_dbg(dev->dev, "FW Client %pUl vtag %d\n", in_client_uuid, vtag);
|
|
|
|
|
|
|
|
switch (cl->state) {
|
|
|
|
case MEI_FILE_DISCONNECTED:
|
|
|
|
if (mei_cl_vtag_by_fp(cl, file) != vtag) {
|
|
|
|
dev_err(dev->dev, "reconnect with different vtag\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case MEI_FILE_INITIALIZING:
|
|
|
|
/* malicious connect from another thread may push vtag */
|
|
|
|
if (!IS_ERR(mei_cl_fp_by_vtag(cl, vtag))) {
|
|
|
|
dev_err(dev->dev, "vtag already filled\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
list_for_each_entry(pos, &dev->file_list, link) {
|
|
|
|
if (pos == cl)
|
|
|
|
continue;
|
|
|
|
if (!pos->me_cl)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* only search for same UUID */
|
|
|
|
if (uuid_le_cmp(*mei_cl_uuid(pos), *in_client_uuid))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* if tag already exist try another fp */
|
|
|
|
if (!IS_ERR(mei_cl_fp_by_vtag(pos, vtag)))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* replace cl with acquired one */
|
|
|
|
dev_dbg(dev->dev, "replacing with existing cl\n");
|
|
|
|
mei_cl_unlink(cl);
|
|
|
|
kfree(cl);
|
|
|
|
file->private_data = pos;
|
|
|
|
cl = pos;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
cl_vtag = mei_cl_vtag_alloc(file, vtag);
|
|
|
|
if (IS_ERR(cl_vtag))
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
list_add_tail(&cl_vtag->list, &cl->vtag_map);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (cl->state != MEI_FILE_INITIALIZING &&
|
|
|
|
cl->state != MEI_FILE_DISCONNECTED &&
|
|
|
|
cl->state != MEI_FILE_CONNECTED) {
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
wait_event_timeout(cl->wait,
|
|
|
|
(cl->state == MEI_FILE_CONNECTED ||
|
|
|
|
cl->state == MEI_FILE_DISCONNECTED ||
|
|
|
|
cl->state == MEI_FILE_DISCONNECT_REQUIRED ||
|
|
|
|
cl->state == MEI_FILE_DISCONNECT_REPLY),
|
|
|
|
mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT));
|
|
|
|
mutex_lock(&dev->device_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!mei_cl_is_connected(cl))
|
|
|
|
return mei_ioctl_connect_client(file, in_client_uuid, client);
|
|
|
|
|
|
|
|
client->max_msg_length = cl->me_cl->props.max_msg_length;
|
|
|
|
client->protocol_version = cl->me_cl->props.protocol_version;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-07-26 09:54:20 +03:00
|
|
|
/**
|
|
|
|
* mei_ioctl_client_notify_request -
|
|
|
|
* propagate event notification request to client
|
|
|
|
*
|
|
|
|
* @file: pointer to file structure
|
|
|
|
* @request: 0 - disable, 1 - enable
|
|
|
|
*
|
|
|
|
* Return: 0 on success , <0 on error
|
|
|
|
*/
|
2016-02-08 00:35:23 +03:00
|
|
|
static int mei_ioctl_client_notify_request(const struct file *file, u32 request)
|
2015-07-26 09:54:20 +03:00
|
|
|
{
|
|
|
|
struct mei_cl *cl = file->private_data;
|
|
|
|
|
2016-01-17 13:25:01 +03:00
|
|
|
if (request != MEI_HBM_NOTIFICATION_START &&
|
|
|
|
request != MEI_HBM_NOTIFICATION_STOP)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return mei_cl_notify_request(cl, file, (u8)request);
|
2015-07-26 09:54:20 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_ioctl_client_notify_get - wait for notification request
|
|
|
|
*
|
|
|
|
* @file: pointer to file structure
|
|
|
|
* @notify_get: 0 - disable, 1 - enable
|
|
|
|
*
|
|
|
|
* Return: 0 on success , <0 on error
|
|
|
|
*/
|
2016-02-08 00:35:23 +03:00
|
|
|
static int mei_ioctl_client_notify_get(const struct file *file, u32 *notify_get)
|
2015-07-26 09:54:20 +03:00
|
|
|
{
|
|
|
|
struct mei_cl *cl = file->private_data;
|
|
|
|
bool notify_ev;
|
|
|
|
bool block = (file->f_flags & O_NONBLOCK) == 0;
|
|
|
|
int rets;
|
|
|
|
|
|
|
|
rets = mei_cl_notify_get(cl, block, ¬ify_ev);
|
|
|
|
if (rets)
|
|
|
|
return rets;
|
|
|
|
|
|
|
|
*notify_get = notify_ev ? 1 : 0;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
/**
|
|
|
|
* mei_ioctl - the IOCTL function
|
|
|
|
*
|
|
|
|
* @file: pointer to file structure
|
|
|
|
* @cmd: ioctl command
|
|
|
|
* @data: pointer to mei message structure
|
|
|
|
*
|
2014-09-29 17:31:49 +04:00
|
|
|
* Return: 0 on success , <0 on error
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
*/
|
|
|
|
static long mei_ioctl(struct file *file, unsigned int cmd, unsigned long data)
|
|
|
|
{
|
|
|
|
struct mei_device *dev;
|
|
|
|
struct mei_cl *cl = file->private_data;
|
2020-08-18 14:51:45 +03:00
|
|
|
struct mei_connect_client_data conn;
|
|
|
|
struct mei_connect_client_data_vtag conn_vtag;
|
|
|
|
const uuid_le *cl_uuid;
|
|
|
|
struct mei_client *props;
|
|
|
|
u8 vtag;
|
2015-07-26 09:54:20 +03:00
|
|
|
u32 notify_get, notify_req;
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
int rets;
|
|
|
|
|
|
|
|
|
|
|
|
if (WARN_ON(!cl || !cl->dev))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
dev = cl->dev;
|
|
|
|
|
2014-09-29 17:31:42 +04:00
|
|
|
dev_dbg(dev->dev, "IOCTL cmd = 0x%x", cmd);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|
|
|
|
mutex_lock(&dev->device_lock);
|
2012-08-07 01:03:56 +04: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 14:43:41 +04:00
|
|
|
rets = -ENODEV;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2014-08-21 15:29:22 +04:00
|
|
|
switch (cmd) {
|
|
|
|
case IOCTL_MEI_CONNECT_CLIENT:
|
2014-09-29 17:31:42 +04:00
|
|
|
dev_dbg(dev->dev, ": IOCTL_MEI_CONNECT_CLIENT.\n");
|
2020-08-18 14:51:45 +03:00
|
|
|
if (copy_from_user(&conn, (char __user *)data, sizeof(conn))) {
|
2014-09-29 17:31:42 +04:00
|
|
|
dev_dbg(dev->dev, "failed to copy data from userland\n");
|
2014-08-21 15:29:22 +04:00
|
|
|
rets = -EFAULT;
|
|
|
|
goto out;
|
|
|
|
}
|
2020-08-18 14:51:45 +03:00
|
|
|
cl_uuid = &conn.in_client_uuid;
|
|
|
|
props = &conn.out_client_properties;
|
|
|
|
vtag = 0;
|
|
|
|
|
|
|
|
rets = mei_vt_support_check(dev, cl_uuid);
|
|
|
|
if (rets == -ENOTTY)
|
|
|
|
goto out;
|
|
|
|
if (!rets)
|
|
|
|
rets = mei_ioctl_connect_vtag(file, cl_uuid, props,
|
|
|
|
vtag);
|
|
|
|
else
|
|
|
|
rets = mei_ioctl_connect_client(file, cl_uuid, props);
|
|
|
|
if (rets)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* if all is ok, copying the data back to user. */
|
|
|
|
if (copy_to_user((char __user *)data, &conn, sizeof(conn))) {
|
|
|
|
dev_dbg(dev->dev, "failed to copy data to userland\n");
|
|
|
|
rets = -EFAULT;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
case IOCTL_MEI_CONNECT_CLIENT_VTAG:
|
|
|
|
dev_dbg(dev->dev, "IOCTL_MEI_CONNECT_CLIENT_VTAG\n");
|
|
|
|
if (copy_from_user(&conn_vtag, (char __user *)data,
|
|
|
|
sizeof(conn_vtag))) {
|
|
|
|
dev_dbg(dev->dev, "failed to copy data from userland\n");
|
|
|
|
rets = -EFAULT;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
cl_uuid = &conn_vtag.connect.in_client_uuid;
|
|
|
|
props = &conn_vtag.out_client_properties;
|
|
|
|
vtag = conn_vtag.connect.vtag;
|
|
|
|
|
|
|
|
rets = mei_vt_support_check(dev, cl_uuid);
|
|
|
|
if (rets == -EOPNOTSUPP)
|
|
|
|
dev_dbg(dev->dev, "FW Client %pUl does not support vtags\n",
|
|
|
|
cl_uuid);
|
|
|
|
if (rets)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (!vtag) {
|
|
|
|
dev_dbg(dev->dev, "vtag can't be zero\n");
|
|
|
|
rets = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|
2020-08-18 14:51:45 +03:00
|
|
|
rets = mei_ioctl_connect_vtag(file, cl_uuid, props, vtag);
|
2014-08-21 15:29:22 +04:00
|
|
|
if (rets)
|
|
|
|
goto out;
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|
2014-08-21 15:29:22 +04:00
|
|
|
/* if all is ok, copying the data back to user. */
|
2020-08-18 14:51:45 +03:00
|
|
|
if (copy_to_user((char __user *)data, &conn_vtag,
|
|
|
|
sizeof(conn_vtag))) {
|
2014-09-29 17:31:42 +04:00
|
|
|
dev_dbg(dev->dev, "failed to copy data to userland\n");
|
2014-08-21 15:29:22 +04:00
|
|
|
rets = -EFAULT;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
break;
|
2014-08-21 15:29:23 +04:00
|
|
|
|
2015-07-26 09:54:20 +03:00
|
|
|
case IOCTL_MEI_NOTIFY_SET:
|
|
|
|
dev_dbg(dev->dev, ": IOCTL_MEI_NOTIFY_SET.\n");
|
|
|
|
if (copy_from_user(¬ify_req,
|
|
|
|
(char __user *)data, sizeof(notify_req))) {
|
|
|
|
dev_dbg(dev->dev, "failed to copy data from userland\n");
|
|
|
|
rets = -EFAULT;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
rets = mei_ioctl_client_notify_request(file, notify_req);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case IOCTL_MEI_NOTIFY_GET:
|
|
|
|
dev_dbg(dev->dev, ": IOCTL_MEI_NOTIFY_GET.\n");
|
|
|
|
rets = mei_ioctl_client_notify_get(file, ¬ify_get);
|
|
|
|
if (rets)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
dev_dbg(dev->dev, "copy connect data to user\n");
|
|
|
|
if (copy_to_user((char __user *)data,
|
|
|
|
¬ify_get, sizeof(notify_get))) {
|
|
|
|
dev_dbg(dev->dev, "failed to copy data to userland\n");
|
|
|
|
rets = -EFAULT;
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2014-08-21 15:29:22 +04:00
|
|
|
default:
|
|
|
|
rets = -ENOIOCTLCMD;
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
return rets;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_poll - the poll function
|
|
|
|
*
|
|
|
|
* @file: pointer to file structure
|
|
|
|
* @wait: pointer to poll_table structure
|
|
|
|
*
|
2014-09-29 17:31:49 +04:00
|
|
|
* Return: poll mask
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
*/
|
2017-07-03 13:39:46 +03:00
|
|
|
static __poll_t mei_poll(struct file *file, poll_table *wait)
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
{
|
2017-07-03 10:14:15 +03:00
|
|
|
__poll_t req_events = poll_requested_events(wait);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
struct mei_cl *cl = file->private_data;
|
|
|
|
struct mei_device *dev;
|
2017-07-03 13:39:46 +03:00
|
|
|
__poll_t mask = 0;
|
2015-07-26 09:54:21 +03:00
|
|
|
bool notify_en;
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|
|
|
|
if (WARN_ON(!cl || !cl->dev))
|
2018-02-12 01:34:03 +03:00
|
|
|
return EPOLLERR;
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|
|
|
|
dev = cl->dev;
|
|
|
|
|
|
|
|
mutex_lock(&dev->device_lock);
|
|
|
|
|
2018-02-12 01:34:03 +03:00
|
|
|
notify_en = cl->notify_en && (req_events & EPOLLPRI);
|
2015-03-27 01:27:58 +03:00
|
|
|
|
|
|
|
if (dev->dev_state != MEI_DEV_ENABLED ||
|
|
|
|
!mei_cl_is_connected(cl)) {
|
2018-02-12 01:34:03 +03:00
|
|
|
mask = EPOLLERR;
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2015-07-26 09:54:21 +03:00
|
|
|
if (notify_en) {
|
|
|
|
poll_wait(file, &cl->ev_wait, wait);
|
|
|
|
if (cl->notify_ev)
|
2018-02-12 01:34:03 +03:00
|
|
|
mask |= EPOLLPRI;
|
2015-07-26 09:54:21 +03:00
|
|
|
}
|
2016-05-24 23:03:38 +03:00
|
|
|
|
2018-02-12 01:34:03 +03:00
|
|
|
if (req_events & (EPOLLIN | EPOLLRDNORM)) {
|
2015-03-27 01:27:57 +03:00
|
|
|
poll_wait(file, &cl->rx_wait, wait);
|
|
|
|
|
2020-08-18 14:51:40 +03:00
|
|
|
if (mei_cl_read_cb(cl, file))
|
2018-02-12 01:34:03 +03:00
|
|
|
mask |= EPOLLIN | EPOLLRDNORM;
|
2015-03-27 01:27:57 +03:00
|
|
|
else
|
2016-07-26 01:06:05 +03:00
|
|
|
mei_cl_read_start(cl, mei_cl_mtu(cl), file);
|
2015-03-27 01:27:57 +03:00
|
|
|
}
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|
2018-09-28 23:27:48 +03:00
|
|
|
if (req_events & (EPOLLOUT | EPOLLWRNORM)) {
|
2018-02-25 21:07:05 +03:00
|
|
|
poll_wait(file, &cl->tx_wait, wait);
|
|
|
|
if (cl->tx_cb_queued < dev->tx_queue_limit)
|
2018-09-28 23:27:48 +03:00
|
|
|
mask |= EPOLLOUT | EPOLLWRNORM;
|
2018-02-25 21:07:05 +03:00
|
|
|
}
|
|
|
|
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
out:
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
return mask;
|
|
|
|
}
|
|
|
|
|
2017-03-20 16:04:06 +03:00
|
|
|
/**
|
|
|
|
* mei_cl_is_write_queued - check if the client has pending writes.
|
|
|
|
*
|
|
|
|
* @cl: writing host client
|
|
|
|
*
|
|
|
|
* Return: true if client is writing, false otherwise.
|
|
|
|
*/
|
|
|
|
static bool mei_cl_is_write_queued(struct mei_cl *cl)
|
|
|
|
{
|
|
|
|
struct mei_device *dev = cl->dev;
|
|
|
|
struct mei_cl_cb *cb;
|
|
|
|
|
|
|
|
list_for_each_entry(cb, &dev->write_list, list)
|
|
|
|
if (cb->cl == cl)
|
|
|
|
return true;
|
|
|
|
list_for_each_entry(cb, &dev->write_waiting_list, list)
|
|
|
|
if (cb->cl == cl)
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mei_fsync - the fsync handler
|
|
|
|
*
|
|
|
|
* @fp: pointer to file structure
|
|
|
|
* @start: unused
|
|
|
|
* @end: unused
|
|
|
|
* @datasync: unused
|
|
|
|
*
|
|
|
|
* Return: 0 on success, -ENODEV if client is not connected
|
|
|
|
*/
|
|
|
|
static int mei_fsync(struct file *fp, loff_t start, loff_t end, int datasync)
|
|
|
|
{
|
|
|
|
struct mei_cl *cl = fp->private_data;
|
|
|
|
struct mei_device *dev;
|
|
|
|
int rets;
|
|
|
|
|
|
|
|
if (WARN_ON(!cl || !cl->dev))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
dev = cl->dev;
|
|
|
|
|
|
|
|
mutex_lock(&dev->device_lock);
|
|
|
|
|
|
|
|
if (dev->dev_state != MEI_DEV_ENABLED || !mei_cl_is_connected(cl)) {
|
|
|
|
rets = -ENODEV;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (mei_cl_is_write_queued(cl)) {
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
rets = wait_event_interruptible(cl->tx_wait,
|
|
|
|
cl->writing_state == MEI_WRITE_COMPLETE ||
|
|
|
|
!mei_cl_is_connected(cl));
|
|
|
|
mutex_lock(&dev->device_lock);
|
|
|
|
if (rets) {
|
|
|
|
if (signal_pending(current))
|
|
|
|
rets = -EINTR;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
if (!mei_cl_is_connected(cl)) {
|
|
|
|
rets = -ENODEV;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
rets = 0;
|
|
|
|
out:
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
return rets;
|
|
|
|
}
|
|
|
|
|
2015-07-26 09:54:22 +03:00
|
|
|
/**
|
|
|
|
* mei_fasync - asynchronous io support
|
|
|
|
*
|
|
|
|
* @fd: file descriptor
|
|
|
|
* @file: pointer to file structure
|
|
|
|
* @band: band bitmap
|
|
|
|
*
|
2016-01-07 15:46:38 +03:00
|
|
|
* Return: negative on error,
|
|
|
|
* 0 if it did no changes,
|
|
|
|
* and positive a process was added or deleted
|
2015-07-26 09:54:22 +03:00
|
|
|
*/
|
|
|
|
static int mei_fasync(int fd, struct file *file, int band)
|
|
|
|
{
|
|
|
|
|
|
|
|
struct mei_cl *cl = file->private_data;
|
|
|
|
|
|
|
|
if (!mei_cl_is_connected(cl))
|
2016-01-07 15:46:38 +03:00
|
|
|
return -ENODEV;
|
2015-07-26 09:54:22 +03:00
|
|
|
|
|
|
|
return fasync_helper(fd, file, band, &cl->ev_async);
|
|
|
|
}
|
|
|
|
|
2019-11-07 13:44:45 +03:00
|
|
|
/**
|
|
|
|
* trc_show - mei device trc attribute show method
|
|
|
|
*
|
|
|
|
* @device: device pointer
|
|
|
|
* @attr: attribute pointer
|
|
|
|
* @buf: char out buffer
|
|
|
|
*
|
|
|
|
* Return: number of the bytes printed into buf or error
|
|
|
|
*/
|
|
|
|
static ssize_t trc_show(struct device *device,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct mei_device *dev = dev_get_drvdata(device);
|
|
|
|
u32 trc;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = mei_trc_status(dev, &trc);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
return sprintf(buf, "%08X\n", trc);
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(trc);
|
|
|
|
|
2014-11-19 18:01:39 +03:00
|
|
|
/**
|
2016-10-30 02:42:18 +03:00
|
|
|
* fw_status_show - mei device fw_status attribute show method
|
2014-11-19 18:01:39 +03:00
|
|
|
*
|
|
|
|
* @device: device pointer
|
|
|
|
* @attr: attribute pointer
|
|
|
|
* @buf: char out buffer
|
|
|
|
*
|
|
|
|
* Return: number of the bytes printed into buf or error
|
|
|
|
*/
|
|
|
|
static ssize_t fw_status_show(struct device *device,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct mei_device *dev = dev_get_drvdata(device);
|
|
|
|
struct mei_fw_status fw_status;
|
|
|
|
int err, i;
|
|
|
|
ssize_t cnt = 0;
|
|
|
|
|
|
|
|
mutex_lock(&dev->device_lock);
|
|
|
|
err = mei_fw_status(dev, &fw_status);
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
if (err) {
|
|
|
|
dev_err(device, "read fw_status error = %d\n", err);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < fw_status.count; i++)
|
|
|
|
cnt += scnprintf(buf + cnt, PAGE_SIZE - cnt, "%08X\n",
|
|
|
|
fw_status.status[i]);
|
|
|
|
return cnt;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(fw_status);
|
|
|
|
|
2016-10-30 02:42:18 +03:00
|
|
|
/**
|
|
|
|
* hbm_ver_show - display HBM protocol version negotiated with FW
|
|
|
|
*
|
|
|
|
* @device: device pointer
|
|
|
|
* @attr: attribute pointer
|
|
|
|
* @buf: char out buffer
|
|
|
|
*
|
|
|
|
* Return: number of the bytes printed into buf or error
|
|
|
|
*/
|
|
|
|
static ssize_t hbm_ver_show(struct device *device,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct mei_device *dev = dev_get_drvdata(device);
|
|
|
|
struct hbm_version ver;
|
|
|
|
|
|
|
|
mutex_lock(&dev->device_lock);
|
|
|
|
ver = dev->version;
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
|
|
|
|
return sprintf(buf, "%u.%u\n", ver.major_version, ver.minor_version);
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(hbm_ver);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* hbm_ver_drv_show - display HBM protocol version advertised by driver
|
|
|
|
*
|
|
|
|
* @device: device pointer
|
|
|
|
* @attr: attribute pointer
|
|
|
|
* @buf: char out buffer
|
|
|
|
*
|
|
|
|
* Return: number of the bytes printed into buf or error
|
|
|
|
*/
|
|
|
|
static ssize_t hbm_ver_drv_show(struct device *device,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
return sprintf(buf, "%u.%u\n", HBM_MAJOR_VERSION, HBM_MINOR_VERSION);
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(hbm_ver_drv);
|
|
|
|
|
2018-02-25 21:07:05 +03:00
|
|
|
static ssize_t tx_queue_limit_show(struct device *device,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct mei_device *dev = dev_get_drvdata(device);
|
|
|
|
u8 size = 0;
|
|
|
|
|
|
|
|
mutex_lock(&dev->device_lock);
|
|
|
|
size = dev->tx_queue_limit;
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
|
2021-02-08 18:06:49 +03:00
|
|
|
return sysfs_emit(buf, "%u\n", size);
|
2018-02-25 21:07:05 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t tx_queue_limit_store(struct device *device,
|
|
|
|
struct device_attribute *attr,
|
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
struct mei_device *dev = dev_get_drvdata(device);
|
|
|
|
u8 limit;
|
|
|
|
unsigned int inp;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = kstrtouint(buf, 10, &inp);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
if (inp > MEI_TX_QUEUE_LIMIT_MAX || inp < MEI_TX_QUEUE_LIMIT_MIN)
|
|
|
|
return -EINVAL;
|
|
|
|
limit = inp;
|
|
|
|
|
|
|
|
mutex_lock(&dev->device_lock);
|
|
|
|
dev->tx_queue_limit = limit;
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RW(tx_queue_limit);
|
|
|
|
|
2018-06-25 00:11:41 +03:00
|
|
|
/**
|
|
|
|
* fw_ver_show - display ME FW version
|
|
|
|
*
|
|
|
|
* @device: device pointer
|
|
|
|
* @attr: attribute pointer
|
|
|
|
* @buf: char out buffer
|
|
|
|
*
|
|
|
|
* Return: number of the bytes printed into buf or error
|
|
|
|
*/
|
|
|
|
static ssize_t fw_ver_show(struct device *device,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct mei_device *dev = dev_get_drvdata(device);
|
|
|
|
struct mei_fw_version *ver;
|
|
|
|
ssize_t cnt = 0;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
ver = dev->fw_ver;
|
|
|
|
|
|
|
|
for (i = 0; i < MEI_MAX_FW_VER_BLOCKS; i++)
|
|
|
|
cnt += scnprintf(buf + cnt, PAGE_SIZE - cnt, "%u:%u.%u.%u.%u\n",
|
|
|
|
ver[i].platform, ver[i].major, ver[i].minor,
|
|
|
|
ver[i].hotfix, ver[i].buildno);
|
|
|
|
return cnt;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(fw_ver);
|
|
|
|
|
2019-04-22 09:51:07 +03:00
|
|
|
/**
|
|
|
|
* dev_state_show - display device state
|
|
|
|
*
|
|
|
|
* @device: device pointer
|
|
|
|
* @attr: attribute pointer
|
|
|
|
* @buf: char out buffer
|
|
|
|
*
|
|
|
|
* Return: number of the bytes printed into buf or error
|
|
|
|
*/
|
|
|
|
static ssize_t dev_state_show(struct device *device,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct mei_device *dev = dev_get_drvdata(device);
|
|
|
|
enum mei_dev_state dev_state;
|
|
|
|
|
|
|
|
mutex_lock(&dev->device_lock);
|
|
|
|
dev_state = dev->dev_state;
|
|
|
|
mutex_unlock(&dev->device_lock);
|
|
|
|
|
|
|
|
return sprintf(buf, "%s", mei_dev_state_str(dev_state));
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(dev_state);
|
|
|
|
|
|
|
|
/**
|
2021-06-21 22:37:55 +03:00
|
|
|
* mei_set_devstate: set to new device state and notify sysfs file.
|
2019-04-22 09:51:07 +03:00
|
|
|
*
|
|
|
|
* @dev: mei_device
|
|
|
|
* @state: new device state
|
|
|
|
*/
|
|
|
|
void mei_set_devstate(struct mei_device *dev, enum mei_dev_state state)
|
|
|
|
{
|
|
|
|
struct device *clsdev;
|
|
|
|
|
|
|
|
if (dev->dev_state == state)
|
|
|
|
return;
|
|
|
|
|
|
|
|
dev->dev_state = state;
|
|
|
|
|
2019-07-24 01:18:35 +03:00
|
|
|
clsdev = class_find_device_by_devt(mei_class, dev->cdev.dev);
|
2019-04-22 09:51:07 +03:00
|
|
|
if (clsdev) {
|
|
|
|
sysfs_notify(&clsdev->kobj, NULL, "dev_state");
|
|
|
|
put_device(clsdev);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-07-28 22:22:42 +03:00
|
|
|
/**
|
|
|
|
* kind_show - display device kind
|
|
|
|
*
|
|
|
|
* @device: device pointer
|
|
|
|
* @attr: attribute pointer
|
|
|
|
* @buf: char out buffer
|
|
|
|
*
|
|
|
|
* Return: number of the bytes printed into buf or error
|
|
|
|
*/
|
|
|
|
static ssize_t kind_show(struct device *device,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct mei_device *dev = dev_get_drvdata(device);
|
|
|
|
ssize_t ret;
|
|
|
|
|
|
|
|
if (dev->kind)
|
|
|
|
ret = sprintf(buf, "%s\n", dev->kind);
|
|
|
|
else
|
|
|
|
ret = sprintf(buf, "%s\n", "mei");
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(kind);
|
|
|
|
|
2014-11-19 18:01:39 +03:00
|
|
|
static struct attribute *mei_attrs[] = {
|
|
|
|
&dev_attr_fw_status.attr,
|
2016-10-30 02:42:18 +03:00
|
|
|
&dev_attr_hbm_ver.attr,
|
|
|
|
&dev_attr_hbm_ver_drv.attr,
|
2018-02-25 21:07:05 +03:00
|
|
|
&dev_attr_tx_queue_limit.attr,
|
2018-06-25 00:11:41 +03:00
|
|
|
&dev_attr_fw_ver.attr,
|
2019-04-22 09:51:07 +03:00
|
|
|
&dev_attr_dev_state.attr,
|
2019-11-07 13:44:45 +03:00
|
|
|
&dev_attr_trc.attr,
|
2020-07-28 22:22:42 +03:00
|
|
|
&dev_attr_kind.attr,
|
2014-11-19 18:01:39 +03:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
ATTRIBUTE_GROUPS(mei);
|
|
|
|
|
2011-11-13 11:41:14 +04:00
|
|
|
/*
|
|
|
|
* file operations structure will be used for mei char device.
|
|
|
|
*/
|
|
|
|
static const struct file_operations mei_fops = {
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.read = mei_read,
|
|
|
|
.unlocked_ioctl = mei_ioctl,
|
2018-09-11 18:23:00 +03:00
|
|
|
.compat_ioctl = compat_ptr_ioctl,
|
2011-11-13 11:41:14 +04:00
|
|
|
.open = mei_open,
|
|
|
|
.release = mei_release,
|
|
|
|
.write = mei_write,
|
|
|
|
.poll = mei_poll,
|
2017-03-20 16:04:06 +03:00
|
|
|
.fsync = mei_fsync,
|
2015-07-26 09:54:22 +03:00
|
|
|
.fasync = mei_fasync,
|
2011-11-13 11:41:14 +04:00
|
|
|
.llseek = no_llseek
|
|
|
|
};
|
|
|
|
|
2014-06-23 16:10:35 +04:00
|
|
|
/**
|
|
|
|
* mei_minor_get - obtain next free device minor number
|
|
|
|
*
|
|
|
|
* @dev: device pointer
|
|
|
|
*
|
2014-09-29 17:31:49 +04:00
|
|
|
* Return: allocated minor, or -ENOSPC if no free minor left
|
2011-11-13 11:41:14 +04:00
|
|
|
*/
|
2014-06-23 16:10:35 +04:00
|
|
|
static int mei_minor_get(struct mei_device *dev)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&mei_minor_lock);
|
|
|
|
ret = idr_alloc(&mei_idr, dev, 0, MEI_MAX_DEVS, GFP_KERNEL);
|
|
|
|
if (ret >= 0)
|
|
|
|
dev->minor = ret;
|
|
|
|
else if (ret == -ENOSPC)
|
2014-09-29 17:31:42 +04:00
|
|
|
dev_err(dev->dev, "too many mei devices\n");
|
2011-11-13 11:41:14 +04:00
|
|
|
|
2014-06-23 16:10:35 +04:00
|
|
|
mutex_unlock(&mei_minor_lock);
|
|
|
|
return ret;
|
|
|
|
}
|
2013-04-05 23:10:34 +04:00
|
|
|
|
2014-06-23 16:10:35 +04:00
|
|
|
/**
|
|
|
|
* mei_minor_free - mark device minor number as free
|
|
|
|
*
|
|
|
|
* @dev: device pointer
|
|
|
|
*/
|
|
|
|
static void mei_minor_free(struct mei_device *dev)
|
2012-08-06 16:23:55 +04:00
|
|
|
{
|
2014-06-23 16:10:35 +04:00
|
|
|
mutex_lock(&mei_minor_lock);
|
|
|
|
idr_remove(&mei_idr, dev->minor);
|
|
|
|
mutex_unlock(&mei_minor_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
int mei_register(struct mei_device *dev, struct device *parent)
|
|
|
|
{
|
|
|
|
struct device *clsdev; /* class device */
|
|
|
|
int ret, devno;
|
|
|
|
|
|
|
|
ret = mei_minor_get(dev);
|
|
|
|
if (ret < 0)
|
2013-04-05 23:10:34 +04:00
|
|
|
return ret;
|
|
|
|
|
2014-06-23 16:10:35 +04:00
|
|
|
/* Fill in the data structures */
|
|
|
|
devno = MKDEV(MAJOR(mei_devt), dev->minor);
|
|
|
|
cdev_init(&dev->cdev, &mei_fops);
|
2015-06-18 11:41:03 +03:00
|
|
|
dev->cdev.owner = parent->driver->owner;
|
2014-06-23 16:10:35 +04:00
|
|
|
|
|
|
|
/* Add the device */
|
|
|
|
ret = cdev_add(&dev->cdev, devno, 1);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(parent, "unable to add device %d:%d\n",
|
|
|
|
MAJOR(mei_devt), dev->minor);
|
|
|
|
goto err_dev_add;
|
|
|
|
}
|
|
|
|
|
2014-11-19 18:01:39 +03:00
|
|
|
clsdev = device_create_with_groups(mei_class, parent, devno,
|
|
|
|
dev, mei_groups,
|
|
|
|
"mei%d", dev->minor);
|
2014-06-23 16:10:35 +04:00
|
|
|
|
|
|
|
if (IS_ERR(clsdev)) {
|
|
|
|
dev_err(parent, "unable to create device %d:%d\n",
|
|
|
|
MAJOR(mei_devt), dev->minor);
|
|
|
|
ret = PTR_ERR(clsdev);
|
|
|
|
goto err_dev_create;
|
|
|
|
}
|
|
|
|
|
2019-06-11 21:38:16 +03:00
|
|
|
mei_dbgfs_register(dev, dev_name(clsdev));
|
2013-04-05 23:10:34 +04:00
|
|
|
|
|
|
|
return 0;
|
2014-06-23 16:10:35 +04:00
|
|
|
|
|
|
|
err_dev_create:
|
|
|
|
cdev_del(&dev->cdev);
|
|
|
|
err_dev_add:
|
|
|
|
mei_minor_free(dev);
|
|
|
|
return ret;
|
2011-11-13 11:41:14 +04:00
|
|
|
}
|
2013-03-27 18:58:30 +04:00
|
|
|
EXPORT_SYMBOL_GPL(mei_register);
|
2011-11-13 11:41:14 +04:00
|
|
|
|
2013-04-05 23:10:34 +04:00
|
|
|
void mei_deregister(struct mei_device *dev)
|
2011-11-13 11:41:14 +04:00
|
|
|
{
|
2014-06-23 16:10:35 +04:00
|
|
|
int devno;
|
|
|
|
|
|
|
|
devno = dev->cdev.dev;
|
|
|
|
cdev_del(&dev->cdev);
|
|
|
|
|
2013-04-05 23:10:34 +04:00
|
|
|
mei_dbgfs_deregister(dev);
|
2014-06-23 16:10:35 +04:00
|
|
|
|
|
|
|
device_destroy(mei_class, devno);
|
|
|
|
|
|
|
|
mei_minor_free(dev);
|
2011-11-13 11:41:14 +04:00
|
|
|
}
|
2013-03-27 18:58:30 +04:00
|
|
|
EXPORT_SYMBOL_GPL(mei_deregister);
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|
2013-03-27 19:29:57 +04:00
|
|
|
static int __init mei_init(void)
|
|
|
|
{
|
2014-06-23 16:10:35 +04:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
mei_class = class_create(THIS_MODULE, "mei");
|
|
|
|
if (IS_ERR(mei_class)) {
|
|
|
|
pr_err("couldn't create class\n");
|
|
|
|
ret = PTR_ERR(mei_class);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = alloc_chrdev_region(&mei_devt, 0, MEI_MAX_DEVS, "mei");
|
|
|
|
if (ret < 0) {
|
|
|
|
pr_err("unable to allocate char dev region\n");
|
|
|
|
goto err_class;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = mei_cl_bus_init();
|
|
|
|
if (ret < 0) {
|
|
|
|
pr_err("unable to initialize bus\n");
|
|
|
|
goto err_chrdev;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_chrdev:
|
|
|
|
unregister_chrdev_region(mei_devt, MEI_MAX_DEVS);
|
|
|
|
err_class:
|
|
|
|
class_destroy(mei_class);
|
|
|
|
err:
|
|
|
|
return ret;
|
2013-03-27 19:29:57 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit mei_exit(void)
|
|
|
|
{
|
2014-06-23 16:10:35 +04:00
|
|
|
unregister_chrdev_region(mei_devt, MEI_MAX_DEVS);
|
|
|
|
class_destroy(mei_class);
|
2013-03-27 19:29:57 +04:00
|
|
|
mei_cl_bus_exit();
|
|
|
|
}
|
|
|
|
|
|
|
|
module_init(mei_init);
|
|
|
|
module_exit(mei_exit);
|
|
|
|
|
2013-03-27 18:58:30 +04:00
|
|
|
MODULE_AUTHOR("Intel Corporation");
|
|
|
|
MODULE_DESCRIPTION("Intel(R) Management Engine Interface");
|
2013-02-06 16:06:41 +04:00
|
|
|
MODULE_LICENSE("GPL v2");
|
staging/mei: PCI device and char driver support.
contains module entries and PCI driver and char device
definitions (using file_operations, pci_driver struts).
The HW interface is exposed on PCI interface.
PCI:
The MEI HW resources are memory map 32 bit registers
(Host and ME Status Registers and Data Registers)
and interrupt (shared, with Intel GFX on some chipsets
and USB2 controller on others).
The device is part of the chipsets and cannot be hotplugged.
The MEI device present is determined by BIOS configuration.
Probe:
The driver starts the init MEI flow, that is explained
in the patch "MEI driver init flow" [06/10],
then schedules a timer that handles
timeouts and watchdog heartbeats.
Remove:
The driver closes all connections and stops the watchdog.
The driver expose char device that supports:
open, release, write, read, ioctl, poll.
Open:
Upon open the driver allocates HOST data structure
on behalf of application which will resides in the file's
private data and assign a host ID number which
will identify messages between driver client instance
and MEI client.
The driver also checks readiness of the device. The number
of simultaneously opened instances is limited to 253.
(255 - (amthi + watchdog))
Release:
In release the driver sends a Disconnect Command to
ME feature and clean all the data structs.
IOCTL:
MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
The IOCTL links the current file descriptor to ME feature.
This is done by sending MEI Bus command: 'hbm_client_connect_request'
to the ME and waiting for an answer :'hbm_client_connect_response'.
Upon answer reception the driver updates its and HOST data
structures in file structure to indicate that the file
descriptor is associated to ME feature.
Each ME feature is represented by UUID which is given as
an input parameter to the IOCTL, upon success connect command the
IOCTL will return the ME feature properties.
ME can reject CONNECT commands due to several reasons,
most common are:
Invalid UUID ME or feature does not exists in ME.
No More Connection allowed to this is feature,
usually only one connection is allowed.
Write:
Upon write, the driver splits the user data into several MEI
messages up to 512 bytes each and sends it to the HW.
If the user wants to write data to AMTHI ME feature then the
drivers routes the messages through AMTHI queues.
Read:
In read the driver checks is a connection exists to
current file descriptor and then wait until a data is available.
Message might be received (by interrupt from ME) in multiple chunks.
Only complete message is released to the application.
Poll:
Nothing special here. Waiting for see if we have
data available for reading.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Itzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-15 14:43:41 +04:00
|
|
|
|