From: Greg KH <greg@kroah.com>
To: Mike Waychison <mikew@google.com>
Cc: Matt Domsch <Matt_Domsch@dell.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Duncan Laurie <dlaurie@google.com>,
Aaron Durbin <adurbin@google.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Tim Hockin <thockin@google.com>, San Mehat <san@google.com>
Subject: Re: [PATCH v2 11/12] driver: Google EFI SMI
Date: Mon, 14 Mar 2011 13:13:46 -0700 [thread overview]
Message-ID: <20110314201346.GA1084@kroah.com> (raw)
In-Reply-To: <AANLkTikhhYv2=memo-Rkhh1pG3v4-edrUROTgLoc6cbd@mail.gmail.com>
On Mon, Mar 14, 2011 at 01:01:50PM -0700, Mike Waychison wrote:
> On Mon, Mar 14, 2011 at 8:47 AM, Greg KH <greg@kroah.com> wrote:
> > On Fri, Mar 11, 2011 at 05:43:53PM -0800, Mike Waychison wrote:
> >> The "gsmi" driver bridges userland with firmware specific routines for
> >> accessing hardware.
> >
> > As with the other driver in this series, what keeps this driver from
> > being loaded on hardware that does not support this functionality? If
> > it is loaded, will it cause bad things to happen?
>
> gsmi itself is better guarded than the memconsole driver that the x86
> maintainers objected to.
>
> It relies on keying off of a couple different strings, looking for
> "GOOGLE" as either the OEM ID in the FADT table, or "Google, Inc." as
> the board vendor. We further discriminate whether the driver should
> load (it doesn't apply to all of our boards) with a couple other
> checks. See gsmi_system_valid(). I've added a comment to the patch
> description indicating this for the upcoming v3 send-out.
Ok, fair enough. I'm guessing that you have tried testing the module by
loading it in a machine where this doesn't work?
> > Also, what causes it to be loaded on hardware that needs it? There
> > should be some MODULE_DEVICE_TABLE somewhere in this thing to cause it
> > to be autoloaded?
>
> I don't know if there is a good way to have this guy autoloaded, but
> that's probably fine. We will likely compile it in as a built-in or
> adjust our userland to have the module loaded. We use it on all
> machines we've been building for the last 4-5 years, and a table of
> device IDs would just contain a list of a bunch of parts that aren't
> really google-specific.
What's wrong with using DMI strings? Are there going to be that many
different ones of them here?
thanks,
greg k-h
next prev parent reply other threads:[~2011-03-14 20:54 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-12 1:42 [PATCH v2 00/12] google firmware support Mike Waychison
2011-03-12 1:43 ` [PATCH v2 01/12] efivars: move efivars globals into struct efivars Mike Waychison
2011-03-12 1:43 ` [PATCH v2 02/12] efivars: Make efivars bin_attributes dynamic Mike Waychison
2011-03-12 1:43 ` [PATCH v2 03/12] efivars: parameterize efivars Mike Waychison
2011-03-12 1:43 ` [PATCH v2 04/12] efivars: Split out variable registration Mike Waychison
2011-03-12 1:43 ` [PATCH v2 05/12] efivars: Parameterize operations Mike Waychison
2011-03-12 1:43 ` [PATCH v2 06/12] efivars: Expose efivars functionality to external drivers Mike Waychison
2011-03-12 1:43 ` [PATCH v2 07/12] efivars: Add Documentation Mike Waychison
2011-03-12 1:43 ` [PATCH v2 08/12] x86: get_bios_ebda_length() Mike Waychison
2011-03-14 15:43 ` Greg KH
2011-03-12 1:43 ` [PATCH v2 09/12] x86: Better comments for get_bios_ebda() Mike Waychison
2011-03-14 15:43 ` Greg KH
2011-03-12 1:43 ` [PATCH v2 10/12] Introduce CONFIG_GOOGLE_FIRMWARE Mike Waychison
2011-03-14 15:45 ` Greg KH
2011-03-14 19:49 ` Mike Waychison
2011-03-14 19:59 ` Greg KH
2011-03-14 20:06 ` Mike Waychison
2011-03-12 1:43 ` [PATCH v2 11/12] driver: Google EFI SMI Mike Waychison
2011-03-14 15:47 ` Greg KH
2011-03-14 20:01 ` Mike Waychison
2011-03-14 20:13 ` Greg KH [this message]
2011-03-14 21:09 ` Mike Waychison
2011-03-14 23:05 ` Alan Cox
2011-03-12 1:43 ` [PATCH v2 12/12] driver: Google Memory Console Mike Waychison
2011-03-14 4:54 ` H. Peter Anvin
2011-03-14 4:58 ` Tim Hockin
2011-03-14 5:02 ` H. Peter Anvin
2011-03-14 9:22 ` Ingo Molnar
2011-03-14 14:01 ` Tim Hockin
2011-03-14 14:23 ` Ingo Molnar
2011-03-14 15:47 ` Greg KH
2011-03-14 20:03 ` Mike Waychison
2011-03-14 22:46 ` H. Peter Anvin
2011-03-12 3:54 ` [PATCH v2 00/12] google firmware support Matt Domsch
2011-03-14 15:42 ` Greg KH
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=20110314201346.GA1084@kroah.com \
--to=greg@kroah.com \
--cc=Matt_Domsch@dell.com \
--cc=adurbin@google.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dlaurie@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikew@google.com \
--cc=san@google.com \
--cc=thockin@google.com \
--cc=x86@kernel.org \
/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.