linux-kernel - Re: [PATCH v8 3/3] mmc: Add driver for LiteX's LiteSDCard interface

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] [day] [month] [year] [list]

Message-ID: <CAHp75VdPQyCd6shYvrr=Hy=hzkyJTu-deSXFJ2nQX=5cXfOKPg@mail.gmail.com>
Date:   Sun, 9 Jan 2022 13:36:40 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     "Gabriel L. Somlo" <gsomlo@...il.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "kgugala@...micro.com" <kgugala@...micro.com>,
        "mholenko@...micro.com" <mholenko@...micro.com>,
        "krakoczy@...micro.com" <krakoczy@...micro.com>,
        "mdudek@...ernships.antmicro.com" <mdudek@...ernships.antmicro.com>,
        "paulus@...abs.org" <paulus@...abs.org>,
        "joel@....id.au" <joel@....id.au>,
        "shorne@...il.com" <shorne@...il.com>,
        "geert@...ux-m68k.org" <geert@...ux-m68k.org>,
        "david.abdurachmanov@...ive.com" <david.abdurachmanov@...ive.com>,
        "florent@...oy-digital.fr" <florent@...oy-digital.fr>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>
Subject: Re: [PATCH v8 3/3] mmc: Add driver for LiteX's LiteSDCard interface

On Sun, Jan 9, 2022 at 1:51 AM Gabriel L. Somlo <gsomlo@...il.com> wrote:
>
> On Sat, Jan 08, 2022 at 07:47:32PM +0200, Andy Shevchenko wrote:
> > On Sat, Jan 8, 2022 at 3:20 PM Gabriel L. Somlo <gsomlo@...il.com> wrote:
> > > On Sat, Jan 08, 2022 at 01:26:08PM +0200, Andy Shevchenko wrote:
> > > > On Sat, Jan 8, 2022 at 3:57 AM Gabriel L. Somlo <gsomlo@...il.com> wrote:
> > > > > On Sat, Jan 08, 2022 at 01:54:07AM +0200, Andy Shevchenko wrote:
> > > > > > On Saturday, January 8, 2022, Gabriel Somlo <gsomlo@...il.com> wrote:
> >
> > ...
> >
> > > > > >     +       u32 div;
> > > > > >     +
> > > > > >     +       div = freq ? host->ref_clk / freq : 256U;
> > > > > >
> > > > > >     +       div = roundup_pow_of_two(div);
> > > > > >     +       div = clamp(div, 2U, 256U);
> > > > > >
> > > > > > Logically seems to me that you may join these two together, because clamped
> > > > > > range is power-of-2 one.
> > > > >
> > > > > `div` needs to be a power-of-2 when written to the LITEX_PHY_CLOCKERDIV
> > > > > register (below). And clamp() will just enforce a min/max range, so if
> > > > > (div = ref_clk / freq) ends up e.g., 5, I need both roundup_pow_of_two()
> > > > > to bump it to 8, and clamp() to enforce that it's between 2 and 256.
> > > > >
> > > > > Unless you mean I should simply write it like:
> > > > >
> > > > >         div = clamp(roundup_pow_of_two(div), 2U, 256U);
> > > > >
> > > > > ... as a single line?
> > > >
> > > > Yes, that's what I meant.
> > >
> > > Turns out, clamp really hates being passed roundup_pow_of_two()
> > > directly (see below). I think it's probably better if we leave
> > > them as-is, to avoid going the explicit cast route which Geert
> > > recommended against.
> >
> > I see, then ignore my comment on this matter in v9.
> > Perhaps add a comment in the code explaining that roundup_pow_of_two()
> > may not be unified with clamp()?
>
> I worry that commenting on why things are not done some other way at
> that location would detract from the legibility of the code itself.
>
> Perhaps we could use a cast after all, and write it out like this:
>
>         div = clamp((u32)roundup_pow_of_two(div), 2U, 256U);
>
> which compiles fine without any warnings, accomplishes your "do it in
> a single line" desired behavior, and doesn't require me commenting on
> which linux library functions do or don't work well with others... :)

We may survive without comment, it's not a big deal.

> Geert, what do you think?


-- 
With Best Regards,
Andy Shevchenko