lkml.org 
[lkml]   [2020]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [GIT PULL] ARM: SoC fixes for v5.10, part 3
On Mon, Nov 30, 2020 at 10:11 AM Doug Anderson <dianders@chromium.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.

> 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.

Linus

\
 
 \ /
  Last update: 2020-11-30 19:26    [W:0.133 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site