From: David Daney <ddaney@caviumnetworks.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org,
devicetree-discuss@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 06/10] MIPS: Octeon: Initialize and fixup device tree.
Date: Wed, 23 Feb 2011 11:20:09 -0800 [thread overview]
Message-ID: <4D655DE9.9080809@caviumnetworks.com> (raw)
In-Reply-To: <20110223185134.GN14597@angua.secretlab.ca>
On 02/23/2011 10:51 AM, Grant Likely wrote:
> On Wed, Feb 23, 2011 at 10:40:32AM -0800, David Daney wrote:
>> On 02/23/2011 09:41 AM, Grant Likely wrote:
>>> On Tue, Feb 22, 2011 at 12:57:50PM -0800, David Daney wrote:
>>>> Signed-off-by: David Daney<ddaney@caviumnetworks.com>
>>>> ---
>>>> arch/mips/Kconfig | 2 +
>>>> arch/mips/cavium-octeon/octeon-platform.c | 280 +++++++++++++++++++++++++++++
>>>> arch/mips/cavium-octeon/setup.c | 17 ++
>>>> 3 files changed, 299 insertions(+), 0 deletions(-)
>>>
>>> I've got an odd feeling of foreboding about this patch. It makes me
>>> nervous, but I can't articulate why yet. Gut-wise I'd rather see the
>>> device tree pruned/fixed up before it gets unflattened,
>>
>> I chose to work on the unflattened form because there were already
>> functions to do it. I didn't see anything that would make
>> manipulating the flattened form easy.
>>
>> I agree that working on the unflattened form would be best. At a
>> minium the /proc/device-tree structure would better reflect reality.
>>
>> What do you think about adding some helper functions to
>> drivers/of/fdt.c for the manipulation of the flattened form?
>
> It would probably be easier/safer to link libfdt into the kernel
> proper. It's already used in the powerpc bootwrapper, and there has
> been talk about replacing some of fdt.c with libfdt. See
> scripts/dtc/libfdt
>
I will take a look at that approach.
>>
>>> or for the
>>> kernel to have a separate .dtb linked in for each legacy platform.
>>
>> I think there are too many variants to make this viable.
>
> Out of curiosity, how many variants?
>
I don't know exactly, but for the sake of argument let's say at least
twenty we support in-house. That is not counting close to 100 customer
boards. Some of these boards have modular I/O connections (SPI-4.2 vs.
XAIU vs. 4xSGMII, etc. across several different ports.), so the hardware
configuration may be different each time they are powered on.
The existing legacy code handles these, so using it to configure the
Device Tree has a certain appeal. I would hope that moving forward a
correct device tree is obtained from the bootloader, but for existing
boards...
> btw, did you know about the dtc '/include/' functionality? It is
> possible to set up .dts include files that represent a SoC and can be
> modified by the .dts files that include them. See
> arch/powerpc/boot/dts/*5200*.dts
Yes.
Thanks,
David Daney
next prev parent reply other threads:[~2011-02-23 19:20 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-22 20:57 [RFC PATCH 00/10] MIPS: Octeon: Use Device Tree David Daney
2011-02-22 20:57 ` [RFC PATCH 01/10] MIPS: Octeon: Move some Ethernet support files out of staging David Daney
2011-02-23 14:48 ` Grant Likely
2011-02-23 17:36 ` David Daney
2011-02-22 20:57 ` [RFC PATCH 02/10] MIPS: Octeon: Add device tree source files David Daney
2011-02-23 0:07 ` David Gibson
2011-02-23 14:30 ` Ralf Baechle
2011-02-23 16:59 ` David Daney
2011-02-24 23:19 ` David Gibson
2011-02-25 15:22 ` Grant Likely
2011-02-25 21:46 ` Benjamin Herrenschmidt
2011-02-23 19:06 ` David Daney
2011-02-23 23:49 ` David Gibson
2011-02-24 1:57 ` David Daney
2011-02-24 2:14 ` David Gibson
2011-02-24 2:22 ` David Daney
2011-02-22 20:57 ` [RFC PATCH 03/10] MIPS: Prune some target specific code out of prom.c David Daney
2011-02-22 20:57 ` [RFC PATCH 04/10] MIPS: Octeon: Add a irq_create_of_mapping() implementation David Daney
2011-02-22 20:57 ` [RFC PATCH 05/10] MIPS: Octeon: Rearrance CVMX files in preperation for device tree David Daney
2011-02-22 20:57 ` [RFC PATCH 06/10] MIPS: Octeon: Initialize and fixup " David Daney
2011-02-23 0:16 ` David Gibson
2011-02-23 17:41 ` Grant Likely
2011-02-23 18:40 ` David Daney
2011-02-23 18:51 ` Grant Likely
2011-02-23 19:20 ` David Daney [this message]
2011-02-22 20:57 ` [RFC PATCH 07/10] i2c: Convert i2c-octeon.c to use " David Daney
2011-02-23 16:25 ` Grant Likely
2011-02-22 20:57 ` [RFC PATCH 08/10] netdev: mdio-octeon.c: Convert " David Daney
2011-02-22 20:57 ` [RFC PATCH 09/10] netdev: octeon_mgmt: " David Daney
2011-02-23 16:32 ` Grant Likely
2011-02-23 20:33 ` David Miller
2011-02-22 20:57 ` [RFC PATCH 10/10] staging: octeon_ethernet: " David Daney
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=4D655DE9.9080809@caviumnetworks.com \
--to=ddaney@caviumnetworks.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.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