Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933331AbcKIOof (ORCPT ); Wed, 9 Nov 2016 09:44:35 -0500 Received: from mail-it0-f46.google.com ([209.85.214.46]:36025 "EHLO mail-it0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933035AbcKIOob (ORCPT ); Wed, 9 Nov 2016 09:44:31 -0500 MIME-Version: 1.0 In-Reply-To: <20161102162811.GN25787@tuxbot> References: <1476972386-28655-1-git-send-email-kimran@codeaurora.org> <3567809.JctLPjIDdk@wuerfel> <3809309.oOnjdjqnN9@wuerfel> <20161102162811.GN25787@tuxbot> From: Geert Uytterhoeven Date: Wed, 9 Nov 2016 15:44:29 +0100 X-Google-Sender-Auth: JNPAWS39VjnUx8MJAPZKGQXwl8k Message-ID: Subject: Re: [PATCH] soc: qcom: Add SoC info driver To: Bjorn Andersson Cc: Arnd Bergmann , Imran Khan , Andy Gross , 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 , Geert Uytterhoeven Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2422 Lines: 55 Hi Bjorn, On Wed, Nov 2, 2016 at 5:28 PM, Bjorn Andersson wrote: > On Wed 26 Oct 07:05 PDT 2016, Arnd Bergmann wrote: >> On Wednesday, October 26, 2016 7:20:42 PM CEST Imran Khan wrote: >> > 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: >> > >> 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. >> >> My first feeling is that this 'vendor' information can should be >> derived from the family. > > In [1] Geert just put the vendor directly into "family", while Imran > uses "Snapdragon" (which I find reasonable in the Qualcomm case). But it > seems like Geert would like a "vendor" as well, rather than a "family". > > And if "family" really is supposed to contain the "SoC family name" and > we're trying to provide user space with some useful information (for > some reason), should we just rely on the unlikeliness of two vendors > using the same family name? > > [1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1261742.html I think vendor is slightly less volatile than family. Family may change overnight if marketing had a good dream. Well, vendor may change, too... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds