linux-kernel - Re: [PATCH] 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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 26 Oct 2016 19:20:42 +0530
From:   Imran Khan <kimran@...eaurora.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     andy.gross@...aro.org, David Brown <david.brown@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "open list:ARM/QUALCOMM SUPPORT" <linux-arm-msm@...r.kernel.org>,
        "open list:ARM/QUALCOMM SUPPORT" <linux-soc@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] soc: qcom: Add SoC info driver

On 10/26/2016 2:19 AM, Arnd Bergmann wrote:
> On Tuesday, October 25, 2016 3:23:34 PM CEST Imran Khan wrote:
>> On 10/21/2016 4:03 PM, Arnd Bergmann wrote:
>>>> +/* socinfo: sysfs functions */
>>>
>>> This seems overly verbose, having both raw and human-readable
>>> IDs is generally not necessary, pick one of the two. If you
>>> need any fields that we don't already support in soc_device,
>>> let's talk about adding them to the generic structure.
>>>
>>>
>>
>> Okay. I will go for human readable IDs. Can we add 2 more fields
>> in the generic structure.
>> These 2 fields would be:
>>
>> vendor: A string for vendor name
>> serial_number: A string containing serial number for the platform
> 
> 
> serial_number seems straightforward, adding this seems like a good
> idea. I don't understand yet what would go into the vendor field
> though. For this particular driver, is it always "Qualcomm", or
> would it be a third-party that makes a device based on that chip?
> 

As we are talking about generic soc_device_attribute fields, I was hoping that
having a vendor field would be helpful as along with family it would provide
a more thorough information. Also as more than one foundries may be used for 
a soc, can we have a field say foundry_id to provide this information.
  
> 	Arnd
> 


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