Fix stale references to source files in kernel-parameters.txt.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Update the delay accounting and taskstats maintainer to Balbir Singh.
I spoke to Shailabh and he is now busy with other things.
Cc: Shailabh Nagar <nagar1234@in.ibm.com>
Cc: Shailabh Nagar <nagar@watson.ibm.com>
Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix regression in cciss driver that if no logical drives are configured,
no device nodes at all get created.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cca.cpqcorp.net>
Acked-by: Mike Miller <mike.miller@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch fixes following build error when CONFIG_PM is set.
CC drivers/video/fsl-diu-fb.o
drivers/video/fsl-diu-fb.c: In function 'fsl_diu_suspend':
drivers/video/fsl-diu-fb.c:1327: error: 'ofdev' undeclared (first use in this function)
drivers/video/fsl-diu-fb.c:1327: error: (Each undeclared identifier is reported only once
drivers/video/fsl-diu-fb.c:1327: error: for each function it appears in.)
drivers/video/fsl-diu-fb.c: In function 'fsl_diu_resume':
drivers/video/fsl-diu-fb.c:1337: error: 'ofdev' undeclared (first use in this function)
While I'm at it, also fix this warning:
drivers/video/fsl-diu-fb.c: In function 'fsl_diu_alloc':
drivers/video/fsl-diu-fb.c:314: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'phys_addr_t'
And these section mismatches:
..from the function fsl_diu_remove() to the function .exit.text:uninstall_fb()
..from the function fsl_diu_remove() to the function .exit.text:uninstall_fb()
..from the function install_fb() to the variable .devinit.data:fsl_diu_mode_db
..from the function install_fb() to the variable .devinit.data:fsl_diu_mode_db
..from the function fsl_diu_probe() to the function .exit.text:uninstall_fb()
..from the function fsl_diu_probe() to the function .exit.text:uninstall_fb()
Also, some sparse fixes: make two functions static, and use NULL where
appropriate. There are still a lot of sparse warnings, mainly wrt absence
of __iomem annotations, but some will require ugly __force stuff. I'll leave
them for now, since proper fix would be not that trivial as few one-liners
below.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Timur Tabi <timur@freescale.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: York Sun <yorksun@freescale.com>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The pca953x driver can handle another 8-bit I/O expander, the max7310.
This patch adds that chip to the list of supported IDs in that driver, and
expands the Kconfig helptext accordingly.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 95b570c9ce ("Taint kernel after
WARN_ON(condition)") introduced a TAINT_WARN that was implemented for
all architectures using the generic warn_on_slowpath(), which excluded
any architecture that set HAVE_ARCH_WARN_ON.
As all of the architectures that implement their own WARN_ON() all go
through the report_bug() path (specifically handling BUG_TRAP_TYPE_WARN),
taint the kernel there as well for consistency.
Tested on avr32 and sh. Also relevant for s390, parisc, and powerpc.
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Acked-by: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The misc_mtx should provide all the protection required to keep the daemon
hash table sane during miscdev registration. Since this mutex is causing
gratuitous lockdep warnings, this patch removes it.
Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>
Reported-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When write in reiserfs_quota_write() fails, we have to properly release
i_mutex. One error path has been missing the unlock...
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When write in ext4_quota_write() fails, we have to properly release
i_mutex. One error path has been missing the unlock...
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When write in ext3_quota_write() fails, we have to properly release
i_mutex. One error path has been missing the unlock...
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It seems VT3336 can't do msi either as with its bro 3351. Disable it.
Reported in the following SUSE bug.
https://bugzilla.novell.com/show_bug.cgi?id=300001
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When writing /proc/acpi/alarm in adjust mode, e.g.
echo "+0000-00-00 00:00:15" >/proc/acpi/alarm
The "century" field should be read and added to "year" field before
writing, otherwise the CMOS time will go back to 2000 years ago, e.g.
# cat /proc/acpi/alarm
0008-06-21 11:38:46
Then the system time may be reset to the date of manufacture after
rebooting. This patch fixed this issue.
Signed-off-by: Huacai Chen <huacai.chen@intel.com>
Acked-by: Pavel Machek <pavel@suse.cz>
Acked-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Acked-by: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I have discovered that the current version of rtc-x1205.c does not work
correctly when asked to set the alarm time by the RTC_WKALM_SET ioctl()
call. This happens because the alarm registers do not behave like the
current-time registers. They are non-volatile. Two things go wrong:
- the X1205 requires a 10 msec delay after any attempt to write to the
non-volatile registers. The x1205_set_datetime() routine does the write
as 8 single-byte writes without any delay. Only the first write
succeeds. The second is NAKed because the chip is busy.
- the X1205 resets the RWEL bit after any write to the non-volatile
registers. This would lock out any further writes after the first even
with a 10msec delay.
I fix this by doing a single 8-byte write and then waiting 10msec for the
chip to be ready. A side effect of this change is that it will speed up
x1205_rtc_set_time() which uses the same code.
I have also implemented the 'enable' bit in the rtc_wkalm structure, which
the existing driver does not attempt to do. I have modified both
x1205_rtc_set_alarm() to set the AL0E bit, and x1205_rtc_read_alarm() to
return it.
I have tested this patch on a LinkSys NSLU2 under OpenWRT, but on no other
hardware. On the NSLU2 the X1205 correctly asserts its IRQ pin when the
alarm time matches the current time.
[akpm@linux-foundation.org: clean up over-parenthesisation]
Signed-off-by: Michael Hamel <mhamel@adi.co.nz>
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
get_user_pages() must not return the error when i != 0. When pages !=
NULL we have i get_page()'ed pages.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Acked-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As reported by Vipul Gandhi, the current serial_match_port() doesn't work
for tty-devices using dynamic major number allocation. Fix it.
It oopses if you suspend a serial port with _dynamic_ major number. ATM,
I think, there's only the drivers/serial/jsm/jsm_driver.c driver, that
does it in-tree.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Tested-by: Vipul Gandhi <vcgandhi1@aol.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> the build (.config attached) failed, make ends with :
> ...
> UPD include/linux/compile.h
> CC init/version.o
> LD init/built-in.o
> LD vmlinux
> drivers/built-in.o: In function `sas_request_addr':
> (.text+0x33bab): undefined reference to `request_firmware'
> drivers/built-in.o: In function `sas_request_addr':
> (.text+0x33c3f): undefined reference to `release_firmware'
> make: *** [vmlinux] Error 1
There's a slight fault in the stub logic. It fails for FW_LOADER=m and
the user =y.
This should fix it.
This patch fixes the following 2.6.26-rc regression:
http://bugzilla.kernel.org/show_bug.cgi?id=10730
Reviewed-by: Toralf Foerster <toralf.foerster@gmx.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
While 0e36a9a4a7 ("rtc: fix readback from
/sys/class/rtc/rtc?/wakealarm") made sure that active alarms were never
returned with invalid "wildcard" fields (negative), it can still report
(wrongly) that the alarm triggers in the past.
Example, if it's now 10am, an alarm firing at 5am will be triggered
TOMORROW not today. (Which may also be next month or next year...)
This updates that alarm handling in three ways:
* Handle alarm rollover in the common cases of RTCs that don't
support matching on all date fields.
* Skip the invalid-field logic when it's not needed.
* Minor bugfix ... tm_isdst should be ignored, it's one of the
fields Linux doesn't maintain.
A warning is emitted for some of the unhandled rollover cases, but the
possible combinations are a bit too numerous to handle every bit of
potential hardware and firmware braindamage.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Mark Lord <lkml@rtr.ca>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dirty page accounting accurately measures the amound of dirty pages in
writable shared mappings by mapping the pages RO (as indicated by
vma_wants_writenotify). We then trap on first write and call
set_page_dirty() on the page, after which we map the page RW and
continue execution.
When we launder dirty pages, we call clear_page_dirty_for_io() which
clears both the dirty flag, and maps the page RO again before we start
writeout so that the story can repeat itself.
vma_wants_writenotify() excludes VM_PFNMAP on the basis that we cannot
do the regular dirty page stuff on raw PFNs and the memory isn't going
anywhere anyway.
The recently introduced VM_MIXEDMAP mixes both !pfn_valid() and
pfn_valid() pages in a single mapping.
We can't do dirty page accounting on !pfn_valid() pages as stated
above, and mapping them RO causes them to be COW'ed on write, which
breaks VM_SHARED semantics.
Excluding VM_MIXEDMAP in vma_wants_writenotify() would mean we don't do
the regular dirty page accounting for the pfn_valid() pages, which
would bring back all the head-aches from inaccurate dirty page
accounting.
So instead, we let the !pfn_valid() pages get mapped RO, but fix them
up unconditionally in the fault path.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Acked-by: Hugh Dickins <hugh@veritas.com>
Cc: "Jared Hulbert" <jaredeh@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove all clameter@sgi.com addresses from the kernel tree since they will
become invalid on June 27th. Change my maintainer email address for the
slab allocators to cl@linux-foundation.org (which will be the new email
address for the future).
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
sata_mv: safer logic for limit_warnings
libata-sff: improve HSM violation reporting
ahci: always clear all bits in irq_stat
sata_sil24: add DID for another adaptec flavor
sata_uli: hardreset is broken
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6:
slub: Do not use 192 byte sized cache if minimum alignment is 128 byte
This updates the MAINTAINERS entries for powerpc. It adds Ben H to
the overall Linux for PowerPC entry and makes it clear this covers
both 32-bit and 64-bit machines. It removes the separate entry we had
for Linux on 64-bit PowerPC where Anton and I were listed as
maintainers - Anton hasn't been involved in the day-to-day maintenance
of the code for several years. Finally, it removes the entry for the
Linux for PowerPC boot code where Tom Rini was listed as the
maintainer. That code got completely rewritten when we merged
32-bit and 64-bit, and I and the various platform maintainers have
been maintaining that code since.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Acked-by: Tom Rini <trini@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There is a miniscule chance that two separate host controllers
might be in sata_mv at the same time and manage to decrement
the static limit_warnings variable below zero.
Fix the comparison to deal with it.
Signed-off-by: Mark Lord <mlord@pobox.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Improve SFF HSM violation reporting such that each HSM violation can
be distinguished using ehi_desc.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Some AHCI controllers (ICH7 was reported) set pending bit in
HOST_IRQ_STAT for non-existent ports and when it's not cleared falls
into IRQ storm. Always clear full irq_stat instead of only the bits
that are handled. As nothing changes for recognized ports, the risk
of breaking things is pretty low.
Reported and verified by Philipp Thomas in the following suse
bugzilla.
https://bugzilla.novell.com/attachment.cgi?id=215692
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Philipp Thomas <pth@novell.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
There's another DID used for Adaptec card. Add it.
Reported by Travis Read.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Travis Read <ics@dark.net.au>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
The restart() function is called when the link state changes and resets
multicast and promiscuous settings. This patch restores those settings at the
end of restart().
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Short packets has to be discarded by the driver. So this patch addresses the
issue of discarding the short packets of size lesser then ethernet header
size.
Signed-off-by: Sathya Narayanan <sathyan@teamf1.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
The descriptor pointers were not initialized to NIL values, so it was
poiniting to some random addresses which was completely invalid. This
fix takes care of initializing the descriptor to NIL values and clearing
the valid descriptors on clean ring operation.
Signed-off-by: Sathya Narayanan <sathyan@teamf1.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
iph->tot_len is stored in network byte order, so access it using
ntohs(). This doesn't have any real world impact on pasemi_mac, since
the device only exists as part of a big-endian system-on-chip, but
fixing this gets rid of a sparse warning and avoids having a bad example
in the tree.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
iph->tot_len is stored in network byte order, so access it using
ntohs(). This doesn't have any real world impact on ehea, since ehea
only exists for big-endian platfroms (at the moment at least) but fixing
this gets rid of a sparse warning and avoids having a bad example in the
tree.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
When ehea_stop is called the function
cancel_work_sync(&port->reset_task) is used to ensure
that the reset task is not running anymore. We need an
additional flag to ensure that it can not be scheduled
after this call again for a certain time.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Required to allow distros to easily detect when ehea
module needs to be loaded
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
A mutex has to be replaced by spinlocks as it can be called from
a context which does not allow sleeping.
The kzalloc flag GFP_KERNEL has to be replaced by GFP_ATOMIC
for the same reason.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
After enabling CONFIG_LOCKDEP and CONFIG_PROVE_LOCKING I get the
following warning when ethtool -s is first called on one of the
forcedeth ports:
=================================
[ INFO: inconsistent lock state ]
2.6.26-rc4 #28
---------------------------------
inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
ethtool/1985 [HC0[0]:SC0[1]:HE1:SE0] takes:
(&np->lock){++..}, at: [<ffffffffa000c5fd>] nv_set_settings+0xc8/0x3de [forcedeth]
{in-hardirq-W} state was registered at:
[<ffffffffffffffff>] 0xffffffffffffffff
irq event stamp: 3606
hardirqs last enabled at (3605): [<ffffffff8068106f>] _spin_unlock_irqrestore+0x3f/0x68
hardirqs last disabled at (3604): [<ffffffff80680d38>] _spin_lock_irqsave+0x13/0x46
softirqs last enabled at (3534): [<ffffffff80246ba5>] __do_softirq+0xbc/0xc5
softirqs last disabled at (3606): [<ffffffff80680b33>] _spin_lock_bh+0x11/0x41
other info that might help us debug this:
2 locks held by ethtool/1985:
#0: (rtnl_mutex){--..}, at: [<ffffffff80596072>] rtnl_lock+0x12/0x14
#1: (_xmit_ETHER){-+..}, at: [<ffffffffa000c5e8>] nv_set_settings+0xb3/0x3de [forcedeth]
stack backtrace:
Pid: 1985, comm: ethtool Not tainted 2.6.26-rc4 #28
Call Trace:
[<ffffffff8025f190>] print_usage_bug+0x162/0x173
[<ffffffff8025fa8b>] mark_lock+0x231/0x41f
[<ffffffff802607cf>] __lock_acquire+0x4e7/0xcac
[<ffffffff8025fe64>] ? trace_hardirqs_on+0xf1/0x115
[<ffffffff80272c3a>] ? disable_irq_nosync+0x6f/0x7b
[<ffffffff80261375>] lock_acquire+0x55/0x6e
[<ffffffffa000c5fd>] ? :forcedeth:nv_set_settings+0xc8/0x3de
[<ffffffff80680b15>] _spin_lock+0x2f/0x3c
[<ffffffffa000c5fd>] :forcedeth:nv_set_settings+0xc8/0x3de
[<ffffffff8058f8bb>] dev_ethtool+0x186/0xea3
[<ffffffff8067f446>] ? mutex_lock_nested+0x243/0x275
[<ffffffff8025df2b>] ? debug_mutex_free_waiter+0x46/0x4a
[<ffffffff8067f469>] ? mutex_lock_nested+0x266/0x275
[<ffffffff8058e1ce>] dev_ioctl+0x4eb/0x600
[<ffffffff8068106f>] ? _spin_unlock_irqrestore+0x3f/0x68
[<ffffffff80580f91>] sock_ioctl+0x1f5/0x202
[<ffffffff802a322e>] vfs_ioctl+0x2a/0x77
[<ffffffff802a34d6>] do_vfs_ioctl+0x25b/0x270
[<ffffffff806807b6>] ? trace_hardirqs_on_thunk+0x35/0x3a
[<ffffffff802a352d>] sys_ioctl+0x42/0x65
[<ffffffff8021fffb>] system_call_after_swapgs+0x7b/0x80
This is caused by the following snippet in nv_set_settings:
netif_carrier_off(dev);
if (netif_running(dev)) {
nv_disable_irq(dev);
netif_tx_lock_bh(dev);
spin_lock(&np->lock);
/* stop engines */
nv_stop_rxtx(dev);
spin_unlock(&np->lock);
netif_tx_unlock_bh(dev);
}
Because of nv_disable_irq this is probably not really a problem
though (I guess) and replacing the spin_lock with spin_lock_irqsave
could keep interrupts disabled for a longer period of time because
of delays in nv_stop_rx and nv_stop_tx.
Signed-off-by: Tobias Diedrich <ranma+kernel@tdiedrich.de>
Cc: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Commit 4c13eb6657 ([ETH]: Make
eth_type_trans set skb->dev like the other *_type_trans) removed
skb->dev assignment from hdlc_fr.c:fr_rx(). Unfortunately it was also
needed for cases other than eth_type_trans().
Adding it back.
It's quite serious and may be a security risk as it causes a wrong
input interface indication (the physical hdlcX instead of logical
pvcX). Probably -stable class fix.
Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
When converting the page number in a pte/pmd/pud/pgd between
machine and pseudo-physical addresses, the converted result was
being truncated at 32-bits. This caused failures on machines
with more than 4G of physical memory.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: "Christopher S. Aker" <caker@theshore.net>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The branch optimization fixes in 2.6.21 introduced a bug in
atomic_sub_if_positive that causes it to return even when the sc
instruction fails. The result is that e.g. down_trylock becomes unreliable
as the semaphore counter is not always decremented.
Original MUA-shredded patch from Morten Larsen <mlarsen@broadcom.com>.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
USB: adding comment for ipaq forcing number of ports
USB: fix Oops on loading ipaq module since 2.6.26
USB: add a pl2303 device id
USB: another option device id
USB: don't lose disconnections during suspend
USB: fix interrupt disabling for HCDs with shared interrupt handlers
USB: New device ID for ftdi_sio driver
sisusbvga: Fix oops on disconnect.
USB: mass storage: new id for US_SC_CYP_ATACB
USB: ohci - record data toggle after unlink
USB: ehci - fix timer regression
USB: fix cdc-acm resume()
OHCI: Fix problem if SM501 and another platform driver is selected
The reason for forcing a number of ports should be documented.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thanks to umesh b <umesh.kollam@gmail.com> for the information here.
Cc: umesh b <umesh.kollam@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1111) fixes a bug in the hub driver. When a hub
resumes, disconnections that occurred while the hub was suspended are
lost.
A completely different fix for this problem has already been accepted
for 2.6.27; however the problem still needs to be handled in 2.6.26.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: fix interrupt disabling for HCDs with shared interrupt handlers
As has been discussed several times on LKML, IRQF_SHARED | IRQF_DISABLED
doesn't work reliably, i.e. a shared interrupt handler CAN'T be certain to
be called with interrupts disabled. Most USB HCD handlers use IRQF_DISABLED
and therefore havoc can break out if they share their interrupt with a
handler that doesn't use it.
On my test machine the yenta_socket interrupt handler (no IRQF_DISABLED)
was registered before ehci_hcd and one uhci_hcd instance. Therefore all
usb_hcd_irq() invocations for ehci_hcd and for one uhci_hcd instance
happened with interrupts enabled. That led to random lockups as USB core
HCD functions that acquire the same spinlock could be called twice
from interrupt handlers.
This patch updates usb_hcd_irq() to always disable/restore interrupts.
usb_add_hcd() will silently remove any IRQF_DISABLED requested from HCD code.
Signed-off-by: Stefan Becker <stefan.becker@nokia.com>
Cc: stable <stable@kernel.org>
Acked-by: David Brownell <david-b@pacbell.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Here's a new device ID for the ftdio_sio driver.
The diff is with linus's tree as of this morning.
The device is the RigExpert Tiny USB Soundcard Transceiver Interface for ham
radio.
(I didn't actually test this. A fellow ham couldn't get the device to work, and
I suggested binding the device ID using sysfs - see
"http://jk.ufisa.uninett.no/usb/". However, he had had moved on to other things
by then. I guess adding the device ID to the kernel "on spec" won't hurt.
The relevant part of cat /proc/bus/usb/devices shows:
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0403 ProdID=ed22 Rev= 5.00
S: Manufacturer=FTDI
S: Product=MixW RigExpert Tiny
S: SerialNumber=00000000
C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
)
From: Jon K Hellan <hellan@acm.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Remove dev_info call on disconnect. The sisusb_dev pointer may have been
set to zero by sisusb_delete at this point causing an oops.
The message does not provide any extra information over the standard USB
subsystem output so removing it does not affect functionality.
Signed-off-by: Will Newton <will.newton@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
