From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 86BDCDDECF for ; Fri, 14 Sep 2007 08:30:40 +1000 (EST) In-Reply-To: <96A13129-D16E-440D-B317-29BED85852D9@kernel.crashing.org> References: <39A1A44F-CD73-4CC1-89DE-608A1041AAF7@kernel.crashing.org> <96A13129-D16E-440D-B317-29BED85852D9@kernel.crashing.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: From: Segher Boessenkool Subject: Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port Date: Fri, 14 Sep 2007 00:30:28 +0200 To: Kumar Gala Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >>>>> + PowerPC,8572@0 { >>>> >>>> Maybe it would be good to use "PowerPC,e500" instead -- it would >>>> make it easier to probe for the actual CPU type, that way. Not >>>> that Linux uses the name/compatible here at all ;-) >>> >>> I thought about this, not sure what the best solution is. >> >> Since the CPU cores on all these SoCs are identical (well, there >> might be a few revisions, or different cache sizes or such -- minor >> differences that can be probed for separately), it probably is a >> good idea to name them in the tree instead of having each client >> have its own table. >> >> Or is there anything about the CPU that can be derived from "8572" >> but not from "e500"? > > Only in so much that we need something that states what the actual > processor is. You mean, something needs to say "8572"? I think the "soc" node would be best for that. It's all not terribly important, just something to think about. >>>> And then there's the pci_bridge thing we're discussing on IRC, of >>>> course -- basically, get rid of the pci_bridge pseudo-node, and >>>> move the interrupt-map for the south-bridge devices into the >>>> south-bridge node. >>> >>> Leaving the interrupt-map in the PHB because that works and moving >>> it down has issues. >> >> Okay, fair enough. Are you looking at resolving those kernel issues? > > No. I've had enough of this device tree foo for a while :) Heh okay :-) > [I'm happy to test any patches related to this, if someone else comes > up with them] Well I don't know what the problem is ("it doesn't work" doesn't say much), and don't have your hardware to test. Maybe we can do it on IRC again ;-) Segher