linux-toradex.git/drivers/acpi, branch toradex_vf_4.1

ACPI / processor: Request native thermal interrupt handling via _OSC

2016-07-11T03:07:20+00:00

[ Upstream commit a21211672c9a1d730a39aa65d4a5b3414700adfb ]

There are several reports of freeze on enabling HWP (Hardware PStates)
feature on Skylake-based systems by the Intel P-states driver. The root
cause is identified as the HWP interrupts causing BIOS code to freeze.

HWP interrupts use the thermal LVT which can be handled by Linux
natively, but on the affected Skylake-based systems SMM will respond
to it by default.  This is a problem for several reasons:
 - On the affected systems the SMM thermal LVT handler is broken (it
   will crash when invoked) and a BIOS update is necessary to fix it.
 - With thermal interrupt handled in SMM we lose all of the reporting
   features of the arch/x86/kernel/cpu/mcheck/therm_throt driver.
 - Some thermal drivers like x86-package-temp depend on the thermal
   threshold interrupts signaled via the thermal LVT.
 - The HWP interrupts are useful for debugging and tuning
   performance (if the kernel can handle them).
The native handling of thermal interrupts needs to be enabled
because of that.

This requires some way to tell SMM that the OS can handle thermal
interrupts.  That can be done by using _OSC/_PDC in processor
scope very early during ACPI initialization.

The meaning of _OSC/_PDC bit 12 in processor scope is whether or
not the OS supports native handling of interrupts for Collaborative
Processor Performance Control (CPPC) notifications.  Since on
HWP-capable systems CPPC is a firmware interface to HWP, setting
this bit effectively tells the firmware that the OS will handle
thermal interrupts natively going forward.

For details on _OSC/_PDC refer to:
http://www.intel.com/content/www/us/en/standards/processor-vendor-specific-acpi-specification.html

To implement the _OSC/_PDC handshake as described, introduce a new
function, acpi_early_processor_osc(), that walks the ACPI
namespace looking for ACPI processor objects and invokes _OSC for
them with bit 12 in the capabilities buffer set and terminates the
namespace walk on the first success.

Also modify intel_thermal_interrupt() to clear HWP status bits in
the HWP_STATUS MSR to acknowledge HWP interrupts (which prevents
them from firing continuously).

Signed-off-by: Srinivas Pandruvada 
[ rjw: Subject & changelog, function rename ]
Signed-off-by: Rafael J. Wysocki 

Signed-off-by: Sasha Levin

ACPI / osi: Fix an issue that acpi_osi=!* cannot disable ACPICA internal strings

2016-06-03T23:15:46+00:00

[ Upstream commit 30c9bb0d7603e7b3f4d6a0ea231e1cddae020c32 ]

The order of the _OSI related functionalities is as follows:

  acpi_blacklisted()
    acpi_dmi_osi_linux()
      acpi_osi_setup()
    acpi_osi_setup()
      acpi_update_interfaces() if "!*"
      <<<<<<<<<<<<<<<<<<<<<<<<
  parse_args()
    __setup("acpi_osi=")
      acpi_osi_setup_linux()
        acpi_update_interfaces() if "!*"
        <<<<<<<<<<<<<<<<<<<<<<<<
  acpi_early_init()
    acpi_initialize_subsystem()
      acpi_ut_initialize_interfaces()
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  acpi_bus_init()
    acpi_os_initialize1()
      acpi_install_interface_handler(acpi_osi_handler)
      acpi_osi_setup_late()
        acpi_update_interfaces() for "!"
        >>>>>>>>>>>>>>>>>>>>>>>>
  acpi_osi_handler()

Since acpi_osi_setup_linux() can override acpi_dmi_osi_linux(), the command
line setting can override the DMI detection. That's why acpi_blacklisted()
is put before __setup("acpi_osi=").

Then we can notice the following wrong invocation order. There are
acpi_update_interfaces() (marked by <<<<) calls invoked before
acpi_ut_initialize_interfaces() (marked by ^^^^). This makes it impossible
to use acpi_osi=!* correctly from OSI DMI table or from the command line.
The use of acpi_osi=!* is meant to disable both ACPICA
(acpi_gbl_supported_interfaces) and Linux specific strings
(osi_setup_entries) while the ACPICA part should have stopped working
because of the order issue.

