From: Darren Hart <dvhart@infradead.org>
To: "Michał Kępień" <kernel@kempniu.pl>
Cc: "Pali Rohár" <pali.rohar@gmail.com>,
"Matthew Garrett" <mjg59@srcf.ucam.org>,
"Richard Purdie" <rpurdie@rpsys.net>,
"Jacek Anaszewski" <j.anaszewski@samsung.com>,
"Alex Hung" <alex.hung@canonical.com>,
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
Date: Mon, 8 Feb 2016 13:42:10 -0800 [thread overview]
Message-ID: <20160208214210.GT1779@malice.jf.intel.com> (raw)
In-Reply-To: <20160121133921.GA4626@eudyptula.hq.kempniu.pl>
On Thu, Jan 21, 2016 at 02:39:21PM +0100, Michał Kępień wrote:
> > Another idea:
> >
> > What about passing struct calling_interface_buffer from caller allocated
> > memory (either from stack or kernel alloc) to dell-smbios which will
> > copy it into own buffer under 4GB and then pass it to dcdbas?
> >
> > This will avoid to use that get/release function and there will be only
> > one send_request.
>
> Well, yes, these two functions could then be ripped out, but the callers
> would have to do the error checking on their own. Of course that's not
> a bad thing per se, but it changes the currently used concept.
>
> > But I will let decision for API to other people as I do not know what
> > the best API to use here...
>
> In order to avoid delaying this any further, I'll post a v2 soon and
> hopefully it'll be good enough for your Acked-by. If it turns out more
> people have misgivings about it, I'll adjust the code.
>
It seems to me the question is primarily over whether or not the interface
protects a shared resource (a common buffer) or if that buffer should be
independent for every caller.
I favor minimal and incremental change and avoiding complexity where it is not
needed. I don't believe there is anything performance critical in any of these
paths, e.g. nothing requires a better response time than about 100ms and nothing
is likely to occur at a frequency above 10Hz or so.
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.
Does anyone have a compelling reason to look for changes to the v2 submitted by
Michał?
--
Darren Hart
Intel Open Source Technology Center
next prev parent reply other threads:[~2016-02-08 21:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-12 14:02 [PATCH 00/14] Common Dell SMBIOS API Michał Kępień
2016-01-12 14:02 ` [PATCH 01/14] dell-laptop: extract SMBIOS-related code to a separate module Michał Kępień
2016-01-16 15:19 ` Pali Rohár
2016-01-18 10:34 ` Michał Kępień
2016-01-20 9:21 ` Michał Kępień
2016-01-21 8:35 ` Pali Rohár
2016-01-21 13:06 ` Michał Kępień
2016-01-21 13:14 ` Pali Rohár
2016-01-21 13:39 ` Michał Kępień
2016-02-08 21:42 ` Darren Hart [this message]
2016-02-09 8:33 ` Pali Rohár
2016-02-09 13:58 ` Michał Kępień
2016-02-09 16:51 ` Darren Hart
2016-02-09 19:12 ` Pali Rohár
2016-02-10 23:03 ` Darren Hart
2016-01-12 14:02 ` [PATCH 02/14] dell-smbios: don't pass a buffer to dell_send_request() Michał Kępień
2016-01-12 14:02 ` [PATCH 03/14] dell-smbios: rename buffer to dell_smbios_buffer Michał Kępień
2016-01-12 14:02 ` [PATCH 04/14] dell-smbios: rename clear_buffer() to dell_smbios_clear_buffer() Michał Kępień
2016-01-12 14:02 ` [PATCH 05/14] dell-smbios: rename get_buffer() to dell_smbios_get_buffer() Michał Kępień
2016-01-12 14:02 ` [PATCH 06/14] dell-smbios: rename release_buffer() to dell_smbios_release_buffer() Michał Kępień
2016-01-12 14:02 ` [PATCH 07/14] dell-smbios: rename dell_send_request() to dell_smbios_send_request() Michał Kępień
2016-01-12 14:02 ` [PATCH 08/14] dell-smbios: implement new function for finding DMI table 0xDA tokens Michał Kępień
2016-01-12 14:02 ` [PATCH 09/14] dell-laptop: use dell_smbios_find_token() instead of find_token_id() Michał Kępień
2016-01-12 14:02 ` [PATCH 10/14] dell-laptop: use dell_smbios_find_token() instead of find_token_location() Michał Kępień
2016-01-12 14:02 ` [PATCH 11/14] dell-smbios: remove find_token_{id,location}() Michał Kępień
2016-01-12 14:02 ` [PATCH 12/14] dell-smbios: make da_tokens static Michał Kępień
2016-01-12 14:02 ` [PATCH 13/14] dell-led: use dell_smbios_find_token() for finding mic DMI tokens Michał Kępień
2016-01-21 10:52 ` Jacek Anaszewski
2016-01-21 15:00 ` Michał Kępień
2016-01-21 15:42 ` Jacek Anaszewski
2016-01-12 14:03 ` [PATCH 14/14] dell-led: use dell_smbios_send_request() for SMBIOS requests Michał Kępień
2016-01-14 22:43 ` [PATCH 00/14] Common Dell SMBIOS API Darren Hart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160208214210.GT1779@malice.jf.intel.com \
--to=dvhart@infradead.org \
--cc=alex.hung@canonical.com \
--cc=j.anaszewski@samsung.com \
--cc=kernel@kempniu.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=pali.rohar@gmail.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rpurdie@rpsys.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.