public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "Andreas Bießmann" <biessmann@corscience.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] avr32: add ATAG_BOARDINFO
Date: Wed, 13 Apr 2011 14:49:20 +0200	[thread overview]
Message-ID: <4DA59BD0.60204@corscience.de> (raw)
In-Reply-To: <20110413114401.E649D14F02E@gemini.denx.de>

Dear Wolfgang Denk,

Am 13.04.2011 13:44, schrieb Wolfgang Denk:
> Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=,
> 
> In message <1302686741-11090-1-git-send-email-biessmann@corscience.de> you wrote:
>> This patch adds a new ATAG_BORADINFO to U-Boot. This tag is intended to hand
>> over the bd->bi_board_number to the linux kernel for early stage board
>> information like a board revision or other kind of board specific decisions
>> necessary before the linux peripherial drivers are up.
> 
> Is this ATAG_BOARDINFO already supported by the ARM Linux kernel?  I
> cannot find it there, nor can I find any postings referencing it on
> linux-arm-kernel

No, it is avr32!

Please see
http://lists.avr32linux.org/pipermail/kernel/2011-April/005593.html
and http://article.gmane.org/gmane.linux.kernel/1125654

> I think it's a fundamentally wrong approach to take, like the
> MACH-ID's have been right from day one.  By now we should have learned
> that lesson and not repeat it again.

Well, there is no fixed mechanism planed for using this information in
linux kernel. But we use it in our (not mainline) product. In one
comment in mentioned threads above I explain why this is needed. In
short I like to pin that ATAG key value to that function to have it
reserved if one other thinks to introduce another ATAG key not using
that one.

> ARM Linux is in the process of being converted to using the Device
> Tree for description of hardware specifics, so this is the way to go
> for new things.

Well, you may be right here, but I don't think we get so much AVR32 SoC
or boards in future as we have on ARM side.

> From my point of view, I would like to reject this patch.  If you
> however manage to get this accepted for mainline Linux, then maybe I
> reconsider.

For now this submission is mostly to reference from linux-list to have a
test basis for other users. I will resend or trigger the list, if my
patch in linux tree will be accepted.

regards

Andreas Bie?mann

  reply	other threads:[~2011-04-13 12:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-13  9:25 [U-Boot] [PATCH] avr32: add ATAG_BOARDINFO Andreas Bießmann
2011-04-13 11:44 ` Wolfgang Denk
2011-04-13 12:49   ` Andreas Bießmann [this message]
2011-04-14  8:33   ` Andreas Bießmann
2011-04-14 12:00     ` Wolfgang Denk
2011-04-14 12:50       ` Reinhard Meyer
2011-04-14 23:02         ` Wolfgang Denk
2011-04-19 16:37           ` Reinhard Meyer

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=4DA59BD0.60204@corscience.de \
    --to=biessmann@corscience.de \
    --cc=u-boot@lists.denx.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