From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Romer, Benjamin M" <Benjamin.Romer@unisys.com>
Cc: *S-Par-Maintainer <SParMaintainer@unisys.com>,
"jkc@redhat.com" <jkc@redhat.com>,
"devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] unisys: staging: Check for s-Par firmware before initializing s-Par modules
Date: Wed, 9 Apr 2014 12:25:52 -0700 [thread overview]
Message-ID: <20140409192552.GA11506@kroah.com> (raw)
In-Reply-To: <C97001BC43954D438ACB059713BA5CDF92040F0F09@USEA-EXCH7.na.uis.unisys.com>
On Wed, Apr 09, 2014 at 02:04:50PM -0500, Romer, Benjamin M wrote:
> This patch adds a function, is_spar_system(), to check that s-Par
> firmware is present, and then uses this function at the beginning of
> each module to verify that the modules are being run on an s-Par system
> before beginning initialization. If the firmware is not detected, the
> module will return a failure code.
>
> Checking for s-Par firmware uses the cpuid instruction to verify that
> the processor is running with virtualization turned on, and then uses a
> second cpuid instruction to check that the hypervisor ID is
> "UnisysSpar64".
Why not use the cpuid infrastructure to automatically load/bind your
code and not rely on it being loaded "by hand"? Doesn't that work for
CPU types already?
> Additionally, some minor clean-up was done on copyright tags and
> unnecessary messages were removed from the visorchipset_main() function.
Patches need to do only one thing, so can you please split this up in to
multiple patches, each one only doing one thing.
> This patch was tested with KVM to ensure that the modules do not load
> when s-Par firmware is not present, and tested with s-Par 4.0.12 to
> verify that the modules load correctly when the firmware is present.
>
> Signed-off-by: Benjamin Romer <benjamin.romer@unisys.com>
You forgot to add a "Reported-by:" line here, and possibly a
"Tested-by:" if someone tested it and reported that it solved the
problem. Proper attribution is very important.
thanks,
greg k-h
next prev parent reply other threads:[~2014-04-09 19:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-09 19:04 [PATCH] unisys: staging: Check for s-Par firmware before initializing s-Par modules Romer, Benjamin M
2014-04-09 19:25 ` Greg Kroah-Hartman [this message]
2014-04-10 14:56 ` Romer, Benjamin M
2014-04-09 19:27 ` Greg Kroah-Hartman
2014-04-09 19:43 ` Dan Carpenter
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=20140409192552.GA11506@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Benjamin.Romer@unisys.com \
--cc=SParMaintainer@unisys.com \
--cc=devel@driverdev.osuosl.org \
--cc=jkc@redhat.com \
--cc=linux-kernel@vger.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.