linux-kernel - Re: [PATCH v2 00/15] clk: sunxi: introduce "modern" clock 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]

Message-ID: <20160621014816.GT1521@codeaurora.org>
Date:	Mon, 20 Jun 2016 18:48:16 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:	Mike Turquette <mturquette@...libre.com>,
	Chen-Yu Tsai <wens@...e.org>, linux-clk@...r.kernel.org,
	Hans de Goede <hdegoede@...hat.com>,
	Andre Przywara <andre.przywara@....com>,
	Rob Herring <robh+dt@...nel.org>,
	Vishnu Patekar <vishnupatekar0510@...il.com>,
	linux-arm-kernel@...ts.infradead.org,
	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	Jean-Francois Moine <moinejf@...e.fr>,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 00/15] clk: sunxi: introduce "modern" clock support

On 06/07, Maxime Ripard wrote:
> 
> The current code has been tested on the H3 and an Orange Pi PC,
> including making sure that MMC still works, so the general approach
> seems ok.
> 
> Let me know what you think,

Overall this looks pretty good. Thanks for taking the time to
rework the driver.

The macro nesting is sort of concerning, but if you're willing to
live with a maze of macros I'm not too worried. Also, I don't see
why we have to use the ccu_common structure everywhere even when
we're not gaining from it, but it's not a huge problem either
way. The non-mmio clks could be split off from the mmio list and
then registered in two lists, or there could be mmio list that
sets up the base address and then a larger list of clk_hw
pointers that we just run through and register.

It would be great if we could squeeze some more code reuse out of
the basic types too, but I'm not sure if there's much more that
can be done. Sometimes I'm seeing the same code multiple times
for handling muxes with parents and dividers or muxes without
dividers, etc. But that seems like future work that isn't going
to block anything here.

Finally, can you please use the clk_hw_register() APIs that we've
recently added. That will save us some time converting a new
driver over to use the new style of registering clks.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project