linux/drivers/mfd, branch v5.17

Merge tag 'driver-core-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2022-01-12T19:11:34Z

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 ...

mfd: tps65910: Set PWR_OFF bit during driver probe

2021-12-29T13:36:16Z

The PWR_OFF bit needs to be set in order to power off properly, without hanging PMIC. This bit needs to be set early in order to allow thermal protection of NVIDIA Terga SoCs to power off hardware properly, otherwise a battery re-plug may be needed on some devices to recover after the hang. Cc: Signed-off-by: Dmitry Osipenko Tested-by: Svyatoslav Ryhel # ASUS TF201 Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20211124190104.23554-1-digetx@gmail.com

mfd: intel_soc_pmic: Use CPU-id check instead of _HRV check to differentiate variants

2021-12-29T13:32:08Z

The Intel Crystal Cove PMIC has 2 different variants, one for use with Bay Trail (BYT) SoCs and one for use with Cherry Trail (CHT) SoCs. So far we have been using an ACPI _HRV check to differentiate between the 2, but at least on the Microsoft Surface 3, which is a CHT device, the wrong _HRV value is reported by ACPI. So instead switch to a CPU-ID check which prevents us from relying on the possibly wrong ACPI _HRV value. Signed-off-by: Hans de Goede Reported-by: Tsuchiya Yuto Reviewed-by: Andy Shevchenko Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20211206174806.197772-2-hdegoede@redhat.com

mfd: intel-lpss: Fix I2C4 not being available on the Microsoft Surface Go & Go 2

2021-12-29T13:17:01Z

Many DSDTs for Kaby Lake and Kaby Lake Refresh models contain a _SB.PCI0.GEXP ACPI Device node describing an I2C attached PCA953x GPIO expander. This seems to be something which is copy and pasted from the DSDT from some reference design since this ACPI Device is present even on models where no such GPIO expander is used at all, such as on the Microsoft Surface Go & Go 2. This ACPI Device is a problem because it contains a SystemMemory OperationRegion which covers the MMIO for the I2C4 I2C controller. This causes the MFD cell for the I2C4 controller to not be instantiated due to a resource conflict, requiring the use of acpi_enforce_resources=lax to work around this. I have done an extensive analysis of all the ACPI tables on the Microsoft Surface Go and the _SB.PCI0.GEXP ACPI Device's methods are not used by any code in the ACPI tables, neither are any of them directly called by any Linux kernel code. This is unsurprising since running i2cdetect on the I2C4 bus shows that there is no GPIO expander chip present on these devices at all. This commit adds a PCI subsystem vendor:device table listing PCI devices where it is known to be safe to ignore resource conflicts with ACPI declared SystemMemory regions. This makes the I2C4 bus work out of the box on the Microsoft Surface Go & Go 2, which is necessary for the cameras on these devices to work. Signed-off-by: Hans de Goede Reviewed-by: Laurent Pinchart Reviewed-by: Andy Shevchenko Acked-by: Mika Westerberg Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20211203115108.89661-1-hdegoede@redhat.com

platform/x86/intel: Move intel_pmt from MFD to Auxiliary Bus

2021-12-22T12:56:19Z

Intel Platform Monitoring Technology (PMT) support is indicated by presence of an Intel defined PCIe Designated Vendor Specific Extended Capabilities (DVSEC) structure with a PMT specific ID. The current MFD implementation creates child devices for each PMT feature, currently telemetry, watcher, and crashlog. However DVSEC structures may also be used by Intel to indicate support for other features. The Out Of Band Management Services Module (OOBMSM) uses DVSEC to enumerate several features, including PMT. In order to support them it is necessary to modify the intel_pmt driver to handle the creation of the child devices more generically. To that end, modify the driver to create child devices for any VSEC/DVSEC features on supported devices (indicated by PCI ID). Additionally, move the implementation from MFD to the Auxiliary bus. VSEC/DVSEC features are really multifunctional PCI devices, not platform devices as MFD was designed for. Auxiliary bus gives more flexibility by allowing the definition of custom structures that can be shared between associated auxiliary devices and the parent device. Also, rename the driver from intel_pmt to intel_vsec to better reflect the purpose. This series also removes the current runtime pm support which was not complete to begin with. None of the current devices require runtime pm. However the support will be replaced when a device is added that requires it. Reviewed-by: Mark Gross Acked-by: Hans de Goede Signed-off-by: David E. Box Link: https://lore.kernel.org/r/20211208015015.891275-4-david.e.box@linux.intel.com Signed-off-by: Greg Kroah-Hartman

