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

ACPI / SBS: Fix rare oops when removing modules

2019-11-24T07:23:19Z

[ Upstream commit 757c968c442397f1249bb775a7c8c03842e3e0c7 ] There was a small race when removing the sbshc module where smbus_alarm() had queued acpi_smbus_callback() for deferred execution but it hadn't been run yet, so that when it did run hc had been freed and the module unloaded, resulting in an invalid paging request. A similar race existed when removing the sbs module with regards to acpi_sbs_callback() (which is called from acpi_smbus_callback()). We therefore need to ensure no callbacks are pending or executing before the cleanups are done and the modules are removed. Signed-off-by: Ronald TschalÃ¤r Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPICA: Never run _REG on system_memory and system_IO

2019-11-24T07:23:05Z

[ Upstream commit 8b1cafdcb4b75c5027c52f1e82b47ebe727ad7ed ] These address spaces are defined by the ACPI spec to be "always available", and thus _REG should never be run on them. Provides compatibility with other ACPI implementations. Signed-off-by: Bob Moore Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

PCI/ACPI: Correct error message for ASPM disabling

2019-11-20T17:00:05Z

[ Upstream commit 1ad61b612b95980a4d970c52022aa01dfc0f6068 ] If _OSC execution fails today for platforms without an _OSC entry, code is printing a misleading message saying disabling ASPM as follows: acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM We need to ensure that platform supports ASPM to begin with. Reported-by: Michael Kelley Signed-off-by: Sinan Kaya Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin

ACPI / LPSS: Exclude I2C busses shared with PUNIT from pmc_atom_d3_mask

2019-11-20T17:00:03Z

[ Upstream commit 86b62e5cd8965d3056f9e9ccdec51631c37add81 ] lpss_iosf_enter_d3_state() checks if all hw-blocks using the DMA controllers are in d3 before powering down the DMA controllers. But on devices, where the I2C bus connected to the PMIC is shared by the PUNIT, the controller for that bus will never reach d3 since it has an effectively empty _PS3 method. Instead it appears to automatically power-down during S0i3 and we never see it as being in d3. This causes the DMA controllers to never be powered-down on these devices, causing them to never reach S0i3. This commit uses the ACPI _SEM method to detect if an I2C bus is shared with the PUNIT and if it is, it removes it from the mask of devices which lpss_iosf_enter_d3_state() checks for. This fixes these devices never reaching any S0ix states. Signed-off-by: Hans de Goede Acked-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI / PCI: fix acpi_pci_irq_enable() memory leak

2019-10-05T10:48:00Z

[ Upstream commit 29b49958cf73b439b17fa29e9a25210809a6c01c ] In acpi_pci_irq_enable(), 'entry' is allocated by kzalloc() in acpi_pci_irq_check_entry() (invoked from acpi_pci_irq_lookup()). However, it is not deallocated if acpi_pci_irq_valid() returns false, leading to a memory leak. To fix this issue, free 'entry' before returning 0. Fixes: e237a5518425 ("x86/ACPI/PCI: Recognize that Interrupt Line 255 means "not connected"") Signed-off-by: Wenwen Wang Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: custom_method: fix memory leaks

2019-10-05T10:47:59Z

[ Upstream commit 03d1571d9513369c17e6848476763ebbd10ec2cb ] In cm_write(), 'buf' is allocated through kzalloc(). In the following execution, if an error occurs, 'buf' is not deallocated, leading to memory leaks. To fix this issue, free 'buf' before returning the error. Fixes: 526b4af47f44 ("ACPI: Split out custom_method functionality into an own driver") Signed-off-by: Wenwen Wang Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI / CPPC: do not require the _PSD method

2019-10-05T10:47:57Z

[ Upstream commit 4c4cdc4c63853fee48c02e25c8605fb65a6c9924 ] According to the ACPI 6.3 specification, the _PSD method is optional when using CPPC. The underlying assumption is that each CPU can change frequency independently from all other CPUs; _PSD is provided to tell the OS that some processors can NOT do that. However, the acpi_get_psd() function returns ENODEV if there is no _PSD method present, or an ACPI error status if an error occurs when evaluating _PSD, if present. This makes _PSD mandatory when using CPPC, in violation of the specification, and only on Linux. This has forced some firmware writers to provide a dummy _PSD, even though it is irrelevant, but only because Linux requires it; other OSPMs follow the spec. We really do not want to have OS specific ACPI tables, though. So, correct acpi_get_psd() so that it does not return an error if there is no _PSD method present, but does return a failure when the method can not be executed properly. This allows _PSD to be optional as it should be. Signed-off-by: Al Stone Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI / processor: don't print errors for processorIDs == 0xff

2019-10-05T10:47:49Z

[ Upstream commit 2c2b005f549544c13ef4cfb0e4842949066889bc ] Some platforms define their processors in this manner: Device (SCK0) { Name (_HID, "ACPI0004" /* Module Device */) // _HID: Hardware ID Name (_UID, "CPUSCK0") // _UID: Unique ID Processor (CP00, 0x00, 0x00000410, 0x06){} Processor (CP01, 0x02, 0x00000410, 0x06){} Processor (CP02, 0x04, 0x00000410, 0x06){} Processor (CP03, 0x06, 0x00000410, 0x06){} Processor (CP04, 0x01, 0x00000410, 0x06){} Processor (CP05, 0x03, 0x00000410, 0x06){} Processor (CP06, 0x05, 0x00000410, 0x06){} Processor (CP07, 0x07, 0x00000410, 0x06){} Processor (CP08, 0xFF, 0x00000410, 0x06){} Processor (CP09, 0xFF, 0x00000410, 0x06){} Processor (CP0A, 0xFF, 0x00000410, 0x06){} Processor (CP0B, 0xFF, 0x00000410, 0x06){} ... The processors marked as 0xff are invalid, there are only 8 of them in this case. So do not print an error on ids == 0xff, just print an info message. Actually, we could return ENODEV even on the first CPU with ID 0xff, but ACPI spec does not forbid the 0xff value to be a processor ID. Given 0xff could be a correct one, we would break working systems if we returned ENODEV. Signed-off-by: Jiri Slaby Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: video: Add new hw_changes_brightness quirk, set it on PB Easynote MZ35

2019-10-05T10:47:38Z

[ Upstream commit 4f7f96453b462b3de0fa18d18fe983960bb5ee7f ] Some machines change the brightness themselves when a brightness hotkey gets pressed, despite us telling them not to. This causes the brightness to go two steps up / down when the hotkey is pressed. This is esp. a problem on older machines with only a few brightness levels. This commit adds a new hw_changes_brightness quirk which makes acpi_video_device_notify() only call backlight_force_update(..., BACKLIGHT_UPDATE_HOTKEY) and not do anything else, notifying userspace that the brightness was changed and leaving it at that fixing the dual step problem. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204077 Reported-by: Kacper Piwiński Tested-by: Kacper Piwiński Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI/IORT: Fix off-by-one check in iort_dev_find_its_id()

2019-08-16T08:13:54Z

[ Upstream commit 5a46d3f71d5e5a9f82eabc682f996f1281705ac7 ] Static analysis identified that index comparison against ITS entries in iort_dev_find_its_id() is off by one. Update the comparison condition and clarify the resulting error message. Fixes: 4bf2efd26d76 ("ACPI: Add new IORT functions to support MSI domain handling") Link: https://lore.kernel.org/linux-arm-kernel/20190613065410.GB16334@mwanda/ Reviewed-by: Hanjun Guo Reported-by: Dan Carpenter Signed-off-by: Lorenzo Pieralisi Cc: Dan Carpenter Cc: Will Deacon Cc: Hanjun Guo Cc: Sudeep Holla Cc: Catalin Marinas Cc: Robin Murphy Signed-off-by: Will Deacon Signed-off-by: Sasha Levin