linux-stable.git/drivers/acpi, branch linux-4.8.y

ACPI / video: Add force_native quirk for HP Pavilion dv6

2017-01-09T07:21:49+00:00

commit 6276e53fa8c06a3a5cf7b95b77b079966de9ad66 upstream.

The HP Pavilion dv6 has a non-working acpi_video0 backlight interface
and an intel_backlight interface which works fine. Add a force_native
quirk for it so that the non-working acpi_video0 interface does not get
registered.

Note that there are quite a few HP Pavilion dv6 variants, some
woth ATI and some with NVIDIA hybrid gfx, both seem to need this
quirk to have working backlight control. There are also some versions
with only Intel integrated gfx, these may not need this quirk, but it
should not hurt there.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1204476
Link: https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1416940
Signed-off-by: Hans de Goede 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / video: Add force_native quirk for Dell XPS 17 L702X

2017-01-09T07:21:49+00:00

commit 350fa038c31b056fc509624efb66348ac2c1e3d0 upstream.

The Dell XPS 17 L702X has a non-working acpi_video0 backlight interface
and an intel_backlight interface which works fine. Add a force_native
quirk for it so that the non-working acpi_video0 interface does not get
registered.

Note that there also is an issue with the brightnesskeys on this laptop,
they do not generate key-press events in anyway. That is not solved by
this patch.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1123661
Signed-off-by: Hans de Goede 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

Revert "ACPI: Execute _PTS before system reboot"

2016-12-15T16:50:36+00:00

commit 9713adc2a1a5488f4889c657a0c0ce0c16056d3c upstream.

Revert commit 2c85025c75df (ACPI: Execute _PTS before system reboot)
as it is reported to cause poweroff and reboot to hang on Dell
Latitude E7250.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=187061
Reported-by:  Gianpaolo 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

acpi, nfit: fix bus vs dimm confusion in xlat_status

2016-12-15T16:50:35+00:00

commit d6eb270c57fef35798525004ddf2ac5dcdadd43b upstream.

Given dimms and bus commands share the same command number space we need
to be careful that we are translating status in the correct context.
Otherwise we can, for example, fail an ND_CMD_GET_CONFIG_SIZE command
because max_xfer is zero. It fails because that condition erroneously
correlates with the 'cleared == 0' failure of ND_CMD_CLEAR_ERROR.

Fixes: aef253382266 ("libnvdimm, nfit: centralize command status translation")
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

acpi, nfit: validate ars_status output buffer size

2016-12-15T16:50:35+00:00

commit 82aa37cf09867c5e2c0326649d570e5b25c1189a upstream.

If an ARS Status command returns truncated output, do not process
partial records or otherwise consume non-status fields.

Fixes: 0caeef63e6d2 ("libnvdimm: Add a poison list and export badblocks")
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

acpi, nfit, libnvdimm: fix / harden ars_status output length handling

2016-12-15T16:50:35+00:00

commit efda1b5d87cbc3d8816f94a3815b413f1868e10d upstream.

Given ambiguities in the ACPI 6.1 definition of the "Output (Size)"
field of the ARS (Address Range Scrub) Status command, a firmware
implementation may in practice return 0, 4, or 8 to indicate that there
is no output payload to process.

The specification states "Size of Output Buffer in bytes, including this
field.". However, 'Output Buffer' is also the name of the entire
payload, and earlier in the specification it states "Max Query ARS
Status Output Buffer Size: Maximum size of buffer (including the Status
and Extended Status fields)".

