This logic is exactly equivalent to the old logic, but it should
be easier to see what it's doing.

The equivalence depends on one fact from outside this function:
when 'r->limit' is false, 'reserved' is zero.  (Well, two facts;
the other is that 'reserved' is never negative.)

Cc: Jiri Kosina <jkosina@suse.cz>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NGreg Price <price@mit.edu>
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>

This comment didn't quite keep up as extract_entropy() was split into
four functions.  Put each bit by the function it describes.
Signed-off-by: NGreg Price <price@mit.edu>
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>

The loop condition never changes until just before a break, so we
might as well write it as a constant.  Also since a996996d
("random: drop weird m_time/a_time manipulation") we don't do anything
after the loop finishes, so the 'break's might as well return
directly.  Some other simplifications.

There should be no change in behavior introduced by this commit.
Signed-off-by: NGreg Price <price@mit.edu>
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>

After this remark was written, commit d2e7c96a added a use of
arch_get_random_long() inside the get_random_bytes codepath.
The main point stands, but it needs to be reworded.
Signed-off-by: NGreg Price <price@mit.edu>
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>

There's only one function here now, as uuid_strategy is long gone.
Also make the bit about "If accesses via ..." clearer.
Signed-off-by: NGreg Price <price@mit.edu>
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>

Signed-off-by: NGreg Price <price@mit.edu>
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>

While we are at it, don't do kmap() under kmap_atomic(), *especially*
for a page we'd allocated with GFP_KERNEL.  It's spelled "page_address",
and had that been more than that, we'd have a real trouble - kmap_high()
can block, and doing that while holding kmap_atomic() is a Bad Idea(tm).
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Fix

  drivers/char/ipmi/ipmi_si_intf.c: In function 'ipmi_parisc_probe':
  drivers/char/ipmi/ipmi_si_intf.c:2752:2: error: 'rv' undeclared (first use in this function)
  drivers/char/ipmi/ipmi_si_intf.c:2752:2: note: each undeclared identifier is reported only once for each function it appears in

Introduced by commit d02b3709 ("ipmi: Cleanup error return")
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NJean Delvare <khali@linux-fr.org>

Return proper errors for a lot of IPMI failure cases.  Also call
pci_disable_device when IPMI PCI devices are removed.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Loading ipmi_si module while bmc is disconnected, we found the timeout
is longer than 5 secs.  Actually it takes about 3 mins and 20
secs.(HZ=250)

error message as below:
  Dec 12 19:08:59 linux kernel: IPMI BT: timeout in RD_WAIT [ ] 1 retries left
  Dec 12 19:08:59 linux kernel: BT: write 4 bytes seq=0x01 03 18 00 01
  [...]
  Dec 12 19:12:19 linux kernel: IPMI BT: timeout in RD_WAIT [ ]
  Dec 12 19:12:19 linux kernel: failed 2 retries, sending error response
  Dec 12 19:12:19 linux kernel: IPMI: BT reset (takes 5 secs)
  Dec 12 19:12:19 linux kernel: IPMI BT: flag reset [ ]

Function wait_for_msg_done() use schedule_timeout_uninterruptible(1) to
sleep 1 tick, so we should subtract jiffies_to_usecs(1) instead of 100
usecs from timeout.
Reported-by: NHu Shiyuan <hushiyuan@huawei.com>
Signed-off-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use USEC_PER_SEC instead of 1000000, that making the later bugfix
more clearly.
Signed-off-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch proposes to remove the use of the IRQF_DISABLED flag

It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Clean-up to remove depedency with bootmem headers.
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NTejun Heo <tj@kernel.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Christoph Lameter <cl@linux-foundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The TTY_PRINTK option is bool, and hence this code is either
present or absent.  It will never be modular, so using
module_init as an alias for __initcall is rather misleading.

Fix this up now, so that we can relocate module_init from
init.h into module.h in the future.  If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.

Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups.  As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- it will remain at level 6 in initcall ordering.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The nwbutton driver uses interruptible_sleep_on to wait for buttons
getting pressed after we enter the read() function, which is inherently
racy and cannot be fixed by using wait_event without changing the
driver's user space interface.

Instead, this patch just uses an open-coded variant of the same
interruptible_sleep_on() call, so the driver behavior doesn't change
but we remove the sleep_on family from the kernel.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The four variants of the synclink driver use the same code in their
open() callback to wait for a port in process of being closed,
using interruptible_sleep_on, which is racy and going away soon.

Making things worse, these functions hold the BTM while doing so,
which means that if we ever enter this code path, we cannot actually
continue since the other thread that is in process of closing the
port can no longer get the BTM.

This addresses both issues by using wait_event_interruptible_tty()
instead.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We're accessing the PCI_COMMAND register here, so use the appropriate
#define.  The bit we're writing (1 << 14) isn't defined by the PCI or PCIe
spec, so we don't have a name for it.

No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

In i810_setup(), i830_setup(), and i9xx_setup(), we use the result of
pci_bus_address() as an argument to ioremap() and to compute gtt_phys_addr.
These should use pci_resource_start() instead because we want the CPU
physical address, not the bus address.

If there were an AGP device behind a host bridge that translated addresses,
e.g., a PNP0A08 device with _TRA != 0, this would fix a bug.  I'm not aware
of any of those, but they are possible.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Per the Intel 915G/915GV/... Chipset spec (document number 301467-005),
GTTADR is a standard PCI BAR.

The PCI core reads GTTADR at enumeration-time.  Use pci_bus_address()
instead of reading it again in the driver.  This works correctly for both
32-bit and 64-bit BARs.  The spec above only mentions 32-bit GTTADR, but we
should still use the standard interface.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Per the Intel 915G/915GV/... Chipset spec (document number 301467-005),
MMADR is a standard PCI BAR.

The PCI core reads MMADR at enumeration-time.  Use pci_bus_address()
instead of reading it again in the driver.  This works correctly for both
32-bit and 64-bit BARs.  The spec above only mentions 32-bit MMADR, but we
should still use the standard interface.

Also, stop clearing the low 19 bits of the bus address because it's invalid
to use addresses outside the region defined by the BAR.  The spec claims
MMADR is 512KB; if that's the case, those bits will be zero anyway.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Per the Intel 915G/915GV/... Chipset spec (document number 301467-005),
GMADR is a standard PCI BAR.

The PCI core reads GMADR at enumeration-time.  Use pci_bus_address()
instead of reading it again in the driver.  This works correctly for both
32-bit and 64-bit BARs.  The spec above only mentions 32-bit GMADR, but
Yinghai's patch (link below) indicates some devices have a 64-bit GMADR.

