SPI-NOR flashes have RESET pin which can be toggled using GPIO
controller, for those platforms reset-gpios property can be used to
reset the flash device.

Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
---
 Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
index 7149784a36ac..d2fc8e9c787f 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
@@ -70,6 +70,12 @@ properties:
       be used on such systems, to denote the absence of a reliable reset
       mechanism.
 
+  reset-gpios:
+    description:
+      contains a GPIO specifier. The reset GPIO is asserted and then deasserted
+      to perform device reset. If "broken-flash-reset" is present then having
+      this property does not make any difference.
+
   partitions:
     type: object
 
-- 
2.17.1

On 29/08/2022 12:05, Sai Krishna Potthuri wrote:
> SPI-NOR flashes have RESET pin which can be toggled using GPIO
> controller, for those platforms reset-gpios property can be used to
> reset the flash device.
> 
> Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
> ---
>  Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> index 7149784a36ac..d2fc8e9c787f 100644
> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> @@ -70,6 +70,12 @@ properties:
>        be used on such systems, to denote the absence of a reliable reset
>        mechanism.
>  
> +  reset-gpios:
> +    description:
> +      contains a GPIO specifier. 

Skip this part - obvious.

> The reset GPIO is asserted and then deasserted
> +      to perform device reset. If "broken-flash-reset" is present then having
> +      this property does not make any difference.

Isn't then broken-flash-reset conflicting with this one (e.g.
disallowing it)?

Best regards,
Krzysztof

Am 2022-08-30 11:21, schrieb Krzysztof Kozlowski:
> On 29/08/2022 12:05, Sai Krishna Potthuri wrote:
>> SPI-NOR flashes have RESET pin which can be toggled using GPIO
>> controller, for those platforms reset-gpios property can be used to
>> reset the flash device.
>> 
>> Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
>> ---
>>  Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 6 ++++++
>>  1 file changed, 6 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml 
>> b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>> index 7149784a36ac..d2fc8e9c787f 100644
>> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>> @@ -70,6 +70,12 @@ properties:
>>        be used on such systems, to denote the absence of a reliable 
>> reset
>>        mechanism.
>> 
>> +  reset-gpios:
>> +    description:
>> +      contains a GPIO specifier.
> 
> Skip this part - obvious.
> 
>> The reset GPIO is asserted and then deasserted
>> +      to perform device reset. If "broken-flash-reset" is present 
>> then having
>> +      this property does not make any difference.
> 
> Isn't then broken-flash-reset conflicting with this one (e.g.
> disallowing it)?

Sometimes the spi-nor driver needs to switch modes, which are persistent
until you either switch em back or do a hardware reset (or software
reset IIRC) of the flash. If broken-flash-reset is set, we try hard
to leave the flash in the mode which it is normally in after reset or
don't switch modes at all.
Of course we cannot make sure, our shutdown gets called in each case,
thus there is may be warning during startup.

So, even if you have a reset-gpio it might be broken I guess. Think
of it being high active, but someone forgot the pull-up. So, if you
do an unexpected reset, the flash chip might not be reset
automatically. So yes, I think, even if there is a dedicated reset
gpio, it could still be messed up. How likely is it? I don't know,
probably not very.

-michael

On 30/08/2022 12:36, Michael Walle wrote:
> Am 2022-08-30 11:21, schrieb Krzysztof Kozlowski:
>> On 29/08/2022 12:05, Sai Krishna Potthuri wrote:
>>> SPI-NOR flashes have RESET pin which can be toggled using GPIO
>>> controller, for those platforms reset-gpios property can be used to
>>> reset the flash device.
>>>
>>> Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
>>> ---
>>>  Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 6 ++++++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml 
>>> b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>>> index 7149784a36ac..d2fc8e9c787f 100644
>>> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>>> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>>> @@ -70,6 +70,12 @@ properties:
>>>        be used on such systems, to denote the absence of a reliable 
>>> reset
>>>        mechanism.
>>>
>>> +  reset-gpios:
>>> +    description:
>>> +      contains a GPIO specifier.
>>
>> Skip this part - obvious.
>>
>>> The reset GPIO is asserted and then deasserted
>>> +      to perform device reset. If "broken-flash-reset" is present 
>>> then having
>>> +      this property does not make any difference.
>>
>> Isn't then broken-flash-reset conflicting with this one (e.g.
>> disallowing it)?
> 
> Sometimes the spi-nor driver needs to switch modes, which are persistent
> until you either switch em back or do a hardware reset (or software
> reset IIRC) of the flash. If broken-flash-reset is set, we try hard
> to leave the flash in the mode which it is normally in after reset or
> don't switch modes at all.
> Of course we cannot make sure, our shutdown gets called in each case,
> thus there is may be warning during startup.
> 
> So, even if you have a reset-gpio it might be broken I guess. Think
> of it being high active, but someone forgot the pull-up. So, if you
> do an unexpected reset, the flash chip might not be reset
> automatically. So yes, I think, even if there is a dedicated reset
> gpio, it could still be messed up. How likely is it? I don't know,
> probably not very.

OK, so let's keep it and allow both.

Best regards,
Krzysztof