Re: [PATCH v13 2/2] leds: Add driver for Qualcomm LPG

[Bjorn Andersson]

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