From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753511Ab3IWSPe (ORCPT ); Mon, 23 Sep 2013 14:15:34 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:48818 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752681Ab3IWSPO (ORCPT ); Mon, 23 Sep 2013 14:15:14 -0400 Message-ID: <524082E3.8070801@wwwdotorg.org> Date: Mon, 23 Sep 2013 12:05:23 -0600 From: Stephen Warren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Peter De Schrijver CC: Mike Turquette , Prashant Gaikwad , Thierry Reding , Joseph Lo , Paul Walmsley , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org Subject: Re: [PATCH 05/12] clk: tegra: add header for common tegra clock IDs References: <1379515331-19427-1-git-send-email-pdeschrijver@nvidia.com> <1379515331-19427-6-git-send-email-pdeschrijver@nvidia.com> In-Reply-To: <1379515331-19427-6-git-send-email-pdeschrijver@nvidia.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/18/2013 08:40 AM, Peter De Schrijver wrote: > Many clocks are common between several Tegra SoCs. Define an enum to list > them so we can move them to separate files which can be shared between > SoCs. Each SoC specific file will provide an array with the common clocks > which are present on the SoC and their DT binding ID. So, this enum is purely something internal to the driver, and is in no way related to the DT binding clock IDs, nor the HW peripheral clock register bits, and finally is a union of all extant clocks across all chips? If so, I suppose it's OK to make an enum for this. If not, the same comments I had re: trying to unify the DT binding clock IDs would apply here; if there's no architectural guarantee that the clock IDs will be kept the same across all future chips, assuming they are the same seems dangerous...