RE: [PATCH 0/3] (Qualcomm) UFS device reset support

[Avri Altman <Avri.Altman@xxxxxxx>]

> 
> On Tue 04 Jun 22:50 PDT 2019, Avri Altman wrote:
> 
> > Hi,
> >
> > >
> > > On Tue, Jun 4, 2019 at 12:22 AM Bjorn Andersson
> > > <bjorn.andersson@xxxxxxxxxx> wrote:
> > > >
> > > > This series exposes the ufs_reset line as a gpio, adds support for ufshcd to
> > > > acquire and toggle this and then adds this to SDM845 MTP.
> > > >
> > > > Bjorn Andersson (3):
> > > >   pinctrl: qcom: sdm845: Expose ufs_reset as gpio
> > > >   scsi: ufs: Allow resetting the UFS device
> > > >   arm64: dts: qcom: sdm845-mtp: Specify UFS device-reset GPIO
> > >
> > > Adding similar change as in sdm845-mtp to the not yet upstream
> > > blueline dts, I validated this allows my micron UFS pixel3 to boot.
> > >
> > > Tested-by: John Stultz <john.stultz@xxxxxxxxxx>
> > Maybe ufs_hba_variant_ops would be the proper place to add this?
> >
> 
> Are you saying that these memories only need a reset when they are
> paired with the Qualcomm host controller?
ufs_hba_variant_ops is for vendors to implement their own vops,
and as you can see, many of them do.
Adding hw_reset to that template seems like the proper way
to do what you are doing.

Thanks,
Avri
> 
> The way it's implemented it here is that the device-reset GPIO is
> optional and only if you specify it we'll toggle the reset. So if your
> board design has a UFS memory that requires a reset pulse during
> initialization you specify this, regardless of which vendor your SoC
> comes from.
> 
> Regards,
> Bjorn