[PATCH] [POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards

Kumar Gala galak at kernel.crashing.org
Wed Sep 12 05:47:28 EST 2007


>>>> Would you feel better if it was in platforms/common/ or  
>>>> platforms/fsl
>>>>
>>>>> Maybe it would make more sense for you guys to slice the platforms
>>>>> differently, and have a common platform for the eval boards you  
>>>>> have
>>>>> with ULi on them instead of grouping it by core used by the  
>>>>> processor
>>>>> on the board.
>>>>>
>>>>> (In other words, move 86xx over under 85xx, since there  
>>>>> wouldn't be
>>>>> much
>>>>> left over anyway).
>>>>
>>>> Moving 86xx (classic 74xx core) under 85xx (book e500 core) makes
>>>> even less sense to me.
>>>
>>> Yeah, that makes *no* sense to me either.  It's an unfortunate  
>>> artifact of the naming of boards to include the core name.  While  
>>> the devices and boards may be similar, once you have bookE vs non- 
>>> bookE cores, they become quite different.
>>>
>>> I still don't see why this isn't in "sysdev".  We intended that  
>>> to be the device "kitchen sink".  If we really don't want to put  
>>> it there, then I would prefer creating a "fsl_common" or "common"  
>>> directory under platforms.
>
> You still haven't, in my opinion, answered my question about why it  
> can't go in sysdev, when I believe the original intent was for  
> stuff like this to go there.

I think sysdev should be related to chipsets and soc functionality.   
It seems odd to me that the Kconfig for these things lives in arch/ 
powerpc/platforms

>>> I'm also guilty of not noticing the original patch - my apologies.
>>
>> maybe we should just have a platforms/fsl for all boards from  
>> freescale.  Not having things broken up by which processor family  
>> they are for.
>
> What do you envision as being under there?  Subdirs?  How's it  
> organized? In some ways that might make sense, but I think we'd  
> need to sit down and think it through with all the twisted  
> combinations our hardware people come up with.  The fact is that  
> there's really no clean way to deal with all the wackiness.  So we  
> just pick something that fits OK and go with it.

Just a flat directory.

I don't really care that much about all this.  If someone wants to  
clean it up feel free to, but not sure what the value of that is.   
However, if you are going to fix the Kconfig issue I just mentioned  
as well.

- k





More information about the Linuxppc-dev mailing list