On 02 December 2019 13:38, Adam Thomson wrote: > On 12/2/19 5:27 AM, Adam Thomson wrote: > > Hi Marco, > > > >>> Hmmm. Wouldn't that then be a board specific fix rather than this change? > >>> Am concerned relying on software to reenable the watchdog on resume > could > >> allow > >>> for a hang scenario potentially if that code never gets to execute. Other > >>> systems shouldn't need this fix, assuming they don't have issues at the HW > >>> level, so this this seems like it could be making those systems less robust. If > >>> we are to do this at the driver level, maybe this should be an option through > DT > >>> to help faulty systems, but I'm thinking this shouldn't be default behaviour. > >> > >> I don't think that we should rely on the OTP values. Those values are > >> set by Dialog, the SoM manufacturers or by the customer itself and the > >> time shows that this is error prone too. At least if the customer or the > >> SoM manufacturer don't ask the Dialog Support.. > >> > >> You're right with the (re-)enabling but there are other drivers using > >> such an approach.. IMHO it is safer to go this way rather than trust > >> the OTP and the PCB layout. I would rather add a dt-compatible to tell > >> the driver to do nothing during suspend/resume e.g.: > >> > >> - dlg,use-hw-pm > >> > >> or something. Because the user needs to validate the PCB and the OTP > >> values. > > > > The thing is the DT FW is supposed to be fairly static so I would rather not > > enforce this change on users if they adopt a kernel version with this update in. > > I also still think it's safer if the HW does this for us. I would have hoped for > > most designs this would be caught in early bring up where it can be rectified > > with minimal impact, although I'm guessing that's not the case in your scenario. > > > > dla,use-sw-pm ? > dla,hw-pm-broken ? Yes, I'd probably opt for 'dlg,use-sw-pm' or maybe 'dlg,manual-pm' to cover it. > > Guenter