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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 42FD2C636D4 for ; Fri, 10 Feb 2023 22:50:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Date:To:Cc:From:Subject:References: In-Reply-To:MIME-Version:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7UfSoQMCUB+7/IK7DqmYEcwOsRAX8ObBoLL3ORi4pKk=; b=or9aU25zy50SuQ F4xVdK0EFeve9r4WomqPy4Encs+rOq54rg/gZ9iIKWjkjchFbLwpH/iNLb8DPBrIBXmPLknjsyMFA 4Tqms6At4T03t+17RsZ9m/mMW9bSdzEyWyKqB82kh8b0OSLHvxO8DFvo6Ge+k4/0fm2CAQd9pqe70 btr6KgBrV7mT8YS0Lfbt38kG0e/uxZPajiKzAFvK6KeceJaML5NMFGTy5MyveI4/dcagvJ/B7SmDz tnAJuqbGtFuHrjd2OW1ENzJQ6uDCtSQAEgWWxJw18g60NeK74GVhmqgrIIvv+ECowIPIpbsRDC0GK Op8IQwZxTMbLqPrjiX6w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQcCp-007pdW-Bq; Fri, 10 Feb 2023 22:49:23 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQcCl-007pc7-PN for linux-arm-kernel@lists.infradead.org; Fri, 10 Feb 2023 22:49:21 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3250861EB4; Fri, 10 Feb 2023 22:49:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E317C433D2; Fri, 10 Feb 2023 22:49:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1676069358; bh=SaVWEZqi6FK5RZrvwlP3inTyWF9/jTYSLZIuA+RQlOY=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=Fjsc41PSUvuYhRh/p0FRD7O8YG83EbFsky6WgGPSPQj4me6aOpo/Fu5UKT0XpT5OH BsJp9v8VLp64Nm6UIcXN+q8KNJNkwLpz6ikFjQqEQoT7fKL2d7aPBB9plkgu4PhYhg EjW/bDmSSV5ALnQMklISKwzbg/PtN6IBGHXD+v9xkjCKkqfoI+R43SMw4qAonK55gT eilyYyzi/i10qxnuwqrRzTACU0gZuVzCxpd6XFxPGTAAmY8E55PFcV5bFXrMpkLuxl 3O+lMjm8g83o0N9gcRJfHmiTOmtkaTUCFmN8vb1+MTNm8RPpB/obE2Shu9z7dRN8mV wmwjutvgTLw7w== Message-ID: <83a3c8d0abf217369f045df0217b1f64.sboyd@kernel.org> MIME-Version: 1.0 In-Reply-To: References: <20230101175740.1010258-1-dario.binacchi@amarulasolutions.com> <1fc8686b0b66c3b3ff80c044ecf1add6.sboyd@kernel.org> Subject: Re: [RFC PATCH v2 00/11] clk: imx8mn: setup clocks from the device tree From: Stephen Boyd Cc: Dario Binacchi , linux-kernel@vger.kernel.org, angelo@amarulasolutions.com, tommaso.merciai@amarulasolutions.com, Chen-Yu Tsai , linux-amarula@amarulasolutions.com, anthony@amarulasolutions.com, jagan@amarulasolutions.com, Abel Vesa , Adam Ford , Fabio Estevam , Krzysztof Kozlowski , Li Jun , Lucas Stach , Marek Vasut , Markus Niebel , Michael Turquette , NXP Linux Team , Pengutronix Kernel Team , Rob Herring , Sascha Hauer , Shawn Guo , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org To: Michael Nazzareno Trimarchi Date: Fri, 10 Feb 2023 14:49:16 -0800 User-Agent: alot/0.10 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230210_144919_932697_41BCB137 X-CRM114-Status: GOOD ( 27.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Quoting Michael Nazzareno Trimarchi (2023-01-26 02:49:54) > Hi > > On Wed, Jan 25, 2023 at 10:11 PM Stephen Boyd wrote: > > > > Quoting Dario Binacchi (2023-01-01 09:57:29) > > > The idea for this series was born back from Dublin (ELCE 2022) after > > > having attended the talk entitled "Updating and Modernizing Clock > > > Drivers" held by Chen-Yu Tsai and the availability of a board with > > > imx8mn SOC. > > > > Interesting. I didn't see any mention of putting clks into DT in that > > presentation. > > > > > > > > This series aims to setup all imx8mn's clocks from the device tree and > > > remove the legacy setup code with hardwired parameters. > > > > Please, no! We don't want one node per clk style of bindings. > > I think the idea behind is: > - create a way from silicon vendor to export their clock mapping with > automatic exportation I suspect silicon vendors automatically generate their clk drivers today. > - reduce the copy and paste code across the drivers > - avoid code duplication Code duplication should be avoided. Surely the clk_ops is shared? Data duplication is the real problem here. The status quo has been to have data descriptions of clks in drivers so that drivers can turn them on. If we're trying to avoid bloat then we only enable the drivers that we care about, or make them modular so they don't waste kernel memory. If you have ideas on how to avoid duplication there then by all means implement them. Don't move the data duplication problem to devicetree though. I've been wondering if we can tag drivers that are compiled into the kernel as freeable if they aren't ever going to probe because they're for some SoC that isn't present. That would allow us to shed various builtin clk drivers on systems instead of forcing us to make everything a module. > > Is the binding a way to solve this problem? Don't think so. > If you don't want one node > per clk style bindings, did you still think that the way > to go is totally wrong? Yes. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel