Message-ID: <CAPDyKFp9L+L9VeUD038G3mBTLBuPJsMtv7JhxCcSGb3iY=eq5A@mail.gmail.com>
Date:   Tue, 1 Dec 2020 12:39:46 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Doug Anderson <dianders@...omium.org>,
        Arnd Bergmann <arnd@...nel.org>, SoC Team <soc@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [GIT PULL] ARM: SoC fixes for v5.10, part 3

On Mon, 30 Nov 2020 at 19:23, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Mon, Nov 30, 2020 at 10:11 AM Doug Anderson <dianders@...omium.org> wrote:
> >
> > So I guess the answer here is: strive very hard but you don't have to
> > guarantee that every corner case is covered?
>
> Yes. Covering every possible theoretical case is basically impossible.
> I mean, it can be something like "the firmware glitched for whatever
> reason, and didn't set up a device, and it didn't show up at boot at
> all until you did something explicit".
>
> (Example: airplane mode wireless switches, but also possibly things
> like just slightly unreliable USB hubs etc - I bet we've all seen
> those).
>
> So the rule should be that you strive very hard to make boots have
> reproducible behavior as far as practically necessary, and avoid
> obvious timing-induced ordering issues.

I agree, but let me also try to clarify a few things.

Indeed, we have been striving towards getting a more consistent
behavior when assigning block numbers for MMC/SD cards. Some time ago
the number depended on:

- The time it took to initialize the MMC/SD cards.
- The probing of the mmc block device.
- The probing of the mmc host drivers.

It's been highly random, unfortunately.

Therefore, we have and are still pointing to things like "disk
labels", but those have limitations.

A while ago, we eliminated the impact of the two first parts, which
left us with solely the probe order of mmc host drivers. Furthermore,
we recently introduced support for the mmc aliases in DT, in a way to
support cases when a "disk label" is not feasible.

>
> > In a traditional PC I think there are fewer dependencies?
>
> I'd say that they were "different", not necessarily "fewer".
>
> > I guess the question is: why is static assignment of numbers not an
> > acceptable solution to the problem?  It gives us the desired fixed
> > numbers and automatically avoids all weird probe ordering / dependency
> > problems.
>
> I think that if this had been done originally, it would probably be fine.
>
> But I still have this - possibly unreasonable - expectation that the
> promise of DT was that it wouldn't be 1:1 tied to the kernel all the
> time. That was always the promise, after all.
>
> So the whole "add DT markers because the subsystem now screws up
> ordering" smells really bad to me.

As stated above, the randomness has been there all the time. We have
had only "disk labels" to help and that's what we have been telling
people consistently. To me, the new mmc aliases in DT, is another step
in the right direction.

That said, perhaps we went too far to optimize boot times while
enabling async probe for some of the mmc host drivers. Clearly, not
all users have been paying attention, but was lucky to receive
"stable" mmc block numbers.

So, I think we have two options. If people are willing to move to
"disk labels" or to patch their DTBs with mmc aliases, things can stay
as is. Otherwise, we can revert the async probe parts of the mmc host
drivers, but that would still leave us in a fragile situation.

Kind regards
Uffe

Powered by blists - more mailing lists