When spinlock is nested, and the outside one is spin_lock_bh, the inner
spinlock should also be spin_lock_bh, otherwise it will bring softirq-safe
to softirq-unsafe lock conversion.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In orginal code, the device_lock and read_io_lock is mess order when nested,
which may bring dead lock. This patch unify the spinlock order of device_lock
and read_io_lock. First acquire device_lock, then read_io_lock.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When the two locks are nested, the code should always first acquire file_lock,
and then acquire device_lock in order not to generate dead-lock race.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix userspace pointer mess.
- In memcmp(), dest and src pointer should be both in kernel space.
- Add (void __user *) modification before userspace pointer.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
List some of the remaining issues in the code.
Cc: Anas Nashif <anas.nashif@intel.com>
Cc: Marcin Obara <marcin.obara@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This resolves a lot of the more obvious sparse warnings in the code.
There still are some major problems in the ioctl handlers dealing with
user and kernel pointers that this patch does not resolve, that needs to
be addressed still.
Also, the locking seems to be a bit strange in places, which sparse
points out, that too need to be resolved.
Cc: Anas Nashif <anas.nashif@intel.com>
Cc: Marcin Obara <marcin.obara@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This resolves the outstanding scripts/checkpatch.pl warnings
Cc: Anas Nashif <anas.nashif@intel.com>
Cc: Marcin Obara <marcin.obara@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It's not needed now that we are now in the main kernel tree.
Cc: Anas Nashif <anas.nashif@intel.com>
Cc: Marcin Obara <marcin.obara@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Intel Management Engine Interface (aka HECI: Host Embedded
Controller Interface ) enables communication between the host OS and
the Management Engine firmware. MEI is bi-directional, and either the
host or Intel AMT firmware can initiate transactions.
The core hardware architecture of Intel Active Management Technology
(Intel AMT) is resident in firmware. The micro-controller within the
chipset's graphics and memory controller (GMCH) hub houses the
Management Engine (ME) firmware, which implements various services
on behalf of management applications.
Some of the ME subsystems that can be access via MEI driver:
- Intel(R) Quiet System Technology (QST) is implemented as a firmware
subsystem that runs in the ME. Programs that wish to expose the
health monitoring and fan speed control capabilities of Intel(R) QST
will need to use the MEI driver to communicate with the ME sub-system.
- ASF is the "Alert Standard Format" which is an DMTF manageability
standard. It is implemented in the PC's hardware and firmware, and is
managed from a remote console.
Most recent Intel desktop chipsets have one or more of the above ME
services. The MEI driver will make it possible to support the above
features on Linux and provides applications access to the ME and it's
features.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Marcin Obara <marcin.obara@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
