<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/mfd, branch v3.16.35</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>mfd: twl6040: Fix deferred probe handling for clk32k</title>
<updated>2015-12-13T17:49:39+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2015-09-18T16:29:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f66ca031516d012303f28bac8fbc3ccd75ff7616'/>
<id>f66ca031516d012303f28bac8fbc3ccd75ff7616</id>
<content type='text'>
commit 75c08f17ec87c2d742487bb87408d6feebc526bd upstream.

Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
added clock handling for the 32k clock from palmas-clk. However, that
patch did not consider a typical situation where twl6040 is built-in,
and palmas-clk is a loadable module like we have in omap2plus_defconfig.

If palmas-clk is not loaded before twl6040 probes, we will get a
"clk32k is not handled" warning during booting. This means that any
drivers relying on this clock will mysteriously fail, including
omap5-uevm WLAN and audio.

Note that for WLAN, we probably should also eventually get
the clk32kgaudio for MMC3 directly as that's shared between
audio and WLAN SDIO at least for omap5-uevm. It seems the
WLAN chip cannot get it as otherwise MMC3 won't get properly
probed.

Fixes: 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Reviewed-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 75c08f17ec87c2d742487bb87408d6feebc526bd upstream.

Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
added clock handling for the 32k clock from palmas-clk. However, that
patch did not consider a typical situation where twl6040 is built-in,
and palmas-clk is a loadable module like we have in omap2plus_defconfig.

If palmas-clk is not loaded before twl6040 probes, we will get a
"clk32k is not handled" warning during booting. This means that any
drivers relying on this clock will mysteriously fail, including
omap5-uevm WLAN and audio.

Note that for WLAN, we probably should also eventually get
the clk32kgaudio for MMC3 directly as that's shared between
audio and WLAN SDIO at least for omap5-uevm. It seems the
WLAN chip cannot get it as otherwise MMC3 won't get properly
probed.

Fixes: 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Reviewed-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mfd: arizona: Fix initialisation of the PM runtime</title>
<updated>2015-08-31T13:14:06+00:00</updated>
<author>
<name>Charles Keepax</name>
<email>ckeepax@opensource.wolfsonmicro.com</email>
</author>
<published>2015-06-14T14:41:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6c3505ca3663a5ff114d0db6778f979560ae65f9'/>
<id>6c3505ca3663a5ff114d0db6778f979560ae65f9</id>
<content type='text'>
commit 72e43164fd472f6c2659c8313b87da962322dbcf upstream.

The PM runtime core by default assumes a chip is suspended when runtime
PM is enabled. Currently the arizona driver enables runtime PM when the
chip is fully active and then disables the DCVDD regulator at the end of
arizona_dev_init. This however has several problems, firstly the if we
reach the end of arizona_dev_init, we did not properly follow all the
proceedures for shutting down the chip, and most notably we never marked
the chip as cache only so any writes occurring between then and the next
PM runtime resume will be lost. Secondly, if we are already resumed when
we reach the end of dev_init, then at best we get unbalanced regulator
enable/disables at work we lose DCVDD whilst we need it.

