linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Robert Schwebel <r.schwebel@pengutronix.de>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: Question on mpc52xx_common.c
Date: Thu, 10 Apr 2008 08:39:35 +0200	[thread overview]
Message-ID: <20080410063935.GD13814@pengutronix.de> (raw)
In-Reply-To: <fa686aa40804081426u2c2a530ej8ecb6ce9f8fb49a0@mail.gmail.com>

Hi Grant,

On Tue, Apr 08, 2008 at 03:26:11PM -0600, Grant Likely wrote:
> I disagree and that is not my point.

Well, having something like a device tree that describes the hardware is
definitely a good thing, in general.

> Now, if out-of-tree ports continue to break then we've got a problem
> that needs to be fixed.

Right, that's the point. Don't get me wrong, I'm deeply against
maintaining large code bases out-of-tree. But it shows in this case that
we have a maintenance problem with the current oftree concept.

When a simple BSP that supports almost nothing than CPU, mem, serial
console and flash needs > 1 week of hacking from an experienced kernel
hacker, just in order to get all the string changes right, something is
wrong.

> Once a binding is established (which usually takes a few kernel
> releases) it should be very stable and even if the definition of ideal
> is changed, backwards compatibility must be maintained.

That's theory, but in practise we see it changing every second day.

> >  The ARM method of using just a device number is so much easier ...
>
> Only if the assumption is made that very little data needs to be
> shared between the kernel and the firmware. The moment you try to do
> something more complex you either have the nightmare of bd_info or you
> use a structured data format (like the device tree)

I agree that the usual ARM hardwares are much less complicated and
configurable than what's available elsewhere. We usually need the
information "this is board FOO_BAR", maybe, if it is a module, on a
"BAZ" baseboard, and this is everything we need to register the platform
devices in some arch/arm/mach-*/my_cpu.c and arch/arm/mach-*/my_board.c
file.

> On another node, there are platforms where a device number is
> unworkable. For example, for Linux on an FPGA like the Xilinx Virtex,
> there would need to be a new platform number every time the FPGA
> bitstream was updated because it is effectively an entirely different
> platform.

Well, we have done FPGA based boards with ARM in the past, and we've
just added hardware auto-detection to the IP cores.

> Finally, using a device number means you need to encode into the
> kernel the exact layout of every platform it supports.  That adds up
> to a lot of code in a real hurry; even if most of it is just
> boilerplate instantiations.

You are right in general. However, it doesn't change the fact that we
are living in maintenance-nightmare land right now ...

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

  parent reply	other threads:[~2008-04-10  6:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m21w5map5f.fsf@ohwell.denx.de>
     [not found] ` <m2wsne9a4c.fsf@ohwell.denx.de>
2008-04-03 19:00   ` Question on mpc52xx_common.c Grant Likely
2008-04-07 22:31     ` Matt Sealey
2008-04-08  2:14       ` Arnd Bergmann
2008-04-08  2:25         ` Grant Likely
     [not found]           ` <23d2e4300804071926n57746a3cj551ef38bf10486c7@mail.gmail.com>
     [not found]             ` <47FB3CD6.2090706@genesi-usa.com>
2008-04-08 14:52               ` Grant Likely
2008-04-08 19:45                 ` Robert Schwebel
2008-04-08 20:07                   ` Scott Wood
2008-04-08 23:51                     ` David Gibson
2008-04-09  6:18                       ` Wolfgang Denk
2008-04-08 20:12                   ` Timur Tabi
2008-04-08 21:26                   ` Grant Likely
2008-04-08 21:51                     ` Segher Boessenkool
2008-04-09 16:46                       ` Matt Sealey
2008-04-10  6:39                     ` Robert Schwebel [this message]
2008-04-08  7:56         ` Sven Luther

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=20080410063935.GD13814@pengutronix.de \
    --to=r.schwebel@pengutronix.de \
    --cc=grant.likely@secretlab.ca \
    --cc=linuxppc-dev@ozlabs.org \
    /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;
as well as URLs for NNTP newsgroup(s).