Message-ID: <20160429224407.GF19428@n2100.arm.linux.org.uk>
Date:	Fri, 29 Apr 2016 23:44:07 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Ulf Hansson <ulf.hansson@...aro.org>,
	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@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	Brian Norris <computersforpeace@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Heiko Stuebner <heiko@...ech.de>,
	Jisheng Zhang <jszhang@...vell.com>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	devicetree-spec@...r.kernel.org,
	Mark Rutland <mark.rutland@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Venu Byravarasu <vbyravarasu@...dia.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Jon Hunter <jonathanh@...dia.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Grant Grundler <grundler@...omium.org>,
	Kumar Gala <galak@...eaurora.org>,
	"Luca Porzio (lporzio)" <lporzio@...ron.com>,
	Rob Herring <robh+dt@...nel.org>,
	Chaotian Jing <chaotian.jing@...iatek.com>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	Sudeep Holla <sudeep.holla@....com>,
	zhonghui.fu@...ux.intel.com, kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk
 numbering w/ device tree

On Fri, Apr 29, 2016 at 03:22:50PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Fri, Apr 29, 2016 at 3:16 PM, Russell King - ARM Linux
> <linux@....linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 02:56:38PM -0700, Doug Anderson wrote:
> >> Russell,
> >>
> >> On Fri, Apr 29, 2016 at 2:50 PM, Russell King - ARM Linux
> >> <linux@....linux.org.uk> wrote:
> >> > On Fri, Apr 29, 2016 at 02:39:35PM -0700, Doug Anderson wrote:
> >> > [didn't read most of your reply]
> >> >
> >> >> Really I just reposted it several times because I notice that you seem
> >> >> to ignore many points of my emails.  I was really hoping to get you to
> >> >> address this point.  I notice that you still didn't.  Either you are
> >> >> just trying to annoy me, or you don't have an answer to how my patch
> >> >> series hurts you.
> >> >
> >> > I don't see you treating Rob with the same contempt that you have
> >> > treated me in this thread, despite Rob and myself both telling you
> >> > basically the same thing.
> >>
> >> Rob wrote a nice thoughtful reply and I tried to give a nice
> >> thoughtful reply back to him.  He raised some good points and I raised
> >> some good points back to him.  I look forward to his future thoughts
> >> on the topic.
> >
> > Meanwhile, I've pointed out that you appear to be coming from a
> > misunderstanding (that's certainly clear because you believed
> > initially that grub did something it doesn't), showing that the
> > "problem" you have is no different from the majority of other
> > systems running Linux, and you treat me with contempt.
> >
> > What are you going to do to resolve this?
> 
> As I tried to indicate in earlier emails, I don't actually care how
> grub works in this case.  It was originally meant to illustrate the
> other people's workflows and mine are not the same.  If they have a
> solution that works for them, that's great.

... and so far you haven't really showed how your workflow is soo
different from that found on a typical x86 or ARM platform not using
coreboot.  Give an example of how your workflow would differ from
using u-boot.

> I want my MMC and MMCBLK device numbers to be sane and consistent to
> help me parse through dmesg and sysfs.  If it happens to also make it
> easy / possible to specify a root filesystem using "mmcblkN" that's
> great and I'll probably take advantage of that.

While I can relate to that as a desire, the idea of having a stable
device namespace is something that has been rejected by kernel
developers over quite a period of time for all sorts of devices.

> I'm very sorry if those using SATA and ATA disks don't have a way to
> get sane and consistent device number ordering.  I really am.  ...but
> just because they don't have a well defined ordering doesn't mean
> those of us using MMC should have to suffer.  ...and I don't think
> giving a sane ordering to MMC devices hurts anyone, does it?

My reply would be... why should MMC have special handling that no
other subsystem has?

Here's another example.  Plug in several USB serial adapters.  Which
USB serial /dev/ttyUSB* device corresponds to which adapter?  The
answer is... it depends on the order you plug them in, which could
well be different from the order in which they are found if the
machine reboots.  That's a very real problem.

However, the answer to this problem is not to find some way to bind
a particular /dev/ttyUSB* node to a particular USB device, but to
use the solution(s) already provided - iow, /dev/serial/by-id or
/dev/serial/by-path trees which give a stable view of these devices.

Now, while that allows the appropriate /dev/ttyUSB* device to be
found, it doesn't solve the "which ttyUSB* entry in the kernel
message log corresponds with which adapter" (which is the basis
of your point #1.)  That's not solved, and isn't purposely isn't
solved for any kernel subsystem.

Another example - I have boards here with multiple RTCs... guess
what happens with those?  Yep, same problem.  They get dynamic
/dev/rtc* assignment.

Another example - I have a board with three ethernet devices...
yep, same problem again, the order depends on the driver probe
order, and they get dynamically assigned eth* names.

The list of subsystems that have this property is large, because
it's all dependent on the device/driver probing order.

So, please answer this question: why should _only_ MMC be treated
as a special case?  Please give a _technical_ reason rather than a
_personal_ reason.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Powered by blists - more mailing lists