Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1761596AbcLPO6O (ORCPT <rfc822;w@1wt.eu>);
        Fri, 16 Dec 2016 09:58:14 -0500
Received: from mga04.intel.com ([192.55.52.120]:54405 "EHLO mga04.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1756770AbcLPO54 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 16 Dec 2016 09:57:56 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.33,358,1477983600"; 
   d="scan'208";a="1082697928"
Subject: Re: [alsa-devel] [PATCH v6 1/3] clk: x86: Add Atom PMC platform
 clocks
To: Andy Shevchenko <andy.shevchenko@gmail.com>
References: <1481306510-7471-1-git-send-email-irina.tirdea@intel.com>
 <1481306510-7471-2-git-send-email-irina.tirdea@intel.com>
 <CAHp75Vdaw4yvTPP2JZc+ti-AVNsisRQ+WG=JxPQ1jv-r7DADQA@mail.gmail.com>
 <20161213232524.GQ5423@codeaurora.org>
 <32235fb3-0d54-211d-28f4-4655e4bc7812@linux.intel.com>
 <CAHp75Vf7Sfq3_mSb6xf0NHutq8tO1y7Rhi7opDkomu+-vQZCYw@mail.gmail.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
        ALSA Development Mailing List <alsa-devel@alsa-project.org>,
        Irina Tirdea <irina.tirdea@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Michael Turquette <mturquette@baylibre.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>, Takashi Iwai <tiwai@suse.com>,
        platform-driver-x86@vger.kernel.org,
        "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>, Mark Brown <broonie@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>, Darren Hart <dvhart@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>, Len Brown <lenb@kernel.org>,
        linux-clk@vger.kernel.org,
        Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Message-ID: <07206bf1-2fab-0bbe-6e1b-762e55f62363@linux.intel.com>
Date: Fri, 16 Dec 2016 08:57:16 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CAHp75Vf7Sfq3_mSb6xf0NHutq8tO1y7Rhi7opDkomu+-vQZCYw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1745
Lines: 47

On 12/16/16 2:46 AM, Andy Shevchenko wrote:
> On Fri, Dec 16, 2016 at 7:15 AM, Pierre-Louis Bossart
> <pierre-louis.bossart@linux.intel.com> wrote:
>> Hi Stephen,
>>
>> can you elaborate on the last comment?
>
> Please don't do top posting.
>
>>>> devm_kasprintf()
>>>
>>> Please no.
>
> That's why I used modal verb "might" instead of "would".
>
>>> It's all local to this function, devm isn't helping anything.
>>> Having one kfree() would be good though. And using init.name for
>>> the clkdev lookup is probably wrong and should be replaced with
>>> something more generic along with an associated device name.
>>
>> I am not sure I understand this last comment.
>> init.name is not a constant, it's made of the "pmc_plt_clk_" string
>> concatenated with an id which directly maps to which hardware clock is
>> registered. Clients use devm_clk_get() with a "pmc_plt_clk_<n>" argument.
>
> Giving more thoughts about design and use of this I would propose to
> do the following.
>
> 1. Create under clock framework something like clk-pmc-atom clock
> driver (see, for example, clk-fractional-divider, though this one
> should indeed go under x86 folder).

apart from the name the current code already does this with code in 
drivers/clk/x86

> 2. In real provider, i.e. pmc_atom, create the necessary clock tree
> with *names*.
>
> Scheme with ID is fragile, imagine another version of PMC where
> ordering would be mixed up? It's not hypothetical since we used to
> have this already in pmc_atom for some registers and bits.

I don't want to deal with hypothetical stuff happening to legacy 
hardware. If there is a problem at some point, it's no big deal to add a 
platform-dependent lookup table and change the registers being accessed.