linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Måns Rullgård" <mans@mansr.com>
To: Stefan Agner <stefan@agner.ch>
Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	Marek Vasut <marex@denx.de>, Tim Harvey <tharvey@gateworks.com>,
	Douglas Anderson <dianders@chromium.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Jaehoon Chung <jh80.chung@samsung.com>,
	shawn.lin@rock-chips.com, Adrian Hunter <adrian.hunter@intel.com>,
	Linux MMC List <linux-mmc@vger.kernel.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Jisheng Zhang <jszhang@marvell.com>,
	linux-rockchip@lists.infradead.org,
	devicetree-spec@vger.kernel.org,
	Mark Rutland <mark.rutland@arm.com>,
	open list <linux-kernel@vger.kernel.org>,
	vbyravarasu@nvidia.com, Lars-Peter Clausen <lars@metafoo.de>,
	jonathanh@nvidia.com, linux-arm-kernel@lists.infradead.org,
	devicetree@vger.kernel.org, Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	grundler@chromium.org, Kumar Gala <galak@codeaurora.org>,
	lporzio@micron.com, Rob Herring <robh+dt@kernel.org>,
	chaotian.jing@mediatek.com,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	sudeep.holla@arm.com, zhonghui.fu@linux.intel.com,
	kirill.shutemov@linux.intel.com
