linux-kernel - Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo 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]

Date:   Mon, 1 May 2017 18:37:19 +0530
From:   Imran Khan <kimran@...eaurora.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh@...nel.org>
Cc:     Stephen Boyd <sboyd@...eaurora.org>,
        Andy Gross <agross@...eaurora.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:ARM/QUALCOMM SUPPORT" <linux-soc@...r.kernel.org>
Subject: Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM
 socinfo driver

On 4/26/2017 4:38 AM, Bjorn Andersson wrote:
> On Tue 25 Apr 10:13 PDT 2017, Rob Herring wrote:
> 
>> On Mon, Apr 24, 2017 at 6:05 PM, Bjorn Andersson
>> <bjorn.andersson@...aro.org> wrote:
>>> On Mon 24 Apr 09:27 PDT 2017, Rob Herring wrote:
> [..]
>>>> Splitting things between common and private seems like a good direction.
>>>>
>>>
>>> But the pattern of amending the common attributes with vendor or
>>> platform-specific ones is how its done in other drivers, e.g.
>>> integrator.
>>>
>>> Why should we for the Qualcomm case make up some other pattern?
>>>
>>> Or am I misunderstanding your suggestion?
>>
>> I'm just trying to ensure that we make things that could be common,
>> common. The question here was about the implementation.
>>
>> Right now, drivers/soc is just a free for all dumping ground IMO.
>>
> 
> Unfortunately I fully agree with this, we did spend several revisions on
> just trying to match Qualcomm properties to the common attributes - and
> I don't know if we got it right.
> 

I would be glad to get further feedback in this regard as we would like it to be 
as close to the generic attributes as possible. But it is also true that 
right now generic soc_device_attributes are too few to expose the information that we are
intending to expose here.

[...]

>>>
>>> So, when Android goes belly up and we want to produce a bugreport that
>>> describes all the pieces of the system we will have to all over sysfs to
>>> figure out the versions of the firmware...
>>
>> Can't you just use the meta build id? That implies the version of
>> *everything*, right?
>>
> 
> For products yes, but when _you_ ask us why WiFi doesn't work on your
> Dragonboard it's quite nice to be able to get hold of the boot-loader
> and wcnss-firmware versions - and you're likely not on an unmodified
> meta-build.
> 
> For me this information is more valuable than the meta-build id, but
> that's because I'm working with engineering builds.
> 
> [..]
>>>>>>>>> +What:             /sys/devices/soc0/build_id
>>>>>>>>> +Date:             January 2017
>>>>>>>>> +Contact:  linux-arm-msm@...r.kernel.org
>>>>>>>>> +Description:
>>>>>>>>> +          This file shows the unique id of current build being used on
>>>>>>>>> +          the system.
>>>>>>>>
>>>>>>>> Build of what? The kernel already has a build version.
>>>>>>>>
>>>>>>> This is not build id of the kernel. This is build ID of complete meta image.
>>>>
>>>> That's assuming everything is built together which generally isn't
>>>> true.
>>>
>>> Not necessarily compiled together, but packaged up in something that
>>> gets a "release number" - which I presume is quite common for any type
>>> of embedded products.
>>>
>>> E.g. we do give the Linaro releases version numbers such as "16.09".
>>
>> Yes, but I doubt the release number is visible inside the release
>> unless it is part of some existing version like the kernel's version
>> string. If this is quite common, then lets make it common.
>>
> 
> I don't know how common this is - as you suggest below perhaps people
> just put it in one of the file systems?
> 
>> Why not just make this a file in the filesystem?
> 
> Because that forces you to rebuild your file system to update the
> version of the system. That said I don't know the details of how
> Qualcomm persistently encode this information.
> 
>> Why does the kernel need to provide it?
>>
> 
> Imran, can you elaborate on how this information is travels from the
> build system to the SMEM item?
> 

This information, along with other SMEM items for this SMEM-id is written by the bootloader (SBL).
Please let me know if this much information suffices in this regard.

Thanks and Regards,
Imran
> Regards,
> Bjorn
> 


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