Skip to content
  • Mario Limonciello's avatar
    platform/x86: wmi: create userspace interface for drivers · 44b6b766
    Mario Limonciello authored
    
    
    For WMI operations that are only Set or Query readable and writable sysfs
    attributes created by WMI vendor drivers or the bus driver makes sense.
    
    For other WMI operations that are run on Method, there needs to be a
    way to guarantee to userspace that the results from the method call
    belong to the data request to the method call.  Sysfs attributes don't
    work well in this scenario because two userspace processes may be
    competing at reading/writing an attribute and step on each other's
    data.
    
    When a WMI vendor driver declares a callback method in the wmi_driver
    the WMI bus driver will create a character device that maps to that
    function.  This callback method will be responsible for filtering
    invalid requests and performing the actual call.
    
    That character device will correspond to this path:
    /dev/wmi/$driver
    
    Performing read() on this character device will provide the size
    of the buffer that the character device needs to perform calls.
    This buffer size can be set by vendor drivers through a new symbol
    or when MOF parsing is available by the MOF.
    
    Performing ioctl() on this character device will be interpretd
    by the WMI bus driver. It will perform sanity tests for size of
    data, test them for a valid instance, copy the data from userspace
    and pass iton to the vendor driver to further process and run.
    
    This creates an implicit policy that each driver will only be allowed
    a single character device.  If a module matches multiple GUID's,
    the wmi_devices will need to be all handled by the same wmi_driver.
    
    The WMI vendor drivers will be responsible for managing inappropriate
    access to this character device and proper locking on data used by
    it.
    
    When a WMI vendor driver is unloaded the WMI bus driver will clean
    up the character device and any memory allocated for the call.
    
    Signed-off-by: default avatarMario Limonciello <mario.limonciello@dell.com>
    Reviewed-by: default avatarEdward O'Callaghan <quasisec@google.com>
    Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
    44b6b766