On Thu, Mar 03, 2022 at 11:17:33AM +0100, Daniel Lezcano wrote:
> On 03/03/2022 07:18, Sanil, Shruthi wrote:
> > > > > > > > + if (!(val & TIM_CONFIG_PRESCALER_ENABLE)) { +
> > > > > > > > pr_err("%pOF: Prescaler is not enabled\n", np);
> > > > > > > > + ret = -ENODEV; + }
> > > > > > >
> > > > > > > Why bail out instead of enabling the prescalar ?
> > > > > >
> > > > > > Because it is a secure register and it would be updated by
> > > > > > the bootloader.
> > > > > Should it be considered as a firmware bug ?
> > > >
> > > > No. This is a common driver across products in the series and
> > > > enablement of this bit depends on the project requirements.
> > > > Hence
> > > > to be sure from driver, we added this check to avoid
> > > > initialization of the driver in the case where it cannot be
> > > > functional.
> > >
> > > I'm not sure to get the meaning of 'project requirements' but (for
> > > my understanding) why not describe the timer in the DT for such
> > > projects?
> > >
> >
> > OK, I understand your point now. We can control the driver
> > initialization from device tree binding rather than add a check in
> > the driver. But isn't it good to have a check, if enabling of the bit
> > is missed out in the FW? This can help in debugging.
>
> So if the description is in the DT but the prescaler bit is not enabled then
> the firmware is buggy, IIUC. Yeah, this check would help, may be add more
> context in the error message, eg. "Firmware has not enabled the prescaler
> bit" or something like that
For this we also use a FW_BUG prefix to printf()-like functions.
--
With Best Regards,
Andy Shevchenko
