linux.git/drivers/acpi, branch v4.7-rc2 Linux kernel source tree Merge branches 'acpica-fixes', 'acpi-video' and 'acpi-processor' 2016-06-03T20:35:05+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2016-06-03T20:35:05+00:00 60c07f80b04698f6c054b675cb67ec5e7ee8db27 * acpica-fixes: ACPICA / Hardware: Fix old register check in acpi_hw_get_access_bit_width() * acpi-video: ACPI / Thermal / video: fix max_level incorrect value * acpi-processor: ACPI / processor: Avoid reserving IO regions too early 
* acpica-fixes:
  ACPICA / Hardware: Fix old register check in acpi_hw_get_access_bit_width()

* acpi-video:
  ACPI / Thermal / video: fix max_level incorrect value

* acpi-processor:
  ACPI / processor: Avoid reserving IO regions too early
ACPI / processor: Avoid reserving IO regions too early 2016-06-01T23:57:50+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2016-06-01T23:57:50+00:00 86314751c7945fa0c67f459beeda2e7c610ca429 Roland Dreier reports that one of his systems cannot boot because of the changes made by commit ac212b6980d8 (ACPI / processor: Use common hotplug infrastructure). The problematic part of it is the request_region() call in acpi_processor_get_info() that used to run at module init time before the above commit and now it runs much earlier. Unfortunately, the region(s) reserved by it fall into a range the PCI subsystem attempts to reserve for AHCI IO BARs. As a result, the PCI reservation fails and AHCI doesn't work, while previously the PCI reservation would be made before acpi_processor_get_info() and it would succeed. That request_region() call, however, was overlooked by commit ac212b6980d8, as it is not necessary for the enumeration of the processors. It only is needed when the ACPI processor driver actually attempts to handle them which doesn't happen before loading the ACPI processor driver module. Therefore that call should have been moved from acpi_processor_get_info() into that module. Address the problem by moving the request_region() call in question out of acpi_processor_get_info() and use the observation that the region reserved by it is only needed if the FADT-based CPU throttling method is going to be used, which means that it should be sufficient to invoke it from acpi_processor_get_throttling_fadt(). Fixes: ac212b6980d8 (ACPI / processor: Use common hotplug infrastructure) Reported-by: Roland Dreier <roland@purestorage.com> Tested-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Roland Dreier reports that one of his systems cannot boot because of
the changes made by commit ac212b6980d8 (ACPI / processor: Use common
hotplug infrastructure).

The problematic part of it is the request_region() call in
acpi_processor_get_info() that used to run at module init time before
the above commit and now it runs much earlier.  Unfortunately, the
region(s) reserved by it fall into a range the PCI subsystem attempts
to reserve for AHCI IO BARs.  As a result, the PCI reservation fails
and AHCI doesn't work, while previously the PCI reservation would
be made before acpi_processor_get_info() and it would succeed.

That request_region() call, however, was overlooked by commit
ac212b6980d8, as it is not necessary for the enumeration of the
processors.  It only is needed when the ACPI processor driver
actually attempts to handle them which doesn't happen before
loading the ACPI processor driver module.  Therefore that call
should have been moved from acpi_processor_get_info() into that
module.

Address the problem by moving the request_region() call in question
out of acpi_processor_get_info() and use the observation that the
region reserved by it is only needed if the FADT-based CPU
throttling method is going to be used, which means that it should
be sufficient to invoke it from acpi_processor_get_throttling_fadt().

