The Dell SMBIOS WMI interface will fail for some more complex calls unless
a WMI hotfix has been included. Most platforms have this fix available in
a maintenance BIOS release. In the case the driver is loaded on a
platform without this fix, disable the userspace interface.
A hotfix indicator is present in the dell-wmi-descriptor that represents
whether or not more complex calls will work properly.
"Simple" calls such as those used by dell-laptop and dell-wmi will continue
to work properly so dell-smbios-wmi should not be blocked from binding and
being used as the dell-smbios dispatcher.
Suggested-by: Girish Prakash <girish.prakash@dell.com>
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
dell-wmi and dell-smbios-wmi are dependent upon dell-wmi-descriptor
finishing probe successfully to probe themselves.
Currently if dell-wmi-descriptor fails probing in a non-recoverable way
(such as invalid header) dell-wmi and dell-smbios-wmi will continue to
try to redo probing due to deferred probing.
To solve this have the dependent drivers query the dell-wmi-descriptor
driver whether the descriptor has been determined valid. The possible
results are:
-ENODEV: Descriptor GUID missing from WMI bus
-EPROBE_DEFER: Descriptor not yet probed, dependent driver should wait
and use deferred probing
< 0: Descriptor probed, invalid. Dependent driver should return an
error.
0: Successful descriptor probe, dependent driver can continue
Successful descriptor probe still doesn't mean that the descriptor driver
is necessarily bound at the time of initialization of dependent driver.
Userspace can unbind the driver, so all methods used from driver
should still be verified to return success values otherwise deferred
probing be used.
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Unbound devices may race with calling this function causing the mutex
to stay locked. This failure mode should have released the mutex too.
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
It's important for the driver to provide a R/W ioctl to ensure that
two competing userspace processes don't race to provide or read each
others data.
This userspace character device will be used to perform SMBIOS calls
from any applications.
It provides an ioctl that will allow passing the WMI calling
interface buffer between userspace and kernel space.
This character device is intended to deprecate the dcdbas kernel module
and the interface that it provides to userspace.
To perform an SMBIOS IOCTL call using the character device userspace will
perform a read() on the the character device. The WMI bus will provide
a u64 variable containing the necessary size of the IOCTL buffer.
The API for interacting with this interface is defined in documentation
as well as the WMI uapi header provides the format of the structures.
Not all userspace requests will be accepted. The dell-smbios filtering
functionality will be used to prevent access to certain tokens and calls.
All whitelisted commands and tokens are now shared out to userspace so
applications don't need to define them in their own headers.
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Reviewed-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
The dell-smbios stack only currently uses an SMI interface which grants
direct access to physical memory to the firmware SMM methods via a pointer.
This dispatcher driver adds a WMI-ACPI interface that is detected by WMI
probe and preferred over the SMI interface in dell-smbios.
Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
for a buffer of data storage when SMM calls are performed.
This is a safer approach to use in kernel drivers as the SMM will
only have access to that OperationRegion.
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Reviewed-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
