cleanup_tis() -> tpm_remove_hardware() -> syncrhonize_rcu() is being
called in an atomic context (tis_lock spinlock held), which is not
allowed. Convert tis_lock to mutex.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Tested-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Acked-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>

Correct spelling "telclk_interrup" to "telclk_interrupt" in
drivers/char/tlclk.c
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Correct spelling "allocat" to "allocate" in
drivers/char/viotape.c
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This commit updates some comments to reflect the fact that code
for periodically updating the CMOS RTC was moved to:

  kernel/time/ntp.c

probably by this commit:

  commit 82644459
  Author: Thomas Gleixner <tglx@linutronix.de>
  Date:   Sat Jul 21 04:37:37 2007 -0700

      NTP: move the cmos update code into ntp.c

      i386 and sparc64 have the identical code to update the cmos clock.  Move it
      into kernel/time/ntp.c as there are other architectures coming along with the
      same requirements.
Signed-off-by: NMichael Witten <mfwitten@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In error cleanup of agp_backend_initialize() and in agp_backend_cleanup(),
agp_destroy_page() is passed virtual address of the scratch page. This
leads to a kernel warning if the initialization fails (or upon regular
cleanup) as pointer to struct page should be passed instead.
Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch fixes an (ACPI S3) suspend regression introduced in commit
68d6e671 ("tpm: Introduce function to poll for result of self test")
and occurring with an Infineon TPM and tpm_tis and tpm_infineon drivers
active.

The suspend problem occurred if the TPM was disabled and/or deactivated
and therefore the TPM_PCRRead checking the result of the (asynchronous)
self test returned an error code which then caused the tpm_tis driver to
become inactive and this then seemed to have negatively influenced the
suspend support by the tpm_infineon driver...  Besides that the tpm_tis
drive may stay active even if the TPM is disabled and/or deactivated.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Tested-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When we are initializing using arch_get_random_long() we only need to
loop enough times to touch all the bytes in the buffer; using
poolwords for that does twice the number of operations necessary on a
64-bit machine, since in the random number generator code "word" means
32 bits.
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Link: http://lkml.kernel.org/r/1324589281-31931-1-git-send-email-tytso@mit.edu

If there is an architecture-specific random number generator (such as
RDRAND for Intel architectures), use it to initialize /dev/random's
entropy stores.  Even in the worst case, if RDRAND is something like
AES(NSA_KEY, counter++), it won't hurt, and it will definitely help
against any other adversaries.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Link: http://lkml.kernel.org/r/1324589281-31931-1-git-send-email-tytso@mit.eduSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

If a platform device exists on the system, but ramoops fails to attach to
it, the module parameters are overridden before ramoops can fall back and
try to use passed module parameters.  Move update to end of init routine.
Signed-off-by: NKees Cook <keescook@chromium.org>
Cc: Marco Stornelli <marco.stornelli@gmail.com>
Cc: Sergiu Iordache <sergiu@chromium.org>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The return value of rounddown_pow_of_two wasn't evaluated, so the
operation was a no-op.
Signed-off-by: NMarco Stornelli <marco.stornelli@gmail.com>
Reported-by: NAndrew Morton <akpm@linux-foundation.org>
Reviewed-by: NWANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

KMSG_DUMP_KEXEC is useless because we already save kernel messages inside
/proc/vmcore, and it is unsafe to allow modules to do other stuffs in a
crash dump scenario.

[akpm@linux-foundation.org: fix powerpc build]
Signed-off-by: NWANG Cong <xiyou.wangcong@gmail.com>
Reported-by: NVivek Goyal <vgoyal@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Acked-by: NJarod Wilson <jarod@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

module_param(bool) used to counter-intuitively take an int.  In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.

It's time to remove the int/unsigned int option.  For this version
it'll simply give a warning, but it'll break next kernel version.
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

To ensure we don't receive any more interrupts from the host after we
enter the freeze function, disable all vq interrupts.

There wasn't any problem seen due to this in tests, but applying this
patch makes the freeze case more robust.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Remove all vqs and associated buffers in the freeze callback which
prepares us to go into hibernation state.  On restore, re-create all the
vqs and populate the input vqs with buffers to get to the pre-hibernate
state.

Note: Any outstanding unconsumed buffers are discarded; which means
there's a possibility of data loss in case the host or the guest didn't
consume any data already present in the vqs.  This can be addressed in a
later patch series, perhaps in virtio common code.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This common code will be shared with the PM freeze function.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Remove wrapper functions. This makes the allocation type explicit in
all callers; I used GPF_KERNEL where it seemed obvious, left it at
GFP_ATOMIC otherwise.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Reviewed-by: NChristoph Hellwig <hch@lst.de>

Signed-off-by: NTormod Volden <debian.tormod@gmail.com>
Reviewed-by: NCorbin Simpson <MostAwesomeDude@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

both callers of device_get_devnode() are only interested in lower 16bits
and nobody tries to return anything wider than 16bit anyway.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

We still don't use rdrand in /dev/random, which just seems stupid. We
accept the *cycle*counter* as a random input, but we don't accept
rdrand? That's just broken.

