From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752122AbcL1WfN (ORCPT ); Wed, 28 Dec 2016 17:35:13 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:34692 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751890AbcL1WfL (ORCPT ); Wed, 28 Dec 2016 17:35:11 -0500 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org 49032611B7 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=sboyd@codeaurora.org Date: Wed, 28 Dec 2016 14:35:09 -0800 From: Stephen Boyd To: Imran Khan Cc: andy.gross@linaro.org, lee.jones@linaro.org, David Brown , 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: <20161228223509.GA17126@codeaurora.org> References: <1481555889-29380-1-git-send-email-kimran@codeaurora.org> <20161214002617.GS5423@codeaurora.org> <20161217012615.GV5423@codeaurora.org> <05cdb699-6406-cff8-cce6-fcedf6ac6c4e@codeaurora.org> <20161220225007.GD5423@codeaurora.org> <1305f89c-2f9b-aa0b-4e22-951bf8af9344@codeaurora.org> <20161222003122.GY8288@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/23, Imran Khan wrote: > On 12/22/2016 6:01 AM, Stephen Boyd wrote: > > > > 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? > > > Okay smem DT entry can be used to provide ODM information but even after > having this feature, I am not sure if we can provide a code in the driver > that will act for all ODMs because we don't know how other ODMs will interpret > platform types and subtypes numbers. > Or do you mean here that we should keep string values corresponding to different > platform type and subtype numbers in the smem DT entry itself. We will use > socinfo from smem to get the raw number and then translate that raw number to > a string, using the mapping given in DT itself. > I mean in DT smem { compatible = "qcom,smem"; qcom,odm = "odm_name"; } And then in the driver code we look for the qcom,odm property and make a sysfs attribute called odm or something that exposes the string "odm_name" to userspace. Then we have some userspace database of odm string and platform type/subtype numbers that we can use to figure out what those numbers mean. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project