[PATCH 3/5] [orion] Move address map setup out of the drivers and into platform.
Nicolas Pitre
nico at fluxnic.net
Tue Nov 15 17:14:57 EST 2011
On Tue, 15 Nov 2011, Andrew Lunn wrote:
> > I understand that you might want to get rid of the annoying platform
> > data pointer for the mbus values. But I think that this could be done
> > some other way though. IMHO the mbus initialization code for
> > peripherals should remain in the drivers, and a different way to query
> > the needed information be elaborated instead. Otherwise this is like
> > throwing out the baby with the bath water.
>
> I'm open to suggestion.
>
> What do you think about the idea of keeping the first two patches,
> i.e. *_mbus_dram_info out of mach-* and into plat-orion. Then
> providing a function orion_mbus_dram_info() which returns its. Keep
> the address map setup code in the drivers, remove struct
> mbus_dram_target_info from platform_data and use this function
> instead?
I pretty much like patch #1. Just remember to mark unneeded data after
boot as __initdata.
I don't see the point of patch #2. Having a kirkwood specific piece of
data called kirkwood_foo rather than orion_foo makes more sense to me.
Having a static orion_mbus_dram_info() function might be a problem on
other platforms. for example, the mv643xx_eth driver is also used by
some PowerPC targets. The sata_mv driver is shared between
Orion/Kirkwood/Dove SOCs and Marvell SATA controllers on PCI cards that
can be found on any architecture with a PCI bus. Etc. It is therefore
necessary to query those resources in a standard way and be prepared for
the fact that they might just be absent. So I'd suggest looking at the
possibility of using IORESOURCE_BUS in the standard platform device
data or a similar mechanism.
Nicolas
More information about the linux-arm-kernel
mailing list