lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=X8Wci5cKPcfHQq-PjsexwLCjErnB63gF4_XgTBK9aWFQ@mail.gmail.com>
Date:   Tue, 14 Apr 2020 11:46:19 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Joe Perches <joe@...ches.com>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Maulik Shah <mkshah@...eaurora.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Evan Green <evgreen@...omium.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] soc: qcom: rpmh-rsc: Factor "tcs_reg_addr" and
 "tcs_cmd_addr" calculation

Hi,

On Tue, Apr 14, 2020 at 10:58 AM Joe Perches <joe@...ches.com> wrote:
>
> On Tue, 2020-04-14 at 10:41 -0700, Douglas Anderson wrote:
> > We can make some of the register access functions more readable by
> > factoring out the calculations a little bit.
>
> unrelated trivia:
>
> > diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
> []
> >  static void write_tcs_reg_sync(struct rsc_drv *drv, int reg, int tcs_id,
> >                              u32 data)
> >  {
> > -     writel(data, drv->tcs_base + RSC_DRV_TCS_OFFSET * tcs_id + reg);
> > +     writel(data, tcs_reg_addr(drv, reg, tcs_id));
> >       for (;;) {
> > -             if (data == readl(drv->tcs_base + reg +
> > -                               RSC_DRV_TCS_OFFSET * tcs_id))
> > +             if (data == readl(tcs_reg_addr(drv, reg, tcs_id)))
> >                       break;
> >               udelay(1);
> >       }
>
> There a lockup potential here.
>
> It might be better to use some max loop counter with
> an error/warning emitted instead of a continuous retry.

Yeah, I noticed that too but I assumed that it was probably OK.  I
think in this case it's really just confirming that the write made it
across the bus since it's checking the same bit that it's writing.
...but I wouldn't be opposed to this changing to use
readl_poll_timeout().

-Doug

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