This patch fixes this issue by moving acpi_update_interfaces() to where
it is invoked for acpi_osi=! (marked by >>>>) as this is ensured to be
invoked after acpi_ut_initialize_interfaces() (marked by ^^^^). Linux
specific strings are still handled in the original place in order to make
the following command line working: acpi_osi=!* acpi_osi="Module Device".

Note that since acpi_osi=!* is meant to further disable linux specific
string comparing to the acpi_osi=!, there is no such use case in our bug
fixing work and hence there is no one using acpi_osi=!* either from the
command line or from the DMI quirks, this issue is just a theoretical
issue.

Fixes: 741d81280ad2 (ACPI: Add facility to remove all _OSI strings)
Cc: 3.12+  # 3.12+
Tested-by: Lukas Wunner 
Tested-by: Chen Yu 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPICA: Dispatcher: Update thread ID for recursive method calls

2016-05-17T17:42:58+00:00

[ Upstream commit 93d68841a23a5779cef6fb9aa0ef32e7c5bd00da ]

ACPICA commit 7a3bd2d962f221809f25ddb826c9e551b916eb25

Set the mutex owner thread ID.
Original patch from: Prarit Bhargava 

Link: https://bugzilla.kernel.org/show_bug.cgi?id=115121
Link: https://github.com/acpica/acpica/commit/7a3bd2d9
Signed-off-by: Prarit Bhargava 
Tested-by: Andy Lutomirski  # On a Dell XPS 13 9350
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI: Revert "ACPI / video: Add Dell Inspiron 5737 to the blacklist"

2016-04-13T21:14:25+00:00

[ Upstream commit b186b4dcb79b1914c3dadb27ac72dafaa4267998 ]

The quirk to get "acpi_backlight=vendor" behavior by default on the
Dell Inspiron 5737 was added before we started doing
"acpi_backlight=native" by default on Win8 ready machines.

Since we now avoid using acpi-video as backlight driver on these machines
by default (using the native driver instead) we no longer need this quirk.

Moreover the vendor driver does not work after a suspend/resume where
as the native driver does.

This reverts commit 08a56226d847 (ACPI / video: Add Dell Inspiron 5737
to the blacklist).

Link: https://bugzilla.kernel.org/show_bug.cgi?id=111061
Cc: 3.19+  # 3.19+
Reported-and-tested-by: erusan@gmail.com
Signed-off-by: Hans de Goede 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI, PCI: Penalize legacy IRQ used by ACPI SCI

2015-09-21T17:05:44+00:00

commit 5d0ddfebb93069061880fc57ee4ba7246bd1e1ee upstream.

Nick Meier reported a regression with HyperV that "
  After rebooting the VM, the following messages are logged in syslog
  when trying to load the tulip driver:
    tulip: Linux Tulip drivers version 1.1.15 (Feb 27, 2007)
    tulip: 0000:00:0a.0: PCI INT A: failed to register GSI
    tulip: Cannot enable tulip board #0, aborting
    tulip: probe of 0000:00:0a.0 failed with error -16
  Errors occur in 3.19.0 kernel
  Works in 3.17 kernel.
"

According to the ACPI dump file posted by Nick at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072

The ACPI MADT table includes an interrupt source overridden entry for
ACPI SCI:
[236h 0566  1]                Subtable Type : 02 
[237h 0567  1]                       Length : 0A
[238h 0568  1]                          Bus : 00
[239h 0569  1]                       Source : 09
[23Ah 0570  4]                    Interrupt : 00000009
[23Eh 0574  2]        Flags (decoded below) : 000D
                                   Polarity : 1
                               Trigger Mode : 3

