Re: Status of arch/arm in linux-next

[Arnd Bergmann <arnd@arndb.de>]

On Tuesday 19 April 2011 18:27:42 Dave Jones wrote:
> On Tue, Apr 19, 2011 at 06:01:19PM +0200, Arnd Bergmann wrote:
>  > > Thinking of it, is it OK to put chip CPUfreq drivers into
>  > > drivers/cpufreq/* instead of into the arch/arm/* platform
>  > > code as everyone does right now? We could probably
>  > > fix that and bring down the diffstat considerably.
>  > 
>  > That's something to discuss with Dave Jones and other people
>  > interested in cpufre. Right now, all cpufreq drivers, including
>  > those for other architectures are in arch/.
>  > 
>  > I think it would be good to have the out of the individual
>  > platforms, in particular in order to get better reviews of
>  > new cpufreq drivers by people that are interested in them.
> 
> The platform drivers are by their nature architecture specific,
> so arch/ seems apropos.  drivers/platform/arm/ maybe ?
> 
> Though, having arm do something different to every other arch seems
> a bit awkward too. Everyone else has their cpufreq platform driver
> somewhere under arch/whatever/../cpufreq/..  so changing that
> violates the principle of least surprise.
> 
> I'm also not convinced that moving them would increase review of changes.
> 
> What problem is this solving again ?

Right now, every subarchitecture in arm implements a number of 
drivers (irq, clocksource, gpio, pci, iommu, cpufreq, ...).
These drivers are frequently copies of other existing ones with
slight modifications or (worse) actually are written independently
for the same IP blocks. In some cases, they are copies of drivers
for stuff that is present in other architectures.

We are discussing on a number of fronts to turn the source code
layout from subarchitecture-centric to subsystem-centric, e.g.
put all gpio drivers into one directory instead of each one
into the directory for its (sub)architecture, in order to improve
the abstractions and code reuse we have between the different
implementations.

	Arnd