Additionally, since the commit 4f0216409f7c ("mfd: arizona: Add better
support for system suspend"), the PM runtime operations may
disable/enable the IRQ, so the IRQs must now be enabled before we call
any PM operations.

This patch adds a call to pm_runtime_set_active to inform the PM core
that the device is starting up active and moves the PM enabling to
around the IRQ initialisation to avoid any PM callbacks happening until
the IRQs are initialised.

Signed-off-by: Charles Keepax &lt;ckeepax@opensource.wolfsonmicro.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 72e43164fd472f6c2659c8313b87da962322dbcf upstream.

The PM runtime core by default assumes a chip is suspended when runtime
PM is enabled. Currently the arizona driver enables runtime PM when the
chip is fully active and then disables the DCVDD regulator at the end of
arizona_dev_init. This however has several problems, firstly the if we
reach the end of arizona_dev_init, we did not properly follow all the
proceedures for shutting down the chip, and most notably we never marked
the chip as cache only so any writes occurring between then and the next
PM runtime resume will be lost. Secondly, if we are already resumed when
we reach the end of dev_init, then at best we get unbalanced regulator
enable/disables at work we lose DCVDD whilst we need it.

Additionally, since the commit 4f0216409f7c ("mfd: arizona: Add better
support for system suspend"), the PM runtime operations may
disable/enable the IRQ, so the IRQs must now be enabled before we call
any PM operations.

This patch adds a call to pm_runtime_set_active to inform the PM core
that the device is starting up active and moves the PM enabling to
around the IRQ initialisation to avoid any PM callbacks happening until
the IRQs are initialised.

Signed-off-by: Charles Keepax &lt;ckeepax@opensource.wolfsonmicro.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mfd: kempld-core: Fix callback return value check</title>
<updated>2015-04-10T09:03:55+00:00</updated>
<author>
<name>Ameya Palande</name>
<email>2ameya@gmail.com</email>
</author>
<published>2015-02-26T20:05:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a58c7438e2e36750088dc53c912e69a99e4b9444'/>
<id>a58c7438e2e36750088dc53c912e69a99e4b9444</id>
<content type='text'>
commit c8648508ebfc597058d2cd00b6c539110264a167 upstream.

On success, callback function returns 0. So invert the if condition
check so that we can break out of loop.

Signed-off-by: Ameya Palande &lt;2ameya@gmail.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c8648508ebfc597058d2cd00b6c539110264a167 upstream.

On success, callback function returns 0. So invert the if condition
check so that we can break out of loop.

Signed-off-by: Ameya Palande &lt;2ameya@gmail.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mfd: rtsx_usb: Fix runtime PM deadlock</title>
<updated>2015-02-04T10:57:40+00:00</updated>
<author>
<name>Roger Tseng</name>
<email>rogerable@realtek.com</email>
</author>
<published>2015-01-15T07:14:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7be4681a36ad1031af068082d8271a70ec2f4d68'/>
<id>7be4681a36ad1031af068082d8271a70ec2f4d68</id>
<content type='text'>
commit b166010f6afbadb896efa37ff85eb681a8f89392 upstream.

sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c
acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the
device is awake while initializing a newly inserted card. Once it is
called during suspending state and explicitly before rtsx_usb_suspend()
acquires the same dev_mutex, both routine deadlock and further hang the
driver because pm_runtime_get_sync() waits the pending PM operations.

Fix this by using an empty suspend method. mmc_core always turns the
LED off after a request is done and thus it is ok to remove the only
rtsx_usb_turn_off_led() here.

Fixes: 730876be2566 ("mfd: Add realtek USB card reader driver")
Signed-off-by: Roger Tseng &lt;rogerable@realtek.com&gt;
[Lee: Removed newly unused variable]
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b166010f6afbadb896efa37ff85eb681a8f89392 upstream.

sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c
acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the
device is awake while initializing a newly inserted card. Once it is
called during suspending state and explicitly before rtsx_usb_suspend()
acquires the same dev_mutex, both routine deadlock and further hang the
driver because pm_runtime_get_sync() waits the pending PM operations.

Fix this by using an empty suspend method. mmc_core always turns the
LED off after a request is done and thus it is ok to remove the only
rtsx_usb_turn_off_led() here.

Fixes: 730876be2566 ("mfd: Add realtek USB card reader driver")
Signed-off-by: Roger Tseng &lt;rogerable@realtek.com&gt;
[Lee: Removed newly unused variable]
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mfd: tps65218: Make INT1 our status_base register</title>
<updated>2015-02-04T10:57:39+00:00</updated>
<author>
<name>Felipe Balbi</name>
<email>balbi@ti.com</email>
</author>
<published>2014-12-26T19:28:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1b57755afc46a6e81ba057805858758dbbb43ae1'/>
<id>1b57755afc46a6e81ba057805858758dbbb43ae1</id>
<content type='text'>
commit f29ae369a412942e81035984fa3d7a22ddf91fcb upstream.

If we don't tell regmap-irq that our first status
register is at offset 1, it will try to read offset
zero, which is the chipid register.

Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Signed-off-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f29ae369a412942e81035984fa3d7a22ddf91fcb upstream.

If we don't tell regmap-irq that our first status
register is at offset 1, it will try to read offset
zero, which is the chipid register.

Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Signed-off-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mfd: tps65218: Make INT[12] and STATUS registers volatile</title>
<updated>2015-02-04T10:57:38+00:00</updated>
<author>
<name>Felipe Balbi</name>
<email>balbi@ti.com</email>
</author>
<published>2014-12-26T19:28:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8031de2a18e4d1ed3ef430aa9166822dbabf2b89'/>
<id>8031de2a18e4d1ed3ef430aa9166822dbabf2b89</id>
<content type='text'>
commit 773328da243978bebac82bf4c45604281edb6975 upstream.

STATUS register can be modified by the HW, so we
should bypass cache because of that.

In the case of INT[12] registers, they are the ones
that actually clear the IRQ source at the time they
are read. If we rely on the cache for them, we will
never be able to clear the interrupt, which will cause
our IRQ line to be disabled due to IRQ throttling.

Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Signed-off-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 773328da243978bebac82bf4c45604281edb6975 upstream.

STATUS register can be modified by the HW, so we
should bypass cache because of that.

In the case of INT[12] registers, they are the ones
that actually clear the IRQ source at the time they
are read. If we rely on the cache for them, we will
never be able to clear the interrupt, which will cause
our IRQ line to be disabled due to IRQ throttling.

Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Signed-off-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mfd: tc6393xb: Fail ohci suspend if full state restore is required</title>
<updated>2015-01-12T15:44:02+00:00</updated>
<author>
<name>Dmitry Eremin-Solenikov</name>
<email>dbaryshkov@gmail.com</email>
</author>
<published>2014-10-24T17:19:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=516c962b63c44010521c86ba8caccf3f95e0356c'/>
<id>516c962b63c44010521c86ba8caccf3f95e0356c</id>
<content type='text'>
commit 1a5fb99de4850cba710d91becfa2c65653048589 upstream.

Some boards with TC6393XB chip require full state restore during system
resume thanks to chip's VCC being cut off during suspend (Sharp SL-6000
tosa is one of them). Failing to do so would result in ohci Oops on
resume due to internal memory contentes being changed. Fail ohci suspend
on tc6393xb is full state restore is required.

Recommended workaround is to unbind tmio-ohci driver before suspend and
rebind it after resume.

Signed-off-by: Dmitry Eremin-Solenikov &lt;dbaryshkov@gmail.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1a5fb99de4850cba710d91becfa2c65653048589 upstream.

Some boards with TC6393XB chip require full state restore during system
resume thanks to chip's VCC being cut off during suspend (Sharp SL-6000
tosa is one of them). Failing to do so would result in ohci Oops on
resume due to internal memory contentes being changed. Fail ohci suspend
on tc6393xb is full state restore is required.

