From: Dave Jones <davej@redhat.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andi Kleen <andi@firstfloor.org>,
linux-kernel@vger.kernel.org, trenn@suse.de, kay.sievers@vrf.org,
Andi Kleen <ak@linux.intel.com>,
kay.sievers@vrfy.org, axboe@kernel.dk,
herbert@gondor.hengli.com.au, ying.huang@intel.com
Subject: Re: [PATCH 03/10] crypto: Add support for x86 cpuid auto loading for x86 crypto drivers
Date: Mon, 19 Dec 2011 18:32:47 -0500 [thread overview]
Message-ID: <20111219233247.GC570@redhat.com> (raw)
In-Reply-To: <4EEFC7D2.70803@zytor.com>
On Mon, Dec 19, 2011 at 03:25:06PM -0800, H. Peter Anvin wrote:
> > > - if (!cpu_has_phe) {
> > > - printk(KERN_NOTICE PFX "VIA PadLock Hash Engine not detected.\n");
> > > - return -ENODEV;
> > > - }
> > > -
> > > - if (!cpu_has_phe_enabled) {
> > > - printk(KERN_NOTICE PFX "VIA PadLock detected, but not enabled. Hmm, strange...\n");
> > > + if (!x86_match_cpu(padlock_sha_ids) || !cpu_has_phe_enabled)
> > > return -ENODEV;
> > > - }
> >
> > don't we want to keep the printk ?
> >
> > Seems that if it's been disabled by the BIOS for some reason, it will now
> > silently fail instead of printing a nice warning.
>
> The first printk is insanely annoying, because the end result is that we
> get a printk of all the crypto engines that are *not* enabled...
> arguably it would be somewhat nice to get a printk when a crypto engine
> *is* enabled.
Sorry, I just meant the second printk, which should hopefully not get
printed by default.
Dave
next prev parent reply other threads:[~2011-12-19 23:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-19 22:47 Updated cpuid-match patchkit v2 Andi Kleen
2011-12-19 22:47 ` [PATCH 02/10] Add driver auto probing for x86 features Andi Kleen
2011-12-19 22:47 ` [PATCH 02/10] Add driver auto probing for x86 features v2 Andi Kleen
2011-12-19 22:47 ` [PATCH 03/10] crypto: Add support for x86 cpuid auto loading for x86 crypto drivers Andi Kleen
2011-12-19 23:22 ` Dave Jones
2011-12-19 23:25 ` H. Peter Anvin
2011-12-19 23:32 ` Dave Jones [this message]
2011-12-20 4:08 ` Andi Kleen
2011-12-20 4:54 ` H. Peter Anvin
2011-12-20 5:30 ` Herbert Xu
2011-12-20 5:35 ` H. Peter Anvin
2011-12-20 5:38 ` Herbert Xu
2011-12-20 6:48 ` H. Peter Anvin
2011-12-19 22:47 ` [PATCH 04/10] intel-idle: convert to x86_cpu_id auto probing Andi Kleen
2011-12-19 22:47 ` [PATCH 05/10] ACPI: Load acpi-cpufreq from processor driver automatically Andi Kleen
2011-12-19 22:47 ` [PATCH 06/10] HWMON: Convert via-cputemp to x86 cpuid autoprobing Andi Kleen
2011-12-19 22:47 ` [PATCH 07/10] HWMON: Convert coretemp " Andi Kleen
2011-12-19 22:47 ` [PATCH 08/10] cpufreq: Add support for x86 cpuinfo auto loading Andi Kleen
2011-12-19 23:03 ` Dave Jones
2011-12-19 23:12 ` Andi Kleen
2011-12-19 23:16 ` H. Peter Anvin
2011-12-19 22:47 ` [PATCH 09/10] x86: autoload microcode driver on Intel and AMD systems Andi Kleen
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=20111219233247.GC570@redhat.com \
--to=davej@redhat.com \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=axboe@kernel.dk \
--cc=herbert@gondor.hengli.com.au \
--cc=hpa@zytor.com \
--cc=kay.sievers@vrf.org \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=trenn@suse.de \
--cc=ying.huang@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).