linux-kernel - Re: [v3 1/2] mtd: nand: Add Cadence NAND 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]

Message-ID: <CAMuHMdXJ=DQgNzvwXiZd2-Xm=GwO0gFywOxpuX+xwHc3J7q+3g@mail.gmail.com>
Date:   Tue, 25 Jun 2019 17:23:01 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Dmitry Osipenko <digetx@...il.com>
Cc:     Piotr Sroka <piotrs@...ence.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Boris Brezillon <bbrezillon@...nel.org>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Marek Vasut <marek.vasut@...il.com>,
        Paul Burton <paul.burton@...s.com>,
        Arnd Bergmann <arnd@...db.de>,
        Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        Stefan Agner <stefan@...er.ch>,
        MTD Maling List <linux-mtd@...ts.infradead.org>
Subject: Re: [v3 1/2] mtd: nand: Add Cadence NAND controller driver

On Tue, Jun 25, 2019 at 4:45 PM Dmitry Osipenko <digetx@...il.com> wrote:
> 25.06.2019 16:02, Piotr Sroka пишет:
> > The 06/16/2019 16:42, Dmitry Osipenko wrote:
> >> 14.06.2019 18:09, Piotr Sroka пишет:
> >>> +/* Cadnence NAND flash controller capabilities get from driver data. */
> >>> +struct cadence_nand_dt_devdata {
> >>> +    /* Skew value of the output signals of the NAND Flash interface. */
> >>> +    u32 if_skew;
> >>> +    /* It informs if aging feature in the DLL PHY supported. */
> >>> +    u8 phy_dll_aging;
> >>> +    /*
> >>> +     * It informs if per bit deskew for read and write path in
> >>> +     * the PHY is supported.
> >>> +     */
> >>> +    u8 phy_per_bit_deskew;
> >>> +    /* It informs if slave DMA interface is connected to DMA engine. */
> >>> +    u8 has_dma;
> >>
> >> There is no needed to dedicate 8 bits to a variable if you only care about a single
> >> bit. You may write this as:
> >>
> >> bool has_dma : 1;
> > I modified it locally but it looks that checkpatch does not like such
> > notation
> > "WARNING: Avoid using bool as bitfield.  Prefer bool bitfields as
> > unsigned int or u<8|16|32>"
> > So maybe I will leave it as is.
>
> You may also use the "u8 : 1" form then, to satisfy the checkpatch. Probably
> "unsigned int : 1" will be the best in this case, it's up to you.

Exactly. The compiler will allocate the sufficient amount of space to store the
bitfield.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds