From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752626AbcBJXEA (ORCPT ); Wed, 10 Feb 2016 18:04:00 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:42582 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750828AbcBJXD6 (ORCPT ); Wed, 10 Feb 2016 18:03:58 -0500 Date: Wed, 10 Feb 2016 15:03:50 -0800 From: Darren Hart To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: =?utf-8?B?TWljaGHFgiBLxJlwaWXFhA==?= , Matthew Garrett , Richard Purdie , Jacek Anaszewski , Alex Hung , platform-driver-x86@vger.kernel.org, linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 01/14] dell-laptop: extract SMBIOS-related code to a separate module Message-ID: <20160210230350.GA11461@dvhart-mobl5.amr.corp.intel.com> References: <1452607380-20861-1-git-send-email-kernel@kempniu.pl> <20160209083303.GN30075@pali> <20160209165106.GB1309@dvhart-mobl5.amr.corp.intel.com> <201602092012.07392@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201602092012.07392@pali> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 09, 2016 at 08:12:07PM +0100, Pali Rohár wrote: > On Tuesday 09 February 2016 17:51:06 Darren Hart wrote: > > On Tue, Feb 09, 2016 at 09:33:03AM +0100, Pali Rohár wrote: > > > On Monday 08 February 2016 13:42:10 Darren Hart wrote: > > > > Assuming the above is an accurate view, I don't see any reason to > > > > go beyond the minimal change to the existing SMBIOS code to make > > > > it a usable API. If the need arises, we can always make such > > > > optimizations and performance improvements later. This is an > > > > internal API and we can change it whenever we need to so long as > > > > we update the call sites. > > > > > > Problem is that now smbios code from dell-laptop.c is moved into > > > dell-smbios.c and dell-smbios.h and LED subsystem starts using > > > dell-smbios.h. In this case I'm thinking that we have something > > > like API usable by other modules/subsystem. And I'm thinking if it > > > is not better to create "correct" API now instead rewriting code > > > in LED and platform subsystem again later... As this API needs to > > > provide just 1 function, send command to Dell SMBIOS I think that > > > API is still minimal. Currently we have another two functions > > > alloc/free buffer (needed for send). > > > > The internal kernel API changes all the time, we are not bound to it > > beyond ensuring we update the internal users when we change it. I > > prefer not to introduce complexity until we have to. > > > > buffer = dell_smbios_get_buffer(); > > buffer->input[0] = token->location; > > buffer->input[1] = token->value; > > dell_smbios_send_request(1, 0); > > dell_smbios_release_buffer(); > > > > The get_buffer and release_buffer also include the locking which is > > necessary for a shared buffer. If you eliminate the shared buffer, > > then you have to have a local buffer, which adds back code to create > > the buffer, initializize it, free it if it's dynamic, etc. > > > > So from that sense, Michał's API seems at least as concise as the > > alternative, and it introduces less change. > > Ok. Then let's stay with it. I have not tested patches yet, but do not > see anything wrong. So go ahead you can add my Reviewed-by. Great. Thank you Pali. This has been queued to testing. Thank you all for your diligence in getting this series to this point. -- Darren Hart Intel Open Source Technology Center