| Message ID | 20220105135734.271313-4-christophe.kerello@foss.st.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Miquel Raynal |
| Headers | show |
| Series | mtd: rawnand: stm32_fmc2: Add NAND Write Protect support | expand |
Hi Christophe, christophe.kerello@foss.st.com 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 <christophe.kerello@foss.st.com> > --- > 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
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
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 >
Hi Christophe, christophe.kerello@foss.st.com 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
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)) {
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 <christophe.kerello@foss.st.com> --- drivers/nvmem/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)