Fix the constant used for the base address when it cannot be determined
from ACPI.  It was off by one order of magnitude.
Signed-off-by: NKylene Hall <kjhall@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix the error handling of some LED _store functions.  This corrects them to
return -EINVAL if the value is not numeric with an optional byte of trailing
whitespace.
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The backlight and LCD class _store functions currently accept values like "34
some random strings" without error.  This corrects them to return -EINVAL if
the value is not numeric with an optional byte of trailing whitespace.
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Improve the NEW_LEDS Kconfig information to say what it does as well as what
it doesn't.
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

While debugging why our LCS emulator is having some problems I noticed the
following weirdness in drivers/s390/net/lcs.c routine lcs_irq.  The `if'
statement is always true since SCHN_STAT_PCI is defined as 0x80.

Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

An earlier commit (75cf7456) changed an
overly-zealous PCI quirk to only poke those VIA devices that need it.
However, some PCI devices were not included in what I hope is now the full
list.  Consequently we're failing to run the quirk on all machines which need
it, causing IRQ routing failures.

This should I hope correct this.

Thanks to Masoud Sharbiani <masouds@masoud.ir> for pointing this out
and testing the fix.
Signed-off-by: NChris Wedgwood <cw@f00f.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix some NULL dereferences in the pcmcia code when using old userland
tools.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The TIS driver is dependent upon information from the ACPI table for device
discovery thus it compiles but does no actual work without this dependency.
Signed-off-by: NKylene Hall <kjhall@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

I am having the bug FATAL: Error inserting capi ([..]/capi.ko): Device or
resource busy when I try to reload capi after loading it.  in dmesg:
capi20: unable to get major 68

Fix the issue which is caused by setting the major to zero when registering
the chrdev succeeded.

(akpm: this means that we can again not use `major=0' (dynamic major
allocation) for this driver).

Cc: Karsten Keil <kkeil@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix race condition during destruction calls to avoid possibility of
accessing object after it has been freed.  Instead of waking up a wait
queue directly, which is susceptible to a race where the object is
freed between the reference count going to 0 and the wake_up(), use a
completion to wait in the function doing the freeing.
Signed-off-by: NSean Hefty <sean.hefty@intel.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

The ipath driver's table of PCI IDs needs a { 0, } entry at the end.
This makes all of the device aliases visible to userspace so hotplug
loads the module for all supported devices.  Without the patch,
modinfo ipath_core only shows:

    alias:          pci:v00001FC1d0000000Dsv*sd*bc*sc*i*

instead of the correct:

    alias:          pci:v00001FC1d00000010sv*sd*bc*sc*i*
    alias:          pci:v00001FC1d0000000Dsv*sd*bc*sc*i*
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Signed-off-by: NBryan O'Sullivan <bos@pathscale.com>

Signed-off-by: NMartin Habets <errandir_news@mph.eclipse.co.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Even with fiber cards ethtool reports that the connected port is TP,
the patch fix this.
Signed-off-by: NKarsten Keil <kkeil@suse.de>
Acked-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

I introduced this way back in 2.6.13 when adding the port lock logic.
This device talks out through different "ports" all at the same time, so
the lock logic was wrong, preventing any data from ever being sent
properly.

Thanks a lot to Bernhard Reiter <bernhard@intevation.de> for being
patient and helping with debugging this.

Cc: Bernhard Reiter <bernhard@intevation.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Based on Simon's original driver, with some minor code cleanups and
tidying by me.

Cc: Simon Schulz <simon@auctionant.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If serial_open() fails at the port assignment or mutex_lock_interruptible()
is interrupted, the 'serial' object will never be freed.

We should call kref_put() when those errors happens.
Signed-off-by: NLuiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If the device is disconnected while serial_open() is executing and
either try_module_get() or the device specific open function fails, the
kref_put() call in the 'bailout_kref_put' label will free the memory
pointed out by 'port'.

The subsequent dereferences in the 'bailout_kref_put' label will be
invalid.

The fix is just to assure kref_put() is called after any 'port' usage.
Signed-off-by: NLuiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

