From: Benjamin Herrenschmidt <benh@kernel•crashing.org>
To: Val Henson <val@nmt•edu>
Cc: <linuxppc-dev@lists•linuxppc.org>
Subject: Re: EV-64260-BP & GT64260 bi_recs
Date: Sun, 24 Mar 2002 17:46:49 +0100 [thread overview]
Message-ID: <20020324164649.32343@smtp.wanadoo.fr> (raw)
In-Reply-To: <20020324120930.A14640@boardwalk>
>
>I had an amazing and brilliant insight (which I'm sure everyone else
>has already had). :) The kernel just ignores bi_recs it doesn't
>understand. Really, you don't need any BI_DEV_TYPE's for non-core
>kernel code - just a type that the kernel is guaranteed never to use
>for any other bi_rec type.
Of course you want to add whatever additional bi_recs, and among the things
I propose is the definition that the kernel will only use all-lowercase
bi_rec types for it's own use leaving any other combo for other uses.
The point is to pass informations to drivers in a bit cleaner
way than inventing a bi_rec type for each combination of driver
and attribute (expecially if a given board can decline in several
models with, for example, a different number of on-chip eth controllers,
or things like that).
>How about one BI_IGNORE type, and driver writers and firmware authors
>can put whatever they feel like inside that bi_rec? The BI_IGNORE
>bi_rec can contain whatever you want - more bi_recs, object code,
>random data - and it would be the driver and firmware writers'
>responsibility to make them match up. I personally think this is an
>awful idea, but it would give everyone the freedom they want while
>staying within the very nice bi_rec interface. The rest of the
>bi_recs, the ones that the core kernel code will interpret, can be
>simple, one-dimensional bi_recs. What do you think, Ben?
Which means that as soon as you want to add more infos, you will have
to deal with all the pre-bi_rec problems when you own stuffs have to
evolve. (versionning etc...).
Again, for anything not realted to device drivers infos (things like
HW ethernet addresses, PHY IDs, eventually interrupt routing), a whole
bunch of bi_rec types will be left free by the kernel for use by your
proprietary stuff the way you want, so you can pretty much define
whatever you want (or not, it's up to you).
But, I feel it's more convenient for drivers to use this signle-level
BI_DEVICE bi_rec that contains itself bi_recs.
>I really agree with Dan Malek on this - we shouldn't use bi_recs as a
>way to reimplement methods of passing information that already exist,
>for example, the __setup() functions. It should be a way of passing
>information that only a bootloader can know, such as the location of a
>ramdisk, or the command line that the user typed into the bootloader.
Which is exactly what I'm proposing. Passing generic informations like
CPU core clocks, command line, ramdisk, etc... is done via bi_recs at
the toplevel.
The BI_DEVICE bi_rec's allow to provide other informations that are
also only known by the firmware (most of the time), like eth MAC
address, PHY wiring, or other kind of wiring informations related
to a given rev. of a board, etc... provided that those infos
concern a given driver for a specific device. It's also a convenient
way to provide interrupt routing informations.
>People who don't agree with this philosophy can shove whatever they
>like into the BI_IGNORE record type, and suffer the consequences. :)
No. A BI_IGNORE makes no sense. A whole class of bi_rec types guaranteed
not to be used by the kernel makes sense. I don't want to fix the kernel
side of the problem just to put back the same problem on my vendor specific
infos (I have various ones; depending on the product, they can have to evolve
especially as I have to maintain different revisions of the produce, and if
possible with the same kernel / firmware). It's always a win when you don't
have to change a line of the kernel code because your HW engineer wired an
interrupt differently. That means I only have to update the tables in
the firmware and not touch the kernel version.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-03-24 16:46 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-20 0:43 EV-64260-BP & GT64260 bi_recs Michael Sokolov
2002-03-19 23:00 ` Mark A. Greer
2002-03-20 7:55 ` Wolfgang Denk
2002-03-20 13:19 ` benh
2002-03-20 15:30 ` Michael Sokolov
2002-03-20 16:19 ` Tom Rini
2002-03-20 16:58 ` benh
2002-03-23 4:01 ` Val Henson
2002-03-23 13:07 ` Murray Jensen
2002-03-24 12:22 ` Benjamin Herrenschmidt
2002-03-24 12:20 ` Benjamin Herrenschmidt
2002-03-24 19:09 ` Val Henson
2002-03-24 16:46 ` Benjamin Herrenschmidt [this message]
2002-03-25 8:51 ` Geert Uytterhoeven
2002-03-24 18:16 ` Benjamin Herrenschmidt
2002-03-26 2:16 ` Val Henson
2002-03-26 10:05 ` Benjamin Herrenschmidt
2002-03-24 19:38 ` Geert Uytterhoeven
2002-03-24 16:55 ` Benjamin Herrenschmidt
2002-03-24 17:18 ` Benjamin Herrenschmidt
2002-03-25 0:44 ` Murray Jensen
2002-03-25 22:05 ` Val Henson
2002-03-26 3:21 ` Val Henson
2002-03-26 4:14 ` Murray Jensen
2002-03-26 10:14 ` benh
2002-03-26 12:05 ` Gabriel Paubert
2002-03-26 12:18 ` benh
2002-03-26 23:24 ` Mark A. Greer
2002-03-26 21:40 ` benh
2002-03-27 15:13 ` Mark A. Greer
-- strict thread matches above, loose matches on Subject: below --
2002-03-27 20:09 Michael Sokolov
2002-03-27 18:53 Michael Sokolov
2002-03-27 19:37 ` benh
2002-03-27 18:34 Michael Sokolov
2002-03-27 18:32 Michael Sokolov
2002-03-27 18:46 ` benh
2002-03-27 18:03 Michael Sokolov
2002-03-27 16:16 ` Mark A. Greer
2002-03-27 16:24 ` Mark A. Greer
2002-03-27 18:40 ` benh
2002-03-27 18:02 ` Mark A. Greer
2002-03-27 18:06 ` Mark A. Greer
2002-03-27 17:32 Michael Sokolov
2002-03-27 15:46 ` Mark A. Greer
2002-03-27 17:48 ` benh
2002-03-27 15:59 ` Mark A. Greer
2002-03-27 2:37 Michael Sokolov
2002-03-26 21:52 ` benh
2002-03-27 14:15 ` Matt Porter
2002-03-27 15:10 ` Mark A. Greer
2002-03-27 15:15 ` Mark A. Greer
2002-03-27 17:47 ` benh
2002-03-28 9:14 ` Geert Uytterhoeven
2002-03-27 1:35 Michael Sokolov
2002-03-26 23:48 ` Mark A. Greer
2002-03-24 16:02 Michael Sokolov
2002-03-21 2:13 Michael Sokolov
2002-03-21 6:39 ` Dan Malek
2002-03-31 8:32 ` Paul Mackerras
2002-04-01 18:39 ` Dan Malek
2002-04-02 5:32 ` Paul Mackerras
2002-04-02 16:33 ` Tom Rini
2002-04-02 17:29 ` Dan Malek
2002-04-02 14:42 ` Armin
2002-04-02 20:12 ` Tom Rini
2002-04-02 21:02 ` Dan Malek
2002-04-03 0:21 ` Tom Rini
[not found] <dan@embeddededge.com>
[not found] ` <3C98DA15.50302@embeddededge.com>
2002-03-21 1:11 ` Murray Jensen
2002-03-21 6:50 ` Dan Malek
2002-03-21 11:05 ` Murray Jensen
2002-03-21 1:10 Michael Sokolov
2002-03-21 0:57 Michael Sokolov
2002-03-21 6:58 ` Dan Malek
2002-03-21 0:47 Michael Sokolov
[not found] <3C98B189.78A92DFE@mvista.com>
2002-03-20 18:12 ` Wolfgang Denk
[not found] ` <3C98DB49.2C3A2F79@mvista.com>
2002-03-23 3:49 ` Val Henson
2002-03-20 17:11 Michael Sokolov
2002-03-20 18:06 ` Wolfgang Denk
2002-03-20 17:04 Michael Sokolov
2002-03-20 17:25 ` Tom Rini
2002-03-21 20:36 ` Troy Benjegerdes
2002-03-21 19:17 ` Mark A. Greer
2002-03-21 21:36 ` Jim Potter
[not found] <20020320164025.31626@mailhost.mipsys.com>
2002-03-20 16:59 ` Wolfgang Denk
[not found] <20020320155551.GD3762@opus.bloom.county>
2002-03-20 16:18 ` Wolfgang Denk
[not found] <20020320150119.GB3762@opus.bloom.county>
2002-03-20 15:43 ` Wolfgang Denk
2002-03-20 1:02 Michael Sokolov
[not found] <20020320000500.GV3762@opus.bloom.county>
2002-03-20 0:28 ` Wolfgang Denk
[not found] <20020319235815.GU3762@opus.bloom.county>
2002-03-20 0:24 ` Wolfgang Denk
[not found] <20020319224420.GO3762@opus.bloom.county>
2002-03-19 23:00 ` Wolfgang Denk
2002-03-20 0:03 ` Gabriel Paubert
[not found] <20020319231628.GQ3762@opus.bloom.county>
2002-03-19 23:46 ` Wolfgang Denk
[not found] <3C97A9C1.EBA150B6@mvista.com>
2002-03-19 23:36 ` Wolfgang Denk
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=20020324164649.32343@smtp.wanadoo.fr \
--to=benh@kernel$(echo .)crashing.org \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
--cc=val@nmt$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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