Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp895420pxb; Tue, 1 Feb 2022 12:39:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJw7B+bBfWSc/+waYu24rc1fvm9QX/2iprPqhnnRj89j0DjmuIh2rJv1l41BkPblg19ZJ1Q0 X-Received: by 2002:a17:902:bcca:: with SMTP id o10mr7464160pls.127.1643747988623; Tue, 01 Feb 2022 12:39:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643747988; cv=none; d=google.com; s=arc-20160816; b=05ERi+hgze8MNTsgDFk2GROs3KK4v1Ojf3JO73da0Ob4++iPYKEQYITM0eawgZjofm KmoKvcbxUn5eDUmJ9NugPudRqyyQ7wTd++ganQDiRV86KzTERTAZU5MId6xGID9L/myK hT2keWtZGliXc+zXbqOW3AFkqo6pe1RfcmdxVmg5PKnSuSAmd/WkZ8kDlESLnrOh8t/r jJChg2DkTIxUIAEwfnuoMzzFtOUPBo3f9uyYS9uRNZgtfwrLzTBdiiG/q1lwEibFKbk+ kik0FCcCdYzs7W6OXeusSzp8YGPC7Vs5zlaOuoKXb5q6Q2/kaivTGjFjqMeR+DvyVosv p48A== 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:dkim-signature; bh=fNzzdrv2WUeULNwAyESjeTV+GL3fcftB5PM2h9pueek=; b=mbGGGkJtbRVT+rQh9gfH5XXe5PAelP4ne5/+kpxJX5U3RhZbcc0n57b7D3bpkI7crL 4iwIxBTA1pe0OS82P80L2ITwQ76BXtIoPIHapjSTRU5K7rGe9AVTxDsSzqrh2xdBogQq nvZcbu4ZNLKv4A3QDL9B2FhGwcxfzILd4S3kHKV4utXNdozSb9EFx901lJhwTK5gmGG8 kGN6uRB2K9nygEixALQM78AAQ3ZD0SMRy8bsaagcm4/7Jz1FEHTXgz04YLUZFdDcgXM2 9rKuDs1/ktPF83Cmc6eHxzpl/FWiDpKyBTAWlNmUMFe0HVIP3l2PI1e73RsyD1WCSJjW /4OA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=McTkn4xG; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s201si18444654pgs.328.2022.02.01.12.39.36; Tue, 01 Feb 2022 12:39:48 -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; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=McTkn4xG; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239639AbiAaNnR (ORCPT + 99 others); Mon, 31 Jan 2022 08:43:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229671AbiAaNnQ (ORCPT ); Mon, 31 Jan 2022 08:43:16 -0500 Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [IPv6:2001:4b98:dc4:8::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 54653C061714; Mon, 31 Jan 2022 05:43:15 -0800 (PST) Received: (Authenticated sender: miquel.raynal@bootlin.com) by relay12.mail.gandi.net (Postfix) with ESMTPSA id 8F55A200014; Mon, 31 Jan 2022 13:43:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1643636592; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fNzzdrv2WUeULNwAyESjeTV+GL3fcftB5PM2h9pueek=; b=McTkn4xGuStHaGZwMMzwEHdXEZ1ZTskZtYmiln/jpDbssu2slFXlEV0LkL+BjV1Csi94cy 9TAoEDRKoFgK8o8b+26uxzMYFbqL3EsqyKjcjPu5iI+T7Dh6DRmHzr7zbhBvFvureek5L/ 9j/d0wKtOMG8f/th0CbBOcF/rGk46muyGCzJeghyKaqufm7fHi36K62rU+SDmKYBXbrqxM lIYN4k8ATVj/mEXwnVfqp0O0/aKlOqxLVb0U7umRvs6JOiIRznkOhckJWye/Uxd3p4i9Gl JYhRsEVxixoBHmncpmVbF2B8JcDv36S8ZniYGtWZ8dzuAUbt7c4aFH2KcxDIVA== Date: Mon, 31 Jan 2022 14:43:09 +0100 From: Miquel Raynal To: Christophe Kerello Cc: , , , , , , , , , Tudor Ambarus , Pratyush Yadav Subject: Re: [PATCH v2 4/4] mtd: core: Fix a conflict between MTD and NVMEM on wp-gpios property Message-ID: <20220131144309.0ffe7cc8@xps13> In-Reply-To: <20220131095755.8981-5-christophe.kerello@foss.st.com> References: <20220131095755.8981-1-christophe.kerello@foss.st.com> <20220131095755.8981-5-christophe.kerello@foss.st.com> Organization: Bootlin X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vignesh, Tudory, Pratyush, + Tudor and Pratyush christophe.kerello@foss.st.com wrote on Mon, 31 Jan 2022 10:57:55 +0100: > Wp-gpios property can be used on NVMEM nodes and the same property can > be also used on MTD NAND nodes. In case of the wp-gpios property is > defined at NAND level node, the GPIO management is done at NAND driver > level. Write protect is disabled when the driver is probed or resumed > and is enabled when the driver is released or suspended. >=20 > When no partitions are defined in the NAND DT node, then the NAND DT node > will be passed to NVMEM framework. If wp-gpios property is defined in > this node, the GPIO resource is taken twice and the NAND controller > driver fails to probe. >=20 > A new Boolean flag named skip_wp_gpio has been added in nvmem_config. > In case skip_wp_gpio is set, it means that the GPIO is handled by the > provider. Lets set this flag in MTD layer to avoid the conflict on > wp_gpios property. >=20 > Signed-off-by: Christophe Kerello > --- > drivers/mtd/mtdcore.c | 2 ++ > 1 file changed, 2 insertions(+) >=20 > diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c > index 70f492dce158..e6d251594def 100644 > --- a/drivers/mtd/mtdcore.c > +++ b/drivers/mtd/mtdcore.c > @@ -546,6 +546,7 @@ static int mtd_nvmem_add(struct mtd_info *mtd) > config.stride =3D 1; > config.read_only =3D true; > config.root_only =3D true; > + config.skip_wp_gpio =3D true; > config.no_of_node =3D !of_device_is_compatible(node, "nvmem-cells"); > config.priv =3D mtd; > =20 > @@ -833,6 +834,7 @@ static struct nvmem_device *mtd_otp_nvmem_register(st= ruct mtd_info *mtd, > config.owner =3D THIS_MODULE; > config.type =3D NVMEM_TYPE_OTP; > config.root_only =3D true; > + config.skip_wp_gpio =3D true; > config.reg_read =3D reg_read; > config.size =3D size; > config.of_node =3D np; TLDR: There is a conflict between MTD and NVMEM, who should handle the WP pin when there is one? At least for raw NAND devices, I don't want the NVMEM core to handle the wp pin. So we've introduced this skip_wp_gpio nvmem config option. But there are two places where this boolean can be set and one of these is for otp regions (see above). In this case, I don't know if it is safe or if CFI/SPI-NOR rely on the nvmem protection. Please tell us if you think this is fine for you. Thanks, Miqu=C3=A8l