And in DSDT table, we have _PRT method to define PCI interrupts, which
eventually goes to:
        Name (PRSA, ResourceTemplate ()
        {
            IRQ (Level, ActiveLow, Shared, )
                {3,4,5,7,9,10,11,12,14,15}
        })
        Name (PRSB, ResourceTemplate ()
        {
            IRQ (Level, ActiveLow, Shared, )
                {3,4,5,7,9,10,11,12,14,15}
        })
        Name (PRSC, ResourceTemplate ()
        {
            IRQ (Level, ActiveLow, Shared, )
                {3,4,5,7,9,10,11,12,14,15}
        })
        Name (PRSD, ResourceTemplate ()
        {
            IRQ (Level, ActiveLow, Shared, )
                {3,4,5,7,9,10,11,12,14,15}
        })

According to the MADT and DSDT tables, IRQ 9 may be used for:
 1) ACPI SCI in level, high mode
 2) PCI legacy IRQ in level, low mode
So there's a conflict in polarity setting for IRQ 9.

Prior to commit cd68f6bd53cf ("x86, irq, acpi: Get rid of special
handling of GSI for ACPI SCI"), ACPI SCI is handled specially and
there's no check for conflicts between ACPI SCI and PCI legagy IRQ.
And it seems that the HyperV hypervisor doesn't make use of the
polarity configuration in IOAPIC entry, so it just works.

Commit cd68f6bd53cf gets rid of the specially handling of ACPI SCI,
and then the pin attribute checking code discloses the conflicts
between ACPI SCI and PCI legacy IRQ on HyperV virtual machine,
and rejects the request to assign IRQ9 to PCI devices.

So penalize legacy IRQ used by ACPI SCI and mark it unusable if ACPI
SCI attributes conflict with PCI IRQ attributes.

Please refer to following links for more information:
https://bugzilla.kernel.org/show_bug.cgi?id=101301
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072

Fixes: cd68f6bd53cf ("x86, irq, acpi: Get rid of special handling of GSI for ACPI SCI")
Reported-and-tested-by: Nick Meier 
Acked-by: Thomas Gleixner 
Signed-off-by: Jiang Liu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

serial: 8250: bind to ALi Fast Infrared Controller (ALI5123)

2015-09-21T17:05:39+00:00

commit 1d7002777a8fe8188caaa98d4a8eb4ed298fcdae upstream.

This way this device can be used with irtty-sir -
at least on Toshiba Satellite A20-S103 it is not configured by default
and needs PNP activation before it starts to respond on I/O ports.

This device has actually its own driver (ali-ircc),
but this driver seems to be non-functional for a very long time
(see http://permalink.gmane.org/gmane.linux.irda.general/484
http://permalink.gmane.org/gmane.network.protocols.obex.openobex.user/943
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535070 ).

Signed-off-by: Maciej Szmigiero 
Signed-off-by: Greg Kroah-Hartman

ACPI / PCI: Fix regressions caused by resource_size_t overflow with 32-bit kernel

2015-08-03T16:29:14+00:00

commit 1fb01ca93a1348a1469b8777326cd7632483de77 upstream.

Zoltan Boszormenyi reported this regression:
  "There's a Realtek RTL8111/8168/8411 (PCI ID 10ec:8168, Subsystem ID
   1565:230e) network chip on the mainboard. After the r8169 driver loaded
   the IRQs in the machine went berserk. Keyboard keypressed arrived with
   considerable latency and duplicated, so no real work was possible.
   The machine responded to the power button but didn't actually power
   down. It just stuck at the powering down message. I had to press the
   power button for 4 seconds to power it down.

   The computer is a POS machine with a big battery inside. Because of this,
   either ACPI or the Realtek chip kept the bad state and after rebooting,
   the network chip didn't even show up in lspci. Not even the PXE ROM
   announced itself during boot. I had to disconnect the battery to beat
   some sense back to the computer.

   The regression happens with 4.0.5, 4.1.0-rc8 and 4.1.0-final. 3.18.16 was
   good."

The regression is caused by commit 593669c2ac0f (x86/PCI/ACPI: Use common
ACPI resource interfaces to simplify implementation). Since commit
593669c2ac0f, x86 PCI ACPI host bridge driver validates ACPI resources by
first converting an ACPI resource to a 'struct resource' structure and
then applying checks against the converted resource structure. The 'start'
and 'end' fields in 'struct resource' are defined to be type of
resource_size_t, which may be 32 bits or 64 bits depending on
CONFIG_PHYS_ADDR_T_64BIT.

