linux-toradex.git/drivers/acpi, branch v4.7-rc4 Linux kernel for Apalis and Colibri modules Merge branch 'acpica-fixes' 2016-06-17T23:55:55+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2016-06-17T23:55:55+00:00 46577e6a052ff5add7577ac748fb8628b3c3c7c9 * acpica-fixes: Revert "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()" 
* acpica-fixes:
  Revert "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()"
Revert "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()" 2016-06-15T00:16:13+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2016-06-15T00:16:13+00:00 da4e792550a856e2f66aa8183d408553f7513a86 Revert commit 66b1ed5aa8dd "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()" that is reported to break suspend-to-RAM (ACPI S3) on one system. The root cause of the failure is a wrong access width value for one of the involved registers provided by the ACPI tables, but before commit 66b1ed5aa8dd that value was not taken into account at all and things worked. Fixes: 66b1ed5aa8dd "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()" Reported-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Revert commit 66b1ed5aa8dd "ACPICA: ACPI 2.0, Hardware: Add
access_width/bit_offset support for acpi_hw_write()" that is reported
to break suspend-to-RAM (ACPI S3) on one system.

The root cause of the failure is a wrong access width value for one of
the involved registers provided by the ACPI tables, but before commit
66b1ed5aa8dd that value was not taken into account at all and things
worked.

Fixes: 66b1ed5aa8dd "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()"
Reported-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge branch 'acpi-ec' 2016-06-09T21:48:54+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2016-06-09T21:48:54+00:00 bd6ac2abc9937eb7613aa194195fd98fe9312b38 * acpi-ec: ACPI / EC: Fix a boot EC regresion by restoring boot EC support for the DSDT EC 
* acpi-ec:
  ACPI / EC: Fix a boot EC regresion by restoring boot EC support for the DSDT EC
ACPI / EC: Fix a boot EC regresion by restoring boot EC support for the DSDT EC 2016-06-07T00:29:53+00:00 Lv Zheng lv.zheng@intel.com 2016-06-03T02:26:12+00:00 dcf15cbded656a12335bc4151f3f75f10080a375 According to the Windows probing result, during the table loading, the EC device described in the ECDT should be used. And the ECDT EC is also effective during the period the namespace objects are initialized (we can see a separate process executing _STA/_INI on Windows before executing other device specific control methods, for example, EC._REG). During the device enumration, the EC device described in the DSDT should be used. But there are differences between Linux and Windows around the device probing order. Thus in Linux, we should enable the DSDT EC as early as possible before enumerating devices in order not to trigger issues related to the device enumeration order differences. This patch thus converts acpi_boot_ec_enable() into acpi_ec_dsdt_probe() to fix the gap. This also fixes a user reported regression triggered after we switched the "table loading"/"ECDT support" to be ACPI spec 2.0 compliant. Fixes: 59f0aa9480cf (ACPI 2.0 / ECDT: Remove early namespace reference from EC) Link: https://bugzilla.kernel.org/show_bug.cgi?id=119261 Reported-and-tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
According to the Windows probing result, during the table loading, the EC
device described in the ECDT should be used. And the ECDT EC is also
effective during the period the namespace objects are initialized (we can
see a separate process executing _STA/_INI on Windows before executing
other device specific control methods, for example, EC._REG). During the
device enumration, the EC device described in the DSDT should be used. But
there are differences between Linux and Windows around the device probing
order. Thus in Linux, we should enable the DSDT EC as early as possible
before enumerating devices in order not to trigger issues related to the
device enumeration order differences.

This patch thus converts acpi_boot_ec_enable() into acpi_ec_dsdt_probe() to
fix the gap. This also fixes a user reported regression triggered after we
switched the "table loading"/"ECDT support" to be ACPI spec 2.0 compliant.

Fixes: 59f0aa9480cf (ACPI 2.0 / ECDT: Remove early namespace reference from EC)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=119261
Reported-and-tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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