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 ESMTPS id B6202DE518 for ; Tue, 1 Jul 2008 07:19:23 +1000 (EST) In-Reply-To: <20080630131441.e9b9ac1c.kim.phillips@freescale.com> References: <20080627115243.d76e0814.kim.phillips@freescale.com> <2b97f7566925ed86b78b364ff5724644@kernel.crashing.org> <20080630110410.7ee097ed.kim.phillips@freescale.com> <20080630131441.e9b9ac1c.kim.phillips@freescale.com> 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 v2] update crypto node definition and device tree instances Date: Mon, 30 Jun 2008 23:19:05 +0200 To: Kim Phillips Cc: linuxppc-dev List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >>>> Also, these made-up names make you do more work: you'll need to >>> >>> who said they were made up? >> >> I did. These names do not refer to some physical part you can buy. > > right, they refer to devices in multiple physical parts you can buy. > Part-you-can-buy documentation clearly indicates the SEC version in > that part, in the form "SEC X.Y", i.e, it's not something made up > that's not already in freescale documentation. Yes. As a side note, since there are multiple devices that contain e.g. a sec-1.0, it would be prudent to describe the exact incarnation in the device tree, like "mpc8272-sec" or something, in either "model" or "compatible", just in case a problem shows up with one of them. >>>> write up a binding for them, explaining exactly what a 1.0 device >>>> etc. is (or at least point to documentation for it). If you use >>>> a name that refers to some device that people can easily google >>>> for documentation, you can skip this (well, you might need to >>>> write a binding anyway; but at least you won't have to explain >>>> what the device _is_). >>> >>> documentation is available in the usual places, and it specifically >>> points out which SEC version it references. >> >> I can't find a manual online for "freescale sec"; googling >> for "freescale sec-1.0" finds a manual for the PowerQUICC I; >> is that the right one? I don't know, so the binding needs >> to explain it to me. > > the binding shouldn't be responsible for google's shortcomings The binding needs to describe what device it is for. I am a stupid user, just like most users, so if the binding doesn't tell me I turn to google. Don't blame them for not finding it; the binding should have told me in the first place! > (that hit is correct, btw). Okay, cool. >> Going from SoC name -> SEC version is easy, but the other way around >> not so. >> >> Anyway, minor stuff. > > sounds like you're pointing out a lack of "SEC versions guide" > documentation of Freescale.. Yes, that would have helped. >>> Plus, as I mentioned >>> before, a lot of the differences between the SEC versions are >>> miniscule >>> feature bits scattered across the programming model. >> >> I don't see how this is relevant, sorry. >> > I'm under the impression that listing the differences (assuming they're > easily obtainable) would lead to unnecessary b-w-of bloat. The binding at a minimum should describe how to identify each unique version from the device tree, no matter how miniscule those differences are. Just a specific "compatible" value will do. > I don't know what google does; I'd search freescale documentation > directly. Or the binding could just bloody say what it is talking about in the first place, heh. Anyway, how about we do something constructive? If you still want to use "fsl,sec-N.M" names, that's fine with me. Each specific device tree needs to still say which exact device it contains, so an entry would look like e.g. compatible = "fsl,mpc8272-sec", "fsl,sec-3.0"; and the driver can just probe for "fsl,sec-3.0" if it doesn't need to know about the exact version; but it _can_ use it if it _does_ need to know. Segher