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: <e4e9a825-fb73-242a-7c66-f8bb4783cfcd@codeaurora.org>
Date:   Fri, 23 Dec 2016 02:53:47 +0530
From:   Imran Khan <kimran@...eaurora.org>
To:     Stephen Boyd <sboyd@...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/22/2016 6:01 AM, Stephen Boyd wrote:
> 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?
> 
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.

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation