summaryrefslogtreecommitdiff
path: root/drivers/platform/x86/intel
AgeCommit message (Collapse)Author
2022-08-01platform/x86/intel/vsec: Fix wrong type for local status variablesHans de Goede
The local status variables in intel_vsec_pci_error_detected() and intel_vsec_pci_slot_reset() should have pci_ers_result_t as type (and not pci_channel_state_t). Also fix a whitespace error as well as intel_vsec_pci_err_handlers not being marked static. This fixes the following sparse errors: drivers/platform/x86/intel/vsec.c:429:38: sparse: sparse: incorrect type in initializer (different base types) @@ expected restricted pci_channel_state_t [usertype] status @@ got restricted pci_ers_result_t @@ drivers/platform/x86/intel/vsec.c:429:38: sparse: expected restricted pci_channel_state_t [usertype] status drivers/platform/x86/intel/vsec.c:429:38: sparse: got restricted pci_ers_result_t drivers/platform/x86/intel/vsec.c:434:24: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted pci_channel_state_t [usertype] status @@ got restricted pci_ers_result_t @@ drivers/platform/x86/intel/vsec.c:434:24: sparse: expected restricted pci_channel_state_t [usertype] status drivers/platform/x86/intel/vsec.c:434:24: sparse: got restricted pci_ers_result_t drivers/platform/x86/intel/vsec.c:438:16: sparse: sparse: incorrect type in return expression (different base types) @@ expected restricted pci_ers_result_t @@ got restricted pci_channel_state_t [usertype] status @@ drivers/platform/x86/intel/vsec.c:438:16: sparse: expected restricted pci_ers_result_t drivers/platform/x86/intel/vsec.c:438:16: sparse: got restricted pci_channel_state_t [usertype] status drivers/platform/x86/intel/vsec.c:444:38: sparse: sparse: incorrect type in initializer (different base types) @@ expected restricted pci_channel_state_t [usertype] status @@ got restricted pci_ers_result_t @@ drivers/platform/x86/intel/vsec.c:444:38: sparse: expected restricted pci_channel_state_t [usertype] status drivers/platform/x86/intel/vsec.c:444:38: sparse: got restricted pci_ers_result_t drivers/platform/x86/intel/vsec.c:457:16: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted pci_channel_state_t [usertype] status @@ got restricted pci_ers_result_t @@ drivers/platform/x86/intel/vsec.c:457:16: sparse: expected restricted pci_channel_state_t [usertype] status drivers/platform/x86/intel/vsec.c:457:16: sparse: got restricted pci_ers_result_t drivers/platform/x86/intel/vsec.c:472:16: sparse: sparse: incorrect type in return expression (different base types) @@ expected restricted pci_ers_result_t @@ got restricted pci_channel_state_t [usertype] status @@ drivers/platform/x86/intel/vsec.c:472:16: sparse: expected restricted pci_ers_result_t drivers/platform/x86/intel/vsec.c:472:16: sparse: got restricted pci_channel_state_t [usertype] status drivers/platform/x86/intel/vsec.c:480:33: sparse: sparse: symbol 'intel_vsec_pci_err_handlers' was not declared. Should it be static? Reported-by: kernel test robot <lkp@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Cc: David E Box <david.e.box@intel.com> Cc: Gayatri Kammela <gayatri.kammela@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220801145536.172410-1-hdegoede@redhat.com
2022-08-01platform/x86: p2sb: Move out of X86_PLATFORM_DEVICES dependencyAndy Shevchenko
The P2SB library is used for various drivers, including server platforms. That's why the dependency on X86_PLATFORM_DEVICES seems superfluous. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220718145328.14374-1-andriy.shevchenko@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-08-01Merge tag 'ib-mfd-edac-i2c-leds-pinctrl-platform-watchdog-v5.20' into ↵Hans de Goede
review-hans Immutable branch between MFD, EDAC, I2C, LEDs, PinCtrl, Platform and Watchdog due for the v5.20 merge window
2022-07-14i2c: i801: convert to use common P2SB accessorAndy Shevchenko
Since we have a common P2SB accessor in tree we may use it instead of open coded variants. Replace custom code by p2sb_bar() call. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Henning Schild <henning.schild@siemens.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Jean Delvare <jdelvare@suse.de> Acked-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Lee Jones <lee@kernel.org>
2022-07-14platform/x86/intel: Add Primary to Sideband (P2SB) bridge supportJonathan Yong
SoC features such as GPIO are accessed via a reserved MMIO area, we don't know its address but can obtain it from the BAR of the P2SB device, that device is normally hidden so we have to temporarily unhide it, read address and hide it back. There are already a few users and at least one more is coming which require an access to Primary to Sideband (P2SB) bridge in order to get IO or MMIO BAR hidden by BIOS. Create a library to access P2SB for x86 devices in a unified way. Background information ====================== Note, the term "bridge" is used in the documentation and it has nothing to do with a PCI (host) bridge as per the PCI specifications. The P2SB is an interesting device by its nature and hardware design. First of all, it has several devices in the hardware behind it. These devices may or may not be represented as ACPI devices by a firmware. It also has a hardwired (to 0s) the least significant bits of the base address register which is represented by the only 64-bit BAR0. It means that OS mustn't reallocate the BAR. On top of that in some cases P2SB is represented by function 0 on PCI slot (in terms of B:D.F) and according to the PCI specification any other function can't be seen until function 0 is present and visible. In the PCI configuration space of P2SB device the full 32-bit register is allocated for the only purpose of hiding the entire P2SB device. As per [3]: 3.1.39 P2SB Control (P2SBC)—Offset E0h Hide Device (HIDE): When this bit is set, the P2SB will return 1s on any PCI Configuration Read on IOSF-P. All other transactions including PCI Configuration Writes on IOSF-P are unaffected by this. This does not affect reads performed on the IOSF-SB interface. This doesn't prevent MMIO accesses, although preventing the OS from assigning these addresses. The firmware on the affected platforms marks the region as unusable (by cutting it off from the PCI host bridge resources) as depicted in the Apollo Lake example below: PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [io 0x0070-0x0077] pci_bus 0000:00: root bus resource [io 0x0000-0x006f window] pci_bus 0000:00: root bus resource [io 0x0078-0x0cf7 window] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] pci_bus 0000:00: root bus resource [mem 0x7c000001-0x7fffffff window] pci_bus 0000:00: root bus resource [mem 0x7b800001-0x7bffffff window] pci_bus 0000:00: root bus resource [mem 0x80000000-0xcfffffff window] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xefffffff window] pci_bus 0000:00: root bus resource [bus 00-ff] The P2SB 16MB BAR is located at 0xd0000000-0xd0ffffff memory window. The generic solution ==================== The generic solution for all cases when we need to access to the information behind P2SB device is a library code where users ask for necessary resources by demand and hence those users take care of not being run on the systems where this access is not required. The library provides the p2sb_bar() API to retrieve the MMIO of the BAR0 of the device from P2SB device slot. P2SB unconditional unhiding awareness ===================================== Technically it's possible to unhide the P2SB device and devices on the same PCI slot and access them at any time as needed. But there are several potential issues with that: - the systems were never tested against such configuration and hence nobody knows what kind of bugs it may bring, especially when we talk about SPI NOR case which contains Intel FirmWare Image (IFWI) code (including BIOS) and already known to be problematic in the past for end users - the PCI by its nature is a hotpluggable bus and in case somebody attaches a driver to the functions of a P2SB slot device(s) the end user experience and system behaviour can be unpredictable - the kernel code would need some ugly hacks (or code looking as an ugly hack) under arch/x86/pci in order to enable these devices on only selected platforms (which may include CPU ID table followed by a potentially growing number of DMI strings The future improvements ======================= The future improvements with this code may go in order to gain some kind of cache, if it's possible at all, to prevent unhiding and hiding many times to take static information that may be saved once per boot. Links ===== [1]: https://lab.whitequark.org/notes/2017-11-08/accessing-intel-ich-pch-gpios/ [2]: https://cdrdv2.intel.com/v1/dl/getContent/332690?wapkw=332690 [3]: https://cdrdv2.intel.com/v1/dl/getContent/332691?wapkw=332691 [4]: https://medium.com/@jacksonchen_43335/bios-gpio-p2sb-70e9b829b403 Signed-off-by: Jonathan Yong <jonathan.yong@intel.com> Co-developed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Henning Schild <henning.schild@siemens.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lee Jones <lee@kernel.org>
2022-07-10platform/x86: intel_atomisp2_led: Also turn off the always-on camera LED on ↵Hans de Goede
the Asus T100TAF Like the Asus T100TA the Asus T100TAF has a camera LED which is always on by default and both also use the same GPIO for the LED. Relax the DMI match for the Asus T100TA so that it also matches the T100TAF. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220710173658.221528-1-hdegoede@redhat.com
2022-07-10platform/x86/intel/ifs: Mark as BROKENHans de Goede
A recent suggested change to the IFS code has shown that the userspace API needs a bit more work, see: https://lore.kernel.org/platform-driver-x86/20220708151938.986530-1-jithu.joseph@intel.com/ Mark it as BROKEN before 5.19 ships, to give ourselves one more kernel-devel cycle to get the userspace API right. Link: https://lore.kernel.org/platform-driver-x86/20220708151938.986530-1-jithu.joseph@intel.com/ Cc: Jithu Joseph <jithu.joseph@intel.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Tony Luck <tony.luck@intel.com> Suggested-by: Greg KH <gregkh@linuxfoundation.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20220710140736.6492-1-hdegoede@redhat.com
2022-07-08platform/x86/intel/vsec: Add PCI error recovery support to Intel PMTGayatri Kammela
Add PCI error recovery support for Intel PMT driver to recover from PCI fatal errors Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Cc: David E Box <david.e.box@intel.com> Signed-off-by: Gayatri Kammela <gayatri.kammela@linux.intel.com> Link: https://lore.kernel.org/r/20220629221334.434307-5-gayatri.kammela@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-07-02platform/x86/intel/pmt: telemetry: Fix fixed region handlingDavid E. Box
Use the telem_type and the fixed block guid to determine if an entry is a fixed region. For certain platforms we don't support this. Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Gayatri Kammela <gayatri.kammela@linux.intel.com> Link: https://lore.kernel.org/r/20220629221334.434307-4-gayatri.kammela@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-07-02platform/x86/intel/vsec: Add support for Raptor LakeDavid E. Box
Add Raptor Lake support to Intel's PMT driver. Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Gayatri Kammela <gayatri.kammela@linux.intel.com> Link: https://lore.kernel.org/r/20220629221334.434307-3-gayatri.kammela@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-07-02platform/x86/intel/vsec: Rework early hardware codeDavid E. Box
In the Intel VSEC PCI driver, use a new VSEC_QUIRK_EARLY_HW flag in driver_data to indicate the need for early hardware quirks in auxiliary devices. Remove the separate PCI ID list maintained by the Intel PMT auxiliary driver. Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Gayatri Kammela <gayatri.kammela@linux.intel.com> Link: https://lore.kernel.org/r/20220629221334.434307-2-gayatri.kammela@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-07-02platform/x86: ISST: PUNIT device mapping with Sub-NUMA clusteringSrinivas Pandruvada
On a multiple package system using Sub-NUMA clustering, there is an issue in mapping Linux CPU number to PUNIT PCI device when manufacturer decided to reuse the PCI bus number across packages. Bus number can be reused as long as they are in different domain or segment. In this case some CPU will fail to find a PCI device to issue SST requests. When bus numbers are reused across CPU packages, we are using proximity information by matching CPU numa node id to PUNIT PCI device numa node id. But on a package there can be only one PUNIT PCI device, but multiple numa nodes (one for each sub cluster). So, the numa node ID of the PUNIT PCI device can only match with one numa node id of CPUs in a sub cluster in the package. Since there can be only one PUNIT PCI device per package, if we match with numa node id of any sub cluster in that package, we can use that mapping for any CPU in that package. So, store the match information in a per package data structure and return the information when there is no match. While here, use defines for max bus number instead of hardcoding. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20220629194817.2418240-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-27platform/x86: intel/pmc: Add Alder Lake N support to PMC core driverGayatri Kammela
Add Alder Lake N (ADL-N) to the list of the platforms that Intel's PMC core driver supports. Alder Lake N reuses all the TigerLake PCH IPs. Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Gayatri Kammela <gayatri.kammela@linux.intel.com> Reviewed-by: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com> Link: https://lore.kernel.org/r/20220615002751.3371730-1-gayatri.kammela@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-12platform/x86/intel: hid: Add Surface Go to VGBS allow listDuke Lee
The Surface Go reports Chassis Type 9 (Laptop,) so the device needs to be added to dmi_vgbs_allow_list to enable tablet mode when an attached Type Cover is folded back. BugLink: https://github.com/linux-surface/linux-surface/issues/837 Signed-off-by: Duke Lee <krnhotwings@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220607213654.5567-1-krnhotwings@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-10platform/x86/intel: pmc: Support Intel Raptorlake PGeorge D Sworo
Add Raptorlake P to the list of the platforms that intel_pmc_core driver supports for pmc_core device. Raptorlake P PCH is based on Alderlake P PCH. Signed-off-by: George D Sworo <george.d.sworo@intel.com> Reviewed-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20220602012617.20100-1-george.d.sworo@intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-10platform/x86/intel: Fix pmt_crashlog array referenceDavid Arcari
The probe function pmt_crashlog_probe() may incorrectly reference the 'priv->entry array' as it uses 'i' to reference the array instead of 'priv->num_entries' as it should. This is similar to the problem that was addressed in pmt_telemetry_probe via commit 2cdfa0c20d58 ("platform/x86/intel: Fix 'rmmod pmt_telemetry' panic"). Cc: "David E. Box" <david.e.box@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mark Gross <markgross@kernel.org> Cc: linux-kernel@vger.kernel.org Signed-off-by: David Arcari <darcari@redhat.com> Reviewed-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20220526203140.339120-1-darcari@redhat.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-19platform/x86/intel/ifs: Add CPU_SUP_INTEL dependencyBorislav Petkov
The driver is using functions from a compilation unit which is enabled by CONFIG_CPU_SUP_INTEL. Add that dependency to Kconfig explicitly otherwise: drivers/platform/x86/intel/ifs/load.o: in function `ifs_load_firmware': load.c:(.text+0x3b8): undefined reference to `intel_cpu_collect_info' Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/YoZay8YR0zRGyVu+@zn.tnic Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-19platform/x86: intel_cht_int33fe: Set driver dataHeikki Krogerus
Module removal fails because cht_int33fe_typec_remove() tries to access driver data that does not exist. Fixing by assigning the data at the end of probe. Fixes: 915623a80b5a ("platform/x86: intel_cht_int33fe: Switch to DMI modalias based loading") Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20220519122103.78546-1-heikki.krogerus@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-19platform/x86: intel-hid: fix _DSM function index handlingMichael Niewöhner
intel_hid_dsm_fn_mask is a bit mask containing one bit for each function index. Fix the function index check in intel_hid_evaluate_method accordingly, which was missed in commit 97ab4516205e ("platform/x86: intel-hid: fix _DSM function index handling"). Fixes: 97ab4516205e ("platform/x86: intel-hid: fix _DSM function index handling") Cc: stable@vger.kernel.org Signed-off-by: Michael Niewöhner <linux@mniewoehner.de> Link: https://lore.kernel.org/r/66f813f5bcc724a0f6dd5adefe6a9728dbe509e3.camel@mniewoehner.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-12Documentation: In-Field ScanTony Luck
Add documentation for In-Field Scan (IFS). This documentation describes the basics of IFS, the loading IFS image, chunk authentication, running scan and how to check result via sysfs. The CORE_CAPABILITIES MSR enumerates whether IFS is supported. The full github location for distributing the IFS images is still being decided. So just a placeholder included for now in the documentation. Future CPUs will support more than one type of test. Plan for that now by using a "_0" suffix on the ABI directory names. Additional test types will use "_1", etc. Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220506225410.1652287-13-tony.luck@intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-12trace: platform/x86/intel/ifs: Add trace point to track Intel IFS operationsTony Luck
Add tracing support which may be useful for debugging systems that fail to complete In Field Scan tests. Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20220506225410.1652287-11-tony.luck@intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-12platform/x86/intel/ifs: Add IFS sysfs interfaceJithu Joseph
Implement sysfs interface to trigger ifs test for a specific cpu. Additional interfaces related to checking the status of the scan test and seeing the version of the loaded IFS binary are also added. The basic usage is as below. - To start test, for example on cpu5: echo 5 > /sys/devices/platform/intel_ifs/run_test - To see the status of the last test cat /sys/devices/platform/intel_ifs/status - To see the version of the loaded scan binary cat /sys/devices/platform/intel_ifs/image_version Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Co-developed-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220506225410.1652287-10-tony.luck@intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-12platform/x86/intel/ifs: Add scan test supportJithu Joseph
In a core, the scan engine is shared between sibling cpus. When a Scan test (for a particular core) is triggered by the user, the scan chunks are executed on all the threads on the core using stop_core_cpuslocked. Scan may be aborted by some reasons. Scan test will be aborted in certain circumstances such as when interrupt occurred or cpu does not have enough power budget for scan. In this case, the kernel restart scan from the chunk where it stopped. Scan will also be aborted when the test is failed. In this case, the test is immediately stopped without retry. Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Co-developed-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220506225410.1652287-9-tony.luck@intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-12platform/x86/intel/ifs: Authenticate and copy to secured memoryJithu Joseph
The IFS image contains hashes that will be used to authenticate the ifs test chunks. First, use WRMSR to copy the hashes and enumerate the number of test chunks, chunk size and the maximum number of cores that can run scan test simultaneously. Next, use WRMSR to authenticate each and every scan test chunk which is stored in the IFS image. The CPU will check if the test chunks match the hashes, otherwise failure is indicated to system software. If the test chunk is authenticated, it is automatically copied to secured memory. Use schedule_work_on() to perform the hash copy and authentication. Note this needs only be done on the first logical cpu of each socket. Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Co-developed-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220506225410.1652287-8-tony.luck@intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-12platform/x86/intel/ifs: Check IFS Image sanityJithu Joseph
IFS image is designed specifically for a given family, model and stepping of the processor. Like Intel microcode header, the IFS image has the Processor Signature, Checksum and Processor Flags that must be matched with the information returned by the CPUID. Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Co-developed-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220506225410.1652287-7-tony.luck@intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-12platform/x86/intel/ifs: Read IFS firmware imageJithu Joseph
Driver probe routine allocates structure to communicate status and parameters between functions in the driver. Also call load_ifs_binary() to load the scan image file. There is a separate scan image file for each processor family, model, stepping combination. This is read from the static path: /lib/firmware/intel/ifs/{ff-mm-ss}.scan Step 1 in loading is to generate the correct path and use request_firmware_direct() to load into memory. Subsequent patches will use the IFS MSR interfaces to copy the image to BIOS reserved memory and validate the SHA256 checksums. Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Co-developed-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220506225410.1652287-6-tony.luck@intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-12platform/x86/intel/ifs: Add stub driver for In-Field ScanTony Luck
Cloud Service Providers that operate fleets of servers have reported [1] occasions where they can detect that a CPU has gone bad due to effects like electromigration, or isolated manufacturing defects. However, that detection method is A/B testing seemingly random application failures looking for a pattern. In-Field Scan (IFS) is a driver for a platform capability to load a crafted 'scan image' to run targeted low level diagnostics outside of the CPU's architectural error detection capabilities. Stub version of driver just does initial part of check for the IFS feature. MSR_IA32_CORE_CAPS must enumerate the presence of the MSR_INTEGRITY_CAPS MSR. [1]: https://www.youtube.com/watch?v=QMF3rqhjYuM Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220506225410.1652287-5-tony.luck@intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-06platform/x86/intel: Fix 'rmmod pmt_telemetry' panicPrarit Bhargava
'rmmod pmt_telemetry' panics with: BUG: kernel NULL pointer dereference, address: 0000000000000040 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 1697 Comm: rmmod Tainted: G S W -------- --- 5.18.0-rc4 #3 Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS ADLPFWI1.R00.3056.B00.2201310233 01/31/2022 RIP: 0010:device_del+0x1b/0x3d0 Code: e8 1a d9 e9 ff e9 58 ff ff ff 48 8b 08 eb dc 0f 1f 44 00 00 41 56 41 55 41 54 55 48 8d af 80 00 00 00 53 48 89 fb 48 83 ec 18 <4c> 8b 67 40 48 89 ef 65 48 8b 04 25 28 00 00 00 48 89 44 24 10 31 RSP: 0018:ffffb520415cfd60 EFLAGS: 00010286 RAX: 0000000000000070 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000080 R08: ffffffffffffffff R09: ffffb520415cfd78 R10: 0000000000000002 R11: ffffb520415cfd78 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f7e198e5740(0000) GS:ffff905c9f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000040 CR3: 000000010782a005 CR4: 0000000000770ee0 PKRU: 55555554 Call Trace: <TASK> ? __xa_erase+0x53/0xb0 device_unregister+0x13/0x50 intel_pmt_dev_destroy+0x34/0x60 [pmt_class] pmt_telem_remove+0x40/0x50 [pmt_telemetry] auxiliary_bus_remove+0x18/0x30 device_release_driver_internal+0xc1/0x150 driver_detach+0x44/0x90 bus_remove_driver+0x74/0xd0 auxiliary_driver_unregister+0x12/0x20 pmt_telem_exit+0xc/0xe4a [pmt_telemetry] __x64_sys_delete_module+0x13a/0x250 ? syscall_trace_enter.isra.19+0x11e/0x1a0 do_syscall_64+0x58/0x80 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x67/0x80 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x67/0x80 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x67/0x80 ? exc_page_fault+0x64/0x140 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f7e1803a05b Code: 73 01 c3 48 8b 0d 2d 4e 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d fd 4d 38 00 f7 d8 64 89 01 48 The probe function, pmt_telem_probe(), adds an entry for devices even if they have not been initialized. This results in the array of initialized devices containing both initialized and uninitialized entries. This causes a panic in the remove function, pmt_telem_remove() which expects the array to only contain initialized entries. Only use an entry when a device is initialized. Cc: "David E. Box" <david.e.box@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mark Gross <markgross@kernel.org> Cc: platform-driver-x86@vger.kernel.org Signed-off-by: David Arcari <darcari@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com> Reviewed-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20220429122322.2550003-1-prarit@redhat.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-04-27platform/x86/intel: pmc/core: Use kobj_to_dev()Minghao Chi
Use kobj_to_dev() instead of open-coding it. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/r/20220425105525.3515831-1-chi.minghao@zte.com.cn Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-04-27platform/x86/intel: pmc/core: change pmc_lpm_modes to staticTom Rix
Sparse reports this issue core.c: note: in included file: core.h:239:12: warning: symbol 'pmc_lpm_modes' was not declared. Should it be static? Global variables should not be defined in headers. This only works because core.h is only included by core.c. Single file use variables should be static, so change its storage-class specifier to static. Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20220423123048.591405-1-trix@redhat.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-04-27platform/x86/intel/sdsi: Fix bug in multi packet readsDavid E. Box
Fix bug that added an offset to the mailbox addr during multi-packet reads. Did not affect current ABI since it doesn't support multi-packet transactions. Fixes: 2546c6000430 ("platform/x86: Add Intel Software Defined Silicon driver") Signed-off-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20220420155622.1763633-4-david.e.box@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-04-27platform/x86/intel/sdsi: Poll on ready bit for writesDavid E. Box
Due to change in firmware flow, update mailbox writes to poll on ready bit instead of run_busy bit. This change makes the polling method consistent for both writes and reads, which also uses the ready bit. Fixes: 2546c6000430 ("platform/x86: Add Intel Software Defined Silicon driver") Signed-off-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20220420155622.1763633-3-david.e.box@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-04-27platform/x86/intel/sdsi: Handle leaky bucketDavid E. Box
To prevent an agent from indefinitely holding the mailbox firmware has implemented a leaky bucket algorithm. Repeated access to the mailbox may now incur a delay of up to 2.1 seconds. Add a retry loop that tries for up to 2.5 seconds to acquire the mailbox. Fixes: 2546c6000430 ("platform/x86: Add Intel Software Defined Silicon driver") Signed-off-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20220420155622.1763633-2-david.e.box@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-04-27platform/x86: intel-uncore-freq: Prevent driver loading in guestsSrinivas Pandruvada
Loading this driver in guests results in unchecked MSR access error for MSR 0x620. There is no use of reading and modifying package/die scope uncore MSRs in guests. So check for CPU feature X86_FEATURE_HYPERVISOR to prevent loading of this driver in guests. Fixes: dbce412a7733 ("platform/x86/intel-uncore-freq: Split common and enumeration part") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215870 Suggested-by: Borislav Petkov <bp@suse.de> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20220427100304.2562990-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-03-08platform/x86: intel-uncore-freq: fix uncore_freq_common_init() error codesDan Carpenter
Currently the uncore_freq_common_init() return one on success and zero on failure. There is only one caller and it has a "forgot to set the error code" bug. Change uncore_freq_common_init() to return negative error codes which makes the code simpler and avoids this kind of bug in the future. Fixes: dbce412a7733 ("platform/x86/intel-uncore-freq: Split common and enumeration part") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20220304131925.GG28739@kili Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-02-21platform/x86: int3472: Add terminator to gpiod_lookup_tableDaniel Scally
Without the terminator, if a con_id is passed to gpio_find() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops. Fixes: 19d8d6e36b4b ("platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell") Signed-off-by: Daniel Scally <djrscally@gmail.com> Link: https://lore.kernel.org/r/20220216225304.53911-5-djrscally@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-02-17platform/x86/intel-uncore-freq: Split common and enumeration partSrinivas Pandruvada
Split the current driver in two parts: - Common part: All the commom function other than enumeration function. - Enumeration/HW specific part: The current enumeration using CPU model is left in the old module. This uses service of common driver to register sysfs objects. Also provide callbacks for MSR access related to uncore. - Add MODULE_DEVICE_TABLE to uncore-frequency.c No functional changes are expected. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20220204000306.2517447-5-srinivas.pandruvada@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-02-17platform/x86/intel/uncore-freq: Display uncore current frequencySrinivas Pandruvada
Add a new sysfs attribute "current_freq_khz" to display current uncore frequency. This value is read from MSR 0x621. Root user permission is required to read uncore current frequency. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20220204000306.2517447-4-srinivas.pandruvada@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-02-17platform/x86/intel/uncore-freq: Use sysfs API to create attributesSrinivas Pandruvada
Use of sysfs API is always preferable over using kobject calls to create attributes. Remove usage of kobject_init_and_add() and use sysfs_create_group(). To create relationship between sysfs attribute and uncore instance use device_attribute*, which is defined per uncore instance. To create uniform locking for both read and write attributes take lock in the sysfs callbacks, not in the actual functions where the MSRs are read or updated. No functional changes are expected. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20220204000306.2517447-3-srinivas.pandruvada@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-02-17platform/x86/intel/uncore-freq: Move to uncore-frequency folderSrinivas Pandruvada
Move the current driver from platform/x86/intel/uncore-frequency.c to platform/x86/intel/uncore-frequency/uncore-frequency.c. No functional changes are expected. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20220204000306.2517447-2-srinivas.pandruvada@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-02-14platform/x86: Add Intel Software Defined Silicon driverDavid E. Box
Intel Software Defined Silicon (SDSi) is a post manufacturing mechanism for activating additional silicon features. Features are enabled through a license activation process. The SDSi driver provides a per socket, sysfs attribute interface for applications to perform 3 main provisioning functions: 1. Provision an Authentication Key Certificate (AKC), a key written to internal NVRAM that is used to authenticate a capability specific activation payload. 2. Provision a Capability Activation Payload (CAP), a token authenticated using the AKC and applied to the CPU configuration to activate a new feature. 3. Read the SDSi State Certificate, containing the CPU configuration state. The operations perform function specific mailbox commands that forward the requests to SDSi hardware to perform authentication of the payloads and enable the silicon configuration (to be made available after power cycling). The SDSi device itself is enumerated as an auxiliary device from the intel_vsec driver and as such has a build dependency on CONFIG_INTEL_VSEC. Link: https://github.com/intel/intel-sdsi Signed-off-by: David E. Box <david.e.box@linux.intel.com> Reviewed-by: Mark Gross <markgross@kernel.org> Link: https://lore.kernel.org/r/20220212013252.1293396-2-david.e.box@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-02-11platform/x86: intel_cht_int33fe: Move to intel directoryHans de Goede
Now that there is only 1 c-file left of the intel_cht_int33fe code, move it to the intel directory instead of it having its own int33fe sub-directory. Note this also renames the module from intel_cht_int33fe_typec to intel_chtwc_int33fe, to better match the names of other PMIC related modules like the intel_chtdc_ti_pwrbtn module. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220206220220.88491-4-hdegoede@redhat.com
2022-02-11platform/x86: intel_cht_int33fe: Drop Lenovo Yogabook YB1-X9x codeHans de Goede
Move the Lenovo Yogabook YB1-X9x fuel-gauge instantiation code over to the x86-android-tablets module, which already deals with this for various other devices. This removes the need to have a special intel_cht_int33fe_microb module just for Lenovo Yogabook YB1-X9x laptops. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220206220220.88491-3-hdegoede@redhat.com
2022-02-11platform/x86: intel_cht_int33fe: Switch to DMI modalias based loadingHans de Goede
The intel_cht_int33fe driver is intended to deal with ACPI INT33FE firmware-nodes on Cherry Trail devices with a Whiskey Cove PMIC. The original version of the driver only dealt with the GPD win and GPD pocket boards where the WC PMIC is connected to a TI BQ24292i charger, paired with a Maxim MAX17047 fuelgauge + a FUSB302 USB Type-C Controller + a PI3USB30532 USB switch, for a fully functional Type-C port. Later it was split into a Type-C and a Micro-B variant to deal with the Lenovo Yoga Book YB1-X90 / Lenovo Yoga Book YB1-X91 boards where the ACPI INT33FE firmware-node only describes the TI BQ27542 fuelgauge. Currently the driver differentiates between these 2 models by counting the number of I2cSerialBus resources in the firmware-node. There are a number of problems with this approach: 1. The driver autoloads based on the acpi:INT33FE modalias causing it to get loaded on almost all Bay Trail and Cherry Trail devices. It checks for the presence of a WC PMIC, so it won't bind but the loading still wastes time and memory. 2. Both code paths in the driver are really only designed for a single board and have harcoded various assumptions about these boards, if another design matching the current checks ever shows up the driver may end up doing something completely wrong. Avoid both issues by switching to using DMI based autoloading of the module, which has neither of these problems. Note this splits the previous intel_cht_int33fe kernel module into two modules: intel_cht_int33fe_typec and intel_cht_int33fe_microb, one for each model. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220206220220.88491-2-hdegoede@redhat.com
2022-02-03platform/x86: Replace acpi_bus_get_device()Rafael J. Wysocki
Replace acpi_bus_get_device() that is going to be dropped with acpi_fetch_acpi_dev(). No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/2631712.mvXUDI8C0e@kreacher Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-01-24platform/x86: ISST: Fix possible circular locking dependency detectedSrinivas Pandruvada
As reported: [ 256.104522] ====================================================== [ 256.113783] WARNING: possible circular locking dependency detected [ 256.120093] 5.16.0-rc6-yocto-standard+ #99 Not tainted [ 256.125362] ------------------------------------------------------ [ 256.131673] intel-speed-sel/844 is trying to acquire lock: [ 256.137290] ffffffffc036f0d0 (punit_misc_dev_lock){+.+.}-{3:3}, at: isst_if_open+0x18/0x90 [isst_if_common] [ 256.147171] [ 256.147171] but task is already holding lock: [ 256.153135] ffffffff8ee7cb50 (misc_mtx){+.+.}-{3:3}, at: misc_open+0x2a/0x170 [ 256.160407] [ 256.160407] which lock already depends on the new lock. [ 256.160407] [ 256.168712] [ 256.168712] the existing dependency chain (in reverse order) is: [ 256.176327] [ 256.176327] -> #1 (misc_mtx){+.+.}-{3:3}: [ 256.181946] lock_acquire+0x1e6/0x330 [ 256.186265] __mutex_lock+0x9b/0x9b0 [ 256.190497] mutex_lock_nested+0x1b/0x20 [ 256.195075] misc_register+0x32/0x1a0 [ 256.199390] isst_if_cdev_register+0x65/0x180 [isst_if_common] [ 256.205878] isst_if_probe+0x144/0x16e [isst_if_mmio] ... [ 256.241976] [ 256.241976] -> #0 (punit_misc_dev_lock){+.+.}-{3:3}: [ 256.248552] validate_chain+0xbc6/0x1750 [ 256.253131] __lock_acquire+0x88c/0xc10 [ 256.257618] lock_acquire+0x1e6/0x330 [ 256.261933] __mutex_lock+0x9b/0x9b0 [ 256.266165] mutex_lock_nested+0x1b/0x20 [ 256.270739] isst_if_open+0x18/0x90 [isst_if_common] [ 256.276356] misc_open+0x100/0x170 [ 256.280409] chrdev_open+0xa5/0x1e0 ... The call sequence suggested that misc_device /dev file can be opened before misc device is yet to be registered, which is done only once. Here punit_misc_dev_lock was used as common lock, to protect the registration by multiple ISST HW drivers, one time setup, prevent duplicate registry of misc device and prevent load/unload when device is open. We can split into locks: - One which just prevent duplicate call to misc_register() and one time setup. Also never call again if the misc_register() failed or required one time setup is failed. This lock is not shared with any misc device callbacks. - The other lock protects registry, load and unload of HW drivers. Sequence in isst_if_cdev_register() - Register callbacks under punit_misc_dev_open_lock - Call isst_misc_reg() which registers misc_device on the first registry which is under punit_misc_dev_reg_lock, which is not shared with callbacks. Sequence in isst_if_cdev_unregister Just opposite of isst_if_cdev_register Reported-and-tested-by: Liwei Song <liwei.song@windriver.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20220112022521.54669-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-01-24platform/x86: intel_crystal_cove_charger: Fix IRQ masking / unmaskingHans de Goede
The driver as originally submitted accidentally relied on Android having run before and Android having unmasked the 2nd level IRQ-mask for the charger IRQ. This worked since these are PMIC registers which are only reset when the battery is fully drained or disconnected. Fix the charger IRQ no longer working after loss of battery power by properly setting the 2nd level IRQ-mask for the charger IRQ. Note this removes the need to enable/disable our parent IRQ which just sets the mask bit in the 1st level IRQ-mask register, setting one of the 2 level masks is enough to stop the IRQ from getting reported. Fixes: 761db353d9e2 ("platform/x86: Add intel_crystal_cove_charger driver") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220111232309.377642-1-hdegoede@redhat.com
2022-01-12Merge tag 'driver-core-5.17-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is the set of changes for the driver core for 5.17-rc1. Lots of little things here, including: - kobj_type cleanups - auxiliary_bus documentation updates - auxiliary_device conversions for some drivers (relevant subsystems all have provided acks for these) - kernfs lock contention reduction for some workloads - other tiny cleanups and changes. All of these have been in linux-next for a while with no reported issues" * tag 'driver-core-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (43 commits) kobject documentation: remove default_attrs information drivers/firmware: Add missing platform_device_put() in sysfb_create_simplefb debugfs: lockdown: Allow reading debugfs files that are not world readable driver core: Make bus notifiers in right order in really_probe() driver core: Move driver_sysfs_remove() after driver_sysfs_add() firmware: edd: remove empty default_attrs array firmware: dmi-sysfs: use default_groups in kobj_type qemu_fw_cfg: use default_groups in kobj_type firmware: memmap: use default_groups in kobj_type sh: sq: use default_groups in kobj_type headers/uninline: Uninline single-use function: kobject_has_children() devtmpfs: mount with noexec and nosuid driver core: Simplify async probe test code by using ktime_ms_delta() nilfs2: use default_groups in kobj_type kobject: remove kset from struct kset_uevent_ops callbacks driver core: make kobj_type constant. driver core: platform: document registration-failure requirement vdpa/mlx5: Use auxiliary_device driver data helpers net/mlx5e: Use auxiliary_device driver data helpers soundwire: intel: Use auxiliary_device driver data helpers ...
2022-01-11Merge tag 'platform-drivers-x86-v5.17-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver updates from Hans de Goede: "Highlights: New drivers: - asus-tf103c-dock - intel_crystal_cove_charger - lenovo-yogabook-wmi - simatic-ipc platform-code + led driver + watchdog driver - x86-android-tablets (kernel module to workaround DSDT bugs on these) amd-pmc: - bug-fixes - smar trace buffer support asus-wmi: - support for custom fan curves int3472 (camera info ACPI object for Intel IPU3/SkyCam cameras): - ACPI core + int3472 changes to delay enumeration of camera sensor I2C clients until the PMIC for the sensor has been fully probed - Add support for board data (DSDT info is incomplete) for setting up the tps68470 PMIC used on some boards with these cameras - Add board data for the Microsoft Surface Go (original, v2 and v3) thinkpad_acpi: - various cleanups - support for forced battery discharging (for battery calibration) - support to inhibit battery charging - this includes power_supply core changes to add new APIs for this think_lmi: - enhanced BIOS password support various other small fixes and hardware-id additions" * tag 'platform-drivers-x86-v5.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (78 commits) power: supply: Provide stubs for charge_behaviour helpers platform/x86: x86-android-tablets: Fix GPIO lookup leak on error-exit platform/x86: int3472: Add board data for Surface Go 3 platform/x86: Add Asus TF103C dock driver platform/x86: x86-android-tablets: Add TM800A550L data platform/x86: x86-android-tablets: Add Asus MeMO Pad 7 ME176C data platform/x86: x86-android-tablets: Add Asus TF103C data platform/x86: x86-android-tablets: Add support for preloading modules platform/x86: x86-android-tablets: Add support for registering GPIO lookup tables platform/x86: x86-android-tablets: Add support for instantiating serdevs platform/x86: x86-android-tablets: Add support for instantiating platform-devs platform/x86: x86-android-tablets: Add support for PMIC interrupts platform/x86: x86-android-tablets: Don't return -EPROBE_DEFER from a non probe() function platform/x86: touchscreen_dmi: Remove the Glavey TM800A550L entry platform/x86: touchscreen_dmi: Enable pen support on the Chuwi Hi10 Plus and Pro platform/x86: touchscreen_dmi: Correct min/max values for Chuwi Hi10 Pro (CWI529) tablet platform/x86: Add intel_crystal_cove_charger driver power: supply: fix charge_behaviour attribute initialization platform/x86: intel-uncore-frequency: use default_groups in kobj_type x86/platform/uv: use default_groups in kobj_type ...
2022-01-10Merge tag 'media/v5.17-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media updates from Mauro Carvalho Chehab: - New sensor driver: ov5693 - A new driver for STM32 Chrom-ART Accelerator - Added V4L2 core helper functions for VP9 codec - Hantro driver has gained support for VP9 codecs - Added support for Maxim MAX96712 Quad GMSL2 Deserializer - The staging atomisp driver has gained lots of improvements, fixes and cleanups. It now works with userptr - Lots of random driver improvements as usual * tag 'media/v5.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (397 commits) media: ipu3-cio2: Add support for instantiating i2c-clients for VCMs media: ipu3-cio2: Call cio2_bridge_init() before anything else media: ipu3-cio2: Defer probing until the PMIC is fully setup media: hantro: Add support for Allwinner H6 media: dt-bindings: allwinner: document H6 Hantro G2 binding media: hantro: Convert imx8m_vpu_g2_irq to helper media: hantro: move postproc enablement for old cores media: hantro: vp9: add support for legacy register set media: hantro: vp9: use double buffering if needed media: hantro: add support for reset lines media: hantro: Fix probe func error path media: i2c: hi846: use pm_runtime_force_suspend/resume for system suspend media: i2c: hi846: check return value of regulator_bulk_disable() media: hi556: Support device probe in non-zero ACPI D state media: ov5675: Support device probe in non-zero ACPI D state media: imx208: Support device probe in non-zero ACPI D state media: ov2740: support device probe in non-zero ACPI D state media: ov5670: Support device probe in non-zero ACPI D state media: ov8856: support device probe in non-zero ACPI D state media: ov8865: Disable only enabled regulators on error path ...
generated by cgit v1.2.3 (git 2.46.0) at 2025-07-20 20:01:35 +0000