max_phys_segments and max_sectors were swapped
Signed-off-by: NVasily Averin <vvs@sw.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NRoel Kluin <12o3l@tiscali.nl>
Acked-by: NKarsten Keil <kkeil@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Three bugfixes to the leds-gpio driver, plus minor whitespace tweaks:

 - Do the INIT_WORK() before registering each LED, so if its trigger
   becomes immediately active it can schedule work without oopsing..

 - Use normal registration, not platform_driver_probe(), so that
   devices appearing "late" (hotplug type) can still be bound.

 - Mark the driver remove code as "__devexit", preventing oopses
   when the underlying device is removed.

These issues came up when using this driver with some GPIO expanders
living on serial busses, which act unlike "normal" platform devices:
they can appear and vanish along with the serial bus driver.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>

Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

[PATCH] pciserial_resume_one ignored return value of pci_enable_device
Signed-off-by: NDirk Hohndel <hohndel@linux.intel.com>
Acked-by: NAlan Cox <alan@redhat.com>
Acked-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The Coverity checker spotted that we'd have already oops'ed if "ctrl"
was NULL.

Additionally, "func" had just been checked for not being NULL.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

pci_match_device() no longer has any other users.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that we have dealt with the real issue, in that some ATI SATA and
USB controllers needed the INTX_DISABLE quirk, we can remove these AMD
chipset global MSI disabling quirks.

This reverts three changesets:

4be8f906 (PCI: disable MSI on RS690)
aea6a433 (PCI: disable MSI on RD580)
f122392f (PCI: disable MSI on RX790)

This is based upon testing and feedback from
Shane Huang <Shane.Huang@amd.com>.

Cc: Shane Huang <Shane.Huang@amd.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

A reasonably common problem with some devices is that they will
disable MSI generation when the INTX_DISABLE bit is set in the
PCI_COMMAND register.

Quirk this explicitly, guarding the pci_intx() calls in msi.c with
this quirk indication.

The first entries for this quirk are for 5714 and 5780 Tigon3 chips,
and thus we can remove the workaround code from the tg3.c driver.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Acked-by: NMichael Chan <mchan@broadcom.com>
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This is the fix for the following problem:

https://bugzilla.redhat.com/show_bug.cgi?id=227657

The bnx2 device 5706 complains about MSI not working behind a
ServerWorks HT1000 PCIX bridge. An earlier commit to fix the problem:

e3008ded:

"PCI: disable MSI by default on systems with Serverworks HT1000 chips"

was not entirely correct, and has been reverted.

MSI does not work on the PCIX bus because the BIOS did not set the
HT_MSI_FLAGS_ENABLE bit in the HyperTransport MSI capability on the
bridge.  We use the existing quirk_msi_ht_cap() to detect the problem
and disable MSI in all buses behind it.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Cc: Anantha Subramanyam <ananth@broadcom.com>
Cc: Naren Sankar <nsankar@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This reverts commit e3008ded.

The real bug was an INTX issue in the tg3 ethernet chip, and
cured by commit c129d962a66c76964954a98b38586ada82cf9381
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

commit 33c1002e incorrectly changed return
value from '0' to '-1', fix it (ns87415 was the only host driver affected
since it uses both IDE_HFLAG_TRUST_BIOS_FOR_DMA and IDE_HFLAG_NO_ATAPI_DMA).
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Problem reported by Mikael.

Cc: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Noticed by Tejun Heo.

Cc: Tejun Heo <htejun@gmail.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

ide_dump_ata_status() may set HOB bit before ide_end_drive_cmd() is called.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

drive_cmd_intr() is used by both REQ_TYPE_ATA_CMD and REQ_TYPE_ATA_TASK
but commands using PIO-in protocol are valid only for REQ_TYPE_ATA_CMD
(&args[4] in case of REQ_TYPE_ATA_TASK points to a value for IDE_LCYL_REG
register instead of the data buffer).  This fix allows REQ_TYPE_ATA_TASK
commands to use non-zero values for IDE_SECTOR_REG (args[3]).
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

This config option is effective only for host drivers that use
IDE_HFLAG_OFF_BOARD host flag (aec62xx, generic, hpt34x, hpt366,
pdc202xx_new, pdc202xx_old and tc86c001).
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

ide_fix_driveid can now be unexported.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Acked-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Add IDEDISK_MULTI_MODE text adapted from hdparm manual page.
Signed-off-by: NMatti Linnanvuori <mattilinnanvuori@yahoo.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Terminates id->model string before invoking strstr() in do_identify().
Signed-off-by: NTejun Heo <tj@home-tj.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

In piix.c (and in ata_piix.c) are already included some patches to skip the
cable check on some laptops and to enable UDMA > 33 modes, but I've noticed
than theese doesn't work on my Acer Aspire 5602WLMi (maybe exist more
versions of this laptop).  With this simple patch I can set transfer mode
to UDMA100.

From: "sebdeg@ngi.it" <sebdeg@ngi.it>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Acked-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Fixes priority mistakes similar to '!x & y'
Signed-off-by: NRoel Kluin <12o3l@tiscali.nl>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Unregistering a device from within a device attribute handler leads to
a deadlock. Need to use device_schedule_callback() to unregister device
in error path.
Signed-off-by: NGerald Schaefer <geraldsc@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

