<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/mmc/core, branch linux-4.1.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>mmc: avoid removing non-removable hosts during suspend</title>
<updated>2018-05-23T01:33:51+00:00</updated>
<author>
<name>Daniel Drake</name>
<email>drake@endlessm.com</email>
</author>
<published>2017-12-12T10:49:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a51ecf1a0b5636366c4a5b9d37b71cee2537d2cb'/>
<id>a51ecf1a0b5636366c4a5b9d37b71cee2537d2cb</id>
<content type='text'>
[ Upstream commit de8dcc3d2c0e08e5068ee1e26fc46415c15e3637 ]

The Weibu F3C MiniPC has an onboard AP6255 module, presenting
two SDIO functions on a single MMC host (Bluetooth/btsdio and
WiFi/brcmfmac), and the mmc layer correctly detects this as
non-removable.

After suspend/resume, the wifi and bluetooth interfaces disappear
and do not get probed again.

The conditions here are:

 1. During suspend, we reach mmc_pm_notify()

 2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can
    suspend the SDIO host. However, mmc_sdio_pre_suspend() returns
    -ENOSYS because btsdio_driver does not have a suspend method.

 3. mmc_pm_notify() proceeds to remove the card

 4. Upon resume, mmc_rescan() does nothing with this host, because of
    the rescan_entered check which aims to only scan a non-removable
    device a single time (i.e. during boot).

Fix the loss of functionality by detecting that we are unable to
suspend a non-removable host, so avoid the forced removal in that
case. The comment above this function already indicates that this
code was only intended for removable devices.

Signed-off-by: Daniel Drake &lt;drake@endlessm.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit de8dcc3d2c0e08e5068ee1e26fc46415c15e3637 ]

The Weibu F3C MiniPC has an onboard AP6255 module, presenting
two SDIO functions on a single MMC host (Bluetooth/btsdio and
WiFi/brcmfmac), and the mmc layer correctly detects this as
non-removable.

After suspend/resume, the wifi and bluetooth interfaces disappear
and do not get probed again.

The conditions here are:

 1. During suspend, we reach mmc_pm_notify()

 2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can
    suspend the SDIO host. However, mmc_sdio_pre_suspend() returns
    -ENOSYS because btsdio_driver does not have a suspend method.

 3. mmc_pm_notify() proceeds to remove the card

 4. Upon resume, mmc_rescan() does nothing with this host, because of
    the rescan_entered check which aims to only scan a non-removable
    device a single time (i.e. during boot).

Fix the loss of functionality by detecting that we are unable to
suspend a non-removable host, so avoid the forced removal in that
case. The comment above this function already indicates that this
code was only intended for removable devices.

Signed-off-by: Daniel Drake &lt;drake@endlessm.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: Do not leave the block driver in a suspended state</title>
<updated>2017-12-08T23:01:15+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2017-11-21T13:42:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8fe2cf2527e2f43f543be6a7fcdf470bea5bd415'/>
<id>8fe2cf2527e2f43f543be6a7fcdf470bea5bd415</id>
<content type='text'>
[ Upstream commit ebe7dd45cf49e3b49cacbaace17f9f878f21fbea ]

The block driver must be resumed if the mmc bus fails to suspend the card.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Cc: stable@vger.kernel.org # v3.19+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit ebe7dd45cf49e3b49cacbaace17f9f878f21fbea ]

The block driver must be resumed if the mmc bus fails to suspend the card.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Cc: stable@vger.kernel.org # v3.19+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdio: fix alignment issue in struct sdio_func</title>
<updated>2017-11-06T04:54:16+00:00</updated>
<author>
<name>Heiner Kallweit</name>
<email>hkallweit1@gmail.com</email>
</author>
<published>2017-03-29T18:54:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0d5a22feab14b82801e35c1e09688a318df2aaaf'/>
<id>0d5a22feab14b82801e35c1e09688a318df2aaaf</id>
<content type='text'>
[ Upstream commit 5ef1ecf060f28ecef313b5723f1fd39bf5a35f56 ]

Certain 64-bit systems (e.g. Amlogic Meson GX) require buffers to be
used for DMA to be 8-byte-aligned. struct sdio_func has an embedded
small DMA buffer not meeting this requirement.
When testing switching to descriptor chain mode in meson-gx driver
SDIO is broken therefore. Fix this by allocating the small DMA buffer
separately as kmalloc ensures that the returned memory area is
properly aligned for every basic data type.

Signed-off-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Tested-by: Helmut Klein &lt;hgkr.klein@gmail.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 5ef1ecf060f28ecef313b5723f1fd39bf5a35f56 ]

Certain 64-bit systems (e.g. Amlogic Meson GX) require buffers to be
used for DMA to be 8-byte-aligned. struct sdio_func has an embedded
small DMA buffer not meeting this requirement.
When testing switching to descriptor chain mode in meson-gx driver
SDIO is broken therefore. Fix this by allocating the small DMA buffer
separately as kmalloc ensures that the returned memory area is
properly aligned for every basic data type.

Signed-off-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Tested-by: Helmut Klein &lt;hgkr.klein@gmail.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: fix multi-bit bus width without high-speed mode</title>
<updated>2017-03-06T22:31:14+00:00</updated>
<author>
<name>Anssi Hannula</name>
<email>anssi.hannula@bitwise.fi</email>
</author>
<published>2017-02-13T11:46:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1c12c2f761072fb1e8a2dd938339feb2dd33be80'/>
<id>1c12c2f761072fb1e8a2dd938339feb2dd33be80</id>
<content type='text'>
[ Upstream commit 3d4ef329757cfd5e0b23cce97cdeca7e2df89c99 ]

Commit 577fb13199b1 ("mmc: rework selection of bus speed mode")
refactored bus width selection code to mmc_select_bus_width().

However, it also altered the behavior to not call the selection code in
non-high-speed modes anymore.

This causes 1-bit mode to always be used when the high-speed mode is not
enabled, even though 4-bit and 8-bit bus are valid bus widths in the
backwards-compatibility (legacy) mode as well (see e.g. 5.3.2 Bus Speed
Modes in JEDEC 84-B50). This results in a significant regression in
transfer speeds.

Fix the code to allow 4-bit and 8-bit widths even without high-speed
mode, as before.

Tested with a Zynq-7000 PicoZed 7020 board.

Fixes: 577fb13199b1 ("mmc: rework selection of bus speed mode")
Signed-off-by: Anssi Hannula &lt;anssi.hannula@bitwise.fi&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3d4ef329757cfd5e0b23cce97cdeca7e2df89c99 ]

Commit 577fb13199b1 ("mmc: rework selection of bus speed mode")
refactored bus width selection code to mmc_select_bus_width().

However, it also altered the behavior to not call the selection code in
non-high-speed modes anymore.

This causes 1-bit mode to always be used when the high-speed mode is not
enabled, even though 4-bit and 8-bit bus are valid bus widths in the
backwards-compatibility (legacy) mode as well (see e.g. 5.3.2 Bus Speed
Modes in JEDEC 84-B50). This results in a significant regression in
transfer speeds.

Fix the code to allow 4-bit and 8-bit widths even without high-speed
mode, as before.

Tested with a Zynq-7000 PicoZed 7020 board.

Fixes: 577fb13199b1 ("mmc: rework selection of bus speed mode")
Signed-off-by: Anssi Hannula &lt;anssi.hannula@bitwise.fi&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: longer timeout for long read time quirk</title>
<updated>2016-06-06T23:12:33+00:00</updated>
<author>
<name>Matt Gumbel</name>
<email>matthew.k.gumbel@intel.com</email>
</author>
<published>2016-05-20T07:33:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a0b7f5619bd13ac231bae4931358d0199b019892'/>
<id>a0b7f5619bd13ac231bae4931358d0199b019892</id>
<content type='text'>
[ Upstream commit 32ecd320db39bcb007679ed42f283740641b81ea ]

008GE0 Toshiba mmc in some Intel Baytrail tablets responds to
MMC_SEND_EXT_CSD in 450-600ms.

This patch will...

() Increase the long read time quirk timeout from 300ms to 600ms. Original
   author of that quirk says 300ms was only a guess and that the number
   may need to be raised in the future.

() Add this specific MMC to the quirk

Signed-off-by: Matt Gumbel &lt;matthew.k.gumbel@intel.com&gt;
Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 32ecd320db39bcb007679ed42f283740641b81ea ]