Fixes: ac212b6980d8 (ACPI / processor: Use common hotplug infrastructure)
Reported-by: Roland Dreier <roland@purestorage.com>
Tested-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA / Hardware: Fix old register check in acpi_hw_get_access_bit_width() 2016-06-01T20:44:22+00:00 Lv Zheng lv.zheng@intel.com 2016-06-01T03:03:20+00:00 7f9bef9debafcb767d00efb177d0f2edd4940eab The address check in acpi_hw_get_access_bit_width() should be byte width based, not bit width based. This patch fixes this mistake. For those who want to review acpi_hw_access_bit_width(), here is the concerns and the design details of the function: It is supposed that the GAS Address field should be aligned to the byte width indicated by the GAS AccessSize field. Similarly, for the old non GAS register, it is supposed that its Address should be aligned to its Length. For the "AccessSize = 0 (meaning ANY)" case, we try to return the maximum instruction width (64 for MMIO or 32 for PIO) or the user expected access bit width (64 for acpi_read()/acpi_write() or 32 for acpi_hw_read()/ acpi_hw_write()) and it is supposed that the GAS Address field should always be aligned to the maximum expected access bit width (otherwise it can't be accessed using ANY access bit width). The problem is in acpi_tb_init_generic_address(), where the non GAS register's Length is converted into the GAS BitWidth field, its Address is converted into the GAS Address field, and the GAS AccessSize field is left 0 but most of the registers actually cannot be accessed using "ANY" accesses. As a conclusion, when AccessSize = 0 (ANY), the Address should either be aligned to the BitWidth (wrong conversion) or aligned to 32 for PIO or 64 for MMIO (real GAS). Since currently, max_bit_width is 32, then: 1. BitWidth for the wrong conversion is 8,16,32; and 2. The Address of the real GAS should always be aligned to 8,16,32. The address alignment check to exclude false matched real GAS is not necessary. Thus this patch fixes the issue by removing the address alignment check. On the other hand, we in fact could use a simpler check of "reg->bit_width < max_bit_width" to exclude the "BitWidth=64 PIO" case that may be issued from acpi_read()/acpi_write() in the future. Fixes: b314a172ee96 (ACPICA: Hardware: Add optimized access bit width support) Reported-and-tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Mike Marshall <hubcap@omnibond.com> Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
The address check in acpi_hw_get_access_bit_width() should be byte width
based, not bit width based. This patch fixes this mistake.

For those who want to review acpi_hw_access_bit_width(), here is the
concerns and the design details of the function:

It is supposed that the GAS Address field should be aligned to the byte
width indicated by the GAS AccessSize field. Similarly, for the old non
GAS register, it is supposed that its Address should be aligned to its
Length.

For the "AccessSize = 0 (meaning ANY)" case, we try to return the maximum
instruction width (64 for MMIO or 32 for PIO) or the user expected access
bit width (64 for acpi_read()/acpi_write() or 32 for acpi_hw_read()/
acpi_hw_write()) and it is supposed that the GAS Address field should
always be aligned to the maximum expected access bit width (otherwise it
can't be accessed using ANY access bit width).

The problem is in acpi_tb_init_generic_address(), where the non GAS
register's Length is converted into the GAS BitWidth field, its Address is
converted into the GAS Address field, and the GAS AccessSize field is left
0 but most of the registers actually cannot be accessed using "ANY"
accesses.

As a conclusion, when AccessSize = 0 (ANY), the Address should either be
aligned to the BitWidth (wrong conversion) or aligned to 32 for PIO or 64
for MMIO (real GAS). Since currently, max_bit_width is 32, then:
1. BitWidth for the wrong conversion is 8,16,32; and
2. The Address of the real GAS should always be aligned to 8,16,32.
The address alignment check to exclude false matched real GAS is not
necessary. Thus this patch fixes the issue by removing the address
alignment check.

On the other hand, we in fact could use a simpler check of
"reg->bit_width < max_bit_width" to exclude the "BitWidth=64 PIO" case that
may be issued from acpi_read()/acpi_write() in the future.

Fixes: b314a172ee96 (ACPICA: Hardware: Add optimized access bit width support)
Reported-and-tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Mike Marshall <hubcap@omnibond.com>
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / Thermal / video: fix max_level incorrect value 2016-05-30T11:53:09+00:00 Aaron Lu aaron.lu@intel.com 2016-05-21T07:30:46+00:00 9f9cd7ee2c05881f151e5ee4889e667a031dd8d9 commit 059500940def (ACPI/video: export acpi_video_get_levels) mistakenly dropped the correct value of max_level and that caused the set_level function following failed and the acpi_video backlight interface didn't get created. Fix this by passing back the correct max_level value. While at it, also fix the param used in acpi_video_device_lcd_query_levels where acpi_handle is expected but acpi_video_device is passed. Fixes: 059500940def (ACPI/video: export acpi_video_get_levels) Reported-and-tested-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
commit 059500940def (ACPI/video: export acpi_video_get_levels)
mistakenly dropped the correct value of max_level and that caused the
set_level function following failed and the acpi_video backlight interface
didn't get created. Fix this by passing back the correct max_level value.

While at it, also fix the param used in acpi_video_device_lcd_query_levels
where acpi_handle is expected but acpi_video_device is passed.

Fixes: 059500940def (ACPI/video: export acpi_video_get_levels)
Reported-and-tested-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
remove lots of IS_ERR_VALUE abuses 2016-05-27T22:26:11+00:00 Arnd Bergmann arnd@arndb.de 2016-05-27T21:23:25+00:00 287980e49ffc0f6d911601e7e352a812ed27768e Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.

However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.

Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.

This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.

Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.

I was using this definition for testing:

 #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
       unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))