[bhelgaas: reworked starting from http://lkml.kernel.org/r/1385851238-21085-13-git-send-email-yinghai@kernel.org]
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The only use of gtt_bus_addr is as an argument to ioremap(), so it is a CPU
physical address, not a bus address.  Rename it to gtt_phys_addr to reflect
this.

No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

amd_irongate_configure(), ati_configure(), and nvidia_configure() call
ioremap() on an address read directly from a BAR.  But a BAR contains a
bus address, and ioremap() expects a CPU physical address.  Use
pci_resource_start() to obtain the physical address.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some embedded systems use hibernation for fast boot. and in it,
some software components need to handle specific things before
hibernation and after restore. So it needs to capture the apm
status about these pm events.

Currently apm just supports suspend to ram, but not suspend to disk,
so here add logic about hibernation apm events.
Signed-off-by: NBin Shi <Bin.Shi@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Per the AGP 3.0 spec, APBASE is a standard PCI BAR and may be either 32
bits or 64 bits wide.  Many drivers read APBASE directly, but they only
handled 32-bit BARs.

The PCI core reads APBASE at enumeration-time.  Use pci_bus_address()
instead of reading it again in the driver.  This works correctly for both
32-bit and 64-bit BARs.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

so we make it static

CC: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
CC: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>

If CONFIG_PM_SLEEP=n, CONFIG_PNP=y we get this warning:

drivers/char/tpm/tpm_tis.c:706:13: warning: 'tpm_tis_reenable_interrupts' defined but not used [-Wunused-function]

This seems to have been introduced in a2fa3fb0 'tpm: convert tpm_tis driver
to use dev_pm_ops from legacy pm_ops'

Also, unpon reviewing, the #ifdefs around tpm_tis_pm are not right, the first
reference is protected, the second is not. tpm_tis_pm is always defined so we
can drop the #ifdef.
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>

This consolidates everything that is only used within tpm-dev.c
into tpm-dev.c and out of the publicly visible struct tpm_chip.

The per-file allocation lays the ground work for someday fixing the
strange forced O_EXCL behaviour of the current code.
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Reviewed-by: NJoel Schopp <jschopp@linux.vnet.ibm.com>
Reviewed-by: NAshley Lai <adlai@linux.vnet.ibm.com>
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>

This builds on the last commit to use the ops structure in the core
and reduce the size of tpm_vendor_specific.
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Reviewed-by: NJoel Schopp <jschopp@linux.vnet.ibm.com>
Reviewed-by: NAshley Lai <adlai@linux.vnet.ibm.com>
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>

This replaces the static initialization of a tpm_vendor_specific
structure in the drivers with the standard Linux idiom of providing
a const structure of function pointers.
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Reviewed-by: NJoel Schopp <jschopp@linux.vnet.ibm.com>
Reviewed-by: NAshley Lai <adlai@linux.vnet.ibm.com>
[phuewe: did apply manually due to commit
191ffc6bde3 tpm/tpm_i2c_atmel: fix coccinelle warnings]
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>

The tpm core now sets up and controls all sysfs attributes, instead
of having each driver have a unique take on it.

All drivers now now have a uniform set of attributes, and no sysfs
related entry points are exported from the tpm core module.

This also uses the new method used to declare sysfs attributes
with DEVICE_ATTR_RO and 'struct attribute *'
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
[phuewe: had to apply the tpm_i2c_atmel part manually due to commit
191ffc6bde3fc tpm/tpm_i2c_atmel: fix coccinelle warnings]
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>

CLASS-sysfs.c is a common idiom for linux subsystems.

This is the first step to pulling all the sysfs support code from
the drivers into tpm-sysfs. This is a plain text copy from tpm-interface
with support changes to make it compile.

_tpm_pcr_read is made non-static and is called tpm_pcr_read_dev.
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>

CLASS-dev.c is a common idiom for Linux subsystems

This pulls all the code related to the miscdev into tpm-dev.c and makes it
static. The identical file_operation structs in the drivers are purged and the
tpm common code unconditionally creates the miscdev.
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Reviewed-by: NJoel Schopp <jschopp@linux.vnet.ibm.com>
Reviewed-by: NAshley Lai <adlai@linux.vnet.ibm.com>
[phuewe:
tpm_dev_release is now used only in this file, thus the EXPORT_SYMBOL
can be dropped and the function be marked as static.
It has no other in-kernel users]
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>

“wait” wait queue is defined but never used in the function, thus
it can be removed.
Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
Acked-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>

drivers/char/tpm/tpm_i2c_atmel.c:178:8-9: WARNING: return of 0/1 in function 'i2c_atmel_req_canceled' with return type bool

 Return statements in functions returning bool should use
 true/false instead of 1/0.
Generated by: coccinelle/misc/boolreturn.cocci

CC: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
CC: Peter Huewe <peterhuewe@gmx.de>
Acked-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>

smatch complains:
drivers/char/tpm/tpm_ibmvtpm.c:510
ibmvtpm_crq_process() info: ignoring unreachable code.

-> The return is not necessary here, remove it
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>

The 'get_burstcount' function can in some circumstances 'return -EBUSY' which
in tpm_stm_i2c_send is stored in an 'u32 burstcnt'
thus converting the signed value into an unsigned value, resulting
in 'burstcnt' being huge.
Changing the type to u32 only does not solve the problem as the signed
value is converted to an unsigned in I2C_WRITE_DATA, resulting in the
same effect.

Thus
-> Change type of burstcnt to u32 (the return type of get_burstcount)
-> Add a check for the return value of 'get_burstcount' and propagate a
potential error.

This makes also sense in the 'I2C_READ_DATA' case, where the there is no
signed/unsigned conversion.

found by coverity
Cc: stable@vger.kernel.org
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>

If
 status = acpi_get_name(handle, ACPI_FULL_PATHNAME, &buffer);
fails for whatever reason and does not return AE_OK
 if (strstr(buffer.pointer, context) != NULL) {
does dereference a null pointer.

-> Check the return value and return the status to the caller

Found by coverity
Cc: stable@vger.kernel.org
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>

Depending on the implementation strcmp might return the difference between
two strings not only -1,0,1 consequently
 if (strcmp (a,b) == -1)
might lead to taking the wrong branch

-> compare with < 0  instead,
which in any case is more canonical.

Cc: stable@vger.kernel.org
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>