1. 24 3月, 2018 4 次提交
  2. 22 3月, 2018 1 次提交
    • M
      platform/x86: fujitsu-laptop: Revert UNSUPPORTED_CMD back to an int · 502ab004
      Michał Kępień 提交于
      UNSUPPORTED_CMD was previously 0x80000000 (int), but commit 819cddae
      ("platform/x86: fujitsu-laptop: Clean up constants") changed it into an
      unsigned long due to BIT() being used to define it.  As call_fext_func()
      returns an int, 0x80000000 would get type promoted when compared to an
      unsigned long, which on a 64-bit system would cause it to become
      0xffffffff80000000 due to sign extension.  This causes one logical
      condition in fujitsu-laptop to always be true and another one to always
      be false on 64-bit systems.  Fix this by reverting UNSUPPORTED_CMD back
      to an int.
      
      This patch fixes the following smatch warnings:
      
      drivers/platform/x86/fujitsu-laptop.c:763 acpi_fujitsu_laptop_leds_register() warn: always true condition '(call_fext_func(device, ((1 << (12)) | (1 << (0))), 2, (1 << (16)), 0) != (1 << (31))) => (s32min-s32max != 2147483648)'
      drivers/platform/x86/fujitsu-laptop.c:816 acpi_fujitsu_laptop_add() warn: impossible condition '(priv->flags_supported == (1 << (31))) => (0-2147483647,18446744071562067968-u64max == 2147483648)'
      
      Fixes: 819cddae ("platform/x86: fujitsu-laptop: Clean up constants")
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
      Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
      Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
      502ab004
  3. 15 3月, 2018 1 次提交
    • D
      platform/x86: Fix dell driver init order · 7129707e
      Darren Hart (VMware) 提交于
      Update the initcall ordering to satisfy the following dependency
      ordering:
      
      1. DCDBAS, ACPI_WMI
      2. DELL_SMBIOS, DELL_RBTN
      3. DELL_LAPTOP, DELL_WMI
      
      By assigning them to the following initcall levels:
      
      subsys_initcall: DCDBAS, ACPI_WMI
      module_init: DELL_SMBIOS, DELL_RBTN
      late_initcall: DELL_LAPTOP, DELL_WMI
      
      Cc: Dominik Brodowski <linux@dominikbrodowski.net>
      Cc: Mario.Limonciello@dell.com
      Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
      7129707e
  4. 13 3月, 2018 1 次提交
    • D
      platform/x86: dell-smbios: Resolve dependency error on ACPI_WMI · 4716007c
      Darren Hart 提交于
      Similarly to DCDBAS for DELL_SMBIOS_SMM, if DELL_SMBIOS_WMI is enabled,
      DELL_SMBIOS becomes dependent on ACPI_WMI. Update the depends lines to
      prevent a configuration where DELL_SMBIOS=y and either backend
      dependency =m. Update the comment accordingly.
      
      Cc: Mario Limonciello <mario.limonciello@dell.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Dominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
      4716007c
  5. 09 3月, 2018 1 次提交
    • D
      platform/x86: dell-smbios: Resolve dependency error on DCDBAS · cc69c88f
      Darren Hart (VMware) 提交于
      When the DELL_SMBIOS_SMM backend is enabled, the DELL_SMBIOS symbol
      depends on DELL_DCDBAS, and we must avoid the situation where
      DELL_SMBIOS=y and DCDBAS=m.
      
      Adding the conditional dependency to DELL_SMBIOS such as:
      
      depends !DELL_SMBIOS_SMM || (DCDBAS || DCDBAS=n)
      
      results in the Kconfig tooling complaining about a circular dependency,
      although it appears to work in practice.
      
      Avoid the errors by simplifying the dependency and forcing DELL_SMBIOS
      to be <= DCDBAS if DCDBAS is enabled (thanks to Greg KH for the
      suggestion).
      
      Cc: Mario.Limonciello@dell.com
      Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
      cc69c88f
  6. 06 3月, 2018 1 次提交
    • D
      platform/x86: Allow for SMBIOS backend defaults · c715e434
      Darren Hart (VMware) 提交于
      Avoid accidental configurations by setting default y for DELL_SMBIOS
      backends. Avoid this impacting the default build size, by making them
      dependent on DELL_SMBIOS, so they only appear when DELL_SMBIOS is
      manually selected, or by DELL_LAPTOP or DELL_WMI.
      
      While DELL_SMBIOS does have a prompt, it does not have any dependencies.
      Keeping DELL_SMBIOS visible, despite being "select"ed by DELL_LAPTOP and
      DELL_WMI, is a deliberate choice to provide context for the WMI and SMM
      backends, which would otherwise appear to float without context within
      the menu.
      Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
      c715e434
  7. 03 3月, 2018 3 次提交
  8. 02 3月, 2018 1 次提交
  9. 28 2月, 2018 2 次提交
  10. 25 2月, 2018 8 次提交
  11. 24 2月, 2018 9 次提交
  12. 19 2月, 2018 1 次提交
  13. 15 2月, 2018 6 次提交
  14. 12 2月, 2018 1 次提交
    • L
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      Linus Torvalds 提交于
      This is the mindless scripted replacement of kernel use of POLL*
      variables as described by Al, done by this script:
      
          for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
              L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
              for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
          done
      
      with de-mangling cleanups yet to come.
      
      NOTE! On almost all architectures, the EPOLL* constants have the same
      values as the POLL* constants do.  But they keyword here is "almost".
      For various bad reasons they aren't the same, and epoll() doesn't
      actually work quite correctly in some cases due to this on Sparc et al.
      
      The next patch from Al will sort out the final differences, and we
      should be all done.
      Scripted-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9a08845