linux-stable.git/drivers/mfd, branch v5.4.166

mfd: tqmx86: Clear GPIO IRQ resource when no IRQ is set

2021-09-22T10:26:44+00:00

[ Upstream commit a946506c48f3bd09363c9d2b0a178e55733bcbb6 ]

The driver was registering IRQ 0 when no IRQ was set. This leads to
warnings with newer kernels.

Clear the resource flags, so no resource is registered at all in this
case.

Fixes: 2f17dd34ffed ("mfd: tqmx86: IO controller with I2C, Wachdog and GPIO")
Signed-off-by: Matthias Schiffer 
Reviewed-by: Andrew Lunn 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: axp20x: Update AXP288 volatile ranges

2021-09-22T10:26:44+00:00

[ Upstream commit f949a9ebce7a18005266b859a17f10c891bb13d7 ]

On Cherry Trail devices with an AXP288 PMIC the external SD-card slot
used the AXP's DLDO2 as card-voltage and either DLDO3 or GPIO1LDO
(GPIO1 pin in low noise LDO mode) as signal-voltage.

These regulators are turned on/off and in case of the signal-voltage
also have their output-voltage changed by the _PS0 and _PS3 power-
management ACPI methods on the MMC-controllers ACPI fwnode as well as
by the _DSM ACPI method for changing the signal voltage.

The AML code implementing these methods is directly accessing the
PMIC through ACPI I2C OpRegion accesses, instead of using the special
PMIC OpRegion handled by drivers/acpi/pmic/intel_pmic_xpower.c .

This means that the contents of the involved PMIC registers can change
without the change being made through the regmap interface, so regmap
should not cache the contents of these registers.

Mark the regulator power on/off, the regulator voltage control and the
GPIO1 control registers as volatile, to avoid regmap caching them.

Specifically this fixes an issue on some models where the i915 driver
toggles another LDO using the same on/off register on/off through
MIPI sequences (through intel_soc_pmic_exec_mipi_pmic_seq_element())
which then writes back a cached on/off register-value where the
card-voltage is off causing the external sdcard slot to stop working
when the screen goes blank, or comes back on again.

The regulator register-range now marked volatile also includes the
buck regulator control registers. This is done on purpose these are
normally not touched by the AML code, but they are updated directly
by the SoC's PUNIT which means that they may also change without going
through regmap.

Note the AXP288 PMIC is only used on Bay- and Cherry-Trail platforms,
so even though this is an ACPI specific problem there is no need to
make the new volatile ranges conditional since these platforms always
use ACPI.

Fixes: dc91c3b6fe66 ("mfd: axp20x: Mark AXP20X_VBUS_IPSOUT_MGMT as volatile")
Fixes: cd53216625a0 ("mfd: axp20x: Fix axp288 volatile ranges")
Reported-and-tested-by: Clamshell 
Signed-off-by: Hans de Goede 
Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: Don't use irq_create_mapping() to resolve a mapping

2021-09-22T10:26:43+00:00

[ Upstream commit 9ff80e2de36d0554e3a6da18a171719fe8663c17 ]

Although irq_create_mapping() is able to deal with duplicate
mappings, it really isn't supposed to be a substitute for
irq_find_mapping(), and can result in allocations that take place
in atomic context if the mapping didn't exist.

Fix the handful of MFD drivers that use irq_create_mapping() in
interrupt context by using irq_find_mapping() instead.

Cc: Linus Walleij 
Cc: Lee Jones 
Cc: Maxime Coquelin 
Cc: Alexandre Torgue 
Signed-off-by: Marc Zyngier 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: db8500-prcmu: Adjust map to reality

2021-09-22T10:26:43+00:00

[ Upstream commit ec343111c056ec3847800302f6dbc57281f833fa ]

These are the actual frequencies reported by the PLL, so let's
report these. The roundoffs are inappropriate, we should round
to the frequency that the clock will later report.

Drop some whitespace at the same time.

Cc: phone-devel@vger.kernel.org
Signed-off-by: Linus Walleij 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: cpcap: Fix cpcap dmamask not set warnings

2021-07-20T14:10:43+00:00

[ Upstream commit 0b7cbe811ca524295ea43d9a4d73d3427e419c54 ]

We have started to get a bunch of pointless dmamask not set warnings
that makes the output of dmesg -l err,warn hard to read with many
extra warnings:

cpcap-regulator cpcap-regulator.0: DMA mask not set
cpcap_adc cpcap_adc.0: DMA mask not set
cpcap_battery cpcap_battery.0: DMA mask not set
cpcap-charger cpcap-charger.0: DMA mask not set
cpcap-pwrbutton cpcap-pwrbutton.0: DMA mask not set
cpcap-led cpcap-led.0: DMA mask not set
cpcap-led cpcap-led.1: DMA mask not set
cpcap-led cpcap-led.2: DMA mask not set
cpcap-led cpcap-led.3: DMA mask not set
cpcap-led cpcap-led.4: DMA mask not set
cpcap-rtc cpcap-rtc.0: DMA mask not set
cpcap-usb-phy cpcap-usb-phy.0: DMA mask not set

This seems to have started with commit 4d8bde883bfb ("OF: Don't set
default coherent DMA mask"). We have the parent SPI controller use
DMA, while CPCAP driver and it's children do not. For audio, the
DMA is handled over I2S bus with the McBSP driver.

Cc: Carl Philipp Klemm 
Cc: Ivan Jelincic 
Cc: Merlijn Wajer 
Cc: Pavel Machek 
Cc: Sebastian Reichel 
Cc: Sicelo A. Mhlongo 
Signed-off-by: Tony Lindgren 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: da9052/stmpe: Add and modify MODULE_DEVICE_TABLE

2021-07-20T14:10:43+00:00

[ Upstream commit 4700ef326556ed74aba188f12396740a8c1c21dd ]

This patch adds/modifies MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.

Reported-by: Hulk Robot 
Signed-off-by: Zou Wei 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: stm32-timers: Avoid clearing auto reload register

2021-05-14T07:44:25+00:00

[ Upstream commit 4917e498c6894ba077867aff78f82cffd5ffbb5c ]

The ARR register is cleared unconditionally upon probing, after the maximum
value has been read. This initial condition is rather not intuitive, when
considering the counter child driver. It rather expects the maximum value
by default:
- The counter interface shows a zero value by default for 'ceiling'
  attribute.
- Enabling the counter without any prior configuration makes it doesn't
  count.

The reset value of ARR register is the maximum. So Choice here
is to backup it, and restore it then, instead of clearing its value.
It also fixes the initial condition seen by the counter driver.

Fixes: d0f949e220fd ("mfd: Add STM32 Timers driver")
Signed-off-by: Fabrice Gasnier 
Acked-by: William Breathitt Gray 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: arizona: Fix rumtime PM imbalance on error

2021-05-11T12:04:12+00:00

[ Upstream commit fe6df2b48043bbe1e852b2320501d3b169363c35 ]

pm_runtime_get_sync() will increase the rumtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.

Signed-off-by: Dinghao Liu 
Acked-by: Charles Keepax 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: wm831x-auxadc: Prevent use after free in wm831x_auxadc_read_irq()

2021-03-04T09:26:33+00:00

[ Upstream commit 26783d74cc6a440ee3ef9836a008a697981013d0 ]

The "req" struct is always added to the "wm831x->auxadc_pending" list,
but it's only removed from the list on the success path.  If a failure
occurs then the "req" struct is freed but it's still on the list,
leading to a use after free.

Fixes: 78bb3688ea18 ("mfd: Support multiple active WM831x AUXADC conversions")
Signed-off-by: Dan Carpenter 
Acked-by: Charles Keepax 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: bd9571mwv: Use devm_mfd_add_devices()

2021-03-04T09:26:28+00:00

[ Upstream commit c58ad0f2b052b5675d6394e03713ee41e721b44c ]

To remove mfd devices when unload this driver, should use
devm_mfd_add_devices() instead.

Fixes: d3ea21272094 ("mfd: Add ROHM BD9571MWV-M MFD PMIC driver")
Signed-off-by: Yoshihiro Shimoda 
Acked-for-MFD-by: Lee Jones 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Matti Vaittinen 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin