Re: [PATCH] mmc: Kconfig: Add dependency on GPIOLIB for MMC_SDHCI
From: Ulf Hansson
Date: Thu Aug 27 2015 - 08:31:17 EST
On 27 August 2015 at 13:43, Michal Simek <michal.simek@xxxxxxxxxx> wrote:
> Hi Ulf,
> On 08/27/2015 01:32 PM, Ulf Hansson wrote:
>> On 25 August 2015 at 14:04, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>>> On 6 August 2015 at 07:39, Michal Simek <michal.simek@xxxxxxxxxx> wrote:
>>>> Add GPIOLIB dependency for MMC_SDHCI.
>>>> Problem was observed after adding the patch
>>>> "mmc: sdhci-of-arasan: Call OF parsing for MMC"
>>>> (sha1: 16b23787fc709fe60c5d2bd05927b1a3da33d4e9) which calls
>>>> mmc_of_parse() -> mmc_gpiod_request_cd() (slot-gpio.c) which
>>>> calls devm_gpiod_get_index() which returns -ENOSYS.
>>>> Error log:
>>>> sdhci-arasan ff160000.sdhci: parsing dt failed (4294967258)
>>>> sdhci-arasan: probe of ff160000.sdhci failed with error -38
>>>> Signed-off-by: Michal Simek <michal.simek@xxxxxxxxxx>
>>> Thanks, applied for next!
>> kbuild test robot reports a warning for this one, so I am dropping it
>> from my next branch.
> I think is just better to fix the problem there instead of dropping this
> patch which fix GPIO dependency.
> Fix is quite easy.
> diff --git a/arch/powerpc/platforms/44x/Kconfig
> index 5538e57c36c1..874f07c7d0b8 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -219,6 +219,7 @@ config AKEBONO
> select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD
> select MMC_SDHCI
> select MMC_SDHCI_PLTFM
> + select GPIOLIB
> select ATA
> select SATA_AHCI_PLATFORM
> But the question is if we should keep these ancient targets in the tree.
> I am happy to send this patch but it should go via PPC tree. Or are you
> happy to apply it to your tree?
It's getting really late for 4.3 so I would rather postpone this to
the next release cycle.
As I stated in my earlier reply, do we really want to add the GPIOLIB
dependency to the Kconfig file for SDHCI?
I assume we have lots of other Kconfig dependencies, then these should
also to be added for the same reasons. I doubt this is the right thing
How about if the mmc core instead treat GPIOs as optional from an API
point of view and thus it won't cause ->probe() to fail. Is that a way
forward for you?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/