Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp307644pxb; Wed, 20 Jan 2021 07:31:08 -0800 (PST) X-Google-Smtp-Source: ABdhPJw2m1ko7xDwAk8aHCQqjwHU+rv0i3fl2VYV3F9dDWuf4hPK1yW7s3et7r1naVKDI6Lg3+HA X-Received: by 2002:a05:6402:104e:: with SMTP id e14mr7924955edu.316.1611156667805; Wed, 20 Jan 2021 07:31:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611156667; cv=none; d=google.com; s=arc-20160816; b=q5B6HQ0jTBadTVF5tHIl+H3L4oDmoMwMvtEZZwouzCxDZ48AWvakbgY7nD1umMk5Wh a/3Hm1b7hVbJr40XHff3adboE/e6DJUvlIajlt9Mw3SSo1WMquAPv2H0E92VnZcajbHS 7CjIU14iPeThDpnepSnpcnZf7H1hPtQWac0h4draMTSV1qhjTTI8fqdTOEGwfU+LxM58 51angprkRVAkHQ/n/bNDTANpp+BijlO4P5B12YWYbr8WWq3HlAk11pKOD5nVeMtivDMj PXvQxD7zWGLh0EfVnQ57byk01yIaT9wlRUglKEyBthRN+pPyrPaflFnlScx6QWS3u+E/ F5/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=G8yynmoVXn+TMX5uXBhiJ4Ec6H0dj45YFgGQG07GZ30=; b=AL5HT5esNIaX7y014gJosizNY/Cl9DOgkmzgd+pDZVFtkcuFbyMIuyRagr34nmGpg0 3omR9/0YFA0j/9a4XTH0nX9y9+odxKlle4CCsFZH6oGi/SMx97Gzd2bElLTR/1PVh83A FxusHn13D045Mo35DXKBgc3JwKcbppS1UmXt1k6vffOSlnTEGrnQtyUvyFdB4T+3MUty SEKXZTWCIJyeRsQo6D97XrMrhy93VpEcBJds6O5Q0D352izlpL88dRw1TUXhq1lrHvb1 laBt61GNb+GBQm2oQoIu5vwfKds7groxDr4UGpogw07S7Bh6LC5ksIIwNgLeNYfkOH36 S8PQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id qh14si797928ejb.360.2021.01.20.07.30.43; Wed, 20 Jan 2021 07:31:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390855AbhATP3k (ORCPT + 99 others); Wed, 20 Jan 2021 10:29:40 -0500 Received: from inva020.nxp.com ([92.121.34.13]:58500 "EHLO inva020.nxp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731468AbhATP3A (ORCPT ); Wed, 20 Jan 2021 10:29:00 -0500 Received: from inva020.nxp.com (localhost [127.0.0.1]) by inva020.eu-rdc02.nxp.com (Postfix) with ESMTP id 0331D1A0A82; Wed, 20 Jan 2021 16:28:14 +0100 (CET) Received: from inva024.eu-rdc02.nxp.com (inva024.eu-rdc02.nxp.com [134.27.226.22]) by inva020.eu-rdc02.nxp.com (Postfix) with ESMTP id E93E01A0A42; Wed, 20 Jan 2021 16:28:13 +0100 (CET) Received: from localhost (fsr-ub1664-175.ea.freescale.net [10.171.82.40]) by inva024.eu-rdc02.nxp.com (Postfix) with ESMTP id D4AA52039A; Wed, 20 Jan 2021 16:28:13 +0100 (CET) Date: Wed, 20 Jan 2021 17:28:13 +0200 From: Abel Vesa To: Sascha Hauer Cc: Adam Ford , arm-soc , Adam Ford-BE , Aisheng Dong , Michael Turquette , Stephen Boyd , Shawn Guo , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Linus Walleij , Jerome Brunet , linux-clk , Linux Kernel Mailing List Subject: Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout Message-ID: <20210120152813.x2pbs5vprevkly23@fsr-ub1664-175> References: <20210115182909.314756-1-aford173@gmail.com> <20210118125204.hxsanoohwvdtdvym@fsr-ub1664-175> <20210120144454.f6b72lnasw4q3bde@fsr-ub1664-175> <20210120151305.GC19063@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210120151305.GC19063@pengutronix.de> User-Agent: NeoMutt/20180622 X-Virus-Scanned: ClamAV using ClamSMTP Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21-01-20 16:13:05, Sascha Hauer wrote: > Hi Abel, > > On Wed, Jan 20, 2021 at 04:44:54PM +0200, Abel Vesa wrote: > > On 21-01-18 08:00:43, Adam Ford wrote: > > > On Mon, Jan 18, 2021 at 6:52 AM Abel Vesa wrote: ... > > > > > > > > > > > TBH, I'm against the idea of having to call consumer API from a clock provider driver. > > > > I'm still investigating a way of moving the uart clock control calls in drivers/serial/imx, > > > > where they belong. > > > > > > That makes sense. > > > > > > > Just a thought. The uart clock used for console remains on from u-boot, > > so maybe it's enough to just add the CLK_IGNORE_UNUSED flag to all the > > uart root clocks and remove the prepare/enable calls for uart clocks > > for good. I don't really have a way to test it right now, but maybe > > you could give it a try. > > That would mean that UART clocks will never be disabled, regardless of > whether they are used for console or not. That doesn't sound very > appealing. AFAIK, the only uart clock that is enabled by u-boot is the one used for the console. Later on, when the serial driver probes, it will enable it itself. Unless I'm missing something, this is exactly what we need.