008GE0 Toshiba mmc in some Intel Baytrail tablets responds to
MMC_SEND_EXT_CSD in 450-600ms.

This patch will...

() Increase the long read time quirk timeout from 300ms to 600ms. Original
   author of that quirk says 300ms was only a guess and that the number
   may need to be raised in the future.

() Add this specific MMC to the quirk

Signed-off-by: Matt Gumbel &lt;matthew.k.gumbel@intel.com&gt;
Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: mmc: Fix partition switch timeout for some eMMCs</title>
<updated>2016-06-06T23:12:22+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2016-05-05T05:12:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a87165993a3702ec5ec8f3af87df8edcce26b3da'/>
<id>a87165993a3702ec5ec8f3af87df8edcce26b3da</id>
<content type='text'>
[ Upstream commit 1c447116d017a98c90f8f71c8c5a611e0aa42178 ]

Some eMMCs set the partition switch timeout too low.

Now typically eMMCs are considered a critical component (e.g. because
they store the root file system) and consequently are expected to be
reliable.  Thus we can neglect the use case where eMMCs can't switch
reliably and we might want a lower timeout to facilitate speedy
recovery.

Although we could employ a quirk for the cards that are affected (if
we could identify them all), as described above, there is little
benefit to having a low timeout, so instead simply set a minimum
timeout.

The minimum is set to 300ms somewhat arbitrarily - the examples that
have been seen had a timeout of 10ms but were sometimes taking 60-70ms.

Cc: stable@vger.kernel.org
Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 1c447116d017a98c90f8f71c8c5a611e0aa42178 ]

Some eMMCs set the partition switch timeout too low.

Now typically eMMCs are considered a critical component (e.g. because
they store the root file system) and consequently are expected to be
reliable.  Thus we can neglect the use case where eMMCs can't switch
reliably and we might want a lower timeout to facilitate speedy
recovery.

Although we could employ a quirk for the cards that are affected (if
we could identify them all), as described above, there is little
benefit to having a low timeout, so instead simply set a minimum
timeout.

The minimum is set to 300ms somewhat arbitrarily - the examples that
have been seen had a timeout of 10ms but were sometimes taking 60-70ms.

Cc: stable@vger.kernel.org
Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: Enable tuning according to the actual timing</title>
<updated>2016-02-03T21:23:15+00:00</updated>
<author>
<name>Carlo Caione</name>
<email>carlo@endlessm.com</email>
</author>
<published>2016-01-13T08:36:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2a048a248fad2e7d49a3a5c8b9259f403182b5ac'/>
<id>2a048a248fad2e7d49a3a5c8b9259f403182b5ac</id>
<content type='text'>
[ Upstream commit e10c321977091f163eceedec0650e0ef4b3cf4bb ]

While in sdhci_execute_tuning() the choice whether or not to enable the
tuning is done on the actual timing, in the mmc_sdio_init_uhs_card() the
check is done on the capability of the card.

This difference is causing some issues with some SDIO cards in DDR50
mode where the CDM19 is wrongly issued.

With this patch we modify the check in both
mmc_(sd|sdio)_init_uhs_card() functions to take the proper decision
only according to the actual timing specification.

Cc: stable@vger.kernel.org
Signed-off-by: Carlo Caione &lt;carlo@endlessm.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit e10c321977091f163eceedec0650e0ef4b3cf4bb ]

While in sdhci_execute_tuning() the choice whether or not to enable the
tuning is done on the actual timing, in the mmc_sdio_init_uhs_card() the
check is done on the capability of the card.

This difference is causing some issues with some SDIO cards in DDR50
mode where the CDM19 is wrongly issued.

With this patch we modify the check in both
mmc_(sd|sdio)_init_uhs_card() functions to take the proper decision
only according to the actual timing specification.

Cc: stable@vger.kernel.org
Signed-off-by: Carlo Caione &lt;carlo@endlessm.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: enable CMD19 tuning for DDR50 mode</title>
<updated>2016-02-03T21:23:15+00:00</updated>
<author>
<name>Weijun Yang</name>
<email>york.yang@csr.com</email>
</author>
<published>2015-10-04T12:04:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6e1e9bd06060eedf56db7aa53909b52944fc3d06'/>
<id>6e1e9bd06060eedf56db7aa53909b52944fc3d06</id>
<content type='text'>
[ Upstream commit 4324f6de6d2eb9b232410eb0d67bfafdde8ba711 ]

