1. 25 7月, 2019 1 次提交
    • M
      treewide: add "WITH Linux-syscall-note" to SPDX tag of uapi headers · d9c52522
      Masahiro Yamada 提交于
      UAPI headers licensed under GPL are supposed to have exception
      "WITH Linux-syscall-note" so that they can be included into non-GPL
      user space application code.
      
      The exception note is missing in some UAPI headers.
      
      Some of them slipped in by the treewide conversion commit b2441318
      ("License cleanup: add SPDX GPL-2.0 license identifier to files with
      no license"). Just run:
      
        $ git show --oneline b2441318 -- arch/x86/include/uapi/asm/
      
      I believe they are not intentional, and should be fixed too.
      
      This patch was generated by the following script:
      
        git grep -l --not -e Linux-syscall-note --and -e SPDX-License-Identifier \
          -- :arch/*/include/uapi/asm/*.h :include/uapi/ :^*/Kbuild |
        while read file
        do
                sed -i -e '/[[:space:]]OR[[:space:]]/s/\(GPL-[^[:space:]]*\)/(\1 WITH Linux-syscall-note)/g' \
                -e '/[[:space:]]or[[:space:]]/s/\(GPL-[^[:space:]]*\)/(\1 WITH Linux-syscall-note)/g' \
                -e '/[[:space:]]OR[[:space:]]/!{/[[:space:]]or[[:space:]]/!s/\(GPL-[^[:space:]]*\)/\1 WITH Linux-syscall-note/g}' $file
        done
      
      After this patch is applied, there are 5 UAPI headers that do not contain
      "WITH Linux-syscall-note". They are kept untouched since this exception
      applies only to GPL variants.
      
        $ git grep --not -e Linux-syscall-note --and -e SPDX-License-Identifier \
          -- :arch/*/include/uapi/asm/*.h :include/uapi/ :^*/Kbuild
        include/uapi/drm/panfrost_drm.h:/* SPDX-License-Identifier: MIT */
        include/uapi/linux/batman_adv.h:/* SPDX-License-Identifier: MIT */
        include/uapi/linux/qemu_fw_cfg.h:/* SPDX-License-Identifier: BSD-3-Clause */
        include/uapi/linux/vbox_err.h:/* SPDX-License-Identifier: MIT */
        include/uapi/linux/virtio_iommu.h:/* SPDX-License-Identifier: BSD-3-Clause */
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d9c52522
  2. 19 6月, 2019 1 次提交
  3. 04 11月, 2017 2 次提交
    • M
      platform/x86: dell-smbios-wmi: introduce userspace interface · f2645fa3
      Mario Limonciello 提交于
      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: NMario Limonciello <mario.limonciello@dell.com>
      Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
      Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
      f2645fa3
    • M
      platform/x86: wmi: create userspace interface for drivers · 44b6b766
      Mario Limonciello 提交于
      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: NMario Limonciello <mario.limonciello@dell.com>
      Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
      Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
      44b6b766