linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Arnd Bergmann <arnd@kernel.org>,
	Douglas Anderson <dianders@chromium.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	SoC Team <soc@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [GIT PULL] ARM: SoC fixes for v5.10, part 3
Date: Sat, 5 Dec 2020 21:48:34 +0100	[thread overview]
Message-ID: <20201205204834.GC8578@amd> (raw)
In-Reply-To: <CAKdAkRRq=GK7N1PDJ4zLfJVSsrd1BB=u69aXtJHh=sW4vn5LOg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1821 bytes --]

Hi!

> > On Fri, Nov 27, 2020 at 12:51 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > >
> > >  - Some DT patches for the Rockchip RK3399 platform,
> > >    in particular fixing the MMC device ordering that
> > >    recently became nondeterministic with async probe.
> >
> > Uhhuh.
> >
> > I didn't realize this MMC breakage happened.
> >
> > That's just an MMC bug. Other subsystems have been able to do async
> > probing without making device ordering be random.
> >
> > So this really smells wrong, and I just never realized.
> >
> > Added Douglas Anderson to the cc - the whole PROBE_PREFER_ASYNCHRONOUS
> > behavior appears broken.
> >
> > You basically should do the device numbering synchronously (or better
> > yet - asynchronously, but single-threaded for the subsystem), and then
> > asynchronously probe the actual device details after you've numbered
> > them reliably.
> 
> Generally speaking it is either unnecessary for a lot of devices where
> we do not care what number they get, harmful (why do I need to probe
> i2c touchscreen and touchpad sequentially if I do not care which one
> comes first but my boot will take 0.5 seconds longer if I serialize),
> or impossible (if device is hit-pluggable). For many years userspace
> has been moving away from static device assignments and we should not
> be going back.

Lets not make userspace's life harder than it should be.

You can't break existing configurations, and people still use
root=/dev/mmcblkX. Recently kernel on Droid 4 switched from MMC on
mmcblk0 and mmcblk1 to MMC on mmcblk0 and mmcblk2. Of course that
broke my config.

And I'm fairly sure I'm not alone.

(And it may not be this bug, and I do have workaround now.)

Best regards,
								Pavel

-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-12-05 20:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-27 20:51 [GIT PULL] ARM: SoC fixes for v5.10, part 3 Arnd Bergmann
2020-11-27 22:56 ` Linus Torvalds
2020-11-30 17:04   ` Doug Anderson
2020-11-30 17:44     ` Linus Torvalds
2020-11-30 18:05       ` Russell King - ARM Linux admin
2020-11-30 18:15         ` Linus Torvalds
2020-11-30 19:06           ` Russell King - ARM Linux admin
2020-11-30 18:11       ` Doug Anderson
2020-11-30 18:22         ` Linus Torvalds
2020-11-30 22:54           ` Russell King - ARM Linux admin
2020-12-01 11:39           ` Ulf Hansson
2020-12-01 14:00             ` Arnd Bergmann
2020-12-07 20:19               ` Geert Uytterhoeven
2020-12-07 21:55                 ` Arnd Bergmann
2020-12-07 22:15                   ` Doug Anderson
2020-12-08  7:31                     ` Geert Uytterhoeven
2020-12-14 20:22                       ` Ulf Hansson
2020-12-15  8:19                         ` Geert Uytterhoeven
2020-12-15  9:53                           ` Ulf Hansson
2020-11-30 17:27   ` Dmitry Torokhov
2020-12-05 20:48     ` Pavel Machek [this message]
2020-11-27 23:29 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201205204834.GC8578@amd \
    --to=pavel@ucw.cz \
    --cc=arnd@kernel.org \
    --cc=dianders@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=soc@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).