All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vernon Mauery <vernux@us.ibm.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Linux Documentation <linux-doc@vger.kernel.org>,
	Platform driver x86 <platform-driver-x86@vger.kernel.org>
Subject: Re: [Patch] IBM Real-Time "SMI Free" mode driver -v7
Date: Thu, 21 Oct 2010 07:38:21 -0700	[thread overview]
Message-ID: <20101021143821.GB8754@lucy> (raw)
In-Reply-To: <20101021142523.GA23171@srcf.ucam.org>

On 21-Oct-2010 03:25 PM, Matthew Garrett wrote:
>On Thu, Oct 21, 2010 at 07:23:19AM -0700, Vernon Mauery wrote:
>> On 21-Oct-2010 02:54 PM, Matthew Garrett wrote:
>>> Applied, thanks. It'd be nice if we didn't have to rely on DMI,
>>> especially since enterprise customers often end up running later kernels
>>
>> I am not sure what you mean here by problems with DMI running later
>> kernels.
>
>Oops, sorry! I mean running on older kernels.

Do older kernels not have DMI support?  I would think that if an 
enterprise distribution wanted this driver they would likely already 
have DMI support backported as well.

Or they can work with me to find a way that works in that kernel.  I was 
thinking that in the current (and future) kernel, DMI was the best way 
to go.

>>> - is there any other way to determine that this is safe to load? Could
>>
>> I can't think of anything off the top of my head that would allow us to
>> ensure that this is only loaded on IBM systems.  DMI is pretty good
>> about that.
>
>I'd suggest using DMI to verify that it's an IBM, and perhaps also using
>DMI to check that it's a server or blade rather than a laptop or
>desktop. After that you could just check the ebda rather than having to
>have an entry for every specific machine.

I went for a better safe than sorry route.  Before I added the DMI 
checking I had some reports of this getting loaded on non-IBM hardware 
and it came up with some nasty error messages.  I figured since I knew 
exactly which platforms have support, I could just limit the driver to 
those.  Then there is the force parameter that allows a user to ignore 
the DMI data and try to load the driver anyway.

--Vernon

  reply	other threads:[~2010-10-21 14:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-05 22:47 [Patch] IBM Real-Time "SMI Free" mode driver -v7 Vernon Mauery
2010-10-21 13:54 ` Matthew Garrett
2010-10-21 14:23   ` Vernon Mauery
2010-10-21 14:25     ` Matthew Garrett
2010-10-21 14:38       ` Vernon Mauery [this message]
2010-10-21 14:42         ` Matthew Garrett
2010-10-21 15:09           ` Vernon Mauery
2010-10-22 21:13             ` [Patch 1/2] ibm_rtl: DMI match should include all IBM machines Vernon Mauery
2010-10-22 21:17             ` [Patch 2/2] ibm_rtl: check for efi_enabled Vernon Mauery

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=20101021143821.GB8754@lucy \
    --to=vernux@us.ibm.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rdunlap@xenotime.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.