Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752806AbcD2CXL (ORCPT ); Thu, 28 Apr 2016 22:23:11 -0400 Received: from mx0b-0016f401.pphosted.com ([67.231.156.173]:36885 "EHLO mx0b-0016f401.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752244AbcD2CXJ (ORCPT ); Thu, 28 Apr 2016 22:23:09 -0400 Date: Fri, 29 Apr 2016 10:18:36 +0800 From: Jisheng Zhang To: Douglas Anderson , , CC: , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering Message-ID: <20160429101836.060ad087@xhacker> In-Reply-To: <1461884805-29466-1-git-send-email-dianders@chromium.org> References: <1461884805-29466-1-git-send-email-dianders@chromium.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-04-29_01:,, signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604290028 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2153 Lines: 50 Dear Douglas, On Thu, 28 Apr 2016 16:06:42 -0700 Douglas Anderson 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 We also need this feature. Thanks so much for upstreaming the series. Jisheng > > 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(-) >