user/sven/linux.git/drivers/acpi, branch v4.2.8

ACPI, PCI: Penalize legacy IRQ used by ACPI SCI

2015-09-21T17:10:58Z

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:10:54Z

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

Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm

2015-08-28T00:46:06Z

Pull nvdimm fixlet from Dan Williams: "This is a libnvdimm ABI fixup. I pushed back on this change quite hard given the late date, that it appears to be purely cosmetic, sysfs is not necessarily meant to be a user friendly UI, and the kernel interprets the reversed polarity of the ACPI_NFIT_MEM_ARMED flag correctly. When this flag is set, the energy source of an NVDIMM is not armed and any new writes to the DIMM may not be preserved. However, Bob Moore warned me that it is important to get these things named correctly wherever they appear otherwise we run the risk of a less than cautious firmware engineer implementing the polarity the wrong way. Once a mistake like that escapes into production platforms the flag becomes useless and we need to move to a new bit position. Bob has agreed to take a change through ACPICA to rename ACPI_NFIT_MEM_ARMED to ACPI_NFIT_MEM_NOT_ARMED, and the patch below from Toshi brings the sysfs representation of these flags in line with their respective polarities. Please pull for 4.2 as this is the first kernel to expose the ACPI NFIT sysfs representation, and this is likely a kernel that firmware developers will be using for checking out their NVDIMM enabling" * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: nfit: Clarify memory device state flags strings

nfit: Clarify memory device state flags strings

2015-08-27T18:35:58Z

ACPI 6.0 NFIT Memory Device State Flags in Table 5-129 defines NVDIMM status as follows. These bits indicate multiple info, such as failures, pending event, and capability. Bit [0] set to 1 to indicate that the previous SAVE to the Memory Device failed. Bit [1] set to 1 to indicate that the last RESTORE from the Memory Device failed. Bit [2] set to 1 to indicate that platform flush of data to Memory Device failed. As a result, the restored data content may be inconsistent even if SAVE and RESTORE do not indicate failure. Bit [3] set to 1 to indicate that the Memory Device is observed to be not armed prior to OSPM hand off. A Memory Device is considered armed if it is able to accept persistent writes. Bit [4] set to 1 to indicate that the Memory Device observed SMART and health events prior to OSPM handoff. /sys/bus/nd/devices/nmemX/nfit/flags shows this flags info. The output strings associated with the bits are "save", "restore", "smart", etc., which can be confusing as they may be interpreted as positive status, i.e. save succeeded. Change also the dev_info() message in acpi_nfit_register_dimms() to be consistent with the sysfs flags strings. Reported-by: Robert Elliott Signed-off-by: Toshi Kani [ross: rename 'not_arm' to 'not_armed'] Cc: Ross Zwisler [djbw: defer adding bit5, HEALTH_ENABLED, for now] Signed-off-by: Dan Williams

Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm

2015-08-26T00:26:00Z

Pull nvdimm fix from Dan Williams: "A single fix for status register read size in the nd_blk driver. The effect of getting the width of this register read wrong is that all I/O fails when the read returns non-zero. Given the availability of ACPI 6 NFIT enabled platforms, this could reasonably wait to come in during the 4.3 merge window with a tag for 4.2-stable. Otherwise, this makes the 4.2 kernel fully functional with devices that conform to the mmio-block-apertures defined in the ACPI 6 NFIT (NVDIMM Firmware Interface Table)" * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: nfit, nd_blk: BLK status register is only 32 bits

nfit, nd_blk: BLK status register is only 32 bits

2015-08-25T23:42:01Z

Only read 32 bits for the BLK status register in read_blk_stat(). The format and size of this register is defined in the "NVDIMM Driver Writer's guide": http://pmem.io/documents/NVDIMM_Driver_Writers_Guide.pdf Signed-off-by: Ross Zwisler Reported-by: Nicholas Moulin Tested-by: Nicholas Moulin Reviewed-by: Jeff Moyer Signed-off-by: Dan Williams

ACPI / video: Fix circular lock dependency issue in the video-detect code

2015-08-14T09:20:20Z