Recommended workaround is to unbind tmio-ohci driver before suspend and
rebind it after resume.

Signed-off-by: Dmitry Eremin-Solenikov &lt;dbaryshkov@gmail.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mfd: twl4030-power: Fix regression with missing compatible flag</title>
<updated>2015-01-12T15:44:01+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2014-11-02T18:09:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=548247a08a4128188da776028e226a135a4d9039'/>
<id>548247a08a4128188da776028e226a135a4d9039</id>
<content type='text'>
commit 1b9b46d05f887aec418b3a5f4f55abf79316fcda upstream.

Commit e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset
configuration") accidentally removed the compatible flag for
"ti,twl4030-power" that should be there as documented in the
binding.

If "ti,twl4030-power" only the poweroff configuration is done
by the driver.

Fixes: e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset configuration")
Reported-by: "Dr. H. Nikolaus Schaller" &lt;hns@goldelico.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1b9b46d05f887aec418b3a5f4f55abf79316fcda upstream.

Commit e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset
configuration") accidentally removed the compatible flag for
"ti,twl4030-power" that should be there as documented in the
binding.

If "ti,twl4030-power" only the poweroff configuration is done
by the driver.

Fixes: e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset configuration")
Reported-by: "Dr. H. Nikolaus Schaller" &lt;hns@goldelico.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mfd: twl4030-power: Fix poweroff with PM configuration enabled</title>
<updated>2014-11-27T11:21:40+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2014-11-02T18:07:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1438d8cf802ff49785b0165312c82645f002ad14'/>
<id>1438d8cf802ff49785b0165312c82645f002ad14</id>
<content type='text'>
commit 481c7f868c6d855f31a29c69b445ac4aee9625a6 upstream.

