On Monday 06 June 2011, Rafał Miłecki wrote:

Greg, Arnd: could you take a look at this patch, please?

With proposed patch we are going back to this ugly array and wrappers hacks.

I was really happy with our final solution, but it seems it's not
doable for embedded systems...? Is there something better we can do
about this?

2011/6/6 Hauke Mehrtens [off-list ref]:

quoted

When using bcma on a embedded device it is initialized very early at
boot. We have to do so as the cpu and interrupt management and all
other devices are attached to this bus and it has to be initialized so
early. In that stage we can not allocate memory or sleep, just use the
memory on the stack and in the text segment as the kernel is not
initialized far enough. This patch removed the kzallocs from the scan
code. Some earlier version of the bcma implementation and the normal
ssb implementation are doing it like this.
The __bcma_dev_wrapper struct is used as the container for the device
struct as bcma_device will be too big if it includes struct device.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

If you rely on device scan to find your CPUs and interrupt controllers,
you are screwed already, this won't work.

In that case, it's better to have a few "early" drivers, as few as
possible, that don't go through the bus scan at all but have their
own ways of bootstrapping themselves. I don't know what you mean by
"CPU management", but I can only assume that it's not doing that much,
and you can just put the register values into the device tree.

For an interrupt controller, it should be ok to have it initialized
late, as long as it's only responsible for the devices on the same
bus and not for instance for IPI interrupts. Just make sure that you
do the bus scan and the initialization of the IRQ driver before you
initialize any drivers that rely in on the interrupts to be working.

	Arnd