which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.

I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.

[ Updated the 9p parts as per Al Viro  - Linus ]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge tag 'mmc-v4.7-rc1' of git://git.linaro.org/people/ulf.hansson/mmc 2016-05-26T16:36:10+00:00 Linus Torvalds torvalds@linux-foundation.org 2016-05-26T16:36:10+00:00 0e77816e096c4ae27e98977fef56b6b9169f9017 Pull MMC fixes from Ulf Hansson: "Here are some mmc fixes intended for v4.7 rc1. They are based on a commit earlier in the merge window and have been tested in linux-next for a while. MMC core: - Prevent re-tuning while serving requests for RPMB partitions - Extend timeout for long read time quirk to support more eMMCs MMC host: - sdhci-acpi: Ensure connected devices are powered when probing - sdhci-pci|acpi: Remove unreliable MMC_CAP_BUS_WIDTH_TEST for Intel HWs - dw_mmc: Correct the assigning of max_blk_size - dw_mmc-rockchip: Allow RPMB partitions to be created - dw_mmc-rockchip: Set the drive phase properly" * tag 'mmc-v4.7-rc1' of git://git.linaro.org/people/ulf.hansson/mmc: mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers mmc: longer timeout for long read time quirk mmc: dw_mmc: rockchip: Set the drive phase properly mmc: dw_mmc: fix the wrong max_blk_size mmc: dw_mmc-rockchip: add MMC_CAP_CMD23 capabilities mmc: sdhci-acpi: Ensure connected devices are powered when probing ACPI / PM: Export acpi_device_fix_up_power() mmc: block: Pause re-tuning while switched to the RPMB partition mmc: block: Always switch back to main area after RPMB access mmc: core: Add a facility to "pause" re-tuning 
Pull MMC fixes from Ulf Hansson:
 "Here are some mmc fixes intended for v4.7 rc1.  They are based on a
  commit earlier in the merge window and have been tested in linux-next
  for a while.

  MMC core:
   - Prevent re-tuning while serving requests for RPMB partitions
   - Extend timeout for long read time quirk to support more eMMCs

  MMC host:
   - sdhci-acpi: Ensure connected devices are powered when probing
   - sdhci-pci|acpi: Remove unreliable MMC_CAP_BUS_WIDTH_TEST for Intel HWs
   - dw_mmc: Correct the assigning of max_blk_size
   - dw_mmc-rockchip: Allow RPMB partitions to be created
   - dw_mmc-rockchip: Set the drive phase properly"

* tag 'mmc-v4.7-rc1' of git://git.linaro.org/people/ulf.hansson/mmc:
  mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers
  mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers
  mmc: longer timeout for long read time quirk
  mmc: dw_mmc: rockchip: Set the drive phase properly
  mmc: dw_mmc: fix the wrong max_blk_size
  mmc: dw_mmc-rockchip: add MMC_CAP_CMD23 capabilities
  mmc: sdhci-acpi: Ensure connected devices are powered when probing
  ACPI / PM: Export acpi_device_fix_up_power()
  mmc: block: Pause re-tuning while switched to the RPMB partition
  mmc: block: Always switch back to main area after RPMB access
  mmc: core: Add a facility to "pause" re-tuning
