linux-kernel - Re: [PATCH v6 3/3] EDAC: nuvoton: Add NPCM memory controller driver

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:   Thu, 14 Apr 2022 10:42:32 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Medad Young <medadyoung@...il.com>,
        Paul Menzel <pmenzel@...gen.mpg.de>
Cc:     rric@...nel.org, James Morse <james.morse@....com>,
        tony.luck@...el.com, Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Benjamin Fair <benjaminfair@...gle.com>,
        Nancy Yuen <yuenn@...gle.com>,
        Patrick Venture <venture@...gle.com>, KWLIU@...oton.com,
        YSCHU@...oton.com, JJLIU0@...oton.com, KFTING <KFTING@...oton.com>,
        Avi Fishman <avifishman70@...il.com>,
        Tomer Maimon <tmaimon77@...il.com>,
        Tali Perry <tali.perry1@...il.com>, ctcchien@...oton.com,
        devicetree <devicetree@...r.kernel.org>,
        OpenBMC Maillist <openbmc@...ts.ozlabs.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-edac <linux-edac@...r.kernel.org>
Subject: Re: [PATCH v6 3/3] EDAC: nuvoton: Add NPCM memory controller driver

On Thu, Apr 14, 2022 at 09:55:05AM +0800, Medad Young wrote:
> > > +                             if (mtype == MEM_TYPE_DDR4)
> > > +                                     dimm->mtype = MEM_DDR4;
> > > +                             else
> > > +                                     dimm->mtype = MEM_EMPTY;
> >
> > Use ternary operator?
> >
> >      dimm-mtype = (mtype == MEM_TYPE_DDR4) ? MEM_DDR4 : MEM_EMPTY;

Ternary operator is less readable than a plain and simple if-else.

> > > +{
> > > +     struct priv_data *priv = mci->pvt_info;
> > > +     const struct npcm_edac_platform_data *npcm_chip = priv->npcm_chip;
> > > +     u64 err_c_addr = 0x0;
> >
> > size_t
> 
> OK

Why is size_t? error address doesn't have anything to do with a
sizeof(), array indexing or loop counting.

It is an error address and having it in an u64 tells you exactly what
its quantity is.

So can we stop the silliness pls?

> > > +static irqreturn_t edac_ecc_isr(int irq, void *dev_id)
> > > +{
> > > +     struct mem_ctl_info *mci = dev_id;
> > > +     struct priv_data *priv = mci->pvt_info;
> > > +     const struct npcm_edac_platform_data *npcm_chip = priv->npcm_chip;
> > > +     u32 intr_status;
> > > +     u32 val;
> > > +
> > > +     /* Check the intr status and confirm ECC error intr */
> > > +     intr_status = readl(priv->reg + npcm_chip->ecc_ctl_int_status);
> > > +
> > > +     edac_dbg(3, "InterruptStatus : 0x%x\n", intr_status);
> >
> > Remove the space before the colon? Maybe use:
> >
> > "Interrupt status (intr_status): 0x%x\n"

And repeat "interrupt status"? Also silly. The question to ask
yourselves should always be: is this error message helpful enough to its
intended recipients.

When I see

  "Interrupt status (intr_status): 0x%x\n"

in my code, I go: "hm, where does this message come from?" because it
ain't helpful enough. So I have to go stare at the code too.

I hope you're catching my drift.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette