Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5772892ybp; Tue, 8 Oct 2019 08:06:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqxVnzgEYNWDvJjZ/ZzMHX/u++a1CYP9tFKZyz0XUwiMLcQMGyVZc2hM2l8Jhft7me8iB5t6 X-Received: by 2002:a7b:c930:: with SMTP id h16mr4131508wml.163.1570547168406; Tue, 08 Oct 2019 08:06:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570547168; cv=none; d=google.com; s=arc-20160816; b=SDTTjRA+Bx24VUs2sBcAzgu773/AyNSpJ6Iogolj/Ae6S7IEAIbl9iQhofaItY8sFN KVlzdyGMEPD3ugft5fMQ8fRieIYz4aczYJc38bNOxp+1j7N6dnbk0hjbAAypW6YXwUnv KfcDh5Z0g6B0GZokgrnMemMtytJg55TmgBs43hSDfjTeg4RcL5hhar3y/J2rjXD4/oOp kJdmvAdvpN+DLCsYYgAcsYEVjTzqa3K2B6Tp0rkIR/bzOOe+3b7Ek7rlJ3Ky8LSda4h3 KY0qYGOmTUDeGLpqjxIKbX3iaGlcQ1OWgoFd8rBFiG9hYxq+3D6GNjFJKHTPyRQaONpn +ZcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=p1YdnYzczik5iiwBCxdwzFTzrWz4u12QlFLu6PJn61w=; b=0cA3hSoj9Y3/1Lai0jP60pwXsklrFV7aiA/1YbuZavllwhYHjNPVCFKBtwm7leyEI9 NzPrn2sTT4y9qpbbEH9pVHCytN65oHIRwo1Msb4g5ImwICJ0pdQ2i8mHV/VgchrjoFdL aXHNNFDnMLnmyptJpT4yoArSrhlBc1Up5nS2y76AhVz3J669o6r1PVYvF6E00TZHFGNW 9g4Ph2+y1Byd13rJtQTiJD+LGkkvcUE4TKi/JpaKZiPoX7krgrr9BuGqj8XQ3KILcVWE WE5Dzc2Lr9JNoYGO87ZuMXtB4iZMZ1CN771os2NDBp1rnUP/+hFRpkOIVcXD9oHlpsZF 30/g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p43si10268089edc.368.2019.10.08.08.05.37; Tue, 08 Oct 2019 08:06:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727365AbfJHPCz convert rfc822-to-8bit (ORCPT + 99 others); Tue, 8 Oct 2019 11:02:55 -0400 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:44027 "EHLO relay1-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727306AbfJHPCy (ORCPT ); Tue, 8 Oct 2019 11:02:54 -0400 X-Originating-IP: 86.250.200.211 Received: from xps13 (lfbn-1-17395-211.w86-250.abo.wanadoo.fr [86.250.200.211]) (Authenticated sender: miquel.raynal@bootlin.com) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id DB95C24000F; Tue, 8 Oct 2019 15:02:50 +0000 (UTC) Date: Tue, 8 Oct 2019 17:02:49 +0200 From: Miquel Raynal To: masonccyang@mxic.com.tw Cc: bbrezillon@kernel.org, computersforpeace@gmail.com, dwmw2@infradead.org, frieder.schrempf@kontron.de, gregkh@linuxfoundation.org, juliensu@mxic.com.tw, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, marcel.ziswiler@toradex.com, marek.vasut@gmail.com, richard@nod.at, tglx@linutronix.de, vigneshr@ti.com Subject: Re: [PATCH RFC 2/3] mtd: rawnand: Add support Macronix Block Protection function Message-ID: <20191008170249.06bd45ce@xps13> In-Reply-To: References: <1568793387-25199-1-git-send-email-masonccyang@mxic.com.tw> <1568793387-25199-2-git-send-email-masonccyang@mxic.com.tw> <20191007104511.5aa7b8f2@xps13> <20191007112442.783e4fbe@xps13> Organization: Bootlin X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mason, masonccyang@mxic.com.tw wrote on Tue, 8 Oct 2019 10:33:11 +0800: > Hi Miquel, > > > > > > > > Macronix AC series support using SET/GET_FEATURES to change > > > > Block Protection and Unprotection. > > > > > > > > MTD default _lock/_unlock function replacement by manufacturer > > > > postponed initialization. > > > > > > Why would we do that? > > > > > > Anyway your solution looks overkill, if we ever decide to > > > implement these hooks for raw nand, it is better just to not > > > overwrite them in nand_scan_tail() if they have been filled > > > previously (ie. by the manufacturer code). > > > > Actually you should add two NAND hooks that do the interface with the > > MTD hooks. In the NAND hooks, check that the request is to lock all the > > device, otherwise return -ENOTSUPP. > > sorry, can't get your point. > > Because the NAND entire chip will be protected if PT(protection) pin > is active high at power-on. In your implementation of the locking, you should check that the locking request is over the entire device, unless you can lock a smaller portion of course. > > > > > Then fill-in these two hooks from the manufacturer code, without the > > postponed init. > > > > But in the final of nand_scan_tail(), mtd->_lock/_unlock will be > filled by NULL, right ? The NAND core should set mtd->_lock/_unlock() to NAND specific hooks so that the MTD layer is abstracted and and drivers do not see it. Then, in the NAND helper, either there is no specific hook defined by a manufacturer driver and you return -ENOTSUPP, or you execute the defined hook. Thanks, Miquèl