Linux-mmc Archive on lore.kernel.org
 help / color / Atom feed
* Consistent block device references for root= cmdline
@ 2020-06-10 13:15 Matthias Schiffer
  2020-06-10 14:52 ` Ulf Hansson
  0 siblings, 1 reply; 7+ messages in thread
From: Matthias Schiffer @ 2020-06-10 13:15 UTC (permalink / raw)
  To: Ulf Hansson, Al Viro, Jens Axboe, s.hauer
  Cc: linux-mmc, linux-block, linux-kernel

Hello all,

there have been numerous attempts to make the numbering of mmcblk
devices consistent, mostly by using aliases from the DTS ([1], [2],
[3]), but all have been (rightfully) rejected. Unless I have overlooked
a more recent development, no attempts for a different solution were
made.

As far as I can tell, the core of the issue seems to be the following:

The existing solutions like LABELs and UUIDs are viable alternatives in
many cases, but in particular on embedded systems, this is not quite
sufficient: In addition to the problem that more knowledge about the
system to boot is required in the bootloader, this approach fails
completely when the same firmware image exists on multiple devices, for
example on an eMMC and an SD card - not an entirely uncommon situation
during the development of embedded systems.

With udev, I can refer to a specific partition using a path like
/dev/disk/by-path/platform-2194000.usdhc-part2. In [4] it was proposed
to add a way to refer to a device path/phandle from the kernel command
line. Has there been any progress on this proposal?

Kind regards,
Matthias


[1] https://patchwork.kernel.org/patch/8685711/
[2] https://lore.kernel.org/patchwork/cover/674381/
[3] https://www.spinics.net/lists/linux-mmc/msg26586.html
[4] https://www.spinics.net/lists/linux-mmc/msg26708.html


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Consistent block device references for root= cmdline
  2020-06-10 13:15 Consistent block device references for root= cmdline Matthias Schiffer
@ 2020-06-10 14:52 ` Ulf Hansson
  2020-06-10 17:33   ` Roger Heflin
  2020-06-11 11:20   ` Matthias Schiffer
  0 siblings, 2 replies; 7+ messages in thread
From: Ulf Hansson @ 2020-06-10 14:52 UTC (permalink / raw)
  To: Matthias Schiffer
  Cc: Al Viro, Jens Axboe, Sascha Hauer, linux-mmc, linux-block,
	Linux Kernel Mailing List

On Wed, 10 Jun 2020 at 15:15, Matthias Schiffer
<matthias.schiffer@ew.tq-group.com> wrote:
>
> Hello all,
>
> there have been numerous attempts to make the numbering of mmcblk
> devices consistent, mostly by using aliases from the DTS ([1], [2],
> [3]), but all have been (rightfully) rejected. Unless I have overlooked
> a more recent development, no attempts for a different solution were
> made.

According to aliases attempts, I think those have failed, mainly
because of two reasons.

1. Arguments stating that LABELs/UUIDs are variable alternatives. This
isn't the case, which I think was also concluded from the several
earlier discussions.
2. Patches that tried adding support for mmc aliases, were not
correctly coded. More precisely, what needs to be addressed is that
the mmc core also preserves the same ids to be set for the host class
as the block device, mmc[n] must correspond to mmcblk[n].

>
> As far as I can tell, the core of the issue seems to be the following:
>
> The existing solutions like LABELs and UUIDs are viable alternatives in
> many cases, but in particular on embedded systems, this is not quite
> sufficient: In addition to the problem that more knowledge about the
> system to boot is required in the bootloader, this approach fails
> completely when the same firmware image exists on multiple devices, for
> example on an eMMC and an SD card - not an entirely uncommon situation
> during the development of embedded systems.
>
> With udev, I can refer to a specific partition using a path like
> /dev/disk/by-path/platform-2194000.usdhc-part2. In [4] it was proposed
> to add a way to refer to a device path/phandle from the kernel command
> line. Has there been any progress on this proposal?

Lots of time during the years I have been approached, both publicly
and offlist, about whether it would be possible to add support for
"consistent" mmcblk devices. To me, I am fine with the aliases
approach, as long as it gets implemented correctly.

>
> Kind regards,
> Matthias
>
>
> [1] https://patchwork.kernel.org/patch/8685711/
> [2] https://lore.kernel.org/patchwork/cover/674381/
> [3] https://www.spinics.net/lists/linux-mmc/msg26586.html
> [4] https://www.spinics.net/lists/linux-mmc/msg26708.html
>