Without this fix if the BIOS happens to return 0 it causes memory
corruption as evidenced by this result from the acpi_nfit_ctl() unit
test.

 ars_status00000000: 00020000 00000000                    ........
 BUG: stack guard page was hit at ffffc90001750000 (stack is ffffc9000174c000..ffffc9000174ffff)
 kernel stack overflow (page fault): 0000 [#1] SMP DEBUG_PAGEALLOC
 task: ffff8803332d2ec0 task.stack: ffffc9000174c000
 RIP: 0010:[]  [] __memcpy+0x12/0x20
 RSP: 0018:ffffc9000174f9a8  EFLAGS: 00010246
 RAX: ffffc9000174fab8 RBX: 0000000000000000 RCX: 000000001fffff56
 RDX: 0000000000000000 RSI: ffff8803231f5a08 RDI: ffffc90001750000
 RBP: ffffc9000174fa88 R08: ffffc9000174fab0 R09: ffff8803231f54b8
 R10: 0000000000000008 R11: 0000000000000001 R12: 0000000000000000
 R13: 0000000000000000 R14: 0000000000000003 R15: ffff8803231f54a0
 FS:  00007f3a611af640(0000) GS:ffff88033ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: ffffc90001750000 CR3: 0000000325b20000 CR4: 00000000000406e0
 Stack:
  ffffffffa00bc60d 0000000000000008 ffffc90000000001 ffffc9000174faac
  0000000000000292 ffffffffa00c24e4 ffffffffa00c2914 0000000000000000
  0000000000000000 ffffffff00000003 ffff880331ae8ad0 0000000800000246
 Call Trace:
  [] ? acpi_nfit_ctl+0x49d/0x750 [nfit]
  [] nfit_test_probe+0x670/0xb1b [nfit_test]

Fixes: 747ffe11b440 ("libnvdimm, tools/testing/nvdimm: fix 'ars_status' output buffer sizing")
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

acpi, nfit: fix extended status translations for ACPI DSMs

2016-12-15T16:50:35+00:00

commit 9a901f5495e26e691c7d0ea7b6057a2f3e6330ed upstream.

ACPI DSMs can have an 'extended' status which can be non-zero to convey
additional information about the command. In the xlat_status routine,
where we translate the command statuses, we were returning an error for
a non-zero extended status, even if the primary status indicated success.

Return from each command's 'case' once we have verified both its status
and extend status are good.

Fixes: 11294d63ac91 ("nfit: fail DSMs that return non-zero status by default")
Signed-off-by: Vishal Verma 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

ACPI/PCI: pci_link: Include PIRQ_PENALTY_PCI_USING for ISA IRQs

2016-11-18T09:51:52+00:00

commit 98756f5319c64c883caa910dce702d9edefe7810 upstream.

Commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
replaced the addition of PIRQ_PENALTY_PCI_USING in acpi_pci_link_allocate()
with an addition in acpi_irq_pci_sharing_penalty(), but f7eca374f000
("ACPI,PCI,IRQ: separate ISA penalty calculation") removed the use
of acpi_irq_pci_sharing_penalty() for ISA IRQs.

Therefore, PIRQ_PENALTY_PCI_USING is missing from ISA IRQs used by
interrupt links.  Include that penalty by adding it in the
acpi_pci_link_allocate() path.

Fixes: f7eca374f000 (ACPI,PCI,IRQ: separate ISA penalty calculation)
Signed-off-by: Sinan Kaya 
Acked-by: Bjorn Helgaas 
Tested-by: Jonathan Liu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI/PCI: pci_link: penalize SCI correctly

2016-11-18T09:51:51+00:00

commit f1caa61df2a3dc4c58316295c5dc5edba4c68d85 upstream.

Ondrej reported that IRQs stopped working in v4.7 on several
platforms.  A typical scenario, from Ondrej's VT82C694X/694X, is:

ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: No IRQ available for PCI Interrupt Link [LNKA]
8139too 0000:00:0f.0: PCI INT A: no GSI

We're using PIC routing, so acpi_irq_balance == 0, and LNKA is already
active at IRQ 11. In that case, acpi_pci_link_allocate() only tries
to use the active IRQ (IRQ 11) which also happens to be the SCI.

We should penalize the SCI by PIRQ_PENALTY_PCI_USING, but
irq_get_trigger_type(11) returns something other than
IRQ_TYPE_LEVEL_LOW, so we penalize it by PIRQ_PENALTY_ISA_ALWAYS
instead, which makes acpi_pci_link_allocate() assume the IRQ isn't
available and give up.

Add acpi_penalize_sci_irq() so platforms can tell us the SCI IRQ,
trigger, and polarity directly and we don't have to depend on
irq_get_trigger_type().

Fixes: 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
Link: http://lkml.kernel.org/r/201609251512.05657.linux@rainbow-software.org
Reported-by: Ondrej Zary 
Acked-by: Bjorn Helgaas 
Signed-off-by: Sinan Kaya 
Tested-by: Jonathan Liu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI/PCI/IRQ: assign ISA IRQ directly during early boot stages

2016-11-18T09:51:51+00:00

commit eeaed4bb5a35591470b545590bb2f26dbe7653a2 upstream.

We do not want to store the SCI penalty in the acpi_isa_irq_penalty[]
table because acpi_isa_irq_penalty[] only holds ISA IRQ penalties and
there's no guarantee that the SCI is an ISA IRQ.  We add in the SCI
penalty as a special case in acpi_irq_get_penalty().

But if we called acpi_penalize_isa_irq() or acpi_irq_penalty_update()
for an SCI that happened to be an ISA IRQ, they stored the SCI
penalty (part of the acpi_irq_get_penalty() return value) in
acpi_isa_irq_penalty[].  Subsequent calls to acpi_irq_get_penalty()
returned a penalty that included *two* SCI penalties.

Fixes: 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
Signed-off-by: Sinan Kaya 
Acked-by: Bjorn Helgaas 
Tested-by: Jonathan Liu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman