[Top] [All Lists]

RE: Location of PCI setup code

To: <>
Subject: RE: Location of PCI setup code
From: "Koeller, T." <>
Date: Fri, 2 Jun 2006 11:16:18 +0200
Original-recipient: rfc822;
Thread-index: AcaF1VkjPtksw6SASzWpstbbqfTi7wAT7ymQ
Thread-topic: Location of PCI setup code
> From: Ralf Baechle [] 
> On Thu, Jun 01, 2006 at 10:46:17PM +0200, Thomas Koeller wrote:
> > the PCI setup code for a platform is conventionally located 
> in arch/mips/pci. 
> > I fail to see the benefits of separating this particular 
> part of a platform's 
> > setup from the rest. The PCI setup code will in general 
> contain references to 
> > platform-specific information, such as the overall address 
> space layout, of 
> > which the PCI memory and I/O pages are a part. If the PCI 
> setup code were in 
> > the platform subdirectory, sharing this information by means of a 
> > platform-local header file would be easy. But with the PCI code in 
> > arch/mips/pci, this becomes more difficult. The platform 
> header could be 
> > located somewhere outside the platform's directory, maybe under 
> > 'include' (where?), or referenced via an ugly relative path like 
> > '../../vendor/platform/platform.h'. All this seems rather 
> clumsy to me. No 
> > other part of a platform's initialization is separated from 
> the rest in a 
> > similar way, so what is so special about PCI setup that it 
> cannot be in the 
> > platform directory, thereby avoiding all these annoyances? 
> The per-platform PCI code used to live in the per-platform 
> directories.
> It turned into a giant mess, very little code was being shared, it was
> hard to uniformly perform any kind of modification or fixes - and more
> of that kind of changes will be needed before the PCI codes really
> shines.
>   Ralf

So how am I supposed to deal with the issues mentioned?
Should I duplicate the PCI-related platform definitions into
arch/mips/pci? Scattering related information across several places is
generally regarded as poor design, as it will make maintenance more
Or should I resort to one of the methods I mentioned, or is there any
preferred/recommended way of dealing with this?

Thomas Koeller, Software Development 

Basler Vision Technologies 
An der Strusbek 60-62 
22926 Ahrensburg 

Tel +49 (4102) 463-390 
Fax +49 (4102) 463-46390 

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