A "coldplug + udevstart" can be simple like this:
  for i in /sys/block/*/*/uevent; do echo 1 > $i; done
  for i in /sys/class/*/*/uevent; do echo 1 > $i; done
  for i in /sys/bus/*/devices/*/uevent; do echo 1 > $i; done
Signed-off-by: NKay Sievers <kay.sievers@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Driver core: pass interface to class intreface methods

Pass interface as argument to add() and remove() class interface
methods. This way a subsystem can implement generic add/remove
handlers and then call interface-specific ones.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

I2O: cleanup - remove i2o_device_class

I2O devices reside on their own bus so there should be no reason
to also have i2c_device class that mirros i2o bus.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

I2O: remove i2o_device_class_interface misuse

The intent of class interfaces was to provide different
'views' at the same object, not just run some code every
time a new class device is registered. Kill interface
structure, make class core register default attributes
and set up sysfs links right when registering class
devices.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Move call to kobject_hotplug() above code that adds interfaces
to a class device, otherwise children's hotplug events may reach
userspace first.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch teaches "usb_device" about the new driver model wakeup support:

 - It updates device wakeup capabilities when entering a configuration
   with the WAKEUP attribute;

 - During suspend processing it consults the policy bit to see
   whether it should enable wakeup for that device.  (This resolves
   a FIXME to not assume the answer is always "yes"; some devices
   lie about supporting remote wakeup.)

Support for root hubs and the HCDs is separate (and more complex).
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This is a refresh of an earlier patch to add "wakeup" support to the
PM core model.  This provides per-device bus-neutral control of the
use of wakeup events.

  * "struct device_pm_info" has two bits that are initialized as
    part of setting up the enclosing struct device:
      - "can_wakeup", reflecting hardware capabilities
      - "may_wakeup", the policy setting (when CONFIG_PM)

  * There's a writeable sysfs "wakeup" file, with one of two values:
      - "enabled", when the policy is to allow wakeup
      - "disabled", when the policy is not to allow it
      - "" if the device can't currently issue wakeups

By default, wakeup is enabled on all devices that support it.  If its
driver doesn't support it ... treat it as a bug.  :)
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

I was recently given an old Travan tape drive and asked to do something
useful with it.  The ide-scsi + st (+serverworks ide controller) combo
results in a hard lockup of the machine which I have not had the energy to
debug, so I turned to ide-tape (which seems to work).  The system in
question debian stable, using udev to manage /dev.

The following patch to ide-tape.c allows udev to create the cdev nodes for
my drive.

Cc: Gadi Oxman <gadio@netvision.net.il>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: N"Ed L. Cashin" <ecashin@coraid.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Update driver version number to 14.

Signed-off-by: N"Ed L. Cashin" <ecashin@coraid.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use get_unaligned for possibly-unaligned multi-byte accesses to the
ATA device identify response buffer.

Don't try to access not-present CPUs.  Conservative governor will always
oops on SMP without this fix.

Fixes http://bugzilla.kernel.org/show_bug.cgi?id=4781Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NDave Jones <davej@redhat.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

I've seen similar failure on alpha.

Obviously, someone forgot to convert sg->handle stuff for
PCI gart case.
Signed-off-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

There are still a couple of cases where md threads (the resync/recovery
thread) is not interruptible since the change to use kthreads.  All places
there it tests "signal_pending", it should also test kthread_should_stop,
as with this patch.
Signed-off-by: NNeil Brown <neilb@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When reserving an PCI quirk, note that in the kernel bootup messages.

Also, parse the strange PIIX4 device resources - they should get their
own PCI resource quirks, but for now just print out what it finds to
verify that the code does the right thing.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

If qla2x00_probe_one()'s call to qla2x00_iospace_config() fails, we call
qla2x00_free_device() to clean up.  But because ha->dpc_pid hasn't been set
yet, qla2x00_free_device() tries to stop a kernel thread which hasn't started
yet.  It does wait_for_completion() against an uninitialised completion struct
and the kernel hangs up.

Fix it by initialising ha->dpc_pid a bit earlier.

Cc: Andrew Vasquez <andrew.vasquez@qlogic.com>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add the new ID 0x132a and configure the new PCI Diva console port.  This
device supports only 1 single console UART.
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Tested by Wolfgang Denk with this device:

    00:0f.0 Network controller: PLX Technology, Inc. PCI <-> IOBus Bridge (rev 01)
        Subsystem: Exsys EX-4055 4S(16C550) RS-232
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at 80100000 (32-bit, non-prefetchable) [size=128]
        Region 1: I/O ports at 7080 [size=128]
        Region 2: I/O ports at 7400 [size=32]

    00:0f.0 Class 0280: 10b5:9050 (rev 01)
        Subsystem: d84d:4055

Results with this patch:

    Serial: 8250/16550 driver $Revision: 1.90 $ 32 ports, IRQ sharing enabled
    ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
    PCI: Found IRQ 10 for device 0000:00:0f.0
    ttyS4 at I/O 0x7400 (irq = 10) is a 16550A
    ttyS5 at I/O 0x7408 (irq = 10) is a 16550A
    ttyS6 at I/O 0x7410 (irq = 10) is a 16550A
    ttyS7 at I/O 0x7418 (irq = 10) is a 16550A
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This small patch returns the stride/line length of the framebuffer via
sysfs.
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We should always re-arm an event queue's interrupt in
mthca_tavor_interrupt() if the corresponding bit is set in the event cause
register (ECR), even if we didn't find any entries in the EQ.  If we don't,
then there's a window where we miss an EQ entry and then get stuck because
we don't get another EQ event.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

On 2005-05-01, Gerd Knorr sent in a patch to add cx22702 to cx88-dvb:

 [PATCH] dvb: cx22702 frontend driver update
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9990d744bea7d28e83c420e2c9d524c7a8a2d136

...but as we can see, the Kconfig portion of his patch was incorrectly
applied to saa7134-dvb instead of cx88-dvb.

On 2005-06-24, Adrian bunk fixed cx88-dvb:

 [PATCH] VIDEO_CX88_DVB must select DVB_CX22702
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d6988588e13616587aa879c2e0bd7cd811705e5d

...but we never removed the original patch from Gerd.

This patch sets things straight:

saa7134-dvb should not select cx22702
Signed-off-by: NMichael Krufky <mkrufky@m1k.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

That's what we've always historically done, and bigger windows seem to
confuse some cardbus bridges. Or something.

Alan reports that this makes the ThinkPad 600x series work properly
again: the 4kB IO window for some reason made IDE DMA not work, which
makes IDE painfully slow even if it works after DMA timeouts.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The wrong state emission routines were being called for G550, and
consistent maps weren't correctly mapped...
Signed-off-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This fixes handling of the phy identifiers in mptsas.
Signed-off-by: NEric Moore <Eric.Moore@lsil.com>
[ split it a pre-2.6.14 portion from Eric's bigger patch ]
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Found in the -rt patch set.  The scsi_error thread likely will be in the
TASK_INTERRUPTIBLE state upon exit.  This patch fixes this bug.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In drivers/acpi/glue.c the address of an integer is cast to the address of
an unsigned long.  This breaks on systems where a long is larger than an
int --- for a start the int can be misaligned; for a second the assignment
through the pointer will overwrite part of the next variable.
Signed-off-by: NPeter Chubb <peterc@gelato.unsw.edu.au>
Acked-by: N"Brown, Len" <len.brown@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

I've gotten a report on lkml, of a possible regression in the MGA DRM in
2.6.14-rc4 (since -rc1), I haven't been able to reproduce it here, but I've
figured out some possible issues in the mga code that were definitely
wrong, some of these are from DRM CVS, the main fix is the agp enable bit
on the old code path still used by everyone.....
Signed-off-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The main problem fixes is that in certain situations stopping md arrays may
take longer than you expect, or may require multiple attempts.  This would
only happen when resync/recovery is happening.

This patch fixes three vaguely related bugs.

1/ The recent change to use kthreads got the setting of the
   process name wrong.  This fixes it.
2/ The recent change to use kthreads lost the ability for
   md threads to be signalled with SIG_KILL.  This restores that.
3/ There is a long standing bug in that if:
    - An array needs recovery (onto a hot-spare) and
    - The recovery is being blocked because some other array being
       recovered shares a physical device and
    - The recovery thread is killed with SIG_KILL
   Then the recovery will appear to have completed with no IO being
   done, which can cause data corruption.
   This patch makes sure that incomplete recovery will be treated as
   incomplete.

Note that any kernel affected by bug 2 will not suffer the problem of bug
3, as the signal can never be delivered.  Thus the current 2.6.14-rc
kernels are not susceptible to data corruption.  Note also that if arrays
are shutdown (with "mdadm -S" or "raidstop") then the problem doesn't
occur.  It only happens if a SIGKILL is independently delivered as done by
'init' when shutting down.
Signed-off-by: NNeil Brown <neilb@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Changes all spinlocks that can be held during an irq handler to disable
interrupts while the lock is held.  Changes spin_[un]lock_irq to use the
irqsave/irqrestore variants for robustness and readability.

In raw1394.c:handle_iso_listen(), don't grab host_info_lock at all -- we're
not accessing host_info_list or host_count, and holding this lock while
trying to tasklet_kill the iso tasklet this can cause an ABBA deadlock if
ohci:dma_rcv_tasklet is running and tries to grab host_info_lock in
raw1394.c:receive_iso.  Test program attached reliably deadlocks all SMP
machines I have been able to test without this patch.
Signed-off-by: NAndy Wingo <wingo@pobox.com>
Acked-by: NBen Collins <bcollins@ubuntu.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Brice Goglin <Brice.Goglin@ens-lyon.org> reports a printk storm from this
driver.  Fix.
Acked-by: NDavid Gibson <hermes@gibson.dropbear.id.au>
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Found in the -rt patch set.  The scsi_error thread likely will be in the
TASK_INTERRUPTIBLE state upon exit.  This patch fixes this bug.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Reported by: Bob Tracy <rct@gherkin.frus.com>

 "...I've got a Toshiba notebook (730XCDT -- Pentium 150MMX) for which
  I'm using the Vesa FB driver.  When the machine has been idle for some
  time and the driver attempts to powerdown the display, rather than the
  display going blank, it goes gray with several strange lines.  When I
  hit the "shift" key or other-wise wake up the display, the old video
  state is not fully restored..."

vesafb recently added a blank method which has only 2 states, powerup and
powerdown.  The powerdown state is used for all blanking levels, but in his
case, powerdown does not work correctly for higher levels of display
powersaving. Thus, for intermediate power levels, use software blanking,
and use only hardware blanking for an explicit powerdown.
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This still leaves driver and architecture-specific subdirectories alone,
but gets rid of the bulk of the "generic" generated files that we should
ignore.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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>

This patch from Eric fixes handling of the phy identifiers in mptsas.
I've split it up from his bigger patch as it should go into 2.6.14
still.
Signed-off-by: NEric Moore <Eric.Moore@lsil.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>