On Thu 03 Mar 08:41 PST 2022, Doug Anderson wrote:
> Hi,
>
> On Wed, Mar 2, 2022 at 4:03 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
> >
> > Hi,
> >
> > On Fri, Feb 18, 2022 at 10:29 AM Bjorn Andersson
> > <bjorn.andersson@xxxxxxxxxx> wrote:
> > >
> > > +static void lpg_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> > > + struct pwm_state *state)
> > > +{
> > > + struct lpg *lpg = container_of(chip, struct lpg, pwm);
> > > + struct lpg_channel *chan = &lpg->channels[pwm->hwpwm];
> > > + unsigned int pre_div;
> > > + unsigned int refclk;
> > > + unsigned int val;
> > > + unsigned int m;
> > > + u16 pwm_value;
> > > + int ret;
> > > +
> > > + ret = regmap_read(lpg->map, chan->base + LPG_SIZE_CLK_REG, &val);
> > > + if (ret)
> > > + return;
> > > +
> > > + refclk = lpg_clk_rates[(val & PWM_CLK_SELECT_MASK) - 1];
> >
> > I don't know why I didn't notice it before (maybe I was accidentally
> > not building with KASAN?), but in my recent boots I'm getting a KASAN
> > error pointing at the line above.
> >
> > Sure enough, the above looks a bit on the unsafe side. If (val & 0x3)
> > is 0 then the "-1" will not be so wonderful. I put some printouts and,
> > indeed, it's not so great.
> >
> > [ 7.201635] DOUG: val is 0x00000004
> >
> > Amazingly my `refclk` ends up as 0 and I guess somehow this doesn't
> > cause a divide by 0.
>
> I dug a little more and found a document that talks about this
> register. I guess the answer here is that at boot time on my device
> the PWM is disabled and has never been enabled. That explains why, at
> boot time, the "clk_select" is 0 AKA "no clock". So we do an invalid
> memory access here and that's not so great, but it doesn't _truly_
> cause any harm. All we need is something like this right before the
> array dereference:
>
> if ((val & PWM_CLK_SELECT_MASK) == 0)
> return;
>
Thanks for spotting and digging that up. I can confirm that the
documentation has 0 as "no clock" and I think it would be nice if
lpg_clk_rates[] reflected the possible hardware values. That way we can
also get rid of the + 1 in lpg_apply_freq().
I will fix this up, as well as fix up the indentation issue spotted by
Uwe in the documentation and repost.
Regards,
Bjorn
> I'm still pretty interested in seeing this patch series land and, if
> it helps it land sooner, I wouldn't object to the above getting fixed
> in a followup patch.
>
> -Doug
