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] [day] [month] [year] [list]
Message-ID: <dad1f0c2-eaec-28a0-47d3-eadc27b1c100@codeaurora.org>
Date:   Thu, 29 Dec 2016 11:16:50 +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/29/2016 4:05 AM, Stephen Boyd wrote:
> 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.
> 
Okay. This approach is fine for me. In the mean time I had tried
one alternative approach which I wanted to share. So in the smem DT 
entry we have something like:

 smem {
                compatible = "qcom,smem";
                ..............................
                ..............................
                smem,plat-type = "Unknown", "Surf", "FFA", "Fluid",
                                "SVLTE_FFA", "SVLTE_SURF", "Unknown",
                                "MDM_MTP_NO_DISPLAY", "MTP", "Liquid",
                                "Dragon", "QRD", "Unknown","HRD", "DTV";
                smem,qrd-plat-subtype = "QRD", "SKUAA", "SKUF", "SKUAB",
                                        "SKUG";
                smem,plat-subtype = "Unknown", "charm", "strange",
                                        "strange_2a";
        };

And back in the qcom_soc_init, we read these lists as per the value(index) obtained
from smem:

     if(socinfo->v0_1.format >= 6) {
                /* Get platform type and subtype here */
                type = socinfo->v0_6.hw_platform_subtype;
                if(type >= 0 && plat_type) {
                        if (socinfo->v0_3.hw_platform == HW_PLATFORM_QRD) {
                                type_max = of_property_count_strings(
                                                device->of_node,
                                                "smem,qrd-plat-subtype");
                                if(type < type_max) {
                                        of_property_read_string_index(
                                                device->of_node,
                                                "smem,qrd-plat-subtype",
                                                type, &plat_type->sub_type);
                                }
                        } else {
                                type_max = of_property_count_strings(
                                                device->of_node,
                                                "smem,plat-subtype");
                                if(type < type_max) {
                                        of_property_read_string_index(
                                                device->of_node,
                                                "smem,plat-subtype",
                                                type, &plat_type->sub_type);
                                }
                        }
                }
        }

        if (socinfo->v0_1.format >= 3) {
                /* Get only platform type */
                type = socinfo->v0_3.hw_platform;
                type_max = of_property_count_strings(
                                device->of_node, "smem,plat-type");
                if((type >= 0 && type < type_max) && plat_type) {
                        of_property_read_string_index(device->of_node,
                                                        "smem,plat-type", type,
                                                        &plat_type->type);
                }
        }


Could you please also provide your feedback about this approach? Just wanted to share
this before going ahead with final implementation.

Regards,
Imran


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