It's become apparent as machines get faster that the emagic kernel firmware
loaders (based on the ezusb loader) have a reset race.  a 400MHz TiBook
never tripped it, but a 2GHz Pentium M seems to hit it about 30% of the
time.  The bug is seen as a hung USB box and the kernel error:

drivers/usb/misc/emi62.c: emi62_load_firmware - error loading firmware:
error = -110

The patch below inserts a delay after deasserting reset to allow the box to
settle before a new command is issued.  This affects only device startup.
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

After recent changes, the USB keyboard as shipped with IBM pSeries systems
does not work anymore, unless the keyboard is replugged after reboot.
Adding this model to the blacklist fixes it.
Signed-off-by: NOlaf Hering <olh@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This adds the Sierra Wireless card to airprime.c.

I tested this on my laptop.
Signed-off-by: NKen Brush <ken@cgi101.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Addresses for ioremap must be calculated off of pci_resource_start;
we can't directly use the bus address as seen by the HCA.  Fix the
code that remaps device memory for FMR access.

Based on patch by Klaus Smolin.
Signed-off-by: NMichael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

661FX7MI-S motherboard which uses the SiS 661FX chipset.  The patch adds
an entry to mii_chip_info for the transceiver.

The PHY ids were found using the sis900_c_122.diff patch from
http://brownhat.org/sis900.html but that patch didn't solve the problem,
because the PHY at address 1 was already being chosen.

Without my patch, when bursts of packets arrive from other hosts on a
LAN, the interface dropped one roughly 10% of the time, causing
retransmits.  There were fifth second pauses in refresh of large xterms,
and it made Netrek suck.  I can provide further test data.

Workaround in lieu of patch is to use mii-tool to advertise
100baseTx-HD, then force renegotiation.

I wasn't able to identify the actual transceiver, so the description
field is a guess.

This patch is similar to Artur Skawina's patch:
http://marc.theaimsgroup.com/?l=linux-netdev&m=114297516729079&w=2

I'm not sure, but I wonder if it means the default behaviour should be
changed, so as to better handle future transceivers.

Diff is against 2.6.16.13.
Signed-off-by: NJames Cameron <james.cameron@hp.com>
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>

Typo will be harder with this one.
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>

make sure phy_map entries whose PHY address is masked are initialized
to NULL, given that other code (such as mdiobus_unregister for
instance) assumes that non-NULL phy_map entries are allocated
phy_devices
Signed-off-by: NHerbert Valerio Riedel <hvr@gnu.org>
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>

Bringing down a port also masks off the status and other IRQ's
needed for device to function due to missing paren's.
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>

This patch corrects the order of the calls to register_chrdev() and
pcmcia_register_driver().  Now udev correctly creates userspace device
files /dev/cmmN and /dev/cmxN respectively.

Based on an earlier patch by Jan Niehusmann <jan@gondor.com>.
Signed-off-by: NHarald Welte <laforge@netfilter.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

A race condition exists in mptfc between the thread registering a device
with the fc transport and the scan work generated by the transport.
This race existed prior to the application of the mptfc bug fix patch.

mptfc_register_dev() calls fc_remote_port_add() with the FC_RPORT_ROLE_TARGET
bit set in the rport ids passed to the function.  Having this bit set causes
fc_remote_port_add() to schedule a scan of the device.

This scan can execute before mptfc_register_dev() can fill in the dd_data
in the rport structure.  When this happens, mptfc_target_alloc() will fail
because dd_data is null.

Attached is a patch which fixes the problem.  The patch changes the rport ids
passed to fc_remote_port_add() to not have the TARGET bit set.  This prevents
the scan from being scheduled.  After mptfc_register_dev() fills in the rport
dd_data field, fc_remote_port_rolechg() is called, changing the role of the
rport to TARGET.  Thus, the scan is scheduled after dd_data is filled
in which prevents the failure in mptfc_target_alloc().
Signed-off-by: NMichael Reed <mdr@sgi.com>
Signed-off-by: NEric Moore <Eric.Moore@lsil.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

tg3_run_loopback doesn't check that dev_alloc_skb() returns anything
useful.

Even if dev_alloc_skb() fails to return an skb to us we'll happily go
on and assume it did, so we risk dereferencing a NULL pointer.  Much
better to fail gracefully by returning -ENOMEM than crashing here.
Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When deleting a child interface with a non-default P_Key via
/sys/class/net/ibX/delete_child, the interface must be freed with
free_netdev() (rather than kfree() on the private data).
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

Since sir_kthread.c pretty much duplicates the workqueue
functionality, we'd better switch.  The SIR fsm has been merged into
sir_dev.c and thus sir_kthread.c is deleted.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NSamuel Ortiz <samuel.ortiz@nokia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Minimal PNP hotplug support for the smsc-ircc2 driver.  A modular
driver will be modprobed via hotplug, but still bypasses driver model
probing.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NSamuel Ortiz <samuel.ortiz@nokia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is a fix for the CS5535 errata 111:

When the SMBus controller tries to access a non-existing device, it sets
the NEGACK bit, SMBus I/O offset 01h[4], to 1 after it detects no
acknowledge at the ninth clock.  The specification states that the bit
can be cleared by writing a 1 to it, but under certain circumstances it
is possible for this bit to not clear.

Writing a 0 to the bit resets the internal state machine and clears the
issue.

Since all writable bits in ACBST are W1C bits (write-one-to-clear) the
second write doesn't affect any other logic except the buggy NEGACK
state machine. The second write clears an internal register which is
responsible for "overwriting" the NEGACK bit in ACBST.
Signed-off-by: NJordan Crouse <jordan.crouse@amd.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We can't pass a string on the stack to request_region. As soon as we
leave the function that stack is gone and the string is lost. Let's
use the same string we identify the i2c_adapter with instead, it's
more simple, more consistent, and just works.

This is the second half of fix to bug #6445.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The scx200_acb driver shouldn't return failure after initialization
if it successfully registered at least one i2c_adapter, else we are
leaking resources. The driver was OK in that respect up to 2.6.16, a
recent change broke it.

This is part of the fix to bug #6445.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Ben Gardner <bgardner@wabtec.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix races in in destroying various objects.  If a destroy routine
waits for an object to become free by doing

	wait_event(&obj->wait, !atomic_read(&obj->refcount));
	/* now clean up and destroy the object */

and another place drops a reference to the object by doing

	if (atomic_dec_and_test(&obj->refcount))
		wake_up(&obj->wait);

then this is susceptible to a race where the wait_event() and final
freeing of the object occur between the atomic_dec_and_test() and the
wake_up().  And this is a use-after-free, since wake_up() will be
called on part of the already-freed object.

Fix this in mthca by replacing the atomic_t refcounts with plain old
integers protected by a spinlock.  This makes it possible to do the
decrement of the reference count and the wake_up() so that it appears
as a single atomic operation to the code waiting on the wait queue.

While touching this code, also simplify mthca_cq_clean(): the CQ being
cleaned cannot go away, because it still has a QP attached to it.  So
there's no reason to be paranoid and look up the CQ by number; it's
perfectly safe to use the pointer that the callers already have.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

If a SCSI abort completes, or the command completes successfully, then
the driver must remove the command from its queue of pending
commands.  Similarly, if a device reset succeeds, then all commands
queued for the given device must be removed from the queue.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

The code to display local_link_integrity_errors and
excessive_buffer_overrun_errors in
/sys/class/infiniband/<hca>/ports/<n>/counters/
uses the wrong shift to extract the 4 bit values.
Signed-off-by: NRalph Campbell <ralph.campbell@qlogic.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

Signed-off-by: NRazvan Gavril <razvan.g@plutohome.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch adds support for ACG Identification Technologies GmbH's HF
Dual ISO Reader (an RFID tag reader) to the ftdi_sio driver's device ID
table.  The product ID was supplied by anotonios (anton at goto10 dot
org) on the ftdi-usb-sio-devel list and subsequently verified by myself
(Ian Abbott).
Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In kernel 2.6.16, if a mounted storage device is removed, an oops happens
because ub supplies an interface device (and kobject) to the block layer,
but neglects to pin it. And apparently, the block layer expects its users
to pin device structures.

The code in ub was broken this way for years. But the bug was exposed only
by 2.6.16 when it started to call block_uevent on close, which traverses
device structures (kobjects actually).
Signed-off-by: NPete Zaitcev <zaitcev@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>