When remapping MSIs into pirqs for PV on HVM guests, qemu is responsible
for doing the actual mapping and unmapping.
We only give qemu the desired pirq number when we ask to do the mapping
the first time, after that we should be reading back the pirq number
from qemu every time we want to re-enable the MSI.

This fixes a bug in xen_hvm_setup_msi_irqs that manifests itself when
trying to enable the same MSI for the second time: the old MSI to pirq
mapping is still valid at this point but xen_hvm_setup_msi_irqs would
try to assign a new pirq anyway.
A simple way to reproduce this bug is to assign an MSI capable network
card to a PV on HVM guest, if the user brings down the corresponding
ethernet interface and up again, Linux would fail to enable MSIs on the
device.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

Use the new hypercall PHYSDEVOP_get_free_pirq to ask Xen to allocate a
pirq. Remove the unsupported PHYSDEVOP_get_nr_pirqs hypercall to get the
amount of pirq available.

This fixes find_unbound_pirq that otherwise would return a number
starting from nr_irqs that might very well be out of range in Xen.

The symptom of this bug is that when you passthrough an MSI capable pci
device to a PV on HVM guest, Linux would fail to enable MSIs on the
device.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

Some Lenovos have TPMs that require a quirk to function correctly. This can
be autodetected by checking whether the device has a _HID of INTC0102. This
is an invalid PNPid, and as such is discarded by the pnp layer - however
it's still present in the ACPI code, so we can pull it out that way. This
means that the quirk won't be automatically applied on non-ACPI systems,
but without ACPI we don't have any way to identify the chip anyway so I
don't think that's a great concern.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
Tested-by: NJiri Kosina <jkosina@suse.cz>
Tested-by: NAndy Isaacson <adi@hexapodia.org>
Signed-off-by: NJames Morris <jmorris@namei.org>

The wrong of initializer entry was modified.
Signed-off-by: NToshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Reported-by: NDr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This driver's AUTHOR was changed to "Toshiharu Okada" from "Masayuki Ohtake".
I update the Kconfig, renamed "Topcliff" to "EG20T".
Signed-off-by: NToshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In commit 58933c64(ucc_geth: Fix the wrong the Rx/Tx FIFO size),
the UCC_GETH_UTFTT_INIT is set to 512 based on the recommendation
of the QE Reference Manual.  But that will sometimes cause tx halt
while working in half duplex mode.

According to errata draft QE_GENERAL-A003(High Tx Virtual FIFO
threshold size can cause UCC to halt), setting UTFTT less than
[(UTFS x (M - 8)/M) - 128] will prevent this from happening
(M is the minimum buffer size).

The patch changes UTFTT back to 256.
Signed-off-by: NLi Yang <leoli@freescale.com>
Cc: Jean-Denis Boyer <jdboyer@media5corp.com>
Cc: Andreas Schmitz <Andreas.Schmitz@riedel.net>
Cc: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds some debug information about ehea not being able to
allocate enough spaces. Also it correctly updates the amount of available
skb.
Signed-off-by: NBreno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The HSO driver incorrectly creates a serial device instead of a net
device when disable_net is set. It shouldn't create anything for the
network interface.
Signed-off-by: NFilip Aben <f.aben@option.com>
Reported-by: NPiotr Isajew <pki@ex.com.pl>
Reported-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We register lapb when tty is created, but unregister it only when the
device is UP. So move the lapb_unregister to x25_asy_close_tty after
the device is down.

The old behaviour causes ldisc switching to fail each second attempt,
because we noted for us that the device is unused, so we use it the
second time, but labp layer still have it registered, so it fails
obviously.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Reported-by: NSergey Lapin <slapin@ossfans.org>
Cc: Andrew Hendry <andrew.hendry@gmail.com>
Tested-by: NSergey Lapin <slapin@ossfans.org>
Tested-by: NMikhail Ulyanov <ulyanov.mikhail@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We were truncating the number of unicast and multicast MAC addresses
supported.  Additionally, we were incorrectly computing the MAC Address
hash (a "1 << N" where we needed a "1ULL << N").
Signed-off-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Allocating unit from ird might return several error codes
not only -EAGAIN, so it should not be changed and returned
precisely. Same time unit release procedure should be invoked
only if device is unregistering.
Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
CC: Paul Mackerras <paulus@samba.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

"aup->enable" holds already the address pointing to the MAC enable
register. The bug was introduced by commit d0e7cb:

"au1000-eth: remove volatiles, switch to I/O accessors".

CC: Florian Fainelli <florian@openwrt.org>
Signed-off-by: NWolfgang Grandegger <wg@denx.de>
Acked-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Incorrect rcu check was used as rcu isn't done
under mutex here. Force check to 1 for now,
to stop it from complaining.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The qdio device indicator is freed before the device is notified that
the indicator is reset. This sequence contains a race when the freed
indicator is used by a new device while the reset of the indicator is
still pending. Do the reset operation before freeing the indicator to
avoid that potential race.
Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

According to the comment describing ops_lock in the definition of struct
backlight_device and when comparing with other functions in backlight.c
the mutex must be hold when checking ops to be non-NULL.

Fixes a problem added by c835ee7f ("backlight: Add suspend/resume
support to the backlight core") in Jan 2009.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NRichard Purdie <rpurdie@linux.intel.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

struct als_data *data is not used in this driver at all.

Also add a missing ">" character for MODULE_AUTHOR.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Chip detection may fail if the chip is in some odd state for example after
system restart.  Chip doesn't have HW reset line.
Signed-off-by: NSamu Onkalo <samu.p.onkalo@nokia.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Chip detection may fail if the chip is in some odd state for example after
system restart.  Chip doesn't have HW reset line.
Signed-off-by: NSamu Onkalo <samu.p.onkalo@nokia.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Delays were little bit too long.  Adjust delay times and add some comments
to them.
Signed-off-by: NSamu Onkalo <samu.p.onkalo@nokia.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Delays were little bit too long.  Adjust delay times and add some comments
to them.
Signed-off-by: NSamu Onkalo <samu.p.onkalo@nokia.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

A small macro changed to inline function to have proper type checking.
Inline added to two similar small functions.
Signed-off-by: NSamu Onkalo <samu.p.onkalo@nokia.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some small macros changed to inline functions to have proper type
checking.
Signed-off-by: NSamu Onkalo <samu.p.onkalo@nokia.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

UV hardware defines 256 memory protection regions versus the baseline 64
with increasing size for the SN2 ia64.  This was overlooked when XPC was
modified to accomodate both UV and SN2.

Without this patch, a user could reconfigure their existing system and
suddenly disable cross-partition communications with no indication of what
has gone wrong.  It also prevents larger configurations from using
cross-partition communication.
Signed-off-by: NRobin Holt <holt@sgi.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

While running randconfg with ktest.pl I stumbled upon this bug:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000003
  IP: [<ffffffff815fe44f>] strstr+0x39/0x86
  PGD 0
  Oops: 0000 [#1] SMP
  last sysfs file:
  CPU 0
  Modules linked in:

  Pid: 1, comm: swapper Not tainted 2.6.37-rc1-test+ #6 DG965MQ/
  RIP: 0010:[<ffffffff815fe44f>]  [<ffffffff815fe44f>] strstr+0x39/0x86
  RSP: 0018:ffff8800797cbd80  EFLAGS: 00010213
  RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffffffffffff
  RDX: 0000000000000000 RSI: ffffffff82eb7ac9 RDI: 0000000000000003
  RBP: ffff8800797cbda0 R08: ffff880000000003 R09: 0000000000030725
  R10: ffff88007d294c00 R11: 0000000000014c00 R12: 0000000000000020
  R13: ffffffff82eb7ac9 R14: ffffffffffffffff R15: ffffffff82eb7b08
  FS:  0000000000000000(0000) GS:ffff88007d200000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000000003 CR3: 0000000002a1d000 CR4: 00000000000006f0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  Process swapper (pid: 1, threadinfo ffff8800797ca000, task ffff8800797d0000)
  Stack:
   00000000000000ba ffffffff82eb7ac9 ffffffff82eb7ab8 00000000000000ba
   ffff8800797cbdf0 ffffffff81e2050f ffff8800797cbdc0 00000000815f913b
   ffff8800797cbe00 ffffffff82eb7ab8 0000000000000000 0000000000000000
  Call Trace:
   [<ffffffff81e2050f>] dmi_matches+0x117/0x154
   [<ffffffff81e205d7>] dmi_check_system+0x3d/0x8d
   [<ffffffff82e1ad25>] ? nas_gpio_init+0x0/0x2c8
   [<ffffffff82e1ad49>] nas_gpio_init+0x24/0x2c8
   [<ffffffff820d750d>] ? wm8350_led_init+0x0/0x20
   [<ffffffff82e1ad25>] ? nas_gpio_init+0x0/0x2c8
   [<ffffffff810022f7>] do_one_initcall+0xab/0x1b2
   [<ffffffff82da749c>] kernel_init+0x248/0x331
   [<ffffffff8100e624>] kernel_thread_helper+0x4/0x10
   [<ffffffff82da7254>] ? kernel_init+0x0/0x331

Found that the nas_led_whitelist dmi_system_id structure array had no
NULL end delimiter, causing the dmi_check_system() loop to read an
undefined entry.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Acked-by: NDave Hansen <dave@sr71.net>
Acked-by: NRichard Purdie <rpurdie@linux.intel.com>
Acked-by: NArjan van de Ven <arjan@linux.intel.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Running randconfig with ktest.pl I hit this bug:

[   16.101158] ICN-ISDN-driver Rev 1.65.6.8 mem=0x000d0000
[   16.106376] icn: (line0) ICN-2B, port 0x320 added
[   16.111064] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: c1642880
[   16.111066] 
[   16.121214] Pid: 1, comm: swapper Not tainted 2.6.37-rc2-test-00124-g6656b3fc #8
[   16.128499] Call Trace:
[   16.130942]  [<c0f51662>] ? printk+0x1d/0x23
[   16.135200]  [<c0f5153f>] panic+0x5c/0x162
[   16.139286]  [<c0d62a9a>] ? icn_addcard+0x6d/0xbe
[   16.143975]  [<c0445783>] print_tainted+0x0/0x8c
[   16.148582]  [<c1642880>] ? icn_init+0xd8/0xdf
[   16.153012]  [<c1642880>] icn_init+0xd8/0xdf
[   16.157271]  [<c04012e5>] do_one_initcall+0x8c/0x143
[   16.162222]  [<c16427a8>] ? icn_init+0x0/0xdf
[   16.166566]  [<c15f1a05>] kernel_init+0x13f/0x1da
[   16.171256]  [<c15f18c6>] ? kernel_init+0x0/0x1da
[   16.175945]  [<c0403bfe>] kernel_thread_helper+0x6/0x10
[   16.181181] panic occurred, switching back to text console

Looking into it I found that the stack was corrupted by the assignment
of the Rev #. The variable rev is given 10 bytes, and in this output the
characters that were copied was: " 1.65.6.8 $". Which was 11 characters
plus the null ending character for a total of 12 bytes, thus corrupting
the stack.

This patch ups the variable size to 20 bytes as well as changes the
strcpy to strncpy. I also added a check to make sure '$' is found.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This change enables PCI root complex support for TILEPro.  Unlike
TILE-Gx, TILEPro has no support for memory-mapped I/O, so the PCI
support consists of hypervisor upcalls for PIO, DMA, etc.  However,
the performance is fine for the devices we have tested with so far
(1Gb Ethernet, SATA, etc.).

The <asm/io.h> header was tweaked to be a little bit more aggressive
about disabling attempts to map/unmap IO port space.  The hacky
<asm/pci-bridge.h> header was rolled into the <asm/pci.h> header
and the result was simplified.  Both of the latter two headers were
preliminary versions not meant for release before now - oh well.

There is one quirk for our TILEmpower platform, which accidentally
negotiates up to 5GT and needs to be kicked down to 2.5GT.
Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>

This change adds the first network driver for the tile architecture,
supporting the on-chip XGBE and GBE shims.

The infrastructure is present for the TILE-Gx networking drivers (another
three source files in the new directory) but for now the the actual
tilegx sources are waiting on releasing hardware to initial customers.

Note that arch/tile/include/hv/* are "upstream" headers from the
Tilera hypervisor and will probably benefit less from LKML review.
Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>

The file is not needed.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Cc: Thomas Winischhofer <thomas@winischhofer.net>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

sis_main.c is always compiled, so we can check Kconfig options there.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Cc: Thomas Winischhofer <thomas@winischhofer.net>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Get rid of one more wrapper.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Cc: Thomas Winischhofer <thomas@winischhofer.net>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Remove register IO wrappers.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Cc: Thomas Winischhofer <thomas@winischhofer.net>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

There is no need to alias CONFIG #defines.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Cc: Thomas Winischhofer <thomas@winischhofer.net>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

It's not needed anymore with SIS_XORG_XF86 gone.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Cc: Thomas Winischhofer <thomas@winischhofer.net>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Delete code for compiling the driver for X.org/XFree86. The development
has forked, so there is no point keeping this code in the tree.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Cc: Thomas Winischhofer <thomas@winischhofer.net>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

If pci_map_rom() fails, there is some fallback code that basically
duplicates pci_map_rom() on non-x86 platforms. No point in that.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Cc: Thomas Winischhofer <thomas@winischhofer.net>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Delete a workaround for a PCI ROM bug that has been fixed ages ago by
the commit 761a3ac0.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Cc: Thomas Winischhofer <thomas@winischhofer.net>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Before 2.6.37, the md layer had a mechanism for catching I/Os with the
barrier flag set, and translating the barrier into barriers for all
the underlying devices.  With 2.6.37, I/O barriers have become plain
old flushes, and the md code was updated to reflect this.  However,
one piece was left out -- the md layer does not tell the block layer
that it supports flushes or FUA access at all, which results in md
silently dropping flush requests.

Since the support already seems there, just add this one piece of
bookkeeping.
Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

Commit 4044ba58 supposedly fixed a
problem where if a raid1 with just one good device gets a read-error
during recovery, the recovery would abort and immediately restart in
an infinite loop.

However it depended on raid1_remove_disk removing the spare device
from the array.  But that does not happen in this case.  So add a test
so that in the 'recovery_disabled' case, the device will be removed.

This suitable for any kernel since 2.6.29 which is when
recovery_disabled was introduced.

Cc: stable@kernel.org
Reported-by: NSebastian Färber <faerber@gmail.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

When trying to grow an array by enlarging component devices,
rdev_size_store() expects the return value of rdev_size_change() to be
in sectors, but the actual value is returned in KBs.

This functionality was broken by commit
     dd8ac336
so this patch is suitable for any kernel since 2.6.30.

Cc: stable@kernel.org
Signed-off-by: NJustin Maggard <jmaggard10@gmail.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

The sysfs files for virtio produce the wrong format and are missing
the required newline. The output for virtio bus vendor/device should
have the same format as the corresponding entries for PCI devices.

Although this technically changes the ABI for sysfs, these files were
broken to start with!
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>