This may cause incorrect resource validation results with 32-bit kernels
because 64-bit ACPI resource descriptors may get truncated when converting
to 32-bit 'start' and 'end' fields in 'struct resource'. It eventually
affects PCI resource allocation subsystem and makes some PCI devices and
the system behave abnormally due to incorrect resource assignment.

So enhance the ACPI resource parsing interfaces to ignore ACPI resource
descriptors with address/offset above 4G when running in 32-bit mode.

With the fix applied, the behavior of the machine was restored to how
3.18.16 worked, i.e. the memory range that is over 4GB is ignored again,
and lspci -vvxxx shows that everything is at the same memory window as
they were with 3.18.16.

Reported-and-tested-by: Boszormenyi Zoltan 
Fixes: 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation)
Signed-off-by: Jiang Liu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPICA: Tables: Fix an issue that FACS initialization is performed twice

2015-08-03T16:29:14+00:00

commit c04be18448355441a0c424362df65b6422e27bda upstream.

ACPICA commit 90f5332a15e9d9ba83831ca700b2b9f708274658

This patch adds a new FACS initialization flag for acpi_tb_initialize().
acpi_enable_subsystem() might be invoked several times in OS bootup process,
and we don't want FACS initialization to be invoked twice. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/90f5332a
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPICA: Tables: Enable both 32-bit and 64-bit FACS

2015-08-03T16:29:14+00:00

commit c04e1fb4396d27f18296db0f914760fa7fe8223a upstream.

ACPICA commit f7b86f35416e3d1f71c3d816ff5075ddd33ed486

The following commit is reported to have broken s2ram on some platforms:
 Commit: 0249ed2444d65d65fc3f3f64f398f1ad0b7e54cd
 ACPICA: Add option to favor 32-bit FADT addresses.
The platform reports 2 FACS tables (which is not allowed by ACPI
specification) and the new 32-bit address favor rule forces OSPMs to use
the FACS table reported via FADT's X_FIRMWARE_CTRL field.

The root cause of the reported bug might be one of the followings:
1. BIOS may favor the 64-bit firmware waking vector address when the
   version of the FACS is greater than 0 and Linux currently only supports
   resuming from the real mode, so the 64-bit firmware waking vector has
   never been set and might be invalid to BIOS while the commit enables
   higher version FACS.
2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the
   FADT while the commit doesn't set the firmware waking vector address of
   the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking
   vector address of the FACS reported by "X_FIRMWARE_CTRL".

This patch excludes the cases that can trigger the bugs caused by the root
cause 2.

There is no handshaking mechanism can be used by OSPM to tell BIOS which
FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still
be used by BIOS and the 0 value of the 32-bit firmware waking vector might
trigger such failure.

This patch tries to favor 32bit FACS address in another way where both the
FACS reported by "FIRMWARE_CTRL" and the FACS reported by "X_FIRMWARE_CTRL"
are loaded so that further commit can set firmware waking vector in the
both tables to ensure we can exclude the cases that trigger the bugs caused
by the root cause 2. The exclusion is split into 2 commits as this commit
is also useful for dumping more ACPI tables, it won't get reverted when
such exclusion is no longer necessary. Lv Zheng.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021
Link: https://github.com/acpica/acpica/commit/f7b86f35
Reported-and-tested-by: Oswald Buddenhagen 
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / LPSS: Fix up acpi_lpss_create_device()

2015-08-03T16:29:14+00:00

commit d3e13ff3c1aa2403d9a5f371baac088daeb8f56d upstream.

Fix a return value (which should be a negative error code) and a
memory leak (the list allocated by acpi_dev_get_resources() needs
to be freed on ioremap() errors too) in acpi_lpss_create_device()
introduced by commit 4483d59e29fe 'ACPI / LPSS: check the result
of ioremap()'.

Fixes: 4483d59e29fe 'ACPI / LPSS: check the result of ioremap()'
Reported-by: Dan Carpenter 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman