Received: by 10.213.65.68 with SMTP id h4csp131937imn; Thu, 15 Mar 2018 11:48:26 -0700 (PDT) X-Google-Smtp-Source: AG47ELuZylVM8EiW9T/DBcyQykbbnwEi8BHuoL1HffkVEUhM65k52vc0GMyioY5XjGhBS8ukK6aH X-Received: by 10.99.191.8 with SMTP id v8mr2873331pgf.1.1521139706269; Thu, 15 Mar 2018 11:48:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521139706; cv=none; d=google.com; s=arc-20160816; b=ZyriYeEOcj6OSl/g5D+6qc1I27kcBjVN15rWpWcoBZYCuypjr1zpFvVEdS9A+03clB P9M6J4hwhoSH5sz0nyvWBTQQmiC127W0Yl7cO3X4XeXuZYSVTQdvSXLTJdY5nBjX7a6t 0+I0Q342ceeY677mzhZulOOQ9fAHJySKgeYz8a+5krddO2KpHjjIJql6ZdZQxMoUFS8s g2EP5YSK2TwKfphGMMwLvHXiKABQkjdb0/jhswbCYJsMB8Jr9YxZ2cwG16dYzptPYyLG 5PGu05QwkTNspqljbFZxY+vw+AAgAfmvzpbff4Rn1U8F30Q+u7zkxf9SjwdPAsXgPYo0 gc6Q== 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:dmarc-filter:arc-authentication-results; bh=0ncy93nsqNGx5rvJgikMt+zcrOMQrLVfpKKHApUDa4M=; b=Q3fyg/4Vacmo3F33rnb93xNS+Sb2gZeAS6JgjdYYFueM0kRHXVr316bl7YkvJkCu/r IWw1om0f7cvdcH3tL9m5ClVTK/4Gp7QNw9khd0hAISlEZFGtSlEEqUom3OclqernsLnJ StGPUMhsh2pYrxGW3BNn1cXZrn42OwrPdmzfGVUF54Bh/fyH01D2f+RMebVCXvcDJ+HV lhLy0wtZ+UNEhRjH0OOWvjTlyJ9hhn5YSOIw8gBTop2LlIZKfXYKodyUglaSdASmkmft cRib6xXDDTfqcAIMSJQ9vqN71lC1CkRU+wS/rqTYUjEejmsTgKhwSSooPJDtEap6t9Ru FnGw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u25si3788488pgn.488.2018.03.15.11.48.10; Thu, 15 Mar 2018 11:48:26 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752495AbeCOSrP convert rfc822-to-8bit (ORCPT + 99 others); Thu, 15 Mar 2018 14:47:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:35200 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751508AbeCOSrO (ORCPT ); Thu, 15 Mar 2018 14:47:14 -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 6C259204EF; Thu, 15 Mar 2018 18:47:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6C259204EF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=sboyd@kernel.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT 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> Message-ID: <152113963269.111154.10395846178696174140@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: Thu, 15 Mar 2018 11:47:12 -0700 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 working as > > intended without this patch, so maybe you can explain a little more 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 = 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. The alternative is to start working on a solution for having the clk framework stop using strings to describe clk topology. My plan there is to allow clk registration to indicate that another parent names array should be used with clk_get() of the device or node pointer that's associated with the clk during registration to find the parent . If we had that, then we could hook up clks into the tree by calling clk_get() in the framework and map through the clock-names property. This also gets us to a point where clk names don't have to be globally unique, which would be nice.