mfd: Kconfig: Change INTEL_SOC_PMIC_CHTDC_TI to bool

2021-11-29T15:12:46Z

The INTEL_SOC_PMIC_CHTDC_TI should be initialized early, before loading the fbcon driver, as otherwise the i915 driver will fail to configure pwm: [ 13.674287] fb0: switching to inteldrmfb from EFI VGA [ 13.682380] Console: switching to colour dummy device 80x25 [ 13.682468] i915 0000:00:02.0: vgaarb: deactivate vga console [ 13.682686] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 13.685773] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 13.686219] i915 0000:00:02.0: [drm] *ERROR* Failed to configure the pwm chip [ 13.699572] [drm] Initialized i915 1.6.0 20200313 for 0000:00:02.0 on minor 0 [ 13.739044] fbcon: i915drmfb (fb0) is primary device [ 14.037792] intel_soc_pmic_exec_mipi_pmic_seq_element: No PMIC registered ... [ 24.621403] intel_pmic_install_opregion_handler: Ask to register OpRegion for bus ID=PMI2, HID=INT33F5 [ 24.630540] intel_pmic_install_opregion_handler: OpRegion registered (some extra debug printk's were added to the above) As suggested by Hans, this patch also addresses an issue with the dependencies, as, for this driver to be a bool, it also need the I2C core and the I2C_DESIGNWARE driver to be builtin. Suggested-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans de Goede Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/86f546b3233fd799b0c39b83afc521440ebfe004.1638192232.git.mchehab+huawei@kernel.org

mfd: da9062: Support SMBus and I2C mode

2021-11-29T13:17:00Z

Enable the I2C bus mode if I2C_FUNC_I2C is set. Based on da6093 commit: "586478bfc9f7 mfd: da9063: Support SMBus and I2C mode" Signed-off-by: Andrej Picej Reviewed-by: Adam Thomson Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20211124065119.2514872-1-andrej.picej@norik.com

mfd: intel-lpss-pci: Fix clock speed for 38a8 UART

2021-11-29T13:17:00Z

This device is found in the MacBookPro16,2, and as the MacBookPro16,1 is from the same generation of MacBooks and has a UART with bxt_uart_info, it was incorrectly assumed that the MacBookPro16,2's UART would have the same info. This led to the wrong clock speed being used, and the Bluetooth controller exposed by the UART receiving and sending random data, which was incorrectly assumed to be an issue with the Bluetooth stuff, not an error with the UART side of things. Changing the info to spt_uart_info changes the clock speed and makes it send and receive data correctly. Fixes: ddb1ada416fd ("mfd: intel-lpss: Add support for MacBookPro16,2 ICL-N UART") Signed-off-by: Orlando Chamberlain Reviewed-by: Andy Shevchenko Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20211124091846.11114-1-redecorating@protonmail.com

mfd: intel-lpss: Fix too early PM enablement in the ACPI ->probe()

2021-11-29T13:17:00Z

The runtime PM callback may be called as soon as the runtime PM facility is enabled and activated. It means that ->suspend() may be called before we finish probing the device in the ACPI case. Hence, NULL pointer dereference: intel-lpss INT34BA:00: IRQ index 0 not found BUG: kernel NULL pointer dereference, address: 0000000000000030 ... Workqueue: pm pm_runtime_work RIP: 0010:intel_lpss_suspend+0xb/0x40 [intel_lpss] To fix this, first try to register the device and only after that enable runtime PM facility. Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS devices") Reported-by: Orlando Chamberlain Reported-by: Aditya Garg Signed-off-by: Andy Shevchenko Tested-by: Aditya Garg Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20211101190008.86473-1-andriy.shevchenko@linux.intel.com

mfd: stmpe: Support disabling sub-functions

2021-11-29T13:17:00Z

Add support of sub-functions disabling. It allows one to define an stmpe sub-function device in devicetree, but keep it disabled. Signed-off-by: Oleksandr Suvorov Signed-off-by: Francesco Dolcini Reviewed-by: Linus Walleij Reviewed-by: Marcel Ziswiler Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20211027082155.206449-1-francesco.dolcini@toradex.com