Hi Ozan, > > > Also, what do you think about using dev_read_u32_default() with a > > default of 3 (appropriately documented) so that any users with > > modified or custom board device trees will not be surprised by this if > > they update to the latest? > > Fair point on not surprising existing users. My only hesitation is that > the SEC ID isn't really a value with a sensible universal default. It's > a fixed per-SoC hardware constant. It's 3 on the current SC5xx parts, but > on the upcoming ADSP SoC the watchdog maps to different SEC ID, for example. > > Defaulting to 3 keeps existing SC5xx device trees working (they all want > 3 anyway), so it does address the custom-DT case you raise. The trade-off > is that a future SoC whose DT omits the property would then probe > "successfully" while programming the wrong SEC source and silently > breaking the watchdog->reset path, rather than failing at probe. > > I'd lean slightly towards keeping it required so a misconfiguration is caught > early. But I don't feel strongly, if you'd prefer the default for the > custom-DT case, > I'm okay to use dev_read_u32_default() with a comment documenting that 3 is > the SC5xx value. Which would you prefer? >
I think you make a good point. Keep it as is, no default value. I would suggest adding a print statement describing the problem in that case, so that it is easy to find the issue with a custom DT from before this change. Thanks, Greg