smsgiucv is a driver that relies on iucv to work properly. If
iucv ans smsgiucv are compiled into the kernel and run on an
lpar the following scenario happens:
iucv is initialized early as a subsystem. It checks for z/VM and
returns with EPROTONOTSUPPORT. Later smsgiucv tries to run
driver_register with iucv_bus as bus. As this bus is not
initialized the driver core and list debugging issue several
warnings and oopses.

Solution is to let smsgiucv also check for z/VM and return
EPROTONOTSUPPORT as well.
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Use INIT_WORK to initialize struct work and don't initialize a
struct work partial by explicitly initializing its private structures.
Fixes the following lockdep bug because no key was assigned:

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
0000000001f07bb8 0000000001f07bf8 0000000000000002 0000000000000000
       0000000001f07c98 0000000001f07c10 0000000001f07c10 0000000000015406
       0000000000000000 0000000000000002 0000000000000000 0000000000000000
       0000000001f07bf8 000000000000000c 0000000001f07bf8 0000000001f07c68
       000000000039ae60 0000000000015406 0000000001f07bf8 0000000001f07c48
Call Trace:
([<0000000000015376>] show_trace+0xda/0x104)
 [<0000000000015460>] show_stack+0xc0/0xf8
 [<00000000000154c6>] dump_stack+0x2e/0x3c
 [<000000000006a71e>] __lock_acquire+0x47e/0x11a0
 [<000000000006b4f0>] lock_acquire+0xb0/0xd8
 [<00000000000555a6>] run_workqueue+0x1aa/0x24c
 [<00000000000556de>] worker_thread+0x96/0xf4
 [<000000000005c210>] kthread+0x90/0xb4
 [<000000000001947a>] kernel_thread_starter+0x6/0xc
 [<0000000000019474>] kernel_thread_starter+0x0/0xc
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

airlied: separated this out from a patch on lkml.
Signed-off-by: NRoel Kluin <12o3l@tiscali.nl>
Signed-off-by: NDave Airlie <airlied@linux.ie>

This code relied on the CPU and GPU address for the aperture being the same,
On some r5xx hardware I was playing with I noticed that this isn't always true.
This fixes issues seen on some r400 cards. (bugs.freedesktop.org 9957)
Signed-off-by: NDave Airlie <airlied@redhat.com>

The pvrusb2 driver is tearing down its sysfs related pieces in the
incorrect order.  This leaves dangling pointers which causes the
kernel device core to oops.  The problem has been present virtually
forever but became malignant with the changeover to the way of
handling /sys/class.  Fix is just to make sure we don't tear down the
class structure until AFTER the driver instances are deregistered.
Signed-off-by: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

vivi.c is a virtual driver that builds without PCI and should run on
non-pci hardware.
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

From: Ludovico Cavedon <cavedon@sssup.it>
Signed-off-by: NLudovico Cavedon <cavedon@sssup.it>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This em28xx-video.c uses functions from this header, but doesn't include it.
It depends on some v4l headers included two levels down including poll.h,
which includes mm.h.

These v4l headers might change, so it's best to include the headers needed
directly.

It also causes problems for the out of core build system's backward
compatibility with older kernels, which is the real reason I bothered to
create a patch for something that would otherwise be so minor that it would
hardly be worth the trouble.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Trent Piepho wrote:
> I do not think the saa7134-alsa driver supports mmap.  The cx88-alsa driver
> also claimed to support mmap, but it never worked until I fixed it.  It's
> pretty clear that the code in saa7134-alsa was based on the same code as
> cx88-alsa, so it's likely it has the same bug.

You are right. The patch below (based on your cx88 patch, but I don't
really understand it) fixes mmap support in saa7134-alsa for me.
Recording via mmap (arecord -M -f S16_LE -c 2 -r 32000 -D hw:1) didn't
work at all before, works now, tested for at least 20 minutes (but,
unfortunately, with one overrun at least 0.719 ms long).
Signed-off-by: NAlexander E. Patrakov <patrakov@ums.usu.ru>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The pvrusb2 driver's sysfs implementation had long since implemented a
dummy hotplug function because at the time the kernel would oops
without at least the empty function being present.  Today - after
numerous class interface changes in the kernel - this pvrusb2 change
had been dutifully carried forward but an inspection of the kernel
sources shows that it is no longer needed.  So remove the dummy
function and its reference.  This also solves a recurring backwards
compatibility issue in the pvrusb2 driver as the class interface has
been getting thrashed in the kernel.
Signed-off-by: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

if(!x & y) should either be if(!(x & y)) or if(!x && y)
    I made changes as seemed appropriate, but please review
    this is against current git.
Signed-off-by: NRoel Kluin <12o3l@tiscali.nl>
Signed-off-by: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Fixes the signal strength value (higher value = higher signal strength)
and scales the value to the range of 0..ffff. The characteristic itself
is wrong. To get proper values on a TT-C2300 in the range of 40..60%
real signal strength, the values from the patch should be divide by two.
The attached patch doesn't fix the characteristic.
Signed-off-by: NHartmut Birr <e9hack@googlemail.com>
Signed-off-by: NOliver Endriss <o.endriss@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>