linux-kernel - Re: [PATCH v5 13/15] mmc: sdhci-cadence: Add AMD Pensando Elba SoC support

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]

Date:   Sun, 3 Jul 2022 14:42:34 -0700
From:   Brad Larson <brad@...sando.io>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Al Cooper <alcooperx@...il.com>, Arnd Bergmann <arnd@...db.de>,
        blarson@....com, Catalin Marinas <catalin.marinas@....com>,
        Gabriel Somlo <gsomlo@...il.com>, gerg@...ux-m68k.org,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Lee Jones <lee.jones@...aro.org>,
        Mark Brown <broonie@...nel.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Pratyush Yadav <p.yadav@...com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Rob Herring <robh+dt@...nel.org>, samuel@...lland.org,
        Serge Semin <fancer.lancer@...il.com>,
        suravee.suthikulpanit@....com,
        Tom Lendacky <thomas.lendacky@....com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Will Deacon <will@...nel.org>,
        devicetree <devicetree@...r.kernel.org>
Subject: Re: [PATCH v5 13/15] mmc: sdhci-cadence: Add AMD Pensando Elba SoC support

Hi Andy,

On Tue, Jun 14, 2022 at 4:19 AM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
>
> On Mon, Jun 13, 2022 at 9:57 PM Brad Larson <brad@...sando.io> wrote:
>
> > Add support for AMD Pensando Elba SoC which explicitly controls
> > byte-lane enables on writes.  Add priv_write_l() which is
>
> enabling ?

Changed to enabling

> ...
>
> > +       void (*priv_write_l)(struct sdhci_cdns_priv *priv, u32 val,
>
> priv_writel

Changed to priv_writel

>
> > +                            void __iomem *reg);
>
> And perhaps leave it on one line.
>
> I also would swap parameters, so address goes first followed by value.

Which is the reverse of writel() parameter ordering which is value,
address.  Should I do this?

> ...
>
> > +static inline void sdhci_cdns_priv_writel(struct sdhci_cdns_priv *priv,
> > +                                         u32 val, void __iomem *reg)
> > +{
>
> > +       if (unlikely(priv->priv_write_l))
>
> First of all, why if (unlikely())-else instead of if (likely())-else?
>
> > +               priv->priv_write_l(priv, val, reg);
> > +       else
> > +               writel(val, reg);
> > +}

It was existing code and never looked at it.  This construct looks to
be widely used however this goes away with the two patch approach
below.

$ find . -name \*.c | xargs grep if | grep unlikely | wc
  18640

> Instead of branching each time you do I/O, make sure that callback is
> always set and call it unconditionally. In this case you don't need to
> have this callback, but maybe just a wrapper on `writel()`. As a
> result you may split this to two patches in the first of which you
> simply introduce a callback and a writel() wrapper which is assigned
> unconditionally to all current chips. In the next you add a new chip
> support.

Next version will separate into two patches as described

> ...
>
> > +       u32 m = (reg & 0x3);
> > +       u32 msk = (0x3 << (m));
> > +
> > +       spin_lock_irqsave(&priv->wrlock, flags);
> > +       writel(msk << 3, priv->ctl_addr);
> > +       writew(val, host->ioaddr + reg);
> > +       spin_unlock_irqrestore(&priv->wrlock, flags);
>
> Too many 3:s as magic. Is it GENMASK() or something else? Perhaps it
> needs a definition.

Definitely, changed this to be understandable by inspection.
GENMASK() for word and BIT() for byte makes this more clear.  The 3's
came from bits [6:3] are the byte-lane enables in the control reg
where the lower two bits of the address specify the byte(s) to enable.

/*  Elba control reg bits [6:3] are byte-lane enables */
#define ELBA_BYTE_ENABLE_MASK(x)        ((x) << 3)

elba_priv_write_l(...):
        writel(ELBA_BYTE_ENABLE_MASK(0xf), priv->ctl_addr);
        writel(val, reg);

elba_write_w(...):
        byte_enables = GENMASK(1, 0) << (reg & 0x3);
        writel(ELBA_BYTE_ENABLE_MASK(byte_enables), priv->ctl_addr);
        writew(val, host->ioaddr + reg);

> ...
>
> > +       u32 m = (reg & 0x3);
> > +       u32 msk = (0x1 << (m));
> > +
> > +       spin_lock_irqsave(&priv->wrlock, flags);
> > +       writel(msk << 3, priv->ctl_addr);
> > +       writeb(val, host->ioaddr + reg);
> > +       spin_unlock_irqrestore(&priv->wrlock, flags);
>
> Ditto.

elba_write_b(...):
        byte_enables = BIT(0) << (reg & 0x3);
        writel(ELBA_BYTE_ENABLE_MASK(byte_enables), priv->ctl_addr);
        writeb(val, host->ioaddr + reg);

> ...
>
> > +       writel(0x78, priv->ctl_addr);
>
> Magic.

writel(ELBA_BYTE_ENABLE_MASK(0xf), priv->ctl_addr);

> ...
>
> > +static const struct sdhci_cdns_drv_data sdhci_cdns_drv_data = {
> > +       .pltfm_data = {
> > +               .ops = &sdhci_cdns_ops,
> > +       },
> > +};
> > +
> > +
>
> One blank line is enough.

Removed extra blank line

> ...
>
> > +       {
> > +               .compatible = "amd,pensando-elba-sd4hc",
> > +               .data = &sdhci_elba_drv_data
>
> Leave a comma here.

Added comma

Regards,
Brad