netdev - Re: [PATCH v8 02/15] octeontx2-af: Reset all RVU blocks

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: <CA+sq2CeXzLip7TQJL1ns57nvP-SfYT4HEO0o3fm0d6WhVpGKuA@mail.gmail.com>
Date:   Tue, 9 Oct 2018 12:40:15 +0530
From:   Sunil Kovvuri <sunil.kovvuri@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Linux Netdev List <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>, linux-soc@...r.kernel.org,
        Sunil Goutham <sgoutham@...vell.com>
Subject: Re: [PATCH v8 02/15] octeontx2-af: Reset all RVU blocks

On Mon, Oct 8, 2018 at 5:46 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Sun, Oct 7, 2018 at 5:00 PM <sunil.kovvuri@...il.com> wrote:
> >
> > From: Sunil Goutham <sgoutham@...vell.com>
> >
> > Go through all BLKADDRs and check which ones are implemented
> > on this silicon and do a HW reset of each implemented block.
> > Also added all RVU AF and PF register offsets.
> >
>
> >
> > +/* Poll a RVU block's register 'offset', for a 'zero'
> > + * or 'nonzero' at bits specified by 'mask'
> > + */
> > +int rvu_poll_reg(struct rvu *rvu, u64 block, u64 offset, u64 mask, bool zero)
> > +{
> > +       void __iomem *reg;
> > +       int timeout = 100;
> > +       u64 reg_val;
> > +
> > +       reg = rvu->afreg_base + ((block << 28) | offset);
> > +       while (timeout) {
> > +               reg_val = readq(reg);
> > +               if (zero && !(reg_val & mask))
> > +                       return 0;
> > +               if (!zero && (reg_val & mask))
> > +                       return 0;
> > +               udelay(1);
> > +               cpu_relax();
> > +               timeout--;
> > +       }
> > +       return -EBUSY;
> > +}
>
> This can be a fairly long wait of multiple milliseconds, given that
> you call it nine times in a row, that each udelay() can take
> multiple microseconds (plus the time for the readq()), and
> you look 100 times.
>
> It seems this is only called from probe(), which is not in atomic
> context, and you don't hold any locks, so why not change the
> udelay() to an msleep() or usleep_range() to let some other
> process run?
>
>        Arnd

Sure, usleep_range seems to be a better option, will change.

Thanks,
Sunil.