2022-01-05 13:58:54

by Christophe Kerello

[permalink] [raw]
Subject: [PATCH 0/3] mtd: rawnand: stm32_fmc2: Add NAND Write Protect support

This patchset adds the management of the WP# signal in FMC2 driver.
WP will be disabled in probe/resume callbacks and will be enabled
in remove/suspend callbacks.

This patchset also fixes a conflict on wp-gpios property between
MTD and NVMEN.

Christophe Kerello (3):
dt-binding: mtd: nand: Document the wp-gpios property
mtd: rawnand: stm32_fmc2: Add NAND Write Protect support
nvmem: core: Fix a conflict between MTD and NVMEM on wp-gpios property

.../bindings/mtd/nand-controller.yaml | 7 ++++
drivers/mtd/nand/raw/stm32_fmc2_nand.c | 40 ++++++++++++++++++-
drivers/nvmem/core.c | 2 +-
3 files changed, 47 insertions(+), 2 deletions(-)

--
2.25.1



2022-01-05 13:59:01

by Christophe Kerello

[permalink] [raw]
Subject: [PATCH 2/3] mtd: rawnand: stm32_fmc2: Add NAND Write Protect support

This patch adds the support of the WP# signal. WP will be disabled in
probe/resume callbacks and will be enabled in remove/suspend callbacks.

Signed-off-by: Christophe Kerello <[email protected]>
---
drivers/mtd/nand/raw/stm32_fmc2_nand.c | 40 +++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
index 97b4e02e43e4..87c1c7dd97eb 100644
--- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
+++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
@@ -9,6 +9,7 @@
#include <linux/dmaengine.h>
#include <linux/dma-mapping.h>
#include <linux/errno.h>
+#include <linux/gpio/consumer.h>
#include <linux/interrupt.h>
#include <linux/iopoll.h>
#include <linux/mfd/syscon.h>
@@ -231,6 +232,7 @@ struct stm32_fmc2_timings {

struct stm32_fmc2_nand {
struct nand_chip chip;
+ struct gpio_desc *wp_gpio;
struct stm32_fmc2_timings timings;
int ncs;
int cs_used[FMC2_MAX_CE];
@@ -1747,6 +1749,18 @@ static const struct nand_controller_ops stm32_fmc2_nfc_controller_ops = {
.setup_interface = stm32_fmc2_nfc_setup_interface,
};

+static void stm32_fmc2_nfc_wp_enable(struct stm32_fmc2_nand *nand)
+{
+ if (nand->wp_gpio)
+ gpiod_set_value(nand->wp_gpio, 1);
+}
+
+static void stm32_fmc2_nfc_wp_disable(struct stm32_fmc2_nand *nand)
+{
+ if (nand->wp_gpio)
+ gpiod_set_value(nand->wp_gpio, 0);
+}
+
static int stm32_fmc2_nfc_parse_child(struct stm32_fmc2_nfc *nfc,
struct device_node *dn)
{
@@ -1785,6 +1799,18 @@ static int stm32_fmc2_nfc_parse_child(struct stm32_fmc2_nfc *nfc,
nand->cs_used[i] = cs;
}

+ nand->wp_gpio = devm_gpiod_get_from_of_node(nfc->dev, dn,
+ "wp-gpios", 0,
+ GPIOD_OUT_HIGH, "wp");
+ if (IS_ERR(nand->wp_gpio)) {
+ ret = PTR_ERR(nand->wp_gpio);
+ if (ret != -ENOENT)
+ return dev_err_probe(nfc->dev, ret,
+ "failed to request WP GPIO\n");
+
+ nand->wp_gpio = NULL;
+ }
+
nand_set_flash_node(&nand->chip, dn);

return 0;
@@ -1956,10 +1982,12 @@ static int stm32_fmc2_nfc_probe(struct platform_device *pdev)
chip->options |= NAND_BUSWIDTH_AUTO | NAND_NO_SUBPAGE_WRITE |
NAND_USES_DMA;

+ stm32_fmc2_nfc_wp_disable(nand);
+
/* Scan to find existence of the device */
ret = nand_scan(chip, nand->ncs);
if (ret)
- goto err_release_dma;
+ goto err_wp_enable;

ret = mtd_device_register(mtd, NULL, 0);
if (ret)
@@ -1972,6 +2000,9 @@ static int stm32_fmc2_nfc_probe(struct platform_device *pdev)
err_nand_cleanup:
nand_cleanup(chip);

+err_wp_enable:
+ stm32_fmc2_nfc_wp_enable(nand);
+
err_release_dma:
if (nfc->dma_ecc_ch)
dma_release_channel(nfc->dma_ecc_ch);
@@ -2012,15 +2043,20 @@ static int stm32_fmc2_nfc_remove(struct platform_device *pdev)

clk_disable_unprepare(nfc->clk);

+ stm32_fmc2_nfc_wp_enable(nand);
+
return 0;
}

static int __maybe_unused stm32_fmc2_nfc_suspend(struct device *dev)
{
struct stm32_fmc2_nfc *nfc = dev_get_drvdata(dev);
+ struct stm32_fmc2_nand *nand = &nfc->nand;

clk_disable_unprepare(nfc->clk);

+ stm32_fmc2_nfc_wp_enable(nand);
+
pinctrl_pm_select_sleep_state(dev);

return 0;
@@ -2042,6 +2078,8 @@ static int __maybe_unused stm32_fmc2_nfc_resume(struct device *dev)

stm32_fmc2_nfc_init(nfc);

+ stm32_fmc2_nfc_wp_disable(nand);
+
for (chip_cs = 0; chip_cs < FMC2_MAX_CE; chip_cs++) {
if (!(nfc->cs_assigned & BIT(chip_cs)))
continue;
--
2.25.1


2022-01-05 13:59:07

by Christophe Kerello

[permalink] [raw]
Subject: [PATCH 1/3] dt-binding: mtd: nand: Document the wp-gpios property

A few drivers use this property to describe the GPIO pin used to protect
the NAND during program/erase operations.

Signed-off-by: Christophe Kerello <[email protected]>
---
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 bd217e6f5018..53b21aed0ac5 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -154,6 +154,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.

+ wp-gpios:
+ description:
+ Contains one GPIO descriptor for the Write Protect pin.
+ Active state refers to the NAND Write Protect state and should be
+ set to GPIOD_ACTIVE_LOW unless the signal is inverted.
+ maxItems: 1
+
secure-regions:
$ref: /schemas/types.yaml#/definitions/uint64-matrix
description:
--
2.25.1


2022-01-05 13:59:10

by Christophe Kerello

[permalink] [raw]
Subject: [PATCH 3/3] nvmem: core: Fix a conflict between MTD and NVMEM on wp-gpios property

Wp-gpios property can be used on NVMEN 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 toggled 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.

As MTD framework is only using NVMEN framework in read only, a way to fix
this conflict is to get the GPIO resource at NVMEM level only if reg_write
API is defined. This GPIO is only toggled if reg_write ops is defined.

Signed-off-by: Christophe Kerello <[email protected]>
---
drivers/nvmem/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index e765d3d0542e..e11c74db64f9 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -769,7 +769,7 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)

if (config->wp_gpio)
nvmem->wp_gpio = config->wp_gpio;
- else
+ else if (config->reg_write)
nvmem->wp_gpio = gpiod_get_optional(config->dev, "wp",
GPIOD_OUT_HIGH);
if (IS_ERR(nvmem->wp_gpio)) {
--
2.25.1


2022-01-22 09:20:16

by Rob Herring (Arm)

[permalink] [raw]
Subject: Re: [PATCH 1/3] dt-binding: mtd: nand: Document the wp-gpios property

On Wed, 05 Jan 2022 14:57:32 +0100, Christophe Kerello wrote:
> A few drivers use this property to describe the GPIO pin used to protect
> the NAND during program/erase operations.
>
> Signed-off-by: Christophe Kerello <[email protected]>
> ---
> Documentation/devicetree/bindings/mtd/nand-controller.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>

Acked-by: Rob Herring <[email protected]>

2022-01-25 14:42:31

by Miquel Raynal

[permalink] [raw]
Subject: Re: [PATCH 3/3] nvmem: core: Fix a conflict between MTD and NVMEM on wp-gpios property

Hi Christophe,

[email protected] wrote on Wed, 5 Jan 2022 14:57:34 +0100:

Sorry for the time it took me to review this patchset.

> Wp-gpios property can be used on NVMEN 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 toggled this GPIO on

toggle

> each write when this GPIO should only be controlled at NAND level driver
> to ensure that the Write Protect has not been enabled.
>
> As MTD framework is only using NVMEN framework in read only, a way to fix

NVMEM

> this conflict is to get the GPIO resource at NVMEM level only if reg_write
> API is defined. This GPIO is only toggled if reg_write ops is defined.

The solution looks a bit hackish to me.

The nvmem_config structure already contains a field named wp_gpio which
seem to imply that callers can provide a wp_gpio handle there if they
want. But yet the nvmem core ignores if no gpio was provided and will
try to get one anyway. Shouldn't this behavior be changed?

There are already a big number of callers for nvmem_register() so I
understand it might be a bit tedious to just drop the else part of
that condition, but maybe we can provide a dummy cookie into the
wp_gpio field which would be interpreted as: "don't mess with it". Or
perhaps an additional flag somewhere else just to clearly skip the
wp_gpio thing entirely?

> Signed-off-by: Christophe Kerello <[email protected]>
> ---
> drivers/nvmem/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index e765d3d0542e..e11c74db64f9 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -769,7 +769,7 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
>
> if (config->wp_gpio)
> nvmem->wp_gpio = config->wp_gpio;
> - else
> + else if (config->reg_write)
> nvmem->wp_gpio = gpiod_get_optional(config->dev, "wp",
> GPIOD_OUT_HIGH);
> if (IS_ERR(nvmem->wp_gpio)) {

Thanks,
Miquèl

2022-01-25 14:56:42

by Srinivas Kandagatla

[permalink] [raw]
Subject: Re: [PATCH 3/3] nvmem: core: Fix a conflict between MTD and NVMEM on wp-gpios property



On 05/01/2022 13:57, Christophe Kerello wrote:
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index e765d3d0542e..e11c74db64f9 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -769,7 +769,7 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
>
> if (config->wp_gpio)
> nvmem->wp_gpio = config->wp_gpio;
> - else
> + else if (config->reg_write)
This is clearly not going to work for everyone.

A flag in nvmem_config to indicate that wp gpio is managed by provider
driver would be the right thing to do here.
> nvmem->wp_gpio = gpiod_get_optional(config->dev, "wp",
> GPIOD_OUT_HIGH);

--srini

2022-01-26 21:08:01

by Christophe Kerello

[permalink] [raw]
Subject: Re: [PATCH 3/3] nvmem: core: Fix a conflict between MTD and NVMEM on wp-gpios property

Hi Srinivas, Miquel,

On 1/25/22 11:44, Srinivas Kandagatla wrote:
>
>
> On 05/01/2022 13:57, Christophe Kerello wrote:
>> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
>> index e765d3d0542e..e11c74db64f9 100644
>> --- a/drivers/nvmem/core.c
>> +++ b/drivers/nvmem/core.c
>> @@ -769,7 +769,7 @@ struct nvmem_device *nvmem_register(const struct
>> nvmem_config *config)
>>       if (config->wp_gpio)
>>           nvmem->wp_gpio = config->wp_gpio;
>> -    else
>> +    else if (config->reg_write)
> This is clearly not going to work for everyone.
>
> A flag in nvmem_config to indicate that wp gpio is managed by provider
> driver would be the right thing to do here.

Based on your inputs, I will add a new boolean flag in nvmen_config
(proposal name: skip_wp_gpio) and I will set it to true in mtdcore.c
when nvmen_config structure is initialized. It will be part of the V2.

Regards,
Christophe Kerello.

>>           nvmem->wp_gpio = gpiod_get_optional(config->dev, "wp",
>>                               GPIOD_OUT_HIGH);
>
> --srini
>

2022-01-26 21:09:12

by Miquel Raynal

[permalink] [raw]
Subject: Re: [PATCH 3/3] nvmem: core: Fix a conflict between MTD and NVMEM on wp-gpios property

Hi Christophe,

[email protected] wrote on Wed, 26 Jan 2022 12:08:38 +0100:

> Hi Srinivas, Miquel,
>
> On 1/25/22 11:44, Srinivas Kandagatla wrote:
> >
> >
> > On 05/01/2022 13:57, Christophe Kerello wrote:
> >> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> >> index e765d3d0542e..e11c74db64f9 100644
> >> --- a/drivers/nvmem/core.c
> >> +++ b/drivers/nvmem/core.c
> >> @@ -769,7 +769,7 @@ struct nvmem_device *nvmem_register(const struct >> nvmem_config *config)
> >>       if (config->wp_gpio)
> >>           nvmem->wp_gpio = config->wp_gpio;
> >> -    else
> >> +    else if (config->reg_write)
> > This is clearly not going to work for everyone.
> >
> > A flag in nvmem_config to indicate that wp gpio is managed by provider > driver would be the right thing to do here.
>
> Based on your inputs, I will add a new boolean flag in nvmen_config (proposal name: skip_wp_gpio) and I will set it to true in mtdcore.c when nvmen_config structure is initialized. It will be part of the V2.

Fine by me. Thanks for your work on this.

>
> Regards,
> Christophe Kerello.
>
> >>           nvmem->wp_gpio = gpiod_get_optional(config->dev, "wp",
> >>                               GPIOD_OUT_HIGH);
> >
> > --srini
> >

Cheers,
Miquèl