[PATCH v2 3/4] Revert "mtd: spi-nor-core: Perform a Soft Reset on boot"

[Pratyush Yadav]

On 17/12/21 06:27AM, Tudor.Ambarus at microchip.com wrote:
> On 12/16/21 8:45 PM, Pratyush Yadav wrote:
> >>>>
> >>>>>
> >>>>>> SFDP signature to determine the mode in which the flash is configured:
> >>>>>> '''
> >>>>>> try to read the SFDP signature (see 6.1) in 4-4-4 mode, if that fails
> >>>>>> try 2-2-2 mode, and if that fails try 1-1-1 mode. For Octal devices,
> >>>>>> these typically support SFDP read operation in both 1S-1S-1S mode and
> >>>>>> 8D-8D-8D mode. If the host controller does not know exactly which
> >>>>>> protocol mode is used for SFDP in 8D-8D-8D mode, this information can be
> >>>>>> found by reading SFDP in 1S-1S-1S mode first. (To read an unknown device
> >>>>>> directly in 8D-8D-8D mode, the host controller may read from address 0,
> >>>>>> and count the number of dummy clocks required before the SFDP signature
> >>>>>> is received.)
> >>>>>> '''
> >>>>
> >>>> Below is the approach for the flashes that are not SFDP compliant:
> >>>>
> >>>>>> If the flash does not support SFDP at all, one should introduce dedicated
> >>>>>> configs for each reset type and issue just the needed reset command.
> >>>
> >>> There are some problems with this approach. What if we have two flashes
> >>> on the board and both use different reset types? How do we figure out
> >>> which reset to apply? This applies to the current implementation as
> >>> well. If there are two flashes then it will issue the reset to both even
> >>> if one of them does not support/need it.
> >>
> >> One would have to choose the NOR manufacturer with care next time. If we'll
> >> have to statically define the reset type for both the flashes, there's nothing
> >> much we can do. Maybe if you have a gpio reset line connected to the flash you
> >> can toggle that instead.
> > 
> > Or we can specify the reset type in the device tree? That should neatly
> > solve the problem I believe.
> > 
> 
> It is surely an approach to consider. The downside with it is that people might
> abuse it, and use it regardless if the reset type is defined in SFDP or not.
> Do we care?

I am not sure to be honest. Let's think through that once the problem 
actually comes up I suppose.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.