Sure, people can do things in user space (write to /dev/random, use
rdrand in addition to /dev/random themselves etc etc), but that
*still* seems to be a particularly stupid reason for saying "we
shouldn't bother to try to do better in /dev/random".

And even if somebody really doesn't trust rdrand as a source of random
bytes, it seems singularly stupid to trust the cycle counter *more*.

So I'd suggest the attached patch. I'm not going to even bother
arguing that we should add more bits to the entropy estimate, because
that's not the point - I don't care if /dev/random fills up slowly or
not, I think it's just stupid to not use the bits we can get from
rdrand and mix them into the strong randomness pool.

Link: http://lkml.kernel.org/r/CA%2B55aFwn59N1=m651QAyTy-1gO1noGbK18zwKDwvwqnravA84A@mail.gmail.comAcked-by: N"David S. Miller" <davem@davemloft.net>
Acked-by: N"Theodore Ts'o" <tytso@mit.edu>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

If the BMC gets reset, it will return 0x80 response errors.

In less than a week
# grep "Error 80 on cmd 22" /var/log/kernel |wc -l
378681

In this case, it is probably a good idea to restore the IPMI settings.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NArkadiusz Miśkiewicz <a.miskiewicz@gmail.com>
Reported-by: NArkadiusz Miśkiewicz <a.miskiewicz@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The below patch fixes some typos in various parts of the kernel, as well as fixes some comments.
Please let me know if I missed anything, and I will try to get it changed and resent.
Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch converts the drivers in drivers/char/hw_random/* to use the
module_platform_driver() macro which makes the code smaller and a bit
simpler.

Cc: David S. Miller <davem@davemloft.net>
Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NAlexander Clouter <alex@digriz.org.uk>
Acked-by: NOlof Johansson <olof@lixom.net>
Acked-by: NDavid Daney <david.daney@cavium.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Signed-off-by: NDave Martin <dave.martin@linaro.org>

If there is an architecture-specific random number generator we use it
to acquire randomness one "long" at a time.  We should put these random
words into consecutive words in the result buffer - not just overwrite
the first word again and again.
Signed-off-by: NTony Luck <tony.luck@intel.com>
Acked-by: NH. Peter Anvin <hpa@zytor.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If there is an architecture-specific random number generator we use
it to acquire randomness one "long" at a time. We should put these
random words into consecutive words in the result buffer - not just
overwrite the first word again and again.
Signed-off-by: NTony Luck <tony.luck@intel.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/4ec4061010261a4cb0@agluck-desktop.sc.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

It's incorrect to assume that buffers returned by the TPM
10 bytes long are always error reports. This patches
parses the error field in its header instead. The error report
is now being printed using dev_err() instead of dev_dbg(), making
it easier for users to provide more detailed bug reports.
Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>

A previous commit removed its PNP dependency, that in fact wasn't
necessary, but also allowed it be built for other architectures not
supported by it. This then caused kernel oops on PPC based machines.
I'm placing a x86 dependency back correctly.
Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>

Moved wait_for_stat to tpm.c so that other drivers can use it.
Also renamed it to avoid future namespace conflicts.
Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>

Moved from using tpm_tis_status() to the vendor specific
one in wait_for_stat(). This way other TPM drivers can use it
instead of reimplementing another.
Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>

This patch adds a delay after aborting a command. Some TPMs need
this and will not process the subsequent command correctly otherwise.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

Check the return code from getting the TPM's timeouts and durations
and reject the driver if they could not be read.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

This patch introduces a function that runs the TPM_ContinueSelfTest()
function and then polls the TPM to check whether it finished the selftest
and can receive new commands.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

Cleanup the tpm_continue_selftest function.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

Have the tpm_get_timeouts function return an error code.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.

Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>

The semi-colon is a typo here and it makes the if statement
unconditional.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NRichard Weinberger <richard@nod.at>

* kill duplicates with drivers/char/Kconfig
* take watchdog one into drivers/watchdog/Kconfig
* take mmapper to arch/um/Kconfig.um
* rename Kconfig.char menu to "UML Character Devices"
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NRichard Weinberger <richard@nod.at>

On s390 I have seen some random

"Warning: unable to open an initial console"

boot failure. Turns out that tty_open fails, because the
hvc_alloc was not yet done. In former times this could not happen,
since the probe function automatically called hvc_alloc. With newer
versions (multiport) some host<->guest interaction is required
before hvc_alloc is called. This might be too late, especially if
an initramfs is involved. Lets use a completion if we have
multiport and an early console.

[Amit:
  * Use NULL instead of 0 for pointer comparison
  * Rename 'port_added' to 'early_console_added'
  * Re-format, re-word commit message
  * Rebase patch on top of current queue]
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Acked-by: NChrstian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This commit adds port-specific stats for the number of bytes received,
sent and discarded.  They're exposed via the debugfs interface.  This
data can be used to check for data loss bugs (or disprove such claims).
It can also be used for accounting, if there's such a need.

The stats remain valid throughout the lifetime of the port.  Unplugging
a port will reset the stats.  The numbers are not reset across port
opens/closes.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>