1. 26 Mar, 2014 2 commits
  2. 18 Mar, 2014 9 commits
  3. 26 Feb, 2014 7 commits
  4. 18 Feb, 2014 2 commits
  5. 13 Feb, 2014 4 commits
    • Lv Zheng's avatar
      ACPICA: Add boot option to disable auto return object repair · 4dde507f
      Lv Zheng authored
      Sometimes, there might be bugs caused by unexpected AML which is compliant
      to the Windows but not compliant to the Linux implementation.
      
      There is a predefined validation mechanism implemented in ACPICA to repair
      the unexpected AML evaluation results that are caused by the unexpected
      AMLs.  For example, BIOS may return misorder _CST result and the repair
      mechanism can make an ascending order on the returned _CST package object
      based on the C-state type.
      This mechanism is quite useful to implement an AML interpreter with better
      compliance with the real world where Windows is the de-facto standard and
      BIOS codes are only tested on one platform thus not compliant to the
      ACPI specification.
      
      But if a compliance issue hasn't been figured out yet, it will be
      difficult for developers to identify if the unexpected evaluation result
      is caused by this mechanism or by the AML interpreter.
      For example, _PR0 is expected to be a control method, but BIOS may use
      Package: "Name(_PR0, Package(1) {P1PR})".
      This boot option can disable the predefined validation mechanism so that
      developers can make sure the root cause comes from the parser/executer.
      
      This patch adds a new kernel parameter to disable this feature.
      
      A build test has been made on a Dell Inspiron mini 1100 (i386 z530)
      machine when this patch is applied and the corresponding boot test is
      performed w/ or w/o the new kernel parameter specified.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=67901Tested-by: default avatarFabian Wehning <fabian.wehning@googlemail.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4dde507f
    • Lv Zheng's avatar
      ACPICA: acpidump: Remove integer types translation protection. · e252652f
      Lv Zheng authored
      Remove translation protection for applications as Linux tools folder will
      start to use such types.
      
      In Linux kernel source tree, after removing this translation protection,
      the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds
      and !__KERNEL__ builds (tools/power/acpi) and the original definitions of
      ACPI_UINT8/16/32/64_MAX are changed.
      
      For !__KERNEL__ builds, this kind of defintions should already been tested
      by the distribution vendors that are distributing binary ACPICA package and
      we've achieved the successful built/run test result in the kernel source
      tree.
      
      For __KERNEL__ builds, there are 2 things affected:
      1. u8/u16/u32/u64/s32/s64 type definitions:
         Since Linux has already type defined u8/u16/u32/u64/s32/s64 in
         include/uapi/asm-generic/int-ll64.h for __KERNEL__.  In order not to
         introduce build regressions where the 2 typedefs are differed,
         ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs.
         It must be defined for Linux __KERNEL__ builds.
      2. ACPI_UINT8/16/32/64_MAX definitions:
         Before applying this change:
           ACPI_UINT8_MAX: sizeof (UINT8)
            UINT8: unsigned char
           ACPI_UINT16_MAX: sizeof (UINT16)
            UINT16: unsigned short
           ACPI_UINT32_MAX: sizeof (UINT32)
            INT32: int
            UINT32: unsigned int
           ACPI_UINT64_MAX: sizeof (UINT64)
            INT64: COMPILER_DEPENDENT_INT64
             COMPILER_DEPENDENT_INT64: signed long (IA64) or
                                       signed long long (IA32)
            UINT64: COMPILER_DEPENDENT_UINT64
             COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or
                                        unsigned long long (IA32)
         After applying this change:
           ACPI_UINT8_MAX: sizeof (u8)
            u8: unsigned char
            UINT8: (removed from actypes.h)
           ACPI_UINT16_MAX: sizeof (u16)
            u16: unsigned short
            UINT16: (removed from actypes.h)
           ACPI_UINT32_MAX: sizeof (u32)
            INT32/UINT32: (removed from actypes.h)
            s32: signed int
            u32: unsigned int
           ACPI_UINT64_MAX: sizeof (u64)
            INT64/UINT64: (removed from actypes.h)
            u64: unsigned long long
            s64: signed long long
            COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more)
                                      signed long long (IA32) (not used any more)
            COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more)
                                       unsigned long long (IA32) (not used any more)
         All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64.  It
         is changed from sizeof(unsigned long) to sizeof(unsigned long long).
         By investigation, 64bit Linux kernel build is LP64 compliant, i.e.,
         sizeof(long) and (pointer) are 64.  As sizeof(unsigned long) equals to
         sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be
         disabled, this change actually will not affect the value of
         ACPI_UINT64_MAX on IA64 platforms.
      
      This patch is necessary for the ACPICA's acpidump tool to build
      correctly.  Lv Zheng.
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e252652f
    • Lv Zheng's avatar
      ACPICA: acpidump: Add sparse declarators support. · 7e66b46b
      Lv Zheng authored
      Linux kernel resident ACPICA headers include some sparse declarators for
      kernel static checkers.  This patch adds code to disable them for non
      __KERNEL__ defined code so that it is possible for the ACPICA user space
      tool's source files to be built with Linux kernel ACPICA header files
      included.  Lv Zheng.
      
      Linux kernel build is not affected by this commit.
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7e66b46b
    • Bob Moore's avatar
      ACPICA: Add "Windows 2013" string to _OSI support. · faae404e
      Bob Moore authored
      This urgent patch is cherry picked from ACPICA upstream.
      It is reported that some platforms fail to boot without this new _OSI
      string.
      
      This change adds this string for Windows 8.1 and Server 2012 R2.
      Reported-by: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarBob Moore <Robert.Moore@intel.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      faae404e
  6. 10 Feb, 2014 14 commits
  7. 09 Feb, 2014 2 commits
    • Al Viro's avatar
      fix a kmap leak in virtio_console · c9efe511
      Al Viro authored
      While we are at it, don't do kmap() under kmap_atomic(), *especially*
      for a page we'd allocated with GFP_KERNEL.  It's spelled "page_address",
      and had that been more than that, we'd have a real trouble - kmap_high()
      can block, and doing that while holding kmap_atomic() is a Bad Idea(tm).
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      c9efe511
    • Al Viro's avatar
      fix O_SYNC|O_APPEND syncing the wrong range on write() · d311d79d
      Al Viro authored
      It actually goes back to 2004 ([PATCH] Concurrent O_SYNC write support)
      when sync_page_range() had been introduced; generic_file_write{,v}() correctly
      synced
      	pos_after_write - written .. pos_after_write - 1
      but generic_file_aio_write() synced
      	pos_before_write .. pos_before_write + written - 1
      instead.  Which is not the same thing with O_APPEND, obviously.
      A couple of years later correct variant had been killed off when
      everything switched to use of generic_file_aio_write().
      
      All users of generic_file_aio_write() are affected, and the same bug
      has been copied into other instances of ->aio_write().
      
      The fix is trivial; the only subtle point is that generic_write_sync()
      ought to be inlined to avoid calculations useless for the majority of
      calls.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      d311d79d