problem:
      id[53-58] might be changed after initializing device CHS settings.

changes:
    - call ata_dev_reread_id() to reread the identify device info,
      after initializing device CHS settings.
Signed-off-by: NAlbert Lee <albertcc@tw.ibm.com>

============
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

     - merge ata_prot_to_cmd() and ata_dev_set_protocol() as
       ata_rwcmd_protocol()
     - pave road for read/write multiple support
     - remove usage of pre-cached command and protocol values and call
       ata_rwcmd_protocol() instead
Signed-off-by: NAlbert Lee <albertcc@tw.ibm.com>

==============
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

   move the initialization of taskfile LBA flags
     "ATA_TFLAG_LBA" and "ATA_TFLAG_LBA48 flags"
   to the SCSI translation functions
Signed-off-by: NAlbert Lee <albertcc@tw.ibm.com>

=============
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

Only signal completion after marking request slot as free, otherwise other
processor can free request structure before we finish using it.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix -EIO on /proc/acpi/events after suspends.  This actually breaks
suspending by power button in many setups.
Signed-off-by: NPavel Machek <pavel@suse.cz>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Since Revision 1.10 was released the n_r3964 module wasn't able to receive any
data.  The reason for that behavior is because there were some wrong calls of
mod_timer(...) in the function receive_char (...).  This patch should fix this
problem and was successfully tested with talking to some kuka industrial
robots.
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This change makes quirk_intel_ide_combined() dependent on the precise
conditions under which it is needed:

* IDE is built in
* IDE SATA option is not set
* ata_piix or ahci drivers are enabled

This fixes an issue where some modular configurations would not cause
the quirk to be enabled.
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
Signed-off-by: NLinus torvalds <torvalds@osdl.org>

During the development of an USB device I found a bug in the handling of
Highspeed HID devices in the kernel.

What happened?

Highspeed HID devices are correctly recognized and enumerated by the
kernel. But even if usbhid kernel module is loaded, no HID reports are
received by the kernel.

The output of the hardware USB analyzer told me that the host doesn't
even poll for interrupt IN transfers (even the "interrupt in" USB
transfer are polled by the host).

After some debugging in hid-core.c I've found the reason.

In case of a highspeed device, the endpoint interval is re-calculated in
driver/usb/input/hid-core.c:

line 1669:
             /* handle potential highspeed HID correctly */
             interval = endpoint->bInterval;
             if (dev->speed == USB_SPEED_HIGH)
                   interval = 1 << (interval - 1);

Basically this calculation is correct (refer to USB 2.0 spec, 9.6.6).
This new calculated value of "interval" is used as input for
usb_fill_int_urb:

line 1685:

            usb_fill_int_urb(hid->urbin, dev, pipe, hid->inbuf, 0,
                   hid_irq_in, hid, interval);

Unfortunately the same calculation as above is done a second time in
usb_fill_int_urb in the file include/linux/usb.h:

line 933:
        if (dev->speed == USB_SPEED_HIGH)
                urb->interval = 1 << (interval - 1);
        else
                urb->interval = interval;

This means, that if the endpoint descriptor (of a high speed device)
specifies e.g. bInterval = 7, the urb->interval gets the value:

hid-core.c: interval = 1 << (7-1) = 0x40 = 64
urb->interval = 1 << (interval -1) = 1 << (63) = integer overflow

Because of this the value of urb->interval is sometimes negative and is
rejected in core/urb.c:
line 353:
                /* too small? */
                if (urb->interval <= 0)
                        return -EINVAL;

The conclusion is, that the recalculaton of the interval (which is
necessary for highspeed) should not be made twice, because this is
simply wrong. ;-)

Re-calculation in usb_fill_int_urb makes more sense, because it is the
most general approach. So it would make sense to remove it from
hid-core.c.

Because in hid-core.c the interval variable is only used for calling
usb_fill_int_urb, it is no problem to remove the highspeed
re-calculation in this file.
Signed-off-by: NChristian Krause <chkr@plauener.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Increased use of scatter-gather by usb-storage driver after 2.6.13 has
exposed a buggy codepath in isp116x-hcd, which was probably never
visited before: bug happened only for those urbs, for which
URB_SHORT_NOT_OK was set AND short transfer occurred.

