From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1433476AbdDYXIw (ORCPT ); Tue, 25 Apr 2017 19:08:52 -0400 Received: from mail-pg0-f48.google.com ([74.125.83.48]:33772 "EHLO mail-pg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1763594AbdDYXIm (ORCPT ); Tue, 25 Apr 2017 19:08:42 -0400 Date: Tue, 25 Apr 2017 16:08:37 -0700 From: Bjorn Andersson To: Rob Herring Cc: Imran Khan , Stephen Boyd , Andy Gross , linux-arm-msm , "linux-kernel@vger.kernel.org" , "open list:ARM/QUALCOMM SUPPORT" Subject: Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver Message-ID: <20170425230837.GO15143@minitux> References: <1487609235-19458-3-git-send-email-kimran@codeaurora.org> <20170222140448.qo677wamcd44tgkw@rob-hp-laptop> <0bf24858-33b2-8d08-ddc3-df83a2bd696d@codeaurora.org> <4b85e85b-8c2a-a226-d3b2-67fde0820ada@codeaurora.org> <0d59bc31-7d35-06c8-68d1-13790a512c23@codeaurora.org> <20170424230530.GN15143@minitux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 25 Apr 10:13 PDT 2017, Rob Herring wrote: > On Mon, Apr 24, 2017 at 6:05 PM, Bjorn Andersson > 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. > >> >>>>> diff --git a/Documentation/ABI/testing/sysfs-driver-qcom_socinfo b/Documentation/ABI/testing/sysfs-driver-qcom_socinfo > >> >>>>> new file mode 100644 > >> >>>>> index 0000000..cce611f > >> >>>>> --- /dev/null > >> >>>>> +++ b/Documentation/ABI/testing/sysfs-driver-qcom_socinfo > >> >>>>> @@ -0,0 +1,171 @@ > >> >>>>> +What: /sys/devices/soc0/accessory_chip > >> >>>>> +Date: January 2017 > >> >>>>> +Contact: linux-arm-msm@vger.kernel.org > >> >>>>> +Description: > >> >>>>> + This file shows the id of the accessory chip. > >> >>>>> + > >> >>>>> +What: /sys/devices/soc0/adsp_image_crm > >> >>>>> +What: /sys/devices/soc0/adsp_image_variant > >> >>>>> +What: /sys/devices/soc0/adsp_image_version > >> >>>>> +Date: January 2017 > >> >>>>> +Contact: linux-arm-msm@vger.kernel.org > >> >>>>> +Description: > >> >>>>> + These files respectively show the crm version, variant and > >> >>>>> + version of the ADSP image. > >> >>>> > >> >>>> Shouldn't this be part of the ADSP driver? > >> >>>> > >> >>> Yes, It can be but I wanted to keep the image information at a central location, > >> >>> rather than pushing it back to each driver. For image information we basically > >> >>> read the same item from SMEM but use different offsets within it for different images, > >> >>> so the idea was to read this information ( get SMEM handler) just once, rather than > >> >>> doing it for each driver. > >> >>> But if this idea does not look correct, I can remove it from socinfo driver. > >> >>> > >> >> > >> >> Could you please provide some feedback regarding this? > >> > >> I don't think parsing things once will save you much. > >> > > > > Defining the struct in some shared header file and implementing the > > "parsing" throughout various drivers would probably work out fine. > > > > What I do not fancy is where these "parsers" would be implemented and > > where the information would end up in sysfs. > > > > "The ADSP driver" has to refer to the remoteproc driver for the adsp and > > it would be reasonable to have version information of the firmware > > available for a running piece of remoteproc. The same would work out for > > modem and wireless. > > > > The v4l driver is responsible for controlling the venus core, so it > > could provide the version attribute - which would show up somewhere in > > the /sys/bus/platform hierarchy. > > > > We have a mfd-like driver for communicating with the RPM, so perhaps we > > could shoehorn in an attribute there. But the sysfs path will be > > completely different, depending on platform and system configuration. > > > > There is no driver representing the boot code. > > > > > > 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@vger.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? Regards, Bjorn