linux-kernel - Re: [PATCH v2 09/22] mmc: tmio: use mmc_can_gpio_cd() instead of checking TMIO_MMC_USE_GPIO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK7LNAQhTGc-iO4H-gZh44S6yoRHFqgWe7ppgGN9tmCUdJK9vQ@mail.gmail.com>
Date:   Fri, 12 Jan 2018 13:06:55 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        linux-mmc <linux-mmc@...r.kernel.org>
Cc:     Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Simon Horman <simon.horman@...ronome.com>,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Wolfram Sang <wsa@...-dreams.de>
Subject: Re: [PATCH v2 09/22] mmc: tmio: use mmc_can_gpio_cd() instead of
 checking TMIO_MMC_USE_GPIO_CD

Hi Ulf,


2018-01-02 21:56 GMT+09:00 Wolfram Sang <wsa@...-dreams.de>:
> On Sat, Nov 25, 2017 at 01:24:44AM +0900, Masahiro Yamada wrote:
>> To use a GPIO line for card detection, TMIO_MMC_USE_GPIO_CD is set
>> by a legacy board (arch/sh/boards/mach-ecovec24).
>>
>> For DT platforms, the "cd-gpios" property is a legitimate way for that
>> in case the IP-builtin card detection can not be used for some reason.
>> mmc_of_parse() calls mmc_gpiod_request_cd() to set up ctx->cd_gpio if
>> the "cd-gpios" property is specified.
>>
>> To cater to both cases, mmc_can_gpio_cd() is a correct way to check
>> which card detection logic is used.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
>
> This patch is correct, yet needed some time for testing because it
> inverts the results for R-Car SoCs. Again, it is correct that it inverts
> it because those SoCs have GPIOs defined in their devicetrees, so they
> shouldn't be using native hotplug. Still, this meant checking that no
> regression gets introduced. Also, for R-Car Gen 2 & 3 native hotplug
> seems to work fine, so I was trying to find out why we use GPIOs here. I
> wasn't successful up to now, but since GPIOs work well, too, and seem to
> react a bit faster even, I am fine with the patch being merged.
>
> Reviewed-by: Wolfram Sang <wsa+renesas@...g-engineering.com>
>
>> ---
>>
>> Changes in v2: None
>>
>>  drivers/mmc/host/tmio_mmc_core.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
>> index efffb04..610f26f 100644
>> --- a/drivers/mmc/host/tmio_mmc_core.c
>> +++ b/drivers/mmc/host/tmio_mmc_core.c
>> @@ -1232,7 +1232,7 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
>>       }
>>       mmc->max_seg_size = mmc->max_req_size;
>>
>> -     _host->native_hotplug = !(pdata->flags & TMIO_MMC_USE_GPIO_CD ||
>> +     _host->native_hotplug = !(mmc_can_gpio_cd(mmc) ||
>>                                 mmc->caps & MMC_CAP_NEEDS_POLL ||
>>                                 !mmc_card_is_removable(mmc));
>>
>> --
>> 2.7.4
>>

Wolfram issued Reviewed-by.

Could you pick up this patch for -next?

-- 
Best Regards
Masahiro Yamada