Kind regards
Uffe

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Consistent block device references for root= cmdline
  2020-06-10 14:52 ` Ulf Hansson
@ 2020-06-10 17:33   ` Roger Heflin
  2020-06-11 11:23     ` (EXT) " Matthias Schiffer
  2020-06-11 11:20   ` Matthias Schiffer
  1 sibling, 1 reply; 7+ messages in thread
From: Roger Heflin @ 2020-06-10 17:33 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Matthias Schiffer, Al Viro, Jens Axboe, Sascha Hauer, linux-mmc,
	linux-block, Linux Kernel Mailing List

No idea if this would still work, but back before label/uuid and lvm
in initird I had a staticly linked "C" program that ran inside initrd,
it searched for likely places a boot device could be (mounted them and
looked for a file to confirm it was the right device, then unmounted
it), and when it found the right one, it then echo's is major/minor
numbers into /proc/sys/kernel/real-root-dev and that is used for root=
without it being on the command line.  Assuming you could get
something similar started by sytemd and/or udev inside the initrd it
might still work.

On Wed, Jun 10, 2020 at 11:51 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Wed, 10 Jun 2020 at 15:15, Matthias Schiffer
> <matthias.schiffer@ew.tq-group.com> wrote:
> >
> > Hello all,
> >
> > there have been numerous attempts to make the numbering of mmcblk
> > devices consistent, mostly by using aliases from the DTS ([1], [2],
> > [3]), but all have been (rightfully) rejected. Unless I have overlooked
> > a more recent development, no attempts for a different solution were
> > made.
>
> According to aliases attempts, I think those have failed, mainly
> because of two reasons.
>
> 1. Arguments stating that LABELs/UUIDs are variable alternatives. This
> isn't the case, which I think was also concluded from the several
> earlier discussions.
> 2. Patches that tried adding support for mmc aliases, were not
> correctly coded. More precisely, what needs to be addressed is that
> the mmc core also preserves the same ids to be set for the host class
> as the block device, mmc[n] must correspond to mmcblk[n].
>
> >
> > As far as I can tell, the core of the issue seems to be the following:
> >
> > The existing solutions like LABELs and UUIDs are viable alternatives in
> > many cases, but in particular on embedded systems, this is not quite
> > sufficient: In addition to the problem that more knowledge about the
> > system to boot is required in the bootloader, this approach fails
> > completely when the same firmware image exists on multiple devices, for
> > example on an eMMC and an SD card - not an entirely uncommon situation
> > during the development of embedded systems.
> >
> > With udev, I can refer to a specific partition using a path like
> > /dev/disk/by-path/platform-2194000.usdhc-part2. In [4] it was proposed
> > to add a way to refer to a device path/phandle from the kernel command
> > line. Has there been any progress on this proposal?
>
> Lots of time during the years I have been approached, both publicly
> and offlist, about whether it would be possible to add support for
> "consistent" mmcblk devices. To me, I am fine with the aliases
> approach, as long as it gets implemented correctly.
>
> >
> > Kind regards,
> > Matthias
> >
> >
> > [1] https://patchwork.kernel.org/patch/8685711/
> > [2] https://lore.kernel.org/patchwork/cover/674381/
> > [3] https://www.spinics.net/lists/linux-mmc/msg26586.html
> > [4] https://www.spinics.net/lists/linux-mmc/msg26708.html
> >
>
> Kind regards
> Uffe

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: (EXT) Re: Consistent block device references for root= cmdline
  2020-06-10 14:52 ` Ulf Hansson
  2020-06-10 17:33   ` Roger Heflin
@ 2020-06-11 11:20   ` Matthias Schiffer
  2020-07-07 14:14     ` Ulf Hansson
  1 sibling, 1 reply; 7+ messages in thread
From: Matthias Schiffer @ 2020-06-11 11:20 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Al Viro, Jens Axboe, Sascha Hauer, linux-mmc, linux-block,
	Linux Kernel Mailing List