Merge tag 'acpi-4.7-rc1-more' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm 2016-05-25T22:38:56+00:00 Linus Torvalds torvalds@linux-foundation.org 2016-05-25T22:38:56+00:00 e92677dfce88b96ade9100c77eb3f76d98d29d74 Pull ACPI fix from Rafael Wysocki: "Additional ACPI update for v4.7-rc1 Just one fix for incorrect async_synchronize_cookie() usage in the ACPI battery driver (Chris Wilson)" * tag 'acpi-4.7-rc1-more' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / battery: Correctly serialise with the pending async probe 
Pull ACPI fix from Rafael Wysocki:
 "Additional ACPI update for v4.7-rc1

  Just one fix for incorrect async_synchronize_cookie() usage in the
  ACPI battery driver (Chris Wilson)"

* tag 'acpi-4.7-rc1-more' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / battery: Correctly serialise with the pending async probe
Merge branch 'acpi-battery' 2016-05-25T20:11:28+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2016-05-25T20:11:28+00:00 0cc4b48149ff6948dd82a039ad55cdbec49107f7 * acpi-battery: ACPI / battery: Correctly serialise with the pending async probe 
* acpi-battery:
  ACPI / battery: Correctly serialise with the pending async probe
Merge tag 'libnvdimm-for-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 2016-05-23T18:18:01+00:00 Linus Torvalds torvalds@linux-foundation.org 2016-05-23T18:18:01+00:00 1f40c49570eb01436786a9b5845c4469a9a1f362 Pull libnvdimm updates from Dan Williams: "The bulk of this update was stabilized before the merge window and appeared in -next. The "device dax" implementation was revised this week in response to review feedback, and to address failures detected by the recently expanded ndctl unit test suite. Not included in this pull request are two dax topic branches (dax error handling, and dax radix-tree locking). These topics were deferred to get a few more days of -next integration testing, and to coordinate a branch baseline with Ted and the ext4 tree. Vishal and Ross will send the error handling and locking topics respectively in the next few days. This branch has received a positive build result from the kbuild robot across 226 configs. Summary: - Device DAX for persistent memory: Device DAX is the device-centric analogue of Filesystem DAX (CONFIG_FS_DAX). It allows memory ranges to be allocated and mapped without need of an intervening file system. Device DAX is strict, precise and predictable. Specifically this interface: a) Guarantees fault granularity with respect to a given page size (pte, pmd, or pud) set at configuration time. b) Enforces deterministic behavior by being strict about what fault scenarios are supported. Persistent memory is the first target, but the mechanism is also targeted for exclusive allocations of performance/feature differentiated memory ranges. - Support for the HPE DSM (device specific method) command formats. This enables management of these first generation devices until a unified DSM specification materializes. - Further ACPI 6.1 compliance with support for the common dimm identifier format. - Various fixes and cleanups across the subsystem" * tag 'libnvdimm-for-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: (40 commits) libnvdimm, dax: fix deletion libnvdimm, dax: fix alignment validation libnvdimm, dax: autodetect support libnvdimm: release ida resources Revert "block: enable dax for raw block devices" /dev/dax, core: file operations and dax-mmap /dev/dax, pmem: direct access to persistent memory libnvdimm: stop requiring a driver ->remove() method libnvdimm, dax: record the specified alignment of a dax-device instance libnvdimm, dax: reserve space to store labels for device-dax libnvdimm, dax: introduce device-dax infrastructure nfit: add sysfs dimm 'family' and 'dsm_mask' attributes tools/testing/nvdimm: ND_CMD_CALL support nfit: disable vendor specific commands nfit: export subsystem ids as attributes nfit: fix format interface code byte order per ACPI6.1 nfit, libnvdimm: limited/whitelisted dimm command marshaling mechanism nfit, libnvdimm: clarify "commands" vs "_DSMs" libnvdimm: increase max envelope size for ioctl acpi/nfit: Add sysfs "id" for NVDIMM ID ... 
Pull libnvdimm updates from Dan Williams:
 "The bulk of this update was stabilized before the merge window and
  appeared in -next.  The "device dax" implementation was revised this
  week in response to review feedback, and to address failures detected
  by the recently expanded ndctl unit test suite.

  Not included in this pull request are two dax topic branches (dax
  error handling, and dax radix-tree locking).  These topics were
  deferred to get a few more days of -next integration testing, and to
  coordinate a branch baseline with Ted and the ext4 tree.  Vishal and
  Ross will send the error handling and locking topics respectively in
  the next few days.

  This branch has received a positive build result from the kbuild robot
  across 226 configs.

  Summary:

   - Device DAX for persistent memory: Device DAX is the device-centric
     analogue of Filesystem DAX (CONFIG_FS_DAX).  It allows memory
     ranges to be allocated and mapped without need of an intervening
     file system.  Device DAX is strict, precise and predictable.
     Specifically this interface:

      a) Guarantees fault granularity with respect to a given page size
         (pte, pmd, or pud) set at configuration time.

      b) Enforces deterministic behavior by being strict about what
         fault scenarios are supported.

     Persistent memory is the first target, but the mechanism is also
     targeted for exclusive allocations of performance/feature
     differentiated memory ranges.

   - Support for the HPE DSM (device specific method) command formats.
     This enables management of these first generation devices until a
     unified DSM specification materializes.

   - Further ACPI 6.1 compliance with support for the common dimm
     identifier format.

   - Various fixes and cleanups across the subsystem"