As SD Specifications Part1 Physical Layer Specification Version
3.01 says, CMD19 tuning is available for unlocked cards in transfer
state of 1.8V signaling mode. The small difference between v3.00
and 3.01 spec means that CMD19 tuning is also available for DDR50
mode.

Signed-off-by: Weijun Yang &lt;york.yang@csr.com&gt;
Signed-off-by: Barry Song &lt;Baohua.Song@csr.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 4324f6de6d2eb9b232410eb0d67bfafdde8ba711 ]

As SD Specifications Part1 Physical Layer Specification Version
3.01 says, CMD19 tuning is available for unlocked cards in transfer
state of 1.8V signaling mode. The small difference between v3.00
and 3.01 spec means that CMD19 tuning is also available for DDR50
mode.

Signed-off-by: Weijun Yang &lt;york.yang@csr.com&gt;
Signed-off-by: Barry Song &lt;Baohua.Song@csr.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdio: Fix invalid vdd in voltage switch power cycle</title>
<updated>2016-02-01T17:39:30+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2015-11-26T12:00:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e6cbcb008a279d7794fba01799ecfb6be391484f'/>
<id>e6cbcb008a279d7794fba01799ecfb6be391484f</id>
<content type='text'>
[ Upstream commit d9bfbb95ed598a09cf336adb0f190ee0ff802f0d ]

The 'ocr' parameter passed to mmc_set_signal_voltage()
defines the power-on voltage used when power cycling
after a failure to set the voltage.  However, in the
case of mmc_sdio_init_card(), the value passed has the
R4_18V_PRESENT flag set which is not valid for power-on
and results in an invalid vdd.  Fix by passing the card's
ocr value which does not have the flag.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d9bfbb95ed598a09cf336adb0f190ee0ff802f0d ]

The 'ocr' parameter passed to mmc_set_signal_voltage()
defines the power-on voltage used when power cycling
after a failure to set the voltage.  However, in the
case of mmc_sdio_init_card(), the value passed has the
R4_18V_PRESENT flag set which is not valid for power-on
and results in an invalid vdd.  Fix by passing the card's
ocr value which does not have the flag.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: Don't return an error for CD/WP GPIOs when GPIOLIB is unset</title>
<updated>2015-10-22T21:43:25+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2015-09-14T10:18:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=344fa142ddc8d2316d0fc30eddf32bf56d19c01f'/>
<id>344fa142ddc8d2316d0fc30eddf32bf56d19c01f</id>
<content type='text'>
commit 43934ece2ea72c1dd279c0b0478c1a036d5d77ee upstream.

When CONFIG_GPIOLIB is unset, its stubs will return -ENOSYS. That means
when the mmc core parses DT for CD/WP GPIOs via mmc_of_parse(), -ENOSYS
becomes propagated to the caller. Typically this means that the mmc host
driver fails to probe.

As the CD/WP GPIOs are already treated as optional, let's extend that to
cover the case when CONFIG_GPIOLIB is unset.

Reported-by: Michal Simek &lt;michal.simek@xilinx.com&gt;
Fixes: 16b23787fc70 ("mmc: sdhci-of-arasan: Call OF parsing for MMC")
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Tested-by: Michal Simek &lt;michal.simek@xilinx.com&gt;
Acked-by: Venu Byravarasu &lt;vbyravarasu@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 43934ece2ea72c1dd279c0b0478c1a036d5d77ee upstream.

When CONFIG_GPIOLIB is unset, its stubs will return -ENOSYS. That means
when the mmc core parses DT for CD/WP GPIOs via mmc_of_parse(), -ENOSYS
becomes propagated to the caller. Typically this means that the mmc host
driver fails to probe.

As the CD/WP GPIOs are already treated as optional, let's extend that to
cover the case when CONFIG_GPIOLIB is unset.

Reported-by: Michal Simek &lt;michal.simek@xilinx.com&gt;
Fixes: 16b23787fc70 ("mmc: sdhci-of-arasan: Call OF parsing for MMC")
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Tested-by: Michal Simek &lt;michal.simek@xilinx.com&gt;
Acked-by: Venu Byravarasu &lt;vbyravarasu@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
