All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: "Måns Rullgård" <mans@mansr.com>
Cc: "Benoît Cousson" <bcousson@baylibre.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	linux-omap@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: dts: am33xx: add aliases for mmc interfaces
Date: Thu, 4 Feb 2021 08:45:42 +0200	[thread overview]
Message-ID: <YBuYFkNFxH8Ngtny@atomide.com> (raw)
In-Reply-To: <yw1xczxoas3l.fsf@mansr.com>

* Måns Rullgård <mans@mansr.com> [210129 11:40]:
> Tony Lindgren <tony@atomide.com> writes:
> 
> > * Mans Rullgard <mans@mansr.com> [210128 18:09]:
> >> Without DT aliases, the numbering of mmc interfaces is unpredictable.
> >> Adding them makes it possible to refer to devices consistently.  The
> >> popular suggestion to use UUIDs obviously doesn't work with a blank
> >> device fresh from the factory.
> >> 
> >> See fa2d0aa96941 "mmc: core: Allow setting slot index via device tree
> >> alias" for more discussion.
> >
> > Sounds good to me, but will wait a few days before applying to make sure
> > this is still what we have agreed on :)
> 
> If it helps the decision, my existing systems fail to boot without
> something like this due to the eMMC moving from /dev/mmcblk1 to mmcblk0,
> at least sometimes.  I guess the kernel cares deeply about not breaking
> userspace, except when it doesn't give a damn.
> 
> I've been fighting this problem in various forms for the last 10 years
> or so, and I was hoping it would finally be over.

Yes this issue has been bugging folks for long time. Applying into fixes
thanks.

Tony

      parent reply	other threads:[~2021-02-04  6:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-28 15:56 [PATCH] ARM: dts: am33xx: add aliases for mmc interfaces Mans Rullgard
     [not found] ` <YBPGyuNQhSypIf1y@atomide.com>
     [not found]   ` <yw1xczxoas3l.fsf@mansr.com>
2021-02-04  6:45     ` Tony Lindgren [this message]

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=YBuYFkNFxH8Ngtny@atomide.com \
    --to=tony@atomide.com \
    --cc=bcousson@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mans@mansr.com \
    --cc=robh+dt@kernel.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.