linux-kernel - Re: [PATCH 0/5] nvmem: some cleanups and sparse warning fixes

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:   Wed, 20 Sep 2017 19:02:24 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:     Keiji Hayashibara <hayashibara.keiji@...ionext.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Jassi Brar <jaswinder.singh@...aro.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Heiko Stuebner <heiko@...ech.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Kevin Hilman <khilman@...libre.com>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Joachim Eastwood <manabian@...il.com>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        linux-amlogic@...ts.infradead.org, Chen-Yu Tsai <wens@...e.org>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Carlo Caione <carlo@...one.org>
Subject: Re: [PATCH 0/5] nvmem: some cleanups and sparse warning fixes

Hi Srinivas,


2017-09-11 22:00 GMT+09:00 Masahiro Yamada <yamada.masahiro@...ionext.com>:
>
> Socionext is trying to add a new nvmem driver.
>
> Before adding a new one, I'd like to be sure about the preferred
> coding style in this subsystem, and build-up cleaner code base.
>
> Please pick up what you like.  Please feel free to throw away
> what you do not like.
>
> 1/5, 2/5: convert kzalloc to stack because nvmem_config
> is small one-time use data.
> This is what we agreed in the discussion.
>
> 3/5, 4/5: fix sparse warning
> For mtk-efuse, qfprom, the base address is the only private data
> but, assigning (void __iomem *) to ->priv directly causes sparse
> warnings.
>
> 5/5: clean-up of owner settings - if the owner field matches
> nvmem->dev->driver->onwer, we need not set the onwer field
> explicitly.


Does this series look OK?

Thanks.




-- 
Best Regards
Masahiro Yamada