From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Walleij Subject: Re: [PATCH 2/2 v4] clk: Add Gemini SoC clock controller Date: Thu, 15 Jun 2017 14:57:53 +0200 Message-ID: References: <20170524082044.8473-1-linus.walleij@linaro.org> <20170601070208.GO20170@codeaurora.org> <20170605195812.GH20170@codeaurora.org> <20170612210248.GP20170@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Geert Uytterhoeven Cc: Stephen Boyd , Rob Herring , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Philipp Zabel , Lee Jones , Michael Turquette , linux-clk , Janos Laube , Paulius Zaleckas , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Hans Ulli Kroll , Florian Fainelli List-Id: devicetree@vger.kernel.org On Thu, Jun 15, 2017 at 10:55 AM, Geert Uytterhoeven wrote: > If clocks and resets are provided by the same hardware module, you can > have a single (platform) driver registering both the clock and reset > controllers. > Cfr. drivers/clk/renesas/renesas-cpg-mssr.c. That is indeed an option. So I would say, clk & reset maintainers: would you prefer that I merge the reset control into the clock driver as well, ask Philipp to drop the pending reset control patches from his subsystem tree and have you manage the combined driver and bindings? It seems to me as very ugly from a divide & conquer subsystem and file split point of view. I seems elegant from the "make clocks a platform device" point of view. I am happy with either approach as long as it works. I guess it is up to the taste of the subsystem maintainers, especially clk. If I get some time I might just hack this up and send the patches so it is on the table as an alternative to the current v5 patch. Certainly it is better than going back and augmenting the DT bindings. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: References: <20170524082044.8473-1-linus.walleij@linaro.org> <20170601070208.GO20170@codeaurora.org> <20170605195812.GH20170@codeaurora.org> <20170612210248.GP20170@codeaurora.org> From: Linus Walleij Date: Thu, 15 Jun 2017 14:57:53 +0200 Message-ID: Subject: Re: [PATCH 2/2 v4] clk: Add Gemini SoC clock controller To: Geert Uytterhoeven Cc: Stephen Boyd , Rob Herring , "devicetree@vger.kernel.org" , Philipp Zabel , Lee Jones , Michael Turquette , linux-clk , Janos Laube , Paulius Zaleckas , "linux-arm-kernel@lists.infradead.org" , Hans Ulli Kroll , Florian Fainelli Content-Type: text/plain; charset="UTF-8" List-ID: On Thu, Jun 15, 2017 at 10:55 AM, Geert Uytterhoeven wrote: > If clocks and resets are provided by the same hardware module, you can > have a single (platform) driver registering both the clock and reset > controllers. > Cfr. drivers/clk/renesas/renesas-cpg-mssr.c. That is indeed an option. So I would say, clk & reset maintainers: would you prefer that I merge the reset control into the clock driver as well, ask Philipp to drop the pending reset control patches from his subsystem tree and have you manage the combined driver and bindings? It seems to me as very ugly from a divide & conquer subsystem and file split point of view. I seems elegant from the "make clocks a platform device" point of view. I am happy with either approach as long as it works. I guess it is up to the taste of the subsystem maintainers, especially clk. If I get some time I might just hack this up and send the patches so it is on the table as an alternative to the current v5 patch. Certainly it is better than going back and augmenting the DT bindings. Yours, Linus Walleij From mboxrd@z Thu Jan 1 00:00:00 1970 From: linus.walleij@linaro.org (Linus Walleij) Date: Thu, 15 Jun 2017 14:57:53 +0200 Subject: [PATCH 2/2 v4] clk: Add Gemini SoC clock controller In-Reply-To: References: <20170524082044.8473-1-linus.walleij@linaro.org> <20170601070208.GO20170@codeaurora.org> <20170605195812.GH20170@codeaurora.org> <20170612210248.GP20170@codeaurora.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Jun 15, 2017 at 10:55 AM, Geert Uytterhoeven wrote: > If clocks and resets are provided by the same hardware module, you can > have a single (platform) driver registering both the clock and reset > controllers. > Cfr. drivers/clk/renesas/renesas-cpg-mssr.c. That is indeed an option. So I would say, clk & reset maintainers: would you prefer that I merge the reset control into the clock driver as well, ask Philipp to drop the pending reset control patches from his subsystem tree and have you manage the combined driver and bindings? It seems to me as very ugly from a divide & conquer subsystem and file split point of view. I seems elegant from the "make clocks a platform device" point of view. I am happy with either approach as long as it works. I guess it is up to the taste of the subsystem maintainers, especially clk. If I get some time I might just hack this up and send the patches so it is on the table as an alternative to the current v5 patch. Certainly it is better than going back and augmenting the DT bindings. Yours, Linus Walleij