From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753520AbcFUBss (ORCPT ); Mon, 20 Jun 2016 21:48:48 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:55270 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752178AbcFUBso (ORCPT ); Mon, 20 Jun 2016 21:48:44 -0400 Date: Mon, 20 Jun 2016 18:48:16 -0700 From: Stephen Boyd To: Maxime Ripard Cc: Mike Turquette , Chen-Yu Tsai , linux-clk@vger.kernel.org, Hans de Goede , Andre Przywara , Rob Herring , Vishnu Patekar , linux-arm-kernel@lists.infradead.org, Boris Brezillon , Jean-Francois Moine , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v2 00/15] clk: sunxi: introduce "modern" clock support Message-ID: <20160621014816.GT1521@codeaurora.org> References: <20160607204154.31967-1-maxime.ripard@free-electrons.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160607204154.31967-1-maxime.ripard@free-electrons.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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