kernel_replicant_linux/drivers/mfd, branch replicant-11

mfd: lpc_sch: Rename GPIOBASE to prevent build error

2021-09-22T10:28:06+00:00

[ Upstream commit cdff1eda69326fb46de10c5454212b3efcf4bb41 ]

One MIPS platform (mach-rc32434) defines GPIOBASE. This macro
conflicts with one of the same name in lpc_sch.c. Rename the latter one
to prevent the build error.

../drivers/mfd/lpc_sch.c:25: error: "GPIOBASE" redefined [-Werror]
   25 | #define GPIOBASE        0x44
../arch/mips/include/asm/mach-rc32434/rb.h:32: note: this is the location of the previous definition
   32 | #define GPIOBASE        0x050000

Cc: Denis Turischev 
Fixes: e82c60ae7d3a ("mfd: Introduce lpc_sch for Intel SCH LPC bridge")
Signed-off-by: Randy Dunlap 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: lpc_sch: Partially revert "Add support for Intel Quark X1000"

2021-09-22T10:28:06+00:00

[ Upstream commit 922e8ce883e59b52786b2c11656d84dc58ef084a ]

The IRQ support for SCH GPIO is not specific to the Intel Quark SoC.
Moreover the IRQ routing is quite interesting there, so while it's
needs a special support, the driver haven't it anyway yet.

Due to above remove basically redundant code of IRQ support.

This reverts commit ec689a8a8155ce8b966bd5d7737a3916f5e48be3.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

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

2021-09-22T10:28:03+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:28:02+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:28:00+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:28:00+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:05:42+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:05:41+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: syscon: Free the allocated name field of struct regmap_config

2021-07-19T07:45:00+00:00

commit 56a1188159cb2b87fbcb5a7a7afb38a4dd9db0c1 upstream.

The commit 529a1101212a("mfd: syscon: Don't free allocated name
for regmap_config") doesn't free the allocated name field of struct
regmap_config, but introduce a memory leak. There is another
commit 94cc89eb8fa5("regmap: debugfs: Fix handling of name string
for debugfs init delays") fixing this debugfs init issue from root
cause. With this fixing, the name field in struct regmap_debugfs_node
is removed. When initialize debugfs for syscon driver, the name
field of struct regmap_config is not used anymore. So, the allocated
name field of struct regmap_config is need to be freed directly after
regmap initialization to avoid memory leak.

Cc: stable@vger.kernel.org
Fixes: 529a1101212a("mfd: syscon: Don't free allocated name for regmap_config")
Signed-off-by: Meng Li 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

mfd: rn5t618: Fix IRQ trigger by changing it to level mode

2021-07-14T14:56:40+00:00

[ Upstream commit a1649a5260631979c68e5b2012f60f90300e646f ]

During more massive generation of interrupts, the IRQ got stuck,
and the subdevices did not see any new interrupts. That happens
especially at wonky USB supply in combination with ADC reads.
To fix that trigger the IRQ at level low instead of falling edge.

Fixes: 0c81604516af ("mfd: rn5t618: Add IRQ support")
Signed-off-by: Andreas Kemnade 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin