[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2ae082c4-27c1-fbdd-cb7a-986716e15d18@codeaurora.org>
Date: Wed, 26 Oct 2016 19:42:08 +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 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.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation
Powered by blists - more mailing lists