linux-kernel - Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD=FV=UYfKfiiBNaDSk9nFi2vuRzV4dHTT=WH7D-ea=M_fgNEg@mail.gmail.com>
Date:	Fri, 29 Apr 2016 10:32:33 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Ulf Hansson <ulf.hansson@...aro.org>
Cc:	Jaehoon Chung <jh80.chung@...sung.com>,
	Shawn Lin <shawn.lin@...k-chips.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Stefan Agner <stefan@...er.ch>,
	linux-mmc <linux-mmc@...r.kernel.org>,
	Brian Norris <computersforpeace@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Mark Rutland <mark.rutland@....com>,
	Venu Byravarasu <vbyravarasu@...dia.com>,
	Justin Wang (王丁) 
	<justin.wang@...eadtrum.com>, ksumrall@...roid.com,
	Lars-Peter Clausen <lars@...afoo.de>,
	Dmitry Torokhov <dtor@...omium.org>,
	Jon Hunter <jonathanh@...dia.com>,
	Tao Huang <huangtao@...k-chips.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Paweł Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"Luca Porzio (lporzio)" <lporzio@...ron.com>,
	Rob Herring <robh+dt@...nel.org>,
	"Dong, Chuanxiao" <chuanxiao.dong@...el.com>,
	Chaotian Jing <chaotian.jing@...iatek.com>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Sudeep Holla <sudeep.holla@....com>
Subject: Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering

Ulf,

On Fri, Apr 29, 2016 at 12:21 AM, Ulf Hansson <ulf.hansson@...aro.org> wrote:
> On 29 April 2016 at 01:06, Douglas Anderson <dianders@...omium.org> wrote:
>> This series picks patches from various different places to produce what
>> I consider the best solution to getting consistent mmc and mmcblk
>> ordering.
>>
>> Why consistent ordering and why not just use UUIDs?  IMHO consistent
>> ordering solves a few different problems:
>>
>> 1. For poor, feeble-minded humans like me, have sane numbering for
>>    devices helps a lot.  When grepping through dmesg it's terribly handy
>>    if a given SDMMC device has a consistent number.  I know that I can
>>    do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
>>    the eMMC.  I know that I can do "dmesg | grep mmc1" to find info
>>    about the SD card slot.  I don't want it to matter which one probed
>>    first, I don't want it to matter if I'm working on a variant of the
>>    hardware that has the SD card slot disabled, and I don't want to care
>>    what my boot device was.  Worrying about what device number I got
>>    increases my cognitive load.
>>
>> 2. There are cases where it's not trivially easy during development to
>>    use the UUID.  Specifically I work a lot with coreboot / depthcharge
>>    as a BIOS.  When configured properly, that BIOS has a nice feature to
>>    allow you to fetch the kernel and kernel command line from TFTP by
>>    pressing Ctrl-N.  In this particular case the BIOS doesn't actually
>>    know which disk I'd like for my root filesystem, so it's not so easy
>>    for it to put the right UUID into the command line.  For this
>>    purpose, knowing that "mmcblk0" will always refer to eMMC is handy.
>>
>>
>> Jaehoon Chung (1):
>>   Documentation: mmc: Document mmc aliases
>>
>> Stefan Agner (2):
>>   mmc: read mmc alias from device tree
>>   mmc: use SD/MMC host ID for block device name ID
>>
>>  Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++++++
>>  drivers/mmc/card/block.c                      |  3 ++-
>>  drivers/mmc/core/host.c                       | 25 ++++++++++++++++++++-----
>>  3 files changed, 33 insertions(+), 6 deletions(-)
>>
>> --
>> 2.8.0.rc3.226.g39d4020
>>
>
> I believe you need to re-base this patchset as things have changed.
>
> Currently the mmc host index that gets picked at host registration
> point, will also be given to the corresponding mmc block device index.
> That's probably solving most of your concerns, but I am open to extend
> this to cover aliases as well, as to allow it to be *really*
> deterministic.

OK, got it.  Send new patch now.  :)  PTAL.