linux-kernel - Re: [PATCH v6] soc: qcom: Add SoC info driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161228223509.GA17126@codeaurora.org>
Date:   Wed, 28 Dec 2016 14:35:09 -0800
From:   Stephen Boyd <sboyd@...eaurora.org>
To:     Imran Khan <kimran@...eaurora.org>
Cc:     andy.gross@...aro.org, lee.jones@...aro.org,
        David Brown <david.brown@...aro.org>,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-soc@...r.kernel.org
Subject: Re: [PATCH v6] soc: qcom: Add SoC info driver

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