From nobody Fri Jun 26 20:22:46 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6B42C433F5 for ; Sun, 20 Feb 2022 15:14:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239449AbiBTPPH (ORCPT ); Sun, 20 Feb 2022 10:15:07 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:50052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233743AbiBTPPA (ORCPT ); Sun, 20 Feb 2022 10:15:00 -0500 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5581434B98 for ; Sun, 20 Feb 2022 07:14:38 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id k3-20020a1ca103000000b0037bdea84f9cso9676932wme.1 for ; Sun, 20 Feb 2022 07:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=wotUyCfca8/zG519U5/af89Me2Zg5VHivde488B+0/k=; b=kSIafJLo1kafBS98UX2zOOmFNXbp+gOAaMPuWX6B30F/0hHFxHx+b6mirLbuWdyPlH trcwVN8Z3gMmNmVFUzBPKfU5dWuJdZblIph9vV4xJPOoDTE3Y3wKmZGCsOk0wXEFe2P4 Ivsu9vqCY1/LvdAjI6vcRirHUMP0PQ01K0tWgyHBb6uGLoXg3FDPuLB39VT5jqgxnJ+r 98/iPJq51Ec4kmj3ifyljDIP8HfTjnIxL6sRv8MlHoIrxjC4KY5Z0JekZOMshFWmX+HM DP8iM/kIOakA5k/dor02gPX6VMvJXy9mk2/44Mpo96ctVORDKBZOtfRiV23f3/XXVA+a FqsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=wotUyCfca8/zG519U5/af89Me2Zg5VHivde488B+0/k=; b=xLWryxPE9BhO6dM0dhYxqrVCs3pCGhMKWPulpKUISKoJkVB1E+E/BJE9igqntJvOX7 q4D9jEzu6BZQ1hMETVK0fB0VzEODjXA3QT+EkD6NWazPXiYh39wGpMvS/ljXvpIbu0Ft B+uqfn3F0GsYuY99HPQgmqiqeK0FYJr2osZaY4o0muawAS3hgMM14avdWuTBubY1hpsj LEEneQSbRYQvvjd7RDKx124qd7etlxlBaSLCPVENIvnRGXoS+njfneZEOF6gz6wVR0kX CrFbWynO/nGaTeWyj+nsPCUhEqZVJtF2pp+8IPsNw+LCB2GbE2nrd7mnZimO1erjX63w jMbg== X-Gm-Message-State: AOAM533COayQiMZ3Pmj/wIdPLr4VUpd47PIXYqw4isJ6rCwPjb4cq6SU RDoIOhaG6G9LIrbUr1LXjjrvsotC399Yvw== X-Google-Smtp-Source: ABdhPJz3XibEQYrsDmXIkvjitdL5RVZsTy7QaoAA+NYJQ1et19WIrkgJjyTtw9bxRpJxOJugiR6DvA== X-Received: by 2002:a7b:cb44:0:b0:37c:4e2d:3bb2 with SMTP id v4-20020a7bcb44000000b0037c4e2d3bb2mr17926595wmj.96.1645370076845; Sun, 20 Feb 2022 07:14:36 -0800 (PST) Received: from srini-hackbox.lan (cpc90716-aztw32-2-0-cust825.18-1.cable.virginm.net. [86.26.103.58]) by smtp.gmail.com with ESMTPSA id d6sm46703322wrs.85.2022.02.20.07.14.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 20 Feb 2022 07:14:36 -0800 (PST) From: Srinivas Kandagatla To: gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org, Christophe Kerello , stable@vger.kernel.org, Srinivas Kandagatla Subject: [PATCH 1/2] nvmem: core: Fix a conflict between MTD and NVMEM on wp-gpios property Date: Sun, 20 Feb 2022 15:14:31 +0000 Message-Id: <20220220151432.16605-2-srinivas.kandagatla@linaro.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20220220151432.16605-1-srinivas.kandagatla@linaro.org> References: <20220220151432.16605-1-srinivas.kandagatla@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Christophe Kerello 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. 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. It would be possible to set config->wp_gpio at MTD level before calling nvmem_register function but NVMEM framework will toggle this GPIO on each write when this GPIO should only be controlled at NAND level driver to ensure that the Write Protect has not been enabled. A way to fix this conflict is to add a new boolean flag in nvmem_config named ignore_wp. In case ignore_wp is set, the GPIO resource will be managed by the provider. Fixes: 2a127da461a9 ("nvmem: add support for the write-protect pin") Signed-off-by: Christophe Kerello Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla --- drivers/nvmem/core.c | 2 +- include/linux/nvmem-provider.h | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index 23a38dcf0fc4..9fd1602b539d 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -771,7 +771,7 @@ struct nvmem_device *nvmem_register(const struct nvmem_= config *config) =20 if (config->wp_gpio) nvmem->wp_gpio =3D config->wp_gpio; - else + else if (!config->ignore_wp) nvmem->wp_gpio =3D gpiod_get_optional(config->dev, "wp", GPIOD_OUT_HIGH); if (IS_ERR(nvmem->wp_gpio)) { diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h index 98efb7b5660d..c9a3ac9efeaa 100644 --- a/include/linux/nvmem-provider.h +++ b/include/linux/nvmem-provider.h @@ -70,7 +70,8 @@ struct nvmem_keepout { * @word_size: Minimum read/write access granularity. * @stride: Minimum read/write access stride. * @priv: User context passed to read/write callbacks. - * @wp-gpio: Write protect pin + * @wp-gpio: Write protect pin + * @ignore_wp: Write Protect pin is managed by the provider. * * Note: A default "nvmem" name will be assigned to the device if * no name is specified in its configuration. In such case "" is @@ -92,6 +93,7 @@ struct nvmem_config { enum nvmem_type type; bool read_only; bool root_only; + bool ignore_wp; struct device_node *of_node; bool no_of_node; nvmem_reg_read_t reg_read; --=20 2.21.0 From nobody Fri Jun 26 20:22:46 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7EA2AC433F5 for ; Sun, 20 Feb 2022 15:14:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239756AbiBTPPK (ORCPT ); Sun, 20 Feb 2022 10:15:10 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:50086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239167AbiBTPPF (ORCPT ); Sun, 20 Feb 2022 10:15:05 -0500 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8033734B97 for ; Sun, 20 Feb 2022 07:14:44 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id o34so8141574wms.1 for ; Sun, 20 Feb 2022 07:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=xVb0fT1MGhcBbhhTafWv2pABvtbVRcxp+NDQSOBSHBI=; b=vrUhGbzWYj9b0IvENuCjMtgDybie2NNldRu/4ngPcWe+XGiXsvwrMpfRvcEvVaP3Ps UJCnKFn+dmvzzjzM9JLBxemtS6FsgvCHYfZREBuBx/aqs/U3r5TPjSNoTAKTbxtQiz0P rIqhmznel+D2xTurkav2gDEPUIjJD0xed1eMPjEWnQIAZKgUMcyViX3CnyU0sxGV1osN r7/KYIk39sxKnmLKQwUvUcGs7WAmYh3m3M+tVqfhecNSCZXoiOM93tTofC/Ot/xWh5k1 d1xruKTiXtp7GXbKUN/vn6p1xgYvC70uJ0zCsrWLsh4iLxMybafTJBLgxOZdU+XDmrY1 rGkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=xVb0fT1MGhcBbhhTafWv2pABvtbVRcxp+NDQSOBSHBI=; b=6th8joYNI/rik54BntjfWrBtI2hNgjaNn3AxJWxCVjowVHGPsP+5PcIjjbWdqKdMTn xycKCLR/CZSZ5Ygl4DHsWbwibWpnCdJ3USe8/ICAzT7V5RrVuDUYvyug4kOBWPJPjr+q Svhoiln5XnT/9J+GDxYa8dzpLRr3hW8w4xbQMDN1/Zi9C2rVaKOCUEXZH67bA0R8SVzs 4ciUtunwzGNEdpqJjfUA3bAtg9//K1dy2dJ1gLVk7BefKD2zl7l4gSTc18LZ0GV2JkXG cw8D3XOvGQyXrnUFOKRmMKX0S+PvC4op/C6+IufbDLBi5q1padbPNBNwF1Jywt79/uX3 N6kQ== X-Gm-Message-State: AOAM533XFIlbugWIYoXb0+1HhtGIUyDieb+jA2TeNQQuysJrf2HPRPoA ojPabPMDDab+wY9LSWj3xQwx3Q== X-Google-Smtp-Source: ABdhPJx0+otiYCAHPq6CQ9cJdD6jVkuoNt9NaRuoXNvS+K1VEh/IhESSbQ3rerpybwtaOmEeML66jw== X-Received: by 2002:a7b:c74e:0:b0:37b:9785:fbe5 with SMTP id w14-20020a7bc74e000000b0037b9785fbe5mr14373492wmk.54.1645370078205; Sun, 20 Feb 2022 07:14:38 -0800 (PST) Received: from srini-hackbox.lan (cpc90716-aztw32-2-0-cust825.18-1.cable.virginm.net. [86.26.103.58]) by smtp.gmail.com with ESMTPSA id d6sm46703322wrs.85.2022.02.20.07.14.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 20 Feb 2022 07:14:37 -0800 (PST) From: Srinivas Kandagatla To: gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org, Christophe Kerello , stable@vger.kernel.org, Miquel Raynal , Srinivas Kandagatla Subject: [PATCH 2/2] mtd: core: Fix a conflict between MTD and NVMEM on wp-gpios property Date: Sun, 20 Feb 2022 15:14:32 +0000 Message-Id: <20220220151432.16605-3-srinivas.kandagatla@linaro.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20220220151432.16605-1-srinivas.kandagatla@linaro.org> References: <20220220151432.16605-1-srinivas.kandagatla@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Christophe Kerello 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. 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. A new Boolean flag named ignore_wp has been added in nvmem_config. In case ignore_wp 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. Fixes: 2a127da461a9 ("nvmem: add support for the write-protect pin") Signed-off-by: Christophe Kerello Cc: stable@vger.kernel.org Acked-by: Miquel Raynal Signed-off-by: Srinivas Kandagatla --- drivers/mtd/mtdcore.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c index 70f492dce158..eef87b28d6c8 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.ignore_wp =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(stru= ct mtd_info *mtd, config.owner =3D THIS_MODULE; config.type =3D NVMEM_TYPE_OTP; config.root_only =3D true; + config.ignore_wp =3D true; config.reg_read =3D reg_read; config.size =3D size; config.of_node =3D np; --=20 2.21.0