The fix attached was tested in 2 ways: (a) it fixed failing
initialization of a flash drive with an embedded hub; (b) the fix was
tested with 'usbtest' against a modified g_zero driver (on top of
net2280), which generated short bulk IN transfers of various lengths
including multiples and non-multiples of max_packet_length.
Signed-off-by: NOlav Kongas <ok@artecdesign.ee>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix the fact that the svideo input will only give input in black/white in
some circumstances.  Reason is that in the PCI controller driver (zr36067),
after setting input, we reset norm, which overwrites the input register
with the default.  This patch makes it always set the correct value for the
input when changing norm.
Signed-off-by: NRonald S. Bultje <rbultje@ronald.bitfreak.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix bug #5404 in kernel bugzilla.

It basically updates the vpx3220 initialization tables with some newer
values that we've had in CVS for a while (and that, for some reason, never
ended up in the kernel...  must've gotten lost).  Those fix a ~16 pixels
noise at the top of the picture in at least SECAM, although (now that I
think about it) PAL was probably affected, also.
Signed-off-by: NRonald S. Bultje <rbultje@ronald.bitfreak.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix bug 5441.

I didn't know about messy programs like svgatextmode...  Couldn't this be
integrated in some linux/drivers/video/console/svgacon.c ?...  So because
of the existence of the svgatextmode program, the kernel is not supposed to
touch to CRT_OVERFLOW/SYNC_END/DISP/DISP_END/OFFSET ?

Disabling the check in vgacon_resize() might help indeed, but I'm really
not sure whether it will work for any chipset: in my patch, CRT registers
are set at each console switch, since stty rows/cols apply to consoles
separately...

The attached solution is to keep the test, but if it fails, we assume that
the caller knows what it does (i.e.  it is svgatextmode) and then disable
any further call to vgacon_doresize.  Svgatextmode is usually used to
_expand_ the display, not to shrink it.  And it is harmless in the case of
a too big stty rows/cols: the display will just be cropped.  I tested it on
my laptop, and it works fine with svgatextmode.

A better solution would be that svgatextmode explicitely tells the kernel
not to care about video timing, but for this an interface needs be defined
and svgatextmode be patched.
Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Kernel version 2.6.13 introduced a regression in the generic USB
serial converter driver (usbserial.o, drivers/usb/serial/generic.c).
The bug manifests, as far as I can tell, whenever you attempt to write
to the device -- the write will never complete (write() returns 0, or
blocks).
Signed-off-by: NRandall Nortman <oss@wonderclown.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Argument does not agree.
Signed-off-by: NYoshinori Sato <ysato@users.sourceforge.jp>
Cc: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

drivers/built-in.o: In function `w1_alloc_dev': undefined reference to `netlink_kernel_create'
drivers/built-in.o: In function `w1_alloc_dev': undefined reference to `sock_release'
Signed-off-by: NEvgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

While doing some testing of error cases I ran into this bug.  In some cases
the reset handler can exit with the host_lock still held.
Signed-off-by: NMark Haverkamp <markh@osdl.org>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The aironet PCI driver has a build dependency on ISA that prevent the
driver to compile on systems that doesn't support ISA, like x86_64.  The
driver really doesn't depend on ISA, it does some ISA stuff in the
initialization code, since the driver supports both ISA and PCI cards.  So
the driver should depend on ISA_DMA_API to build on all systems, and this
will not hurt PCI at all.
Signed-off-by: NMatteo Croce <3297627799@wind.it>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This fixes depenencies of collie keyboard.
Signed-off-by: NPavel Machek <pavel@suse.cz>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This fixes wrong comments, non-working debug subsystem, and some
potentially dangerous macros.
Signed-off-by: NPavel Machek <pavel@suse.cz>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This fixes compilation with CPU_FREQ disabled.
Signed-off-by: NPavel Machek <pavel@suse.cz>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

These days, in 2.6.x, even INQUIRY commands are sent using
scatter gather lists.

Bug reported by Tom 'spot' Callaway.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Patch from Richard Purdie

Correct the right shift key entry in the spitz keyboard driver.
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Lothar Wassmann

The function serial_pxa_set_termios() is calling uart_update_timeout()
with the baud rate divisor as third parameter, while
uart_update_timeout() expects the baud rate in this place.
This results in a bogus port->timeout which is proportional to the
baud rate.
Signed-off-by: NLothar Wassmann <LW@KARO-electronics.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Sascha Hauer

handle rts interrupt
Signed-off-by: NGiancarlo Formicuccia <giancarlo.formicuccia@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Ben Dooks

The s3c2410 serial driver is missing static declerations
on several functions that are not exported, and have no
need of being exported outside the driver
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

