Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753488AbcKBHt5 (ORCPT ); Wed, 2 Nov 2016 03:49:57 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:44112 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751541AbcKBHty (ORCPT ); Wed, 2 Nov 2016 03:49:54 -0400 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org 683C4602A8 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=kimran@codeaurora.org Subject: Re: [PATCH] soc: qcom: Add SoC info driver To: Arnd Bergmann References: <1476972386-28655-1-git-send-email-kimran@codeaurora.org> <4173870.AkctyO62lp@wuerfel> <9172138.R1PTFlLtP9@wuerfel> Cc: andy.gross@linaro.org, David Brown , Rob Herring , Mark Rutland , "open list:ARM/QUALCOMM SUPPORT" , "open list:ARM/QUALCOMM SUPPORT" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list From: Imran Khan Message-ID: Date: Wed, 2 Nov 2016 13:19:47 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9172138.R1PTFlLtP9@wuerfel> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2945 Lines: 67 On 10/27/2016 7:11 PM, Arnd Bergmann wrote: > On Thursday, October 27, 2016 6:40:27 PM CEST Imran Khan wrote: >> On 10/26/2016 8:16 PM, Arnd Bergmann wrote: >>> On Wednesday, October 26, 2016 7:42:08 PM CEST Imran Khan wrote: >>>> On 10/26/2016 7:35 PM, Arnd Bergmann wrote: >>>>>>> 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. >>>>> My first feeling is that this 'vendor' information can should be >>>>> derived from the family. It's also not clear what would happen >>>>> to this when a company gets bought. E.g. the Oxnas product family >>>>> was subsequently owned by Oxford, PLX, Avago and Broadcom, and the >>>>> mxs family was Sigmatel, Freescale, now NXP and might soon be >>>>> Qualcomm. What would you put in there in this case? >>>> >>>> Okay, not having vendor field is fine for me. Could you also suggest >>>> something about the foundry_id field. >>> >>> This one seems more well-defined, so it's probably ok to add. What >>> would be the use case of reading this? Would you want to read it >>> just from user space or also from the kernel? >>> >> >> As of now the use case I can think of, only involve reading this from user >> space. For example for the same soc, coming from different foundries with >> different manufacturing process, we may have a situation where some inconsistent >> h/w behavior is being observed only on parts received from a certain foundry >> and in those cases this information may help in segregation of problematic socs >> and may also be used in testing these socs under a different set of settings like >> voltage, frequency etc. >> >>> Maybe this can be combined with a manufacturing process, which probably >>> falls into a similar category, so we could have something like >>> "TSMC 28ULP" as a string in there. >>> >> >> Yes. Having a manufacturing process as part of foundry-id can provide a more >> thorough information. > > Ok, sounds good. Let's do it like this. We can always add support for > in-kernel matching of this string if needed later. > Thanks for the feedback. So how should I proceed now, should I i. send one patch first that adds the serial_number and foundry_id fields in generic soc_dev_attribute structure and then send my modified socinfo driver as per new soc_dev_attribute structure or ii. send both the changes as 2 separate patches of the same patch set. or iii. Continue with the current soc_dev_attribute structure and modify the socinfo driver once soc_dev_attribute structure has serial_number and foundry_id fields. > Arnd > -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation