forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge tag 'char-misc-3.10-rc1' of git://git.kernel.org/pub/scm/linux/…
…kernel/git/gregkh/char-misc Pull char/misc driver update from Greg Kroah-Hartman: "Here's the big char / misc driver update for 3.10-rc1 A number of various driver updates, the majority being new functionality in the MEI driver subsystem (it's now a subsystem, it started out just a single driver), extcon updates, memory updates, hyper-v updates, and a bunch of other small stuff that doesn't fit in any other tree. All of these have been in linux-next for a while" * tag 'char-misc-3.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (148 commits) Tools: hv: Fix a checkpatch warning tools: hv: skip iso9660 mounts in hv_vss_daemon tools: hv: use FIFREEZE/FITHAW in hv_vss_daemon tools: hv: use getmntent in hv_vss_daemon Tools: hv: Fix a checkpatch warning tools: hv: fix checks for origin of netlink message in hv_vss_daemon Tools: hv: fix warnings in hv_vss_daemon misc: mark spear13xx-pcie-gadget as broken mei: fix krealloc() misuse in in mei_cl_irq_read_msg() mei: reduce flow control only for completed messages mei: reseting -> resetting mei: fix reading large reposnes mei: revamp mei_irq_read_client_message function mei: revamp mei_amthif_irq_read_message mei: revamp hbm state machine Revert "drivers/scsi: use module_pcmcia_driver() in pcmcia drivers" Revert "scsi: pcmcia: nsp_cs: remove module init/exit function prototypes" scsi: pcmcia: nsp_cs: remove module init/exit function prototypes mei: wd: fix line over 80 characters misc: tsl2550: Use dev_pm_ops ...
- Loading branch information
Showing
131 changed files
with
4,596 additions
and
1,331 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
What: /sys/bus/mei/devices/.../modalias | ||
Date: March 2013 | ||
KernelVersion: 3.10 | ||
Contact: Samuel Ortiz <[email protected]> | ||
[email protected] | ||
Description: Stores the same MODALIAS value emitted by uevent | ||
Format: mei:<mei device name> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,18 @@ | ||
* Qualcomm SSBI | ||
|
||
Some Qualcomm MSM devices contain a point-to-point serial bus used to | ||
communicate with a limited range of devices (mostly power management | ||
chips). | ||
|
||
These require the following properties: | ||
|
||
- compatible: "qcom,ssbi" | ||
|
||
- qcom,controller-type | ||
indicates the SSBI bus variant the controller should use to talk | ||
with the slave device. This should be one of "ssbi", "ssbi2", or | ||
"pmic-arbiter". The type chosen is determined by the attached | ||
slave. | ||
|
||
The slave device should be the single child node of the ssbi device | ||
with a compatible field. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,138 @@ | ||
Intel(R) Management Engine (ME) Client bus API | ||
=============================================== | ||
|
||
|
||
Rationale | ||
========= | ||
MEI misc character device is useful for dedicated applications to send and receive | ||
data to the many FW appliance found in Intel's ME from the user space. | ||
However for some of the ME functionalities it make sense to leverage existing software | ||
stack and expose them through existing kernel subsystems. | ||
|
||
In order to plug seamlessly into the kernel device driver model we add kernel virtual | ||
bus abstraction on top of the MEI driver. This allows implementing linux kernel drivers | ||
for the various MEI features as a stand alone entities found in their respective subsystem. | ||
Existing device drivers can even potentially be re-used by adding an MEI CL bus layer to | ||
the existing code. | ||
|
||
|
||
MEI CL bus API | ||
=========== | ||
A driver implementation for an MEI Client is very similar to existing bus | ||
based device drivers. The driver registers itself as an MEI CL bus driver through | ||
the mei_cl_driver structure: | ||
|
||
struct mei_cl_driver { | ||
struct device_driver driver; | ||
const char *name; | ||
|
||
const struct mei_cl_device_id *id_table; | ||
|
||
int (*probe)(struct mei_cl_device *dev, const struct mei_cl_id *id); | ||
int (*remove)(struct mei_cl_device *dev); | ||
}; | ||
|
||
struct mei_cl_id { | ||
char name[MEI_NAME_SIZE]; | ||
kernel_ulong_t driver_info; | ||
}; | ||
|
||
The mei_cl_id structure allows the driver to bind itself against a device name. | ||
|
||
To actually register a driver on the ME Client bus one must call the mei_cl_add_driver() | ||
API. This is typically called at module init time. | ||
|
||
Once registered on the ME Client bus, a driver will typically try to do some I/O on | ||
this bus and this should be done through the mei_cl_send() and mei_cl_recv() | ||
routines. The latter is synchronous (blocks and sleeps until data shows up). | ||
In order for drivers to be notified of pending events waiting for them (e.g. | ||
an Rx event) they can register an event handler through the | ||
mei_cl_register_event_cb() routine. Currently only the MEI_EVENT_RX event | ||
will trigger an event handler call and the driver implementation is supposed | ||
to call mei_recv() from the event handler in order to fetch the pending | ||
received buffers. | ||
|
||
|
||
Example | ||
======= | ||
As a theoretical example let's pretend the ME comes with a "contact" NFC IP. | ||
The driver init and exit routines for this device would look like: | ||
|
||
#define CONTACT_DRIVER_NAME "contact" | ||
|
||
static struct mei_cl_device_id contact_mei_cl_tbl[] = { | ||
{ CONTACT_DRIVER_NAME, }, | ||
|
||
/* required last entry */ | ||
{ } | ||
}; | ||
MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl); | ||
|
||
static struct mei_cl_driver contact_driver = { | ||
.id_table = contact_mei_tbl, | ||
.name = CONTACT_DRIVER_NAME, | ||
|
||
.probe = contact_probe, | ||
.remove = contact_remove, | ||
}; | ||
|
||
static int contact_init(void) | ||
{ | ||
int r; | ||
|
||
r = mei_cl_driver_register(&contact_driver); | ||
if (r) { | ||
pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n"); | ||
return r; | ||
} | ||
|
||
return 0; | ||
} | ||
|
||
static void __exit contact_exit(void) | ||
{ | ||
mei_cl_driver_unregister(&contact_driver); | ||
} | ||
|
||
module_init(contact_init); | ||
module_exit(contact_exit); | ||
|
||
And the driver's simplified probe routine would look like that: | ||
|
||
int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id) | ||
{ | ||
struct contact_driver *contact; | ||
|
||
[...] | ||
mei_cl_enable_device(dev); | ||
|
||
mei_cl_register_event_cb(dev, contact_event_cb, contact); | ||
|
||
return 0; | ||
} | ||
|
||
In the probe routine the driver first enable the MEI device and then registers | ||
an ME bus event handler which is as close as it can get to registering a | ||
threaded IRQ handler. | ||
The handler implementation will typically call some I/O routine depending on | ||
the pending events: | ||
|
||
#define MAX_NFC_PAYLOAD 128 | ||
|
||
static void contact_event_cb(struct mei_cl_device *dev, u32 events, | ||
void *context) | ||
{ | ||
struct contact_driver *contact = context; | ||
|
||
if (events & BIT(MEI_EVENT_RX)) { | ||
u8 payload[MAX_NFC_PAYLOAD]; | ||
int payload_size; | ||
|
||
payload_size = mei_recv(dev, payload, MAX_NFC_PAYLOAD); | ||
if (payload_size <= 0) | ||
return; | ||
|
||
/* Hook to the NFC subsystem */ | ||
nfc_hci_recv_frame(contact->hdev, payload, payload_size); | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.