mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: David Jander <david.jander@protonic.nl>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: /dev/disk0 vs /dev/mmc0
Date: Tue, 8 Oct 2013 09:02:29 +0200	[thread overview]
Message-ID: <20131008090229.051cd853@archvile> (raw)
In-Reply-To: <20131007201936.GW30088@pengutronix.de>

On Mon, 7 Oct 2013 22:19:36 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:

> On Mon, Oct 07, 2013 at 11:57:35AM +0200, David Jander wrote:
> > On Mon, 7 Oct 2013 08:41:11 +0200
> > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > 
> > > On Mon, Oct 07, 2013 at 08:32:03AM +0200, David Jander wrote:
> > > > 
> > > > Dear Sascha,
> > > > 
> > > > On Sun, 6 Oct 2013 12:39:50 +0200
> > > > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > > > 
> > > > > It doesn't interfere with the kernel. The kernel currently ignores
> > > > > this aliases. There are patches floating to let the kernel honor this
> > > > > aliases, but then they should simply have the same effect as they
> > > > > have in barebox.
> > > > 
> > > > That doesn't _feel_ right. Changing standard device names in Linux via
> > > > aliases in the DT might be a fancy idea, but it'd have a different
> > > > reason/use-case than in the case of barebox. IMHO using the same DT for
> > > > both seems to be the Right Thing (tm) to do, but then the semantics
> > > > must be the same also. If I need aliases in the DT only to be able to
> > > > tell devices apart from each other in barebox, while in Linux the
> > > > effect would only be a rather inconvenient renaming of devices with no
> > > > other added value, I think we need a different way to differentiate
> > > > devices in barebox. Why not just use a simple driver-provided prefix
> > > > (mci, mmc, usb, sata, etc...) for now?
> > > 
> > > That's not enough. We also need a fixed numbering. Otherwise a
> > > nonremovable eMMC and a removable SD card change their device names
> > > depending on the detect order.
> > 
> > True. Can host->dev.id be used? Should be fixed AFAICS...
> 
> host->dev.id depends on the probe order.

:-(

> > > Using aliases to provide a numbering is done in the Kernel aswell at
> > > least for gpios, uarts and i2c busses, so expanding this scheme to
> > > mmc/sd slots doesn't feel too wrong to me.
> > 
> > Yes, but we are doing it in barebox now only because there is no other way
> > to tell devices apart from each other. While the MMC device being called
> > "mmcblk0" or whatever in Linux is perfectly fine (no need for alias),
> 
> Linux has exactly the same problem. There are enough systems on which
> the eMMC changes its name depending on a SD card being plugged in or
> not.

Yes, but you have udev/mdev hotplugging and the sysfs interface to figure out
what you need to know. Barebox has nothing like that AFAICS.

> > in
> > barebox the device is now named "disk0", and there is no way of knowing
> > what "disk0" actually is. Using DT-aliases for that purpose seems wrong to
> > me. Why was this changed anyway? Introduction of some common "disk" layer
> > (like scsi-disk on Linux)? Or just for the sake of confusing it with other
> > "disk"-like devices?
> 
> It has always been diskx on barebox, this behaviour hasn't changed.

You are right. Sorry for the confusion. There were aliases in barebox's
version of imx53.dtsi which went missing somehow in my tree. I have been
merging stuff from mainline Linux....
That leads me to the question: What is the intended relationship between
barebox and Linux kernel DTS files? Which one is supposed to be the "master" or
"upstream" version? Aren't they supposed to be kept in sync somehow? At least
the basic SoC-specific .dtsi files?

Best regards,

-- 
David Jander
Protonic Holland.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2013-10-08  7:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-03 15:17 David Jander
2013-10-03 19:23 ` Jean-Christophe PLAGNIOL-VILLARD
2013-10-04  7:17   ` David Jander
2013-10-06 10:39     ` Sascha Hauer
2013-10-06 18:40       ` Jean-Christophe PLAGNIOL-VILLARD
     [not found]       ` <20131007083203.7aa17d5b@archvile>
2013-10-07  6:41         ` Sascha Hauer
2013-10-07  9:57           ` David Jander
2013-10-07 20:19             ` Sascha Hauer
2013-10-08  7:02               ` David Jander [this message]
2013-10-08  7:45                 ` Lucas Stach
2013-10-08  9:13                   ` David Jander
2013-10-08  9:39                     ` Lucas Stach
2013-10-08 13:47                       ` David Jander
2013-10-08 14:11                         ` Lucas Stach
2013-10-08 14:49                           ` David Jander
2013-10-08 14:58                             ` Lucas Stach

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=20131008090229.051cd853@archvile \
    --to=david.jander@protonic.nl \
    --cc=barebox@lists.infradead.org \
    --cc=s.hauer@pengutronix.de \
    /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