> > 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