* tag 'libnvdimm-for-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: (40 commits)
  libnvdimm, dax: fix deletion
  libnvdimm, dax: fix alignment validation
  libnvdimm, dax: autodetect support
  libnvdimm: release ida resources
  Revert "block: enable dax for raw block devices"
  /dev/dax, core: file operations and dax-mmap
  /dev/dax, pmem: direct access to persistent memory
  libnvdimm: stop requiring a driver ->remove() method
  libnvdimm, dax: record the specified alignment of a dax-device instance
  libnvdimm, dax: reserve space to store labels for device-dax
  libnvdimm, dax: introduce device-dax infrastructure
  nfit: add sysfs dimm 'family' and 'dsm_mask' attributes
  tools/testing/nvdimm: ND_CMD_CALL support
  nfit: disable vendor specific commands
  nfit: export subsystem ids as attributes
  nfit: fix format interface code byte order per ACPI6.1
  nfit, libnvdimm: limited/whitelisted dimm command marshaling mechanism
  nfit, libnvdimm: clarify "commands" vs "_DSMs"
  libnvdimm: increase max envelope size for ioctl
  acpi/nfit: Add sysfs "id" for NVDIMM ID
  ...
ACPI / battery: Correctly serialise with the pending async probe 2016-05-20T23:25:07+00:00 Chris Wilson chris@chris-wilson.co.uk 2016-05-19T08:11:52+00:00 5dfa0c73953360e07a47731e412d33dfc896bf4e async_synchronize_cookie() only serialises all tasks up to the specified cookie, and importantly does not wait for the task corresponding with the cookie. [This is so that it can be trivially used from inside the async_func_t in order to serialise with all preceding tasks.] In order to serialise with acpi_battery_init_async() we need to compensate and pass in the next cookie instead. The impact today is zero since performing an async_schedule() from inside a module init function will trigger an async_synchronize_full() prior to the module loader's completion. However, if the probe was moved to its own unregistered async_domain, then the async_synchronize_cookie would be replaced with an async_synchronize_full_domain. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
async_synchronize_cookie() only serialises all tasks up to the specified
cookie, and importantly does not wait for the task corresponding with
the cookie. [This is so that it can be trivially used from inside the
async_func_t in order to serialise with all preceding tasks.] In order
to serialise with acpi_battery_init_async() we need to compensate and
pass in the next cookie instead.

The impact today is zero since performing an async_schedule() from inside
a module init function will trigger an async_synchronize_full() prior to
the module loader's completion. However, if the probe was moved to its
own unregistered async_domain, then the async_synchronize_cookie would
be replaced with an async_synchronize_full_domain.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>