[Top] [All Lists]

Re: [PATCH 1/8] MIPS: BCM63XX: move flash registration out of board_bcm9

To: Florian Fainelli <>
Subject: Re: [PATCH 1/8] MIPS: BCM63XX: move flash registration out of board_bcm963xx.c
From: Ralf Baechle <>
Date: Wed, 13 Jun 2012 14:59:53 +0100
Cc: Jonas Gorski <>,, Maxime Bizon <>, Kevin Cernekee <>
In-reply-to: <2177534.JpaDVG7JnB@flexo>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
References: <> <> <> <2177534.JpaDVG7JnB@flexo>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Jun 13, 2012 at 03:51:30PM +0200, Florian Fainelli wrote:

> > And the grand cure for that sort of issue is FDT - we by now have built
> > big deserts of code just registering platform devices like this..  See
> > John Crispin's Lantiq work or David's Cavium code for FDT examples.
> I have some patches to convert bcm63xx to FDT but that is still work in 
> progress, and I don't want them to hold support for newer BCM63xx CPUs.

Oh absolutely.  I'm just nagging to make it clear to everybody into what
direction the world is moving.

> > I suggest to make bcm63xx_flash_register an arch_initcall.  It already is
> > being called indirectly from an bcm63xx_flash_register() so this would
> > allow making the function static, get rid of bcm63xx_dev_flash.h which
> > only exists to silence checkpatch warnings and make board_register_devices
> > a little cleaner.
> Well, yes, this makes it easier, but this is not robust, because you rely on 
> the function alphabetical name to make sure that everything gets registered 
> in 
> the right order. Plus, the big advantage of letting this code separate and 
> explicitely called, is to let out-of-tree boards use it as they wish too.

Ok.  That sort of dependency was not immediately obvious from the patches
and generally can be handled nicely by using the available set of priorities
for initcalls.


<Prev in Thread] Current Thread [Next in Thread>