linux-stable.git/drivers/mfd, branch v4.14.166

mfd: max8997: Enale irq-wakeup unconditionally

2019-12-01T08:13:46+00:00

[ Upstream commit efddff27c886e729a7f84a7205bd84d7d4af7336 ]

IRQ wake up support for MAX8997 driver was initially configured by
respective property in pdata. However, after the driver conversion to
device-tree, setting it was left as 'todo'. Nowadays most of other PMIC MFD
drivers initialized from device-tree assume that they can be an irq wakeup
source, so enable it also for MAX8997. This fixes support for wakeup from
MAX8997 RTC alarm.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: intel_soc_pmic_bxtwc: Chain power button IRQs as well

2019-12-01T08:13:45+00:00

[ Upstream commit 9f8ddee1dab836ca758ca8fc555ab5a3aaa5d3fd ]

Power button IRQ actually has a second level of interrupts to
distinguish between UI and POWER buttons. Moreover, current
implementation looks awkward in approach to handle second level IRQs by
first level related IRQ chip.

To address above issues, split power button IRQ to be chained as well.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Mika Westerberg 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: mc13xxx-core: Fix PMIC shutdown when reading ADC values

2019-12-01T08:13:45+00:00

[ Upstream commit 55143439b7b501882bea9d95a54adfe00ffc79a3 ]

When trying to read any MC13892 ADC channel on a imx51-babbage board:

The MC13892 PMIC shutdowns completely.

After debugging this issue and comparing the MC13892 and MC13783
initializations done in the vendor kernel, it was noticed that the
CHRGRAWDIV bit of the ADC0 register was not being set.

This bit is set by default after power on, but the driver was
clearing it.

After setting this bit it is possible to read the ADC values correctly.

Signed-off-by: Fabio Estevam 
Tested-by: Chris Healy 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: arizona: Correct calling of runtime_put_sync

2019-12-01T08:13:45+00:00

[ Upstream commit 6b269a41a4520f7eb639e61a45ebbb9c9267d5e0 ]

Don't call runtime_put_sync when clk32k_ref is ARIZONA_32KZ_MCLK2
as there is no corresponding runtime_get_sync call.

MCLK1 is not in the AoD power domain so if it is used as 32kHz clock
source we need to hold a runtime PM reference to keep the device from
going into low power mode.

Fixes: cdd8da8cc66b ("mfd: arizona: Add gating of external MCLKn clocks")
Signed-off-by: Sapthagiri Baratam 
Acked-by: Charles Keepax 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: ti_am335x_tscadc: Keep ADC interface on if child is wakeup capable

2019-11-24T07:23:24+00:00

[ Upstream commit c974ac771479327b5424f60d58845e31daddadea ]

If a child device like touchscreen is wakeup capable, then keep ADC
interface on, so that a touching resistive screen will generate wakeup
event to the system.

Signed-off-by: Vignesh R 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: palmas: Assign the right powerhold mask for tps65917

2019-11-12T18:18:19+00:00

commit 572ff4d560be3784205b224cd67d6715620092d7 upstream

The powerhold mask for TPS65917 is different when comapred to
the other palmas versions. Hence assign the right mask that enables
power off of tps65917 pmic correctly.

Signed-off-by: Keerthy 
Signed-off-by: Lee Jones 
Signed-off-by: Mathieu Poirier 
Signed-off-by: Greg Kroah-Hartman

mfd: intel-lpss: Remove D3cold delay

2019-10-07T16:55:08+00:00

[ Upstream commit 76380a607ba0b28627c9b4b55cd47a079a59624b ]

Goodix touchpad may drop its first couple input events when
i2c-designware-platdrv and intel-lpss it connects to took too long to
runtime resume from runtime suspended state.

This issue happens becuase the touchpad has a rather small buffer to
store up to 13 input events, so if the host doesn't read those events in
time (i.e. runtime resume takes too long), events are dropped from the
touchpad's buffer.

The bottleneck is D3cold delay it waits when transitioning from D3cold
to D0, hence remove the delay to make the resume faster. I've tested
some systems with intel-lpss and haven't seen any regression.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202683
Signed-off-by: Kai-Heng Feng 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: hi655x-pmic: Fix missing return value check for devm_regmap_init_mmio_clk

2019-07-31T05:28:53+00:00

[ Upstream commit 7efd105c27fd2323789b41b64763a0e33ed79c08 ]

Since devm_regmap_init_mmio_clk can fail, add return value checking.

Signed-off-by: Axel Lin 
Acked-by: Chen Feng 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: arizona: Fix undefined behavior

2019-07-31T05:28:53+00:00

[ Upstream commit 5da6cbcd2f395981aa9bfc571ace99f1c786c985 ]

When the driver is used with a subdevice that is disabled in the
kernel configuration, clang gets a little confused about the
control flow and fails to notice that n_subdevs is only
uninitialized when subdevs is NULL, and we check for that,
leading to a false-positive warning:

drivers/mfd/arizona-core.c:1423:19: error: variable 'n_subdevs' is uninitialized when used here
      [-Werror,-Wuninitialized]
                              subdevs, n_subdevs, NULL, 0, NULL);
                                       ^~~~~~~~~
drivers/mfd/arizona-core.c:999:15: note: initialize the variable 'n_subdevs' to silence this warning
        int n_subdevs, ret, i;
                     ^
                      = 0

Ideally, we would rearrange the code to avoid all those early
initializations and have an explicit exit in each disabled case,
but it's much easier to chicken out and add one more initialization
here to shut up the warning.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Nathan Chancellor 
Signed-off-by: Charles Keepax 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

mfd: core: Set fwnode for created devices

2019-07-31T05:28:53+00:00

[ Upstream commit c176c6d7e932662668bcaec2d763657096589d85 ]

The logic for setting the of_node on devices created by mfd did not set
the fwnode pointer to match, which caused fwnode-based APIs to
malfunction on these devices since the fwnode pointer was null. Fix
this.

Signed-off-by: Robert Hancock 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin