Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1595682pxb; Mon, 8 Mar 2021 01:15:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJzB3CLqEoZtSZW5gikFkATtNP6qg1t/XfnRpHF0i0sQ3K2utl0SH8k50CHlypQYlsnn5sCN X-Received: by 2002:aa7:dd99:: with SMTP id g25mr20675823edv.230.1615194907464; Mon, 08 Mar 2021 01:15:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615194907; cv=none; d=google.com; s=arc-20160816; b=s+kvasudpXqvU18FtFIE9xaRLdzYMN/biBzJCpciX7604KHA0hCQDD32cLoUVGk6M6 2+0a66itkjz+IhDt67wMtRAPMbQyzyHioFuUwQZt/0onKbhDxPf1tRPmPQCa/T62iTz9 dXQJMSwP5DbcBK17GUuLqgYYk8lOM4M1lfvZeJa5cEQKiGZaKQWaHCBA8N2Pjgh9VWzv fbP4hkfmIGegMlLGWxZmHgmZQeHV0PV3PtE3OjFkzC/E4WE4WVZ3v4XMsUDToQOMblFh tocga7zrNcyQmAfgnHECWAjrTZlCdbS0d0eecs8vwNx2Dz6dgOT/EAdJE8DStY8O/cjk jzqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=TJrMhJXTPtGl/XHI2184Y1RLufoeX8Wy0u/vM0Tkapo=; b=iQrmGcQNoSQFJ69giyej8hYVqjVMZXlRtAyq7EcxOD/yF711xdqgqNkFszsXe3Wcve VqoZidmh15Mvz36p31W/lB6xfjFo5FzExTcVz1MZf5ibPIwJbm4YPQaPS968d22QQLIY HTRpzMgcJsN6WuEgdq7/qPT6NG8samFHDUz5TdgfW5sgKgGtZPQjCwCY840tt2OX4tro 6npgmFinIJjVVeRLm00PwBrwUU2sSihKNgPztD8OnktJtjROUfmC79cfD49tjFqPlRyB JQEj4ZtZKZbeuN8qsq6iJLiFwIrD3lhjvf5azBggwe481me3E5UPDk16mEQ4NPXmD4c4 NGCA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ar21si6639374ejc.618.2021.03.08.01.14.45; Mon, 08 Mar 2021 01:15:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229955AbhCHJLe (ORCPT + 99 others); Mon, 8 Mar 2021 04:11:34 -0500 Received: from bhuna.collabora.co.uk ([46.235.227.227]:44016 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229904AbhCHJLE (ORCPT ); Mon, 8 Mar 2021 04:11:04 -0500 Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id BE6CB1F44CCF; Mon, 8 Mar 2021 09:11:02 +0000 (GMT) Date: Mon, 8 Mar 2021 10:10:59 +0100 From: Boris Brezillon To: Manivannan Sadhasivam Cc: miquel.raynal@bootlin.com, richard@nod.at, robh+dt@kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Daniele.Palmas@telit.com, bjorn.andersson@linaro.org Subject: Re: [PATCH v4 2/3] dt-bindings: mtd: Add a property to declare secure regions in NAND chips Message-ID: <20210308101059.08658fbe@collabora.com> In-Reply-To: <20210308054447.28418-3-manivannan.sadhasivam@linaro.org> References: <20210308054447.28418-1-manivannan.sadhasivam@linaro.org> <20210308054447.28418-3-manivannan.sadhasivam@linaro.org> Organization: Collabora X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 8 Mar 2021 11:14:46 +0530 Manivannan Sadhasivam wrote: > On a typical end product, a vendor may choose to secure some regions in > the NAND memory which are supposed to stay intact between FW upgrades. > The access to those regions will be blocked by a secure element like > Trustzone. So the normal world software like Linux kernel should not > touch these regions (including reading). > > So let's add a property for declaring such secure regions so that the > drivers can skip touching them. > > Signed-off-by: Manivannan Sadhasivam > --- > Documentation/devicetree/bindings/mtd/nand-controller.yaml | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml > index d0e422f4b3e0..15a674bedca3 100644 > --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml > +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml > @@ -143,6 +143,13 @@ patternProperties: > Ready/Busy pins. Active state refers to the NAND ready state and > should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted. > > + secure-regions: > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > + description: > + Regions in the NAND chip which are protected using a secure element > + like Trustzone. This property contains the start address and size of > + the secure regions present. > + Since you declare this as a generic property, I think it'd be simpler to do the check at the core level. > required: > - reg >