On Wed, 2020-06-10 at 16:52 +0200, Ulf Hansson wrote:
> On Wed, 10 Jun 2020 at 15:15, Matthias Schiffer
> <matthias.schiffer@ew.tq-group.com> wrote:
> > 
> > Hello all,
> > 
> > there have been numerous attempts to make the numbering of mmcblk
> > devices consistent, mostly by using aliases from the DTS ([1], [2],
> > [3]), but all have been (rightfully) rejected. Unless I have
> > overlooked
> > a more recent development, no attempts for a different solution
> > were
> > made.
> 
> According to aliases attempts, I think those have failed, mainly
> because of two reasons.
> 
> 1. Arguments stating that LABELs/UUIDs are variable alternatives.
> This
> isn't the case, which I think was also concluded from the several
> earlier discussions.
> 2. Patches that tried adding support for mmc aliases, were not
> correctly coded. More precisely, what needs to be addressed is that
> the mmc core also preserves the same ids to be set for the host class
> as the block device, mmc[n] must correspond to mmcblk[n].
> 
> > 
> > As far as I can tell, the core of the issue seems to be the
> > following:
> > 
> > The existing solutions like LABELs and UUIDs are viable
> > alternatives in
> > many cases, but in particular on embedded systems, this is not
> > quite
> > sufficient: In addition to the problem that more knowledge about
> > the
> > system to boot is required in the bootloader, this approach fails
> > completely when the same firmware image exists on multiple devices,
> > for
> > example on an eMMC and an SD card - not an entirely uncommon
> > situation
> > during the development of embedded systems.
> > 
> > With udev, I can refer to a specific partition using a path like
> > /dev/disk/by-path/platform-2194000.usdhc-part2. In [4] it was
> > proposed
> > to add a way to refer to a device path/phandle from the kernel
> > command
> > line. Has there been any progress on this proposal?
> 
> Lots of time during the years I have been approached, both publicly
> and offlist, about whether it would be possible to add support for
> "consistent" mmcblk devices. To me, I am fine with the aliases
> approach, as long as it gets implemented correctly.


It seems the principal technical problem is the one described here:

https://www.spinics.net/lists/linux-mmc/msg26602.html

I don't see any way to solve this completely, as there seem to be two
fundamentally conflicting requirements:

1) If a mounted SD card is replaced, it must be assigned a new
/dev/mmcblkN
2) /dev/mmcblkN should always match the configured alias IDs

What is the reason we need 1) - is it possible to have multiple eMMCs
or SD cards on a single bus, with detection at runtime? Otherwise I'd
expect this to be handled like other drives with removable media (CD,
floppy), with static device assignment.

If we can't give up on 1) for some reason, we'll have to accept that we
can't guarantee 2) unconditionally. As far as I can tell, the patches
provided by Sascha and others did that in a reasonable way: The aliases
would work in most cases - in particular for the first assignment on
boot, which is required to find the correct rootfs.

> 
> > 
> > Kind regards,
> > Matthias
> > 
> > 
> > [1] https://patchwork.kernel.org/patch/8685711/
> > [2] https://lore.kernel.org/patchwork/cover/674381/
> > [3] https://www.spinics.net/lists/linux-mmc/msg26586.html
> > [4] https://www.spinics.net/lists/linux-mmc/msg26708.html
> > 
> 
> Kind regards
> Uffe


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: (EXT) Re: Consistent block device references for root= cmdline
  2020-06-10 17:33   ` Roger Heflin
@ 2020-06-11 11:23     ` Matthias Schiffer
  0 siblings, 0 replies; 7+ messages in thread
From: Matthias Schiffer @ 2020-06-11 11:23 UTC (permalink / raw)
  To: Roger Heflin
  Cc: Al Viro, Jens Axboe, Sascha Hauer, linux-mmc, linux-block,
	Linux Kernel Mailing List, Ulf Hansson

On Wed, 2020-06-10 at 12:33 -0500, Roger Heflin wrote:
> No idea if this would still work, but back before label/uuid and lvm
> in initird I had a staticly linked "C" program that ran inside
> initrd,
> it searched for likely places a boot device could be (mounted them
> and
> looked for a file to confirm it was the right device, then unmounted
> it), and when it found the right one, it then echo's is major/minor
> numbers into /proc/sys/kernel/real-root-dev and that is used for
> root=
> without it being on the command line.  Assuming you could get
> something similar started by sytemd and/or udev inside the initrd it
> might still work.

Using an initramfs is obviously an option, but it complicates both the
build setup and boot process, so we would like to avoid making this a
hard requirement if possible.