Subject: Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree
Date: Sun, 17 Mar 2019 16:48:24 +0000	[thread overview]
Message-ID: <yw1xbm2930rr.fsf@mansr.com> (raw)
In-Reply-To: <c23d6c4edf92d58aec86da811eaa97a5@agner.ch> (Stefan Agner's message of "Sun, 17 Mar 2019 16:05:14 +0100")

Stefan Agner <stefan@agner.ch> writes:

> On 16.03.2019 16:39, Russell King - ARM Linux admin wrote:
>> On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote:
>>> If you have a FS or partition table there, it does.
>>> If you don't, I agree ... that's a problem.
>> 
>> eMMC boot partitions are called mmcblkXbootY, and unless you have more
>> than one eMMC device on the system, they can be found either by looking
>> for /dev/mmcblk*boot* or by querying udev.  The advantage of using udev
>> is you can discover the physical device behind it by looking at DEVPATH,
>> ID_PATH, etc, but you may not have that installed on an embedded device.
>> 
>> However, as I say, just looking for /dev/mmcblk*boot* is sufficient to
>> find the eMMC boot partitions where there is just one eMMC device
>> present (which seems to be the standard setup.)
>> 
>>> > I don't care the slightest what the numbering is, as long as it is
>>> > stable.  On some hardware, with an unpatched kernel, the mmc device
>>> > numbering changes depending on whether or not an SD card is inserted on
>>> > boot.  Getting rid of that behaviour is really all I want.
>>>
>>> Agreed, that would be an improvement.
>> 
>> The mmc device numbering was tied to the mmc host numbering a while back
>> and the order that the hosts are probed should be completely independent
>> of whether a card is inserted or not:
>> 
>>         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
>>                  "mmcblk%u%s", card->host->index, subname ? subname : "");
>> 
>>         snprintf(rpmb_name, sizeof(rpmb_name),
>>                  "mmcblk%u%s", card->host->index, subname ? subname : "");
>> 
>> I suspect that Mans is quoting something from the dim and distant past
>> to confuse the issue - as shown above, it is now dependent on the host
>> numbering order not the order in which cards are inserted.
>
> Commit 9aaf3437aa72 ("mmc: block: Use the mmc host device index as the
> mmcblk device index") which came in with v4.6 enables constant mmc block
> device numbering. I can confirm that it works nicely, and it improved
> the situation a lot.

That's the answer I was looking for.  I guess we can drop these patches
from our kernels then.

> That being said, we still use a patch downstream which allows
> renumbering using an alias. We deal with a bunch of different boards
> with different SoC's. I have a couple of SD cards with various rootfs
> and use internal eMMC boot quite often as well. Remembering which board
> uses which numbering is a pain. Maintaining a patch is just easier...
> Furthermore, U-Boot allows reordering and all boards I deal with use mmc
> 0 for the internal eMMC. The aliases allow consistency.

Since pretty much every other device type supports renumbering with DT
aliases, it would make sense to do this for mmc as well.

-- 
Måns Rullgård

  parent reply	other threads:[~2019-03-17 16:48 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-29 17:32 [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree Douglas Anderson
2016-04-29 17:32 ` [PATCH v2 1/4] Documentation: mmc: Document mmc aliases Douglas Anderson
2016-04-29 17:32 ` [PATCH v2 2/4] mmc: read mmc alias from device tree Douglas Anderson
2016-04-29 17:32 ` [PATCH v2 3/4] mmc: use SD/MMC host ID for block device name ID Douglas Anderson
2016-04-29 17:32 ` [PATCH v2 4/4] ARM: dts: rockchip: Add mmc aliases for rk3288 platform Douglas Anderson
2016-04-29 18:12 ` [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree Rob Herring
2016-04-29 19:31   ` Doug Anderson
2016-04-29 19:50     ` Russell King - ARM Linux
2016-04-29 20:02       ` Doug Anderson
2016-04-29 18:12 ` Russell King - ARM Linux
2016-04-29 19:43   ` Doug Anderson
2016-04-29 19:57     ` Russell King - ARM Linux
2016-04-29 20:04       ` Doug Anderson
2016-04-29 21:13         ` Russell King - ARM Linux
2016-04-29 21:17           ` Doug Anderson
2016-04-29 21:29             ` Russell King - ARM Linux
2016-04-29 21:39               ` Doug Anderson
2016-04-29 21:50                 ` Russell King - ARM Linux
2016-04-29 21:56                   ` Doug Anderson
2016-04-29 22:16                     ` Russell King - ARM Linux
2016-04-29 22:22                       ` Doug Anderson
2016-04-29 22:44                         ` Russell King - ARM Linux
2016-04-29 23:01                           ` Doug Anderson
2016-04-29 23:58                             ` Peter Hurley
     [not found]                               ` <CAD=FV=V_YyfBOSs7BLkyhv=_5HBmf3djUWACbL6d-bwnrueDjA@mail.gmail.com>
2016-04-30  0:31                                 ` Peter Hurley
2016-04-30  2:29                                   ` Doug Anderson
2016-04-30  8:38                                   ` Russell King - ARM Linux
2016-04-30 13:23                             ` Rob Herring
2016-04-29 22:42                       ` Javier Martinez Canillas
2016-04-30 10:48                         ` Russell King - ARM Linux
2016-05-03 19:17                           ` Trent Piepho
2016-05-04  7:18   ` Pavel Machek
2016-05-04 12:25     ` Rob Herring
2016-05-04 12:46       ` Pavel Machek
2019-03-05 12:39 ` Måns Rullgård
2019-03-15 21:52   ` Tim Harvey
2019-03-15 23:00     ` Marek Vasut
2019-03-15 23:13       ` Tim Harvey
2019-03-15 23:23       ` Doug Anderson
     [not found]       ` <yw1xftrn2em9.fsf@mansr.com>
2019-03-16 12:33         ` Marek Vasut
2019-03-16 15:39           ` Russell King - ARM Linux admin
2019-03-17 15:05             ` Stefan Agner
2019-03-17 15:43               ` Russell King - ARM Linux admin
2019-03-17 15:50                 ` Marek Vasut
2019-03-17 16:48               ` Måns Rullgård [this message]
2019-03-17 16:59                 ` Russell King - ARM Linux admin
2019-03-27 17:37                   ` Tim Harvey
2019-03-27 20:54                     ` Russell King - ARM Linux admin

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=yw1xbm2930rr.fsf@mansr.com \
    --to=mans@mansr.com \
    --cc=adrian.hunter@intel.com \
    --cc=chaotian.jing@mediatek.com \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree-spec@vger.kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=galak@codeaurora.org \
    --cc=grundler@chromium.org \
    --cc=heiko@sntech.de \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jh80.chung@samsung.com \
    --cc=jonathanh@nvidia.com \
    --cc=jszhang@marvell.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=lporzio@micron.com \
    --cc=marex@denx.de \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=shawn.lin@rock-chips.com \
    --cc=stefan@agner.ch \
    --cc=sudeep.holla@arm.com \
    --cc=tharvey@gateworks.com \
    --cc=ulf.hansson@linaro.org \
    --cc=vbyravarasu@nvidia.com \
    --cc=zhonghui.fu@linux.intel.com \
    /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).