* bttv-cards.c:
- Enable S-Video input on DViCO FusionHDTV5 Lite
Signed-off-by: NMichael Krufky <mkrufky@m1k.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@brturbo.com.br>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In the current dell_rbu code ver 2.0 the packet update mechanism makes the
user app dump every individual packet in to the driver.

This adds in efficiency as every packet update makes the
/sys/class/firmware/dell_rbu/loading and data files to disappear and reappear
again.  Thus the user app needs to wait for the files to reappear to dump
another packet.  This slows down the packet update tremendously in case of
large number of packets.  I am submitting a new patch for dell_rbu which will
change the way we do packet updates;

In the new method the user app will create a new single file which has already
packetized the rbu image and all the packets are now staged in this file.

This driver also creates a new entry in
/sys/devices/platform/dell_rbu/packet_size ; the user needs to echo the packet
size here before downloading the packet file.

The user should do the following:

 create one single file which has all the packets stacked together.
 echo the packet size in to /sys/devices/platform/dell_rbu/packet_size.
 echo 1 > /sys/class/firmware/dell_rbu/loading
 cat the packetfile > /sys/class/firmware/dell_rbu/data
 echo 0 > /sys/class/firmware/dell_rbu/loading

The driver takes the file which came through /sys/class/firmware/dell_rbu/data
and takes chunks of paket_size data from it and place in contiguous memory.

This makes packet update process very efficient and fast.  As all the packet
update happens in one single operation.  The user can still read back the
downloaded file from /sys/devices/platform/dell_rbu/data.
Signed-off-by: NAbhay Salunke <abhay_salunke@dell.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Search for a disconnect ccw_device on the ccw bus rather than on the css
bus (was a typo in patch I did for the klist conversion).  A cast to an
embedding ccw_device from an embedded device in a struct subchannel will
lead us to oopses.
Signed-off-by: NCornelia Huck <cohuck@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

from me: change from OSL+GPL to GPL (with approval)

from Mark: Gets rid of an unneeded control bit, slightly increasing
throughput.

for certain NICs

Reverting 685fac63:
> [PATCH] e100: CPU cycle saver microcode
>
>
> Add cpu cycle saver microcode to 8086:{1209/1229} other than ICH devices.
>
> Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
> Signed-off-by: Ganesh Venkatesan <ganesh.venkatesan@intel.com>
> Signed-off-by: John Ronciak <john.ronciak@intel.com>
> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

Incorrect uart_write_wakeup() calls cause reference to a
NULL tty pointer in sunsab and sunzilog serial drivers.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

All the same issues - we can't just save the pointer to the thread, we
must save the pid/uid/euid combination.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

If a process issues an URB from userspace and (starts to) terminate
before the URB comes back, we run into the issue described above.  This
is because the urb saves a pointer to "current" when it is posted to the
device, but there's no guarantee that this pointer is still valid
afterwards.

In fact, there are three separate issues:

1) the pointer to "current" can become invalid, since the task could be
   completely gone when the URB completion comes back from the device.

2) Even if the saved task pointer is still pointing to a valid task_struct,
   task_struct->sighand could have gone meanwhile.

3) Even if the process is perfectly fine, permissions may have changed,
   and we can no longer send it a signal.

So what we do instead, is to save the PID and uid's of the process, and
introduce a new kill_proc_info_as_uid() function.
Signed-off-by: NHarald Welte <laforge@gnumonks.org>
[ Fixed up types and added symbol exports ]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Patch from Nicolas Pitre

drivers/mfd/ucb1x00-core.c: In function 'ucb1x00_probe':
drivers/mfd/ucb1x00-core.c:482: error: 'ucb1x00_class' undeclared (first use in this function)
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The logic in ide_do_request() doesn't guarantee that both drives will be
serviced after a call.  It may "forget" to service one in some
circumstances, including when one of the drive is suspended (it will
eventually fail to service the slave when the master is suspended for
example).  This prevents the wakeup requests that gets queued on wakeup
from sleep from beeing serviced in some cases when 2 drives are sharing
an IDE bus.

The problem is deep enough in the way this code works (and there are
probably a few other problematic but rare corner cases) and fixing it
would require some major rethinking of the way IDE decides which channel
to service.  This is not 2.6.14 material.  However, in the meantime,
Bart has accepted this simple workaround that will fix the crash on
wakeup from sleep since this specific corner case is actually hitting
users to get into 2.6.14.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The pccardd thread has a race in it that it can shutdown in the
TASK_INTERRUPTIBLE state.

Make sure we mark ourselves runnable again as we remove ourselves from
the wait queue.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>