> 
> On Wed, Jun 10, 2020 at 11:51 AM Ulf Hansson <ulf.hansson@linaro.org>
> wrote:
> > 
> > On Wed, 10 Jun 2020 at 15:15, Matthias Schiffer
> > <matthias.schiffer@ew.tq-group.com> wrote:
> > > 
> > > Hello all,
> > > 
> > > there have been numerous attempts to make the numbering of mmcblk
> > > devices consistent, mostly by using aliases from the DTS ([1],
> > > [2],
> > > [3]), but all have been (rightfully) rejected. Unless I have
> > > overlooked
> > > a more recent development, no attempts for a different solution
> > > were
> > > made.
> > 
> > According to aliases attempts, I think those have failed, mainly
> > because of two reasons.
> > 
> > 1. Arguments stating that LABELs/UUIDs are variable alternatives.
> > This
> > isn't the case, which I think was also concluded from the several
> > earlier discussions.
> > 2. Patches that tried adding support for mmc aliases, were not
> > correctly coded. More precisely, what needs to be addressed is that
> > the mmc core also preserves the same ids to be set for the host
> > class
> > as the block device, mmc[n] must correspond to mmcblk[n].
> > 
> > > 
> > > As far as I can tell, the core of the issue seems to be the
> > > following:
> > > 
> > > The existing solutions like LABELs and UUIDs are viable
> > > alternatives in
> > > many cases, but in particular on embedded systems, this is not
> > > quite
> > > sufficient: In addition to the problem that more knowledge about
> > > the
> > > system to boot is required in the bootloader, this approach fails
> > > completely when the same firmware image exists on multiple
> > > devices, for
> > > example on an eMMC and an SD card - not an entirely uncommon
> > > situation
> > > during the development of embedded systems.
> > > 
> > > With udev, I can refer to a specific partition using a path like
> > > /dev/disk/by-path/platform-2194000.usdhc-part2. In [4] it was
> > > proposed
> > > to add a way to refer to a device path/phandle from the kernel
> > > command
> > > line. Has there been any progress on this proposal?
> > 
> > Lots of time during the years I have been approached, both publicly
> > and offlist, about whether it would be possible to add support for
> > "consistent" mmcblk devices. To me, I am fine with the aliases
> > approach, as long as it gets implemented correctly.
> > 
> > > 
> > > Kind regards,
> > > Matthias
> > > 
> > > 
> > > [1] https://patchwork.kernel.org/patch/8685711/
> > > [2] https://lore.kernel.org/patchwork/cover/674381/
> > > [3] https://www.spinics.net/lists/linux-mmc/msg26586.html
> > > [4] https://www.spinics.net/lists/linux-mmc/msg26708.html
> > > 
> > 
> > Kind regards
> > Uffe


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: (EXT) Re: Consistent block device references for root= cmdline
  2020-06-11 11:20   ` Matthias Schiffer
@ 2020-07-07 14:14     ` Ulf Hansson
  2020-07-29  8:43       ` (EXT) " Matthias Schiffer
  0 siblings, 1 reply; 7+ messages in thread
From: Ulf Hansson @ 2020-07-07 14:14 UTC (permalink / raw)
  To: Matthias Schiffer
  Cc: Al Viro, Jens Axboe, Sascha Hauer, linux-mmc, linux-block,
	Linux Kernel Mailing List

On Thu, 11 Jun 2020 at 13:20, Matthias Schiffer
<matthias.schiffer@ew.tq-group.com> wrote:
>
> On Wed, 2020-06-10 at 16:52 +0200, Ulf Hansson wrote:
> > On Wed, 10 Jun 2020 at 15:15, Matthias Schiffer
> > <matthias.schiffer@ew.tq-group.com> wrote:
> > >
> > > Hello all,
> > >
> > > there have been numerous attempts to make the numbering of mmcblk
> > > devices consistent, mostly by using aliases from the DTS ([1], [2],
> > > [3]), but all have been (rightfully) rejected. Unless I have
> > > overlooked
> > > a more recent development, no attempts for a different solution
> > > were
> > > made.
> >
> > According to aliases attempts, I think those have failed, mainly
> > because of two reasons.
> >
> > 1. Arguments stating that LABELs/UUIDs are variable alternatives.
> > This
> > isn't the case, which I think was also concluded from the several
> > earlier discussions.
> > 2. Patches that tried adding support for mmc aliases, were not
> > correctly coded. More precisely, what needs to be addressed is that
> > the mmc core also preserves the same ids to be set for the host class
> > as the block device, mmc[n] must correspond to mmcblk[n].
> >
> > >
> > > As far as I can tell, the core of the issue seems to be the
> > > following:
> > >
> > > The existing solutions like LABELs and UUIDs are viable
> > > alternatives in
> > > many cases, but in particular on embedded systems, this is not
> > > quite
> > > sufficient: In addition to the problem that more knowledge about
> > > the
> > > system to boot is required in the bootloader, this approach fails
> > > completely when the same firmware image exists on multiple devices,
> > > for
> > > example on an eMMC and an SD card - not an entirely uncommon
> > > situation
> > > during the development of embedded systems.
> > >
> > > With udev, I can refer to a specific partition using a path like
> > > /dev/disk/by-path/platform-2194000.usdhc-part2. In [4] it was
> > > proposed
> > > to add a way to refer to a device path/phandle from the kernel
> > > command
> > > line. Has there been any progress on this proposal?
> >
> > Lots of time during the years I have been approached, both publicly
> > and offlist, about whether it would be possible to add support for
> > "consistent" mmcblk devices. To me, I am fine with the aliases
> > approach, as long as it gets implemented correctly.
>
>
> It seems the principal technical problem is the one described here:
>
> https://www.spinics.net/lists/linux-mmc/msg26602.html
>
> I don't see any way to solve this completely, as there seem to be two
> fundamentally conflicting requirements:
>
> 1) If a mounted SD card is replaced, it must be assigned a new
> /dev/mmcblkN
> 2) /dev/mmcblkN should always match the configured alias IDs
>
> What is the reason we need 1) - is it possible to have multiple eMMCs
> or SD cards on a single bus, with detection at runtime?

Yes. The mmc_bus_type holds all cards - all discovered at runtime.

> Otherwise I'd
> expect this to be handled like other drives with removable media (CD,
> floppy), with static device assignment.
>
> If we can't give up on 1) for some reason, we'll have to accept that we
> can't guarantee 2) unconditionally. As far as I can tell, the patches
> provided by Sascha and others did that in a reasonable way: The aliases
> would work in most cases - in particular for the first assignment on
> boot, which is required to find the correct rootfs.

Well, if we would pre-parse the DTB to look for all "mmc block
aliases" and keep a mark of those ids as being reserved, then we
should be able to cope with both 1) and 2).

>
> >
> > >
> > > Kind regards,
> > > Matthias
> > >
> > >
> > > [1] https://patchwork.kernel.org/patch/8685711/
> > > [2] https://lore.kernel.org/patchwork/cover/674381/
> > > [3] https://www.spinics.net/lists/linux-mmc/msg26586.html
> > > [4] https://www.spinics.net/lists/linux-mmc/msg26708.html
> > >
> >

Kind regards
Uffe

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: (EXT) Re: (EXT) Re: Consistent block device references for root= cmdline
  2020-07-07 14:14     ` Ulf Hansson