Before this commit, the following would happen: a) acpi_video_get_backlight_type() gets called b) acpi_video_get_backlight_type() calls acpi_video_init_backlight_type() c) acpi_video_init_backlight_type() locks its function static init_mutex d) acpi_video_init_backlight_type() calls backlight_register_notifier() e) backlight_register_notifier() takes its notifier-chain lock And when the backlight notifier chain gets called we've: 1) blocking_notifier_call_chain() gets called 2) blocking_notifier_call_chain() takes the notifier-chain lock 3) blocking_notifier_call_chain() calls acpi_video_backlight_notify() 4) acpi_video_backlight_notify() calls acpi_video_get_backlight_type() 5) acpi_video_get_backlight_type() calls acpi_video_init_backlight_type() 6) acpi_video_init_backlight_type() locks its function static init_mutex So in the first call sequence we have: a) init_mutex gets locked b) notifier-chain gets locked and in the second call sequence we have: 1) notifier-chain gets locked 2) init_mutex gets locked And we've a circular locking dependency. This specific locking dependency is fixable without using the big hammer otherwise known as a workqueue, but further analysis shows a similar problem with the backlight notifier chain lock vs register_count_mutex from drivers/acpi/acpi_video.c, and fixing that becomes problematic. So this commit simply fixes this with the big hammer, performance wise this is a non issue as we expect the work to get scheduled exactly zero or one times during normal system use. Fixes: 93a291dfaf9c (ACPI / video: Move backlight notifier to video_detect.c) Signed-off-by: Hans de Goede Reported-and-tested-by: Sedat Dilek Signed-off-by: Rafael J. Wysocki

ACPI / PM: Use target_state to set the device power state

2015-07-28T14:29:08Z

Commit 20dacb71ad28 ("ACPI / PM: Rework device power management to follow ACPI 6") changed the device power management to use D3hot if the device in question does not have _PR3 method even if D3cold was requested by the caller. However, if the device has _PR3 device->power.state is also set to D3hot instead of D3Cold after power resources have been turned off because device->power.state will be assigned from "state" instead of "target_state". Next time the device is transitioned to D0, acpi_power_transition() will find that the current power state of the device is D3hot instead of D3cold which causes it to power down all resources required for the current (wrong) state D3hot. Below is a simplified ASL example of a real touch panel device which triggers the problem: Scope (TPL1) { Name (_PR0, Package (1) { \_SB.PCI0.I2C1.PXTC }) Name (_PR3, Package (1) { \_SB.PCI0.I2C1.PXTC }) ... } In both D0 and D3hot the same power resource is required. However, when acpi_power_transition() turns off power resources required for D3hot (as the device is transitioned to D0) it powers down PXTC which then makes the device to lose its power. Fix this by assigning "target_state" to the device power state instead of "state" that is always D3hot even for devices with valid _PR3. Fixes: 20dacb71ad28 (ACPI / PM: Rework device power management to follow ACPI 6) Signed-off-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki

Merge branches 'pm-cpuidle', 'pm-cpufreq' and 'acpi-resources'

2015-07-16T21:47:19Z

* pm-cpuidle: suspend-to-idle: Prevent RCU from complaining about tick_freeze() * pm-cpufreq: cpufreq: Allow freq_table to be obtained for offline CPUs cpufreq: Initialize the governor again while restoring policy * acpi-resources: ACPI / PCI: Fix regressions caused by resource_size_t overflow with 32-bit kernel

Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm

2015-07-12T03:44:31Z

Pull libnvdimm fixes from Dan Williams: "1) Fixes for a handful of smatch reports (Thanks Dan C.!) and minor bug fixes (patches 1-6) 2) Correctness fixes to the BLK-mode nvdimm driver (patches 7-10). Granted these are slightly large for a -rc update. They have been out for review in one form or another since the end of May and were deferred from the merge window while we settled on the "PMEM API" for the PMEM-mode nvdimm driver (ie memremap_pmem, memcpy_to_pmem, and wmb_pmem). Now that those apis are merged we implement them in the BLK driver to guarantee that mmio aperture moves stay ordered with respect to incoming read/write requests, and that writes are flushed through those mmio-windows and platform-buffers to be persistent on media. These pass the sub-system unit tests with the updates to tools/testing/nvdimm, and have received a successful build-report from the kbuild robot (468 configs). With acks from Rafael for the touches to drivers/acpi/" * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm: nfit: add support for NVDIMM "latch" flag nfit: update block I/O path to use PMEM API tools/testing/nvdimm: add mock acpi_nfit_flush_address entries to nfit_test tools/testing/nvdimm: fix return code for unimplemented commands tools/testing/nvdimm: mock ioremap_wt pmem: add maintainer for include/linux/pmem.h nfit: fix smatch "use after null check" report nvdimm: Fix return value of nvdimm_bus_init() if class_create() fails libnvdimm: smatch cleanups in __nd_ioctl sparse: fix misplaced __pmem definition