Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1399320imm; Fri, 1 Jun 2018 23:41:18 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIvNNHMARgaUUXUEafytozrmkWKOVU5volw4fJWARqJ8YvQ+kigl3NUGldIUkZRl5k9Z9qc X-Received: by 2002:a63:8f0d:: with SMTP id n13-v6mr11390402pgd.109.1527921678596; Fri, 01 Jun 2018 23:41:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527921678; cv=none; d=google.com; s=arc-20160816; b=qBkYVZ4FV+QnrcLgvP+b6uSA/HVlz7V3P96iDTjQUPG3hrsVrcZcJiViGpT+NrJdxq ejzZkWM/l/+7VzTHvq0yRYnFu5Na7nb4A+UDi+iQvuykAxDNr75PdUr3IGPBVQ9TctV7 AXX85qi6vf8l1rL9xarkxTn0Gkd+/i0orOhX9uWIewCbMbjiLNrCThx7xyqhrIlwrNeI k0do+XUJpJ4eYHlf0xcUSvyZw5BtCPt2xiFaD0SYFJ8P/ckgJnq9uzn8TsYXCeWjYGP/ 7e+MAASkwMAkl9DcgenEhVB6/WEATvUgpgPOizRzRnhCg4pC5zqhTVs5OIduWj6RNygd /5ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:user-agent:message-id :references:cc:in-reply-to:from:to:content-transfer-encoding :mime-version:dkim-signature:arc-authentication-results; bh=PkedYiKm7MOvqPlcobkiqwAGnpAP8HsTQ6ALu7W7iXE=; b=DCuBbGKngxgIyuB2u5Q+/I6aTrtEYbSn2jDp2JovYd0hTzMRh+jwAkwUuu3i0lzNcw V1/6uzrM/IeIbY4u59CfoY/tXWjaEs0+fHjDRQKfVRR19ak59MLSg92SKy4AapP9zIZv 63Q1Lz2+SLOA/q+xVMRiP1YwKjPElOPWOt+ZYNmiT2xUT9XEtl0jFNuYEsriXXp8wDJH f6fnOTXHAOR7xiFac8CNr0eUsjKOPFdbvr2yVmnc12YFdDg2ihwov4c5UKsnURkkI3ab adgEK+q1QYgrVq5SCnpIdQg5Azx/Mj1I9DHDJVtg5G/7ZuAW9firWGSyamKwzketufSQ L7Cw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NyLSI+Lf; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v136-v6si8874193pfc.273.2018.06.01.23.41.04; Fri, 01 Jun 2018 23:41:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NyLSI+Lf; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751477AbeFBGkk (ORCPT + 99 others); Sat, 2 Jun 2018 02:40:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:54184 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750812AbeFBGkh (ORCPT ); Sat, 2 Jun 2018 02:40:37 -0400 Received: from localhost (unknown [104.132.1.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 17ED720876; Sat, 2 Jun 2018 06:40:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1527921637; bh=L/IKp/qaWfEhbN/GMa+IoKpVuCPU8+oCi7G5jh0idmQ=; h=To:From:In-Reply-To:Cc:References:Subject:Date:From; b=NyLSI+LfP5m8jjeeglJ2IDxI6Pr55q6jmkskK1fR8jlaziX+epvz9Mef1Fkq8Myn/ hacG08i0srxQP+yeP8TmvudeXig2PYKy4Rxg0vgsnhWG2WPAGjLandtNK/8U03SlKH sZkpvoOWXPj9r1q6ZsGrVcP+vj7TGd5eD7aelDEk= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable To: Rajan Vaja From: Stephen Boyd In-Reply-To: Cc: "linux-clk@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Jolly Shah , Michal Simek , "mturquette@baylibre.com" References: <1520518500-5500-1-git-send-email-rajanv@xilinx.com> <152061989141.26240.15533446439693285034@swboyd.mtv.corp.google.com> <152113963269.111154.10395846178696174140@swboyd.mtv.corp.google.com> Message-ID: <152792163637.225090.8916381060805852261@swboyd.mtv.corp.google.com> User-Agent: alot/0.7 Subject: RE: [PATCH] clk: clk-fixed-factor: Use new macro CLK_OF_DECLARE_DRIVER Date: Fri, 01 Jun 2018 23:40:36 -0700 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Rajan Vaja (2018-05-03 02:18:30) > Hi Stephen, > = > > -----Original Message----- > > From: Rajan Vaja > > Sent: 16 March 2018 05:20 PM > > To: 'Stephen Boyd' > > Cc: linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org; Jolly Shah > > ; Michal Simek ; > > mturquette@baylibre.com > > Subject: RE: [PATCH] clk: clk-fixed-factor: Use new macro > > CLK_OF_DECLARE_DRIVER > > = > > Hi Stephen, > > = > > Thanks for the comment. > > = > > > -----Original Message----- > > > From: Stephen Boyd [mailto:sboyd@kernel.org] > > > Sent: 16 March 2018 12:17 AM > > > To: Rajan Vaja > > > Cc: linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org; Jolly Sh= ah > > > ; Michal Simek ; > > > mturquette@baylibre.com > > > Subject: RE: [PATCH] clk: clk-fixed-factor: Use new macro > > > CLK_OF_DECLARE_DRIVER > > > > > > Quoting Rajan Vaja (2018-03-09 11:27:40) > > > > > From: Stephen Boyd [mailto:sboyd@kernel.org] > > > > > > > > > > Is the intent to register the clk twice? I believe things are wor= king as > > > > > intended without this patch, so maybe you can explain a little mo= re what > > > > > you're trying to fix. > > > > [Rajan] Yes. During of_clk_init() if some DT fixed factor clock has > > > > parent which is neither mentioned in output-clock-names of clock > > > > controller nor registered as clock provider, of_clk_init() will try= to > > > > forcefully register in second loop. > > > > > > > > if (force || parent_ready(clk_provider->np)= ) { > > > > > > > > /* Don't populate platform devices = */ > > > > of_node_set_flag(clk_provider->np, > > > > OF_POPULATED); > > > > > > > > So registration of this DT fixed-factor clock would fail as parent > > > > would be NULL as below (called from _of_fixed_factor_clk_setup()): > > > > parent_name =3D of_clk_get_parent_name(node, 0); > > > > > > > > On the other hand, even if registration failed, that node will be > > > > marked as OF_POPULATED, so probe of clk-fixed-factor.c will also not > > > > be called and that DT fixed-factor clock would never be registered. > > > > > > > > Same thing is discussed at https://lkml.org/lkml/2017/6/5/681 . > > > > > > Ok. I believe the answer is to fix the DT to describe the parent chain > > > properly with clock-output-names. Otherwise, we have no good way of > > > figuring out what the name should be. > > [Rajan] clock DT binding doc says that clock-output-names property > > is optional and sometimes not recommended. > > I think this patch fixes the issue we have which mandates to add clock-= output- > > names > > property (for this particular case). Also, IIUC platform driver probe i= n clk-fixed- > > factor.c > > will never be called unless we use CLK_OF_DECLARE_DRIVER. > > I completely agree that proper solution would be to stop using strings = to > > describe clock topology. > [Rajan] Any comments on this? > Unless we have proper solution ready, we need to have some mechanism to h= andle this scenario. > clock-output-names is optional and without this, it mandates to use clock= -output-names. > = I couldn't read your outlook sent email and I was too busy to go translate it. Some bug in my MUA it seems. Can you add the output-names property? In this case it's practically mandatory, so if you can't do it I'd like to hear why not.