Re: [PATCH 0/2] gpiolib: Fix issues introduced by fast bitmap processing path

[Marek Szyprowski]

Hi Janusz,

On 2018-09-24 01:53, Janusz Krzysztofik wrote:
> While investigating possible reasons of GPIO fast bitmap processing
> related boot hang on Samsung Snow Chromebook, reported by Marek
> Szyprowski (thanks!), I've discovered one coding bug, addressed by
> PATCH 1/2 of this series, and one potential regression introduced at
> design level of the solution, hopefully fixed by PATCH 2/2.  See
> commit messages for details.
>
> Janusz Krzysztofik (2):
>        gpiolib: Fix missing updates of bitmap index
>        gpiolib: Fix array members of same chip processed separately
>
> The fixes should resolve the boot hang observed by Marek, however the
> second change excludes that particular case from fast bitmap processing
> and restores the old behaviour.

I confirm, that the above 2 patches fixes boot issue on Samsung Snow
Chromebook with next-20180920.

Tested-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>

> Hence, it is possible still another
> issue which have had an influence on that boot hang exists in the code.
> In order to fully verify the fix, it would have to be tested on a
> platform where an array of GPIO descriptors is used which starts from
> at least two consecutive pins of one GPIO chip in hardware order,
> starting ftom 0, followed by one or more pins belonging to other
> chip(s).
>
> In order to verify if separate calls to .set() chip callback for each
> pin instead of one call to .set_multiple() is actually the reason of
> boot hang on Samsung Snow Chromebook, the affected driver -
> drivers/mmc/core/pwrseq_simple.c - would have to be temporarily
> modified for testing purposes so it calls gpiod_set_value() for each
> pin instead of gpiod_set_array_value() for all of them.  If that would
> also result in boot hang, we could be sure the issue was really the
> one addressed by the second fix.  Marek, could you please try to
> perform such test?

Yes, I've just tested next-20180920 only with the first patch from this
patchset and the mentioned change to drivers/mmc/core/pwrseq_simple.c.
It boots fine, so indeed the issue is in handling of arrays of gpios.

Just to be sure I did it right, this is my change to the mentioned file:

diff --git a/drivers/mmc/core/pwrseq_simple.c 
b/drivers/mmc/core/pwrseq_simple.c
index 7f882a2bb872..9397dc1f2e38 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -38,16 +38,11 @@ static void mmc_pwrseq_simple_set_gpios_value(struct 
mmc_pwrseq_simple *pwrseq,
 ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ int value)
 Â{
 ÂÂÂÂÂÂÂ struct gpio_descs *reset_gpios = pwrseq->reset_gpios;
+ÂÂÂÂÂÂ int i;

-ÂÂÂÂÂÂ if (!IS_ERR(reset_gpios)) {
-ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ DECLARE_BITMAP(values, BITS_PER_TYPE(value));
-ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ int nvalues = reset_gpios->ndescs;
-
-ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ values[0] = value;
-
-ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ gpiod_set_array_value_cansleep(nvalues, reset_gpios->desc,
-ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ reset_gpios->info, values);
-ÂÂÂÂÂÂ }
+ÂÂÂÂÂÂ if (!IS_ERR(reset_gpios))
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ for (i = 0; i < reset_gpios->ndescs; i++)
+ gpiod_set_value_cansleep(reset_gpios->desc[i], value);
 Â}

 Âstatic void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland