1. 08 Jan, 2018 1 commit
  2. 08 Nov, 2017 1 commit
  3. 03 Nov, 2017 3 commits
    • 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
    • Mario Limonciello's avatar
      platform/x86: wmi: Don't allow drivers to get each other's GUIDs · f97e058c
      Mario Limonciello authored
      
      
      The only driver using this was dell-wmi, and it really was a hack.
      The driver was getting a data attribute from another driver and this
      type of action should not be encouraged.
      
      Rather drivers that need to interact with one another should pass
      data back and forth via exported functions.
      
      Signed-off-by: default avatarMario Limonciello <mario.limonciello@dell.com>
      Reviewed-by: default avatarEdward O'Callaghan <quasisec@google.com>
      Reviewed-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      f97e058c
    • Mario Limonciello's avatar
      platform/x86: wmi: Add new method wmidev_evaluate_method · 722c856d
      Mario Limonciello authored
      
      
      Drivers properly using the wmibus can pass their wmi_device
      pointer rather than the GUID back to the WMI bus to evaluate
      the proper methods.
      
      Any "new" drivers added that use the WMI bus should use this
      rather than the old wmi_evaluate_method that would take the
      GUID.
      
      Signed-off-by: default avatarMario Limonciello <mario.limonciello@dell.com>
      Reviewed-by: default avatarEdward O'Callaghan <quasisec@google.com>
      Reviewed-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      722c856d
  4. 27 Sep, 2017 3 commits
  5. 18 Aug, 2017 1 commit
  6. 21 Jul, 2017 1 commit
  7. 13 Jun, 2017 2 commits
  8. 06 Jun, 2017 14 commits
  9. 21 May, 2016 1 commit
  10. 10 Sep, 2015 1 commit
    • Rasmus Villemoes's avatar
      wmi: Remove private %pUL implementation · 85b4e4eb
      Rasmus Villemoes authored
      
      
      The work performed by wmi_gtoa is equivalent to simply sprintf(out,
      "%pUL", in), so one could replace its body by this. However, most
      users feed the result directly as a %s argument to some other function
      which also understands the %p extensions (they all ultimately use
      vsnprintf), so we can eliminate some stack buffers and quite a bit of
      code by just using %pUL directly.
      
      In wmi_dev_uevent I'm not sure whether there's room for a
      nul-terminator in env->buf, so I've just replaced wmi_gtoa with the
      equivalent sprintf call.
      
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      85b4e4eb
  11. 08 Apr, 2015 1 commit
  12. 25 Mar, 2015 1 commit
    • Paul Gortmaker's avatar
      x86/wmi: delete unused wmi_data_lock mutex causing gcc warning · f62a4ffd
      Paul Gortmaker authored
      In commit bff431e4
      
       ("ACPI: WMI: Add
      ACPI-WMI mapping driver") this mutex was added, but the rest of the
      final commit never actually made use of it, resulting in:
      
       In file included from include/linux/mutex.h:29:0,
                        from include/linux/kernfs.h:13,
                        from include/linux/sysfs.h:15,
                        from include/linux/kobject.h:21,
                        from include/linux/device.h:17,
                        from drivers/platform/x86/wmi.c:35:
       drivers/platform/x86/wmi.c:48:21: warning: ‘wmi_data_lock’ defined but not used [-Wunused-variable]
        static DEFINE_MUTEX(wmi_data_lock);
                            ^
      
      A git grep shows no other instances/references to the wmi_data_lock.
      Delete it, assuming that the mutex addition was just a leftover from
      an earlier work in progress version of the change, since the original
      dates from 2008.
      
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      f62a4ffd
  13. 16 Aug, 2014 1 commit
    • Himangi Saraogi's avatar
      WMI: Remove unnecessary null test · 959ef6d5
      Himangi Saraogi authored
      
      
      This patch removes the null test on block. block is initialized at the
      beginning of the function to &wblock->gblock. Since wblock is
      dereferenced prior to the null test, wblock must be a valid pointer,
      and &wblock->gblock cannot be null.
      
      The following Coccinelle script is used for detecting the change:
      
      @r@
      expression e,f;
      identifier g,y;
      statement S1,S2;
      @@
      
      *e = &f->g
      <+...
       f->y
       ...+>
      *if (e != NULL || ...)
       S1 else S2
      
      Signed-off-by: default avatarHimangi Saraogi <himangi774@gmail.com>
      Signed-off-by: default avatarMatthew Garrett <matthew.garrett@nebula.com>
      959ef6d5
  14. 07 Dec, 2013 1 commit
    • Lv Zheng's avatar
      ACPI: Clean up inclusions of ACPI header files · 8b48463f
      Lv Zheng authored
      
      
      Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
      <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
      inclusions and remove some inclusions of those files that aren't
      necessary.
      
      First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
      should not be included directly from any files that are built for
      CONFIG_ACPI unset, because that generally leads to build warnings about
      undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
      <linux/acpi.h> includes those files and for CONFIG_ACPI unset it
      provides stub ACPI symbols to be used in that case.
      
      Second, there are ordering dependencies between those files that always
      have to be met.  Namely, it is required that <acpi/acpi_bus.h> be included
      prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
      latter depends on are always there.  And <acpi/acpi.h> which provides
      basic ACPICA type declarations should always be included prior to any other
      ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
      <linux/acpi.h> as appropriate.
      
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8b48463f
  15. 21 Nov, 2013 1 commit
  16. 23 Sep, 2013 2 commits
  17. 05 Sep, 2013 1 commit
  18. 20 Aug, 2013 1 commit
  19. 03 Jul, 2013 1 commit
  20. 25 Jan, 2013 1 commit
  21. 12 Jan, 2012 1 commit