From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC6F7C4320E for ; Sat, 31 Jul 2021 07:41:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C0F6660F35 for ; Sat, 31 Jul 2021 07:41:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232027AbhGaHl2 (ORCPT ); Sat, 31 Jul 2021 03:41:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:36210 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230196AbhGaHl1 (ORCPT ); Sat, 31 Jul 2021 03:41:27 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3148A60EE6; Sat, 31 Jul 2021 07:41:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627717281; bh=Hv1Kjt0wM3IMrL51Qq27kQRTwgyaY1whymskpzTrLBg=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=Mfe/v8Uz7KZzXezwTwjXNOUR+12p4qzmq6509mWK4HR6HXGPAgYYHOsPNIDypMN4W dptRTFmjMlRcoslggxxB3pGQBj0x6UrIzpyRhgK0eHShF1H4ayZFJwSjbVOjohBESi S7z2KmeryQRXtF7eCeDb2EWvnztkdGkPMUlZcvNgWKzC+b7h/pDhgVb1avCQX29DcW jD3PhoYFAFhcJd+plY+0d1jbLOvWrCoQRpOp8y4dhHXeVVhAQXt6M5qmuAJacc37Fb htU5NUsNIGPVW4EzuZd3O1Ri4wdN/qcx17MjnStx1zor6X+sjRKLhzQ7jQZ84kkJOU +DAteW7woUfZA== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20210728204033.GF22278@shell.armlinux.org.uk> References: <20210625171434.3xusxpxjprcdqa47@pengutronix.de> <20210722060654.nudpdtemosi64nlb@pengutronix.de> <20210722081817.2tsjzof4gvldq6ka@pengutronix.de> <20210723091331.wl33wtcvvnejuhau@pengutronix.de> <06e799be-b7c0-5b93-8586-678a449d2239@microchip.com> <20210728202547.7uvfwflpruku7yps@pengutronix.de> <20210728204033.GF22278@shell.armlinux.org.uk> Subject: Re: About clk maintainership [Was: Re: [PULL] Add variants of devm_clk_get for prepared and enabled clocks enabled clocks] From: Stephen Boyd Cc: Michael Turquette , Claudiu.Beznea@microchip.com, alexandre.belloni@bootlin.com, linux-kernel@vger.kernel.org, thierry.reding@gmail.com, lee.jones@linaro.org, linux-clk@vger.kernel.org, linux-rtc@vger.kernel.org, Ludovic.Desroches@microchip.com, o.rempel@pengutronix.de, andy.shevchenko@gmail.com, aardelean@deviqon.com, linux-pwm@vger.kernel.org, Arnd Bergmann , broonie@kernel.org, Jonathan.Cameron@huawei.com, linux-arm-kernel@lists.infradead.org, a.zummo@towertech.it, linux-spi@vger.kernel.org, wsa@kernel.org, kernel@pengutronix.de, akpm@linux-foundation.org, torvalds@linux-foundation.org To: Russell King (Oracle) , Date: Sat, 31 Jul 2021 00:41:19 -0700 Message-ID: <162771727997.714452.2303764341103276867@swboyd.mtv.corp.google.com> User-Agent: alot/0.9.1 Precedence: bulk List-ID: X-Mailing-List: linux-pwm@vger.kernel.org Quoting Russell King (Oracle) (2021-07-28 13:40:34) > > I adapted the Subject in the hope to catch Stephen's and Michael's > > attention. My impression is that this thread isn't on their radar yet, > > but the topic here seems important enough to get a matching Subject. The thread is on my radar but... >=20 > Have you thought about sending your pull request to the clk API > maintainer (iow, me) ? >=20 +1 This patch doesn't fall under CCF maintainer. $ ./scripts/get_maintainer.pl -f include/linux/clk.h Russell King (maintainer:CLK API) linux-clk@vger.kernel.org (open list:CLK API) linux-kernel@vger.kernel.org (open list) Finally, this sort of patch has been discussed for years and I didn't see any mention of those previous attempts in the patch series. Has something changed since that time? I think we've got a bunch of hand rolled devm things in the meantime but not much else.=20 I still wonder if it would be better if we had some sort of DT binding that said "turn this clk on when the driver probes this device and keep it on until the driver is unbound". That would probably work well for quite a few drivers that don't want to ever call clk_get() or clk_prepare_enable() and could tie into the assigned-clock-rates property in a way that let us keep the platform details out of the drivers. We could also go one step further and make a clk pm domain when this new property is present and then have the clk be enabled based on runtime PM of the device (and if runtime PM is disabled then just enable it at driver probe time).