@ 2020-07-29  8:43       ` Matthias Schiffer
  0 siblings, 0 replies; 7+ messages in thread
From: Matthias Schiffer @ 2020-07-29  8:43 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Al Viro, Jens Axboe, Sascha Hauer, linux-mmc, linux-block,
	Linux Kernel Mailing List

On Tue, 2020-07-07 at 16:14 +0200, Ulf Hansson wrote:
> On Thu, 11 Jun 2020 at 13:20, Matthias Schiffer
> <matthias.schiffer@ew.tq-group.com> wrote:
> > 
> > On Wed, 2020-06-10 at 16:52 +0200, Ulf Hansson wrote:
> > > On Wed, 10 Jun 2020 at 15:15, Matthias Schiffer
> > > <matthias.schiffer@ew.tq-group.com> wrote:
> > > > 
> > > > Hello all,
> > > > 
> > > > there have been numerous attempts to make the numbering of
> > > > mmcblk
> > > > devices consistent, mostly by using aliases from the DTS ([1],
> > > > [2],
> > > > [3]), but all have been (rightfully) rejected. Unless I have
> > > > overlooked
> > > > a more recent development, no attempts for a different solution
> > > > were
> > > > made.
> > > 
> > > According to aliases attempts, I think those have failed, mainly
> > > because of two reasons.
> > > 
> > > 1. Arguments stating that LABELs/UUIDs are variable alternatives.
> > > This
> > > isn't the case, which I think was also concluded from the several
> > > earlier discussions.
> > > 2. Patches that tried adding support for mmc aliases, were not
> > > correctly coded. More precisely, what needs to be addressed is
> > > that
> > > the mmc core also preserves the same ids to be set for the host
> > > class
> > > as the block device, mmc[n] must correspond to mmcblk[n].
> > > 
> > > > 
> > > > As far as I can tell, the core of the issue seems to be the
> > > > following:
> > > > 
> > > > The existing solutions like LABELs and UUIDs are viable
> > > > alternatives in
> > > > many cases, but in particular on embedded systems, this is not
> > > > quite
> > > > sufficient: In addition to the problem that more knowledge
> > > > about
> > > > the
> > > > system to boot is required in the bootloader, this approach
> > > > fails
> > > > completely when the same firmware image exists on multiple
> > > > devices,
> > > > for
> > > > example on an eMMC and an SD card - not an entirely uncommon
> > > > situation
> > > > during the development of embedded systems.
> > > > 
> > > > With udev, I can refer to a specific partition using a path
> > > > like
> > > > /dev/disk/by-path/platform-2194000.usdhc-part2. In [4] it was
> > > > proposed
> > > > to add a way to refer to a device path/phandle from the kernel
> > > > command
> > > > line. Has there been any progress on this proposal?
> > > 
> > > Lots of time during the years I have been approached, both
> > > publicly
> > > and offlist, about whether it would be possible to add support
> > > for
> > > "consistent" mmcblk devices. To me, I am fine with the aliases
> > > approach, as long as it gets implemented correctly.
> > 
> > 
> > It seems the principal technical problem is the one described here:
> > 
> > https://www.spinics.net/lists/linux-mmc/msg26602.html
> > 
> > I don't see any way to solve this completely, as there seem to be
> > two
> > fundamentally conflicting requirements:
> > 
> > 1) If a mounted SD card is replaced, it must be assigned a new
> > /dev/mmcblkN
> > 2) /dev/mmcblkN should always match the configured alias IDs
> > 
> > What is the reason we need 1) - is it possible to have multiple
> > eMMCs
> > or SD cards on a single bus, with detection at runtime?
> 
> Yes. The mmc_bus_type holds all cards - all discovered at runtime.
> 
> > Otherwise I'd
> > expect this to be handled like other drives with removable media
> > (CD,
> > floppy), with static device assignment.
> > 
> > If we can't give up on 1) for some reason, we'll have to accept
> > that we
> > can't guarantee 2) unconditionally. As far as I can tell, the
> > patches
> > provided by Sascha and others did that in a reasonable way: The
> > aliases
> > would work in most cases - in particular for the first assignment
> > on
> > boot, which is required to find the correct rootfs.
> 
> Well, if we would pre-parse the DTB to look for all "mmc block
> aliases" and keep a mark of those ids as being reserved, then we
> should be able to cope with both 1) and 2).

Hello Ulf,

it seems to me like Sascha's patches from 2014 do precisely that:

https://www.spinics.net/lists/linux-mmc/msg26587.html
https://www.spinics.net/lists/linux-mmc/msg26588.html

I haven't looked into porting this to a modern kernel yet, but do you
think that the approach is sound?



> 
> > 
> > > 
> > > > 
> > > > Kind regards,
> > > > Matthias
> > > > 
> > > > 
> > > > [1] https://patchwork.kernel.org/patch/8685711/
> > > > [2] https://lore.kernel.org/patchwork/cover/674381/
> > > > [3] https://www.spinics.net/lists/linux-mmc/msg26586.html
> > > > [4] https://www.spinics.net/lists/linux-mmc/msg26708.html
> > > > 
> 
> Kind regards
> Uffe


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, back to index

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-10 13:15 Consistent block device references for root= cmdline Matthias Schiffer
2020-06-10 14:52 ` Ulf Hansson
2020-06-10 17:33   ` Roger Heflin
2020-06-11 11:23     ` (EXT) " Matthias Schiffer
2020-06-11 11:20   ` Matthias Schiffer
2020-07-07 14:14     ` Ulf Hansson
2020-07-29  8:43       ` (EXT) " Matthias Schiffer

Linux-mmc Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mmc/0 linux-mmc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mmc linux-mmc/ https://lore.kernel.org/linux-mmc \
		linux-mmc@vger.kernel.org
	public-inbox-index linux-mmc

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-mmc


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git