From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 97CC9E008D7; Sun, 9 Nov 2014 09:03:35 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 19074E007C2 for ; Sun, 9 Nov 2014 09:03:30 -0800 (PST) Received: from [192.168.1.10] (unknown [68.38.40.177]) by smtp.webfaction.com (Postfix) with ESMTP id 23352207D582 for ; Sun, 9 Nov 2014 17:03:29 +0000 (UTC) Message-ID: <545F9E5D.2010007@mindchasers.com> Date: Sun, 09 Nov 2014 12:03:25 -0500 From: Bob Cochran User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: meta-freescale@yoctoproject.org References: <1415353415-3805-1-git-send-email-holler@ahsoftware.de> <20141107150003.27c16356@e6520eb.localdomain> <20141107160443.765f9b19@e6520eb.localdomain> <545CE3DE.4070902@ahsoftware.de> <545CF576.5050403@ahsoftware.de> <545D79DC.8030701@mail.bg> <545E65D3.5080003@ahsoftware.de> <545F3E8F.8040003@ahsoftware.de> <20141109160925.17f94589@e6520eb.localdomain> In-Reply-To: <20141109160925.17f94589@e6520eb.localdomain> Subject: Re: [PATCH 0/1] arm: imx: fsl_otp: make fuses (OTP memory) read-only X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 17:03:35 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 11/09/2014 10:09 AM, Eric Bénard wrote: > Hi Alexander, > > Le Sun, 09 Nov 2014 11:14:39 +0100, > Alexander Holler a écrit : > >> Am 08.11.2014 19:49, schrieb Alexander Holler: >> >>> I'm not confused, at least not in regard what you want to suggest. Of >>> course, I'm totally confused about the fact that almost nobody else >>> before has critized that write functionality of this driver, also I'm >>> already used to the fact that I'm unable to understand many things which >>> are happing in todays world. But nobody is perfect. ;) >> >> Just to make it more clear what this thread is about, here is a relevant >> sentence copied form the reference manual for the chip: >> >> "In order to avoid "rogue" code performing erroneous writes to OTP, a >> special unlocking sequence is required for writes to the fuse banks." >> > That's why adding an unlock sysfs entry would match the required > sequence to unlock the write access on the user point of view, but > that's Freescale's problem and policy. Hi, My preference would be to have an otp recipe under meta-fsl-arm/recipes-manufacturing and in the recipe would be the otp kernel patch that could be applied along with user space code to exercise it. As an un-applied patch, I would never have to worry about it bricking my board. However, when it comes time to use the feature in a manufacturing environment, it's there for me. And for extra safety, give the patch an unusual suffix (e.g., .otp) so it doesn't accidentally get swept into a kernel patch set. Bob > >> Now guess why the HW was designed this way. And then look again at the >> driver which nullifies the careful implementation in the HW. It doesn't >> have to be the fault of the author, e.g. he just might have written it >> for internal use. The problem is that it went into kernels for public >> use and nobody has seen a problem. Might be because of missing knowledge >> about what the driver does at all or whatever. I don't know. >> > Evaluation boards come with unlocked/unburned fuse so if a designer > wants to evaluate his fuse configuration on an EVB during the design > phase of his custom product he may need this driver especially when > using Freescale's MFG Tools. > If your Wandboard has unburned fuses and their kernel has this driver, > then ask them why they keep this features open to their users by default > (this can be because the SOM are intended to be used in final products > and they let the final user of their SOM burn what he wants in the fuse > - his own MAC address for example - so here again that's the job of the > end product designer to remove this feature once he launch his product > on the market). > > Best regards, > Eric >