DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org E25F06155B
Date: Wed, 21 Dec 2016 16:31:22 -0800
From: Stephen Boyd <sboyd@codeaurora.org>
To: Imran Khan <kimran@codeaurora.org>
Cc: andy.gross@linaro.org, lee.jones@linaro.org,
        David Brown <david.brown@linaro.org>, linux-kernel@vger.kernel.org,
        linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org
Subject: Re: [PATCH v6] soc: qcom: Add SoC info driver
Message-ID: <20161222003122.GY8288@codeaurora.org>
References: <1481555889-29380-1-git-send-email-kimran@codeaurora.org>
 <20161214002617.GS5423@codeaurora.org>
 <d9ab1896-5c60-ef08-3eac-85de5624ca89@codeaurora.org>
 <20161217012615.GV5423@codeaurora.org>
 <05cdb699-6406-cff8-cce6-fcedf6ac6c4e@codeaurora.org>
 <20161220225007.GD5423@codeaurora.org>
 <1305f89c-2f9b-aa0b-4e22-951bf8af9344@codeaurora.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1305f89c-2f9b-aa0b-4e22-951bf8af9344@codeaurora.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1442
Lines: 28

On 12/21, Imran Khan wrote:
> On 12/21/2016 4:20 AM, Stephen Boyd wrote:
> > 
> > I'll wait to see what the next patch version has. We will
> > probably need to have some way to know which ODM the kernel is
> > running on, so we can interpret the platform type/subtype fields
> > properly. That part seems to be lacking from this patch right
> > now. We assume it's always qcom as the ODM, which isn't true.
> > 
> Now I get this point. So far we don't have any mechanism in the driver that
> gives ODM information. As far as generic soc_device_attribute's vendor field
> is concerned we use Qualcomm since this will be true for SoC.
> For hardware type and sub-types the various relevant values in SMEM are numeric
> values and indeed it would be very difficult to estimate how some other ODM
> will use the same number.
> So for the h/w types and sub-types can we keep the numeric values rather than 
> showing strings as attribute values. We can leave the interpretation of these
> values to ODM specific code.

Raw numbers sounds fine, but how do we know what ODM it is to
understand how to parse the numbers appropriately? Perhaps the
smem DT entry needs to have a property indicating the ODM that
has configured these numbers, and then we can have an ODM sysfs
node that we use to expose that string property to userspace?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project