Commit e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset
configuration") enabled configuring the PM features for twl4030.

This caused poweroff command to fail on devices that have the
BCI charger on twl4030 wired, or have power wired for VBUS.
Instead of powering off, the device reboots. This is because
voltage is detected on charger or VBUS with the default bits
enabled for the power transition registers.

To fix the issue, let's just clear VBUS and CHG bits as we want
poweroff command to keep the system powered off.

Fixes: e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset configuration")
Reported-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 481c7f868c6d855f31a29c69b445ac4aee9625a6 upstream.

Commit e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset
configuration") enabled configuring the PM features for twl4030.

This caused poweroff command to fail on devices that have the
BCI charger on twl4030 wired, or have power wired for VBUS.
Instead of powering off, the device reboots. This is because
voltage is detected on charger or VBUS with the default bits
enabled for the power transition registers.

To fix the issue, let's just clear VBUS and CHG bits as we want
poweroff command to keep the system powered off.

Fixes: e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset configuration")
Reported-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mfd: rtsx_pcr: Fix MSI enable error handling</title>
<updated>2014-11-17T14:11:40+00:00</updated>
<author>
<name>Chris Ball</name>
<email>chris@printf.net</email>
</author>
<published>2014-09-04T16:11:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2192ea7dd7d80127c1e92750ba2b8c14e7d05c0a'/>
<id>2192ea7dd7d80127c1e92750ba2b8c14e7d05c0a</id>
<content type='text'>
commit 5152970538a5e16c03bbcb9f1c780489a795ed40 upstream.

pci_enable_msi() can return failure with both positive and negative
integers -- it returns 0 for success -- but is only tested here for
"if (ret &lt; 0)".  This causes us to try to use MSI on the RTS5249 SD
reader in the Dell XPS 11 when enabling MSI failed, causing:

[    1.737110] rtsx_pci: probe of 0000:05:00.0 failed with error -110

Reported-by: D. Jared Dominguez &lt;Jared_Dominguez@Dell.com&gt;
Tested-by: D. Jared Dominguez &lt;Jared_Dominguez@Dell.com&gt;
Signed-off-by: Chris Ball &lt;chris@printf.net&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5152970538a5e16c03bbcb9f1c780489a795ed40 upstream.

pci_enable_msi() can return failure with both positive and negative
integers -- it returns 0 for success -- but is only tested here for
"if (ret &lt; 0)".  This causes us to try to use MSI on the RTS5249 SD
reader in the Dell XPS 11 when enabling MSI failed, causing:

[    1.737110] rtsx_pci: probe of 0000:05:00.0 failed with error -110

Reported-by: D. Jared Dominguez &lt;Jared_Dominguez@Dell.com&gt;
Tested-by: D. Jared Dominguez &lt;Jared_Dominguez@Dell.com&gt;
Signed-off-by: Chris Ball &lt;chris@printf.net&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
