All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Doug Anderson <dianders@chromium.org>,
	Arnd Bergmann <arnd@kernel.org>, SoC Team <soc@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>
Subject: Re: [GIT PULL] ARM: SoC fixes for v5.10, part 3
Date: Mon, 30 Nov 2020 18:05:24 +0000	[thread overview]
Message-ID: <20201130180523.GZ1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <CAHk-=whtySEgkH+VFy9oW8Q-+iuivGBo0hOUcee3DvrsBAQUrA@mail.gmail.com>

On Mon, Nov 30, 2020 at 09:44:03AM -0800, Linus Torvalds wrote:
> On Mon, Nov 30, 2020 at 9:04 AM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Without static assignment, maybe we could do numbering of MMC devices
> > in some type of a pre-probe routine?  Is that what you're suggesting?
> 
> Yes.
> 
> So basically, the way the async probing works for say SCSI is that we
> have multiple "layers of asynchroniety". We have the usual "init calls
> done asynchronously", but then within the init calls themselves you
> can start sub-scans asynchronously.
> 
> In order to get reliable ordering between multiple controllers, the
> PCI bus is probed in order in pci_init() (or whatever), so each SCSI
> controller gets called in a fixed order.
> 
> That then gets to scsi_scan_host() does that async_schedule() thing to
> actually scan the SCSI buses on that host.

I'm afraid that you don't get stable device numbering on x86. You get
something that _looks_ like stable device numbering, but it really
isn't.

If you think that /dev/sda for example is always the machine's internal
HDD, that is wrong.

I have a HP Pavilion laptop with its internal HDD with a Windows
installation. Because I didn't want to destroy that in any way, I
bought an external USB3 SATA enclosure and SSD, and installed Debian
Stable on there.

When I installed Debian stable, the HDD was /dev/sda and the SSD was
/dev/sdb. When I boot Debian, the SSD is /dev/sda and the internal
HDD is /dev/sdb.

Maybe /dev/sda through /dev/sdd should be reserved for internal
motherboard drives?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Arnd Bergmann <arnd@kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Doug Anderson <dianders@chromium.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	SoC Team <soc@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [GIT PULL] ARM: SoC fixes for v5.10, part 3
Date: Mon, 30 Nov 2020 18:05:24 +0000	[thread overview]
Message-ID: <20201130180523.GZ1551@shell.armlinux.org.uk> (raw)
Message-ID: <20201130180524.nd8RE49EOD0U-x8aTOB0lRzvjfNdXdYik1Ur_ok0qYQ@z> (raw)
In-Reply-To: <CAHk-=whtySEgkH+VFy9oW8Q-+iuivGBo0hOUcee3DvrsBAQUrA@mail.gmail.com>

On Mon, Nov 30, 2020 at 09:44:03AM -0800, Linus Torvalds wrote:
> On Mon, Nov 30, 2020 at 9:04 AM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Without static assignment, maybe we could do numbering of MMC devices
> > in some type of a pre-probe routine?  Is that what you're suggesting?
> 
> Yes.
> 
> So basically, the way the async probing works for say SCSI is that we
> have multiple "layers of asynchroniety". We have the usual "init calls
> done asynchronously", but then within the init calls themselves you
> can start sub-scans asynchronously.
> 
> In order to get reliable ordering between multiple controllers, the
> PCI bus is probed in order in pci_init() (or whatever), so each SCSI
> controller gets called in a fixed order.
> 
> That then gets to scsi_scan_host() does that async_schedule() thing to
> actually scan the SCSI buses on that host.

I'm afraid that you don't get stable device numbering on x86. You get
something that _looks_ like stable device numbering, but it really
isn't.

If you think that /dev/sda for example is always the machine's internal
HDD, that is wrong.

I have a HP Pavilion laptop with its internal HDD with a Windows
installation. Because I didn't want to destroy that in any way, I
bought an external USB3 SATA enclosure and SSD, and installed Debian
Stable on there.

When I installed Debian stable, the HDD was /dev/sda and the SSD was
/dev/sdb. When I boot Debian, the SSD is /dev/sda and the internal
HDD is /dev/sdb.

Maybe /dev/sda through /dev/sdd should be reserved for internal
motherboard drives?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

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

  reply	other threads:[~2020-11-30 18:05 UTC|newest]

Thread overview: 44+ 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 20:51 ` Arnd Bergmann
2020-11-27 22:56 ` Linus Torvalds
2020-11-27 22:56   ` Linus Torvalds
2020-11-30 17:04   ` Doug Anderson
2020-11-30 17:04     ` Doug Anderson
2020-11-30 17:44     ` Linus Torvalds
2020-11-30 17:44       ` Linus Torvalds
2020-11-30 18:05       ` Russell King - ARM Linux admin [this message]
2020-11-30 18:05         ` Russell King - ARM Linux admin
2020-11-30 18:15         ` Linus Torvalds
2020-11-30 18:15           ` Linus Torvalds
2020-11-30 19:06           ` Russell King - ARM Linux admin
2020-11-30 19:06             ` Russell King - ARM Linux admin
2020-11-30 18:11       ` Doug Anderson
2020-11-30 18:11         ` Doug Anderson
2020-11-30 18:22         ` Linus Torvalds
2020-11-30 18:22           ` Linus Torvalds
2020-11-30 22:54           ` Russell King - ARM Linux admin
2020-11-30 22:54             ` Russell King - ARM Linux admin
2020-12-01 11:39           ` Ulf Hansson
2020-12-01 11:39             ` Ulf Hansson
2020-12-01 14:00             ` Arnd Bergmann
2020-12-01 14:00               ` Arnd Bergmann
2020-12-07 20:19               ` Geert Uytterhoeven
2020-12-07 20:19                 ` Geert Uytterhoeven
2020-12-07 21:55                 ` Arnd Bergmann
2020-12-07 21:55                   ` Arnd Bergmann
2020-12-07 22:15                   ` Doug Anderson
2020-12-07 22:15                     ` Doug Anderson
2020-12-08  7:31                     ` Geert Uytterhoeven
2020-12-08  7:31                       ` Geert Uytterhoeven
2020-12-14 20:22                       ` Ulf Hansson
2020-12-14 20:22                         ` Ulf Hansson
2020-12-15  8:19                         ` Geert Uytterhoeven
2020-12-15  8:19                           ` Geert Uytterhoeven
2020-12-15  9:53                           ` Ulf Hansson
2020-12-15  9:53                             ` Ulf Hansson
2020-11-30 17:27   ` Dmitry Torokhov
2020-11-30 17:27     ` Dmitry Torokhov
2020-12-05 20:48     ` Pavel Machek
2020-12-05 20:48       ` Pavel Machek
2020-11-27 23:29 ` pr-tracker-bot
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=20201130180523.GZ1551@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=arnd@kernel.org \
    --cc=dianders@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=soc@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=ulf.hansson@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.