From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756386AbcBHVbb (ORCPT ); Mon, 8 Feb 2016 16:31:31 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:57077 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753606AbcBHVb2 (ORCPT ); Mon, 8 Feb 2016 16:31:28 -0500 Date: Mon, 8 Feb 2016 13:31:22 -0800 From: Darren Hart To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Greg Kroah-Hartman , =?utf-8?B?TWljaGHFgiBLxJlwaWXFhA==?= , Matthew Garrett , Richard Purdie , Jacek Anaszewski , platform-driver-x86@vger.kernel.org, linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 00/16] Common Dell SMBIOS API Message-ID: <20160208213122.GS1779@malice.jf.intel.com> References: <1453472848-3118-1-git-send-email-kernel@kempniu.pl> <20160208192920.GA10110@kroah.com> <20160208204646.GQ1779@malice.jf.intel.com> <201602082204.32958@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201602082204.32958@pali> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 08, 2016 at 10:04:32PM +0100, Pali Rohár wrote: > On Monday 08 February 2016 21:46:46 Darren Hart wrote: > > Pali, are you happy enough with this to add your reviewed-by? > > There was dicussion about dell-smbios API which you probably missed in > tons of other emails. It has subject: > > "[PATCH 01/14] dell-laptop: extract SMBIOS-related code to a separate module" > > And you can find it in archive at: > http://www.spinics.net/lists/linux-leds/msg05379.html > > I wanted to hear your opinion about this API and I'm not 100% fine with > it but on other side it is not easy to design better... Maybe you could > have better idea. I will review the above. However, a new API can be treated as separate from the refactoring which is all this series really does. It doesn't do anything that I saw beyond moving existing code into a separate module and wrapping the use of the buffer and tokens. In that sense, it seems to me that this can be considered a first step toward a redesigned API by first removing duplicate code and reusing some of the existing code. -- Darren Hart Intel Open Source Technology Center