From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 372CFE0084F; Sat, 8 Nov 2014 10:50:16 -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 mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 3E448E00830 for ; Sat, 8 Nov 2014 10:50:10 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 153272C9C203; Sat, 8 Nov 2014 19:50:07 +0100 (CET) Received: from eiche.ahsoftware (p4FC373F3.dip0.t-ipconnect.de [79.195.115.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 557322C9C1EC for ; Sat, 8 Nov 2014 19:50:07 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id 95D5A8E4B8; Sat, 8 Nov 2014 19:50:06 +0100 (CET) Received: from krabat.ahsoftware (unknown [IPv6:feee::5246:5dff:fe8b:95f8]) by eiche.ahsoftware (Postfix) with ESMTP id E2E208E34E; Sat, 8 Nov 2014 18:49:55 +0000 (UTC) Message-ID: <545E65D3.5080003@ahsoftware.de> Date: Sat, 08 Nov 2014 19:49:55 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Nikolay Dimitrov 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> In-Reply-To: <545D79DC.8030701@mail.bg> Cc: "meta-freescale@yoctoproject.org" , Jon Nettleton , Otavio Salvador 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: Sat, 08 Nov 2014 18:50:16 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Am 08.11.2014 03:03, schrieb Nikolay Dimitrov: > Hi Alexander, > > The driver allows to be enabled/disabled by a configuration option, so > it's a responsibility of your engineering team to properly configure > the software for development, manufacturing and production purposes, as > there's no "one size fits all" solution for this option. Sorry to disappoint you, but I'm currently just a hobbyist. ;) > And I think it would be a unwise decision just to cripple the driver > because there is potential for misuse the driver. If so, we have to > disable also all device files and sysfs entries that allow raw access > to physical memory, physical disks, cpu frequency, thermal device, > power supply voltages, as all of these can screw-up the product (either > by deleting data or by frying a component on the board). And we have to > forbid kitchen knives :). Hmm, maybe I should repeat that this driver is about ONE TIME PROGRAMMABLE memory. So all your comparisons are (imho) totally wrong. YOU ONLY HAVE ONE SHOT to set one of these values to whatever value you want. And if you get it wrong, the HW might be unusable afterwards. Not to speak about all the things which can go wrong and might write to one of these files, changing the (hopefully correct) values such that the HW is dead afterwards too. > I like Eric's idea with sysfs unlock entry. It's also possible to have > different sysfs "read" and "write" files' permissions, to provide > privilege separation. > > I also understand your confusion of the answers received on LKML and > here, but you should already know that each FOSS tribe has its own > customs. What's good for the kernel itself doesn't make it instantly > good for actual systems/product integration, so it's normal to have > groups with different goals to react differently on the same topic. 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. ;) But there is absolutely no reason to include this ONE TIME FUNCTIONALITY into any kernel meant for the public, especially as it is very dangerous. And for sure not without any content veryfication and some other means to make sure the value one wants to put ONCE into that ONE TIME MEMORY isn't wrong. That's why I just refuse to change my patch in order to add write functionality. I don't want to do (imho) foolish things just because someone else tells me to do them. I'm no Lemming. At least not without adequate compensations. ;) Regards, Alexander Holler