mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Trent Piepho <tpiepho@kymetacorp.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: [RFC] at24: get devfs name from dt aliase
Date: Mon, 30 Nov 2015 18:10:41 +0000	[thread overview]
Message-ID: <1448907044.4553.215.camel@rtred1test09.kymeta.local> (raw)
In-Reply-To: <20151130071651.GR11966@pengutronix.de>

On Mon, 2015-11-30 at 08:16 +0100, Sascha Hauer wrote:
> On Fri, Nov 27, 2015 at 08:37:02AM +0000, Trent Piepho wrote:
> > > -----Original Message-----
> > > From: Antony Pavlov [mailto:antonynpavlov@gmail.com]
> > > 
> > > At the moment barebox can't work correctly with more that one at24
> > > eeprom because drivers/eeprom/at24.c tries to register all eeproms as
> > > /dev/eeprom0.
> > 
> > I had this same problem with my system.  It is because different types of EEPROMs have different names and the IDs are assigned sequentially for each different name.  So if you have two 24c02 and one 24c1025, they would have the ids 0, 1, and 0.  The code that produces the IDs for the i2c devices (24c020, 24c021, 2401250) does not know that the eeprom driver will try to make cdevs with the same name pattern from all of them.
> > 
> > I did a different solution, see below, but didn't send it out as I'm not happy with it.  I thought also of an alias like this, but feel like there are also problems with that approach.
> > 
> > 1. It seems like it should not be necessary to add aliases to get the system to work at all.
> 
> Antonys patch falls back to dynamic numbering if no alias is found.

But still some eeproms will not show up with no error message.  It seems
like dynamic numbering should work better than that.

> > 2. My system also has <64 kB xloader which does not use OF to save
> > space.  So alias will not work.  I don't know of an alternative to the
> > alias system when using i2c_register_board_info().
> 
> We also have the approach of putting the name into platform_data, this
> is done with some MMC controllers. However, with an xloader wouldn't it
> be possible to just register the device which you need? You don't need
> all EEPROMs in the xloader, right?

Remains to be seen.  At this point of three types on the board, I'm
using two in the xloader.  It could change with further development.

I suppose adding the name to the platform data would be the best way to
get OF alias like naming.  Though I'd be fine with just dynamic
numbering that works, hence my simple patch to add that.


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

      reply	other threads:[~2015-11-30 18:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-27  7:29 Antony Pavlov
2015-11-27  8:37 ` Trent Piepho
2015-11-30  7:16   ` Sascha Hauer
2015-11-30 18:10     ` Trent Piepho [this message]

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=1448907044.4553.215.camel@rtred1test09.kymeta.local \
    --to=tpiepho@kymetacorp.com \
    --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