From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: In-Reply-To: <20070807034136.GC13522@localhost.localdomain> References: <20070730150648.GA5005@ru.mvista.com> <20070801020836.GB31391@localhost.localdomain> <65ff446478a9fd0a48061079d5f04f8f@kernel.crashing.org> <20070801050422.GI31391@localhost.localdomain> <20070801054751.GM31391@localhost.localdomain> <59e87834966d80bb143e1683fe751cd1@kernel.crashing.org> <20070807034136.GC13522@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <03211b7766f4a21c90889344f843a564@kernel.crashing.org> From: Segher Boessenkool Subject: Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS Date: Tue, 7 Aug 2007 18:33:01 +0200 To: David Gibson Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >>>>> Yeah, better names please -- if possible, something that someone >>>>> without knowledge of this SoC will understand what it is. >>>> >>>> I think the names are probably ok - I'm assuming they're in keeping >>>> with the convention I've used of using the same names / >>>> abbreviations >>>> as in the CPU user manual. I'm asking just for my own information, >>>> although a comment might not be a bad idea. >> >> Fine with me -- I personally prefer "system-device-controller" >> and "clock-power-controller" or similar, but that is mostly a >> matter of taste. As long as it's human readable it's fine. > > Actually, it occurs to me that I've only sometimes been using that > convention for the names: basically just for the weirdo chip control > devices that don't have a more widespread generic name. It's pretty darn hard to make good sensible "generic names" for some of the devices on a SoC; using the acronym that's in the documentation for that SoC certainly isn't the worst choice. >>> + Flash partitions >>> + - reg : >>> + - read-only : (optional) >> >> I'll hold off commenting on this until you've finish writing it, >> you probably know my opinion about it anyway :-) > > Heh.. actually I was kind of hoping for your input on what's still > missing. For example, I don't know what the necessary extra > properties for JEDEC chips are. I meant for the "partitions" stuff only. For the JEDEC chips, we need a "vendor-id" and "device-id" property at least (or similar names -- whatever is general practice for this); both are a single byte, encoded as with encode-int. >> One thing though -- what _exactly_ does "read-only" signify? > > That's... a good question. Yeah. It seems to me that the way it is currently used is pure policy enforcement, which doesn't belong in the device tree. Segher