From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751662AbdEUFbH (ORCPT ); Sun, 21 May 2017 01:31:07 -0400 Received: from mailout1.hostsharing.net ([83.223.95.204]:56865 "EHLO mailout1.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750999AbdEUFbF (ORCPT ); Sun, 21 May 2017 01:31:05 -0400 Date: Sun, 21 May 2017 07:31:14 +0200 From: Lukas Wunner To: Mika Westerberg Cc: Greg Kroah-Hartman , Andreas Noever , Michael Jamet , Yehezkel Bernat , Amir Levy , Andy Lutomirski , Mario.Limonciello@dell.com, Jared.Dominguez@dell.com, Andy Shevchenko , linux-kernel@vger.kernel.org Subject: Re: [PATCH 10/24] thunderbolt: Read vendor and device name from DROM Message-ID: <20170521053114.GA3003@wunner.de> References: <20170518143914.60902-1-mika.westerberg@linux.intel.com> <20170518143914.60902-11-mika.westerberg@linux.intel.com> <20170519100710.GA15926@wunner.de> <20170519102836.GE8541@lahna.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170519102836.GE8541@lahna.fi.intel.com> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 19, 2017 at 01:28:36PM +0300, Mika Westerberg wrote: > On Fri, May 19, 2017 at 12:07:10PM +0200, Lukas Wunner wrote: > > Apple uses 0x30 to store a > > serial number. Is this attribute number assigned by Intel to Apple > > or is it reserved for vendor use or did they arbitrarily choose it? > > It is part of the DROM specification. The 0x30 - 0x3e are vendor > specific entries. Ah, so I have to qualify the vendor number with Apple's ID before I know that it's a serial number. Thanks. > > If there can be many attributes, should they be stored in a list > > rather than adding a char* pointer for each one to struct tb_switch? > > The latter doesn't scale. > > I don't think we need other attributes (well, at least right now). The > device/vendor name is useful because that's what we expose to the > userspace for device identification along with the device/vendor ID. Okay. It might be worth to log additional attributes with info level. > > > +static void tb_drom_parse_generic_entry(struct tb_switch *sw, > > > + struct tb_drom_entry_generic *entry) > > > +{ > > > + if (entry->header.index == 1) > > > + sw->vendor_name = kstrdup((char *)entry->data, GFP_KERNEL); > > > + else if (entry->header.index == 2) > > > + sw->device_name = kstrdup((char *)entry->data, GFP_KERNEL); > > > +} > > > > This assumes that these are properly null-terminated strings, but the DROM > > may contain complete garbage. The existing drom parser is very careful > > to validate and sanitize everything. > > The DROM specification says they must be null-terminated but I yes, it > is possible that some of the devices have it wrong. The generic entry > includes length field so I suppose we can use that + kmemdup() instead > here? Yes, as long as you check that the last character is null. Thanks, Lukas