Back in 2.6.12-pre, usb_start_wait_urb was switched over to take
milliseconds instead of jiffies. kaweth.c was never updated to match.
Signed-off-by: Russ Dill <Russ.Dill@asu.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
This makes the ->poll() routines of the E100, E1000, E1000E, IXGB, and
IXGBE drivers complete ->poll() consistently.
Now they will all break out when the amount of RX work done is less
than 'budget'.
At a later time, we may want put back code to include the TX work as
well (as at least one other NAPI driver does, but by in large NAPI
drivers do not do this). But if so, it should be done consistently
across the board to all of these drivers.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Auke Kok <auke-jan.h.kok@intel.com>
When we add the generic napi_disable_pending() breakout
logic to net_rx_action() it means that napi_disable()
can cause NAPI poll interrupt events to be disabled.
And this is exactly what we want. If a napi_disable()
is pending, and we are looping in the ->poll(), we want
->poll() event interrupts to stay disabled and we want
to complete the NAPI poll ASAP.
When ->poll() break out during device down was being handled on a
per-driver basis, often these drivers would turn interrupts back on
when '!netif_running()' was detected.
And this would just cause a reschedule of the NAPI ->poll() in the
interrupt handler before the napi_disable() could get in there and
grab the NAPI_STATE_SCHED bit.
The vast majority of drivers don't care if napi_disable() might have
the side effect of disabling NAPI ->poll() event interrupts. In all
such cases, when a napi_disable() is performed, the driver just
disabled interrupts or is about to.
However there were three exceptions to this in PCNET32, R8169, and
SKY2. To fix those cases, at the subsequent napi_enable() points, I
added code to ensure that the ->poll() interrupt events are enabled in
the hardware.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Don Fry <pcnet32@verizon.net>
This will make sure that always the correct core is selected, even if
there are both a PCI and PCI-E core on a PCI or PCI-E card.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Drivers do this to try to break out of the ->poll()'ing loop
when the device is being brought administratively down.
Now that we have a napi_disable() "pending" state we are going
to solve that problem generically.
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes the parsing of the RX data header channel field.
The current code parses the header incorrectly and passes a wrong
channel number and frequency for each frame to mac80211.
The FIXMEs added by this patch don't matter for now as the code
where they live won't get executed anyway. They will be fixed later.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This should fix the kernel warn/oops reported while routing.
The tulip driver has a fencepost bug with new NAPI in 2.6.24
It has an off by one bug if a full quantum is reached.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
meth didn't set a valid mac address during probing, but later during
open. Newer kernel refuse to open device with 00:00:00:00:00:00 as mac
address -> dead ethernet. This patch sets the mac address in the probe
function and uses only the mac address from the netdevice struct when
setting up the hardware.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
This was missed when commit e2ac455a18
fixed the compile errors in drivers/net/netx-eth.c caused by
commit 09f75cd7bf.
Signed-off-by: Adrian Bunk <adrian.bunk@movial.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
It is possible for the TX ring to have packets sit in it for unbounded
amounts of time.
The only way to defer TX interrupts in the chip is to periodically set
"mark" bits, when processing of a TX descriptor with the mark bit set
is complete it triggers the interrupt for the TX queue's LDG.
A consequence of this kind of scheme is that if packet flow suddenly
stops, the remaining TX packets will just sit there.
If this happens, since those packets could be charged to TCP socket
send queues, such sockets could get stuck.
The simplest solution is to divorce the socket ownership of the packet
once the device takes the SKB, by using skb_orphan() in
niu_start_xmit().
In hindsight, it would have been much nicer if the chip provided two
interrupt sources for TX (like basically every other ethernet chip
does). Namely, keep the "mark" bit, but also signal the LDG when the
TX queue becomes completely empty. That way there is no need to have
a deadlock breaker like this.
Signed-off-by: David S. Miller <davem@davemloft.net>
niu_slowpath_interrupt() expects values to be setup in lp->{v0,v1,v2}
but they aren't. That's only done by niu_schedule_napi() which is
done later in the interrupt path.
If niu_rx_error() returns zero, and v0 is clear, hit the
RX_DMA_CTL_STATE register with a RX_DMA_CTL_STAT_MEX.
Only emit verbose RX error logs if a fatal channel or port error is
signalled. Other cases will be recorded into statistics by
niu_log_rxchan_errors().
Signed-off-by: David S. Miller <davem@davemloft.net>
Cleaning out all the incorrect 'no change made' checks for termios
settings showed up a problem with the PL2303. The hardware here seems to
lose sync and bits if you tell it to make no changes. This shows up with
a real world application.
To fix this the driver check for meaningful hardware changes is restored
but doing the tests correctly and as a tty layer function so it doesn't
get duplicated wrongly everywhere if other drivers turn out to need it.
Signed-off-by: Alan Cox <alan@redhat.com>
Tested-by: Mirko Parthey <mirko.parthey@informatik.tu-chemnitz.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
gcc 3.2 has a hard time coping with the code in dmi_id_init():
drivers/built-in.o(.init.text+0x789e): In function `dmi_id_init':
: undefined reference to `__you_cannot_kmalloc_that_much'
make: *** [.tmp_vmlinux1] Error 1
Moving half of the code to a separate function seems to help. This is a
no-op for gcc 4.1 which will successfully inline the code anyway.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Dave Airlie <airlied@linux.ie>
Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We currently do not wait for the block from the missing device to be
computed from parity before copying data to the new stripe layout.
The change in the raid6 code is not techincally needed as we don't delay
data block recovery in the same way for raid6 yet. But making the change
now is safer long-term.
This bug exists in 2.6.23 and 2.6.24-rc
Cc: <stable@kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix a glitch reported by lockdep in the spi_bitbang code: it needs to
consistently block IRQs when holding that spinlock.
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>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
IB/srp: Release transport before removing host
IB/mlx4: Fix value of pkey_index in QP1 completions
MAINTAINERS: Update Sean Hefty's email address
The documented call sequence for removing a host is to call the
transport xxx_remove_host() prior to scsi_remove_host(). The SRP
transport used to crash when that order was followed, but as it is now
fixed, use the documented order.
Signed-off-by: David Dillow <dillowda@ornl.gov>
Acked-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Fix the value of pkey_index in completions to get a valid value for
GSI QPs. Without this fix, incoming GSI packets on port 2 get an
invalid P_Key index in the completion, which prevents the MAD layer
from sending back a response, which can make the second port of
ConnectX HCAs completely useless.
Signed-off-by: Dotan Barak <dotanb@dev.mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
The eeprom decides which Hauppauge model it is, so the decision whether to
use an udelay of 5 or 10 needs to be taken after reading the eeprom, not
before.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This reverts commit ac40532ef0, which gets
us back the original cleanup of 6f5391c283.
It turns out that the bug that was triggered by that commit was
apparently not actually triggered by that commit at all, and just the
testing conditions had changed enough to make it appear to be due to it.
The real problem seems to have been found by Peter Osterlund:
"pktcdvd sets it [block device size] when opening the /dev/pktcdvd
device, but when the drive is later opened as /dev/scd0, there is
nothing that sets it back. (Btw, 40944 is possible if the disk is a
CDRW that was formatted with "cdrwtool -m 10236".)
The problem is that pktcdvd opens the cd device in non-blocking mode
when pktsetup is run, and doesn't close it again until pktsetup -d is
run. The effect is that if you meanwhile open the cd device,
blkdev.c:do_open() doesn't call bd_set_size() because
bdev->bd_openers is non-zero."
In particular, to repeat the bug (regardless of whether commit
6f5391c283 is applied or not):
" 1. Start with an empty drive.
2. pktsetup 0 /dev/scd0
3. Insert a CD containing an isofs filesystem.
4. mount /dev/pktcdvd/0 /mnt/tmp
5. umount /mnt/tmp
6. Press the eject button.
7. Insert a DVD containing a non-writable filesystem.
8. mount /dev/scd0 /mnt/tmp
9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
10. If the DVD contains data beyond the physical size of a CD, you
get I/O errors in the terminal, and dmesg reports lots of
"attempt to access beyond end of device" errors."
which in turn is because the nested open after the media change won't
cause the size to be set properly (because the original open still holds
the block device, and we only do the bd_set_size() when we don't have
other people holding the device open).
The proper fix for that is probably to just do something like
bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
in fs/block_dev.c:do_open() even for the cases where we're not the
original opener (but *not* call bd_set_size(), since that will also
change the block size of the device).
Cc: Peter Osterlund <petero2@telia.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The SCSI SRP transport class currently iterates over all children
devices of the host that is being removed in srp_remove_host(). However,
not all of those children were created by the SRP transport, and
removing them will cause corruption and an oops when their creator tries
to remove them.
Signed-off-by: David Dillow <dillowda@ornl.gov>
Acked-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
The DLE handling in i4l-audio seems to be broken.
It produces spurious DLEs so asterisk 1.2.24 with chan_modem_i4l
gets irritated, the error message is:
"chan_modem_i4l.c:450 i4l_read: Value of escape is ^ (17)".
-> There shouldn't be a DLE-^.
If a spurious DLE-ETX occurs, the audio connection even dies.
I use a "AVM Fritz!PCI" isdn card.
I found two issues that only appear if ISDN_AUDIO_SKB_DLECOUNT(skb) > 0:
- The loop in isdn_tty.c:isdn_tty_try_read() doesn't escape a DLE if it's
the last character.
- The loop in isdn_common.c:isdn_readbchan_tty() doesn't copy its characters,
it only remembers the last one ("last = *p;").
Compare it with the loop in isdn_common.c:isdn_readbchan(), that *does*
copy them ("*cp++ = *p;") correctly.
The special handling of the "last" character made it more difficult.
I compared it to linux-2.4.19: There was no "last"-handling and both loops
did escape and copy all characters correctly.
Signed-off-by: Matthias Goebl <matthias.goebl@goebl.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
The ISDN tty layer doesn't produce a 'NO CARRIER' message after hangup.
I suppose it broke when tty_buffer_flush() has been added to
tty_ldisc_flush() in the commit below.
For isdn_tty_modem_result(RESULT_NO_CARRIER..) the
message inserted via isdn_tty_at_cout() -> tty_insert_flip_char()
is flushed immediately by tty_ldisc_flush() -> tty_buffer_flush().
More annoyingly, the audio abort sequence DLE-ETX is also lost.
This patch fixes only active audio connections, because I assume that nobody
changes the line discipline for audio.
For non-audio connections the problem remains.
Maybe we can remove the tty_ldisc_flush() in isdn_tty_modem_result()
at all because it's done at tty_close?
On Mon, May 07, 2007 at 04:05:57PM -0500, Paul Fulghum wrote:
> Flush the tty flip buffer when the line discipline
> input queue is flushed, including the user call
> tcflush(TCIFLUSH/TCIOFLUSH). This prevents unexpected
> stale data after a user application calls tcflush().
>
> Cc: Alan Cox <alan@lxorguk.org.uk>
> Cc: Antonino Ingargiola <tritemio@gmail.com>
> Signed-off-by: Paul Fulghum <paulkf@microgate.com>
>
> --- a/drivers/char/tty_io.c 2007-05-04 05:46:55.000000000 -0500
> +++ b/drivers/char/tty_io.c 2007-05-05 03:23:46.000000000 -0500
> @@ -1240,6 +1263,7 @@ void tty_ldisc_flush(struct tty_struct *
> ld->flush_buffer(tty);
> tty_ldisc_deref(ld);
> }
> + tty_buffer_flush(tty);
[..]
Signed-off-by: Matthias Goebl <matthias.goebl@goebl.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Error code should be set to EINVAL instead of ENODEV if !queue_work().
There's another call of queue_work() which may set err to EINVAL.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts changeset fa4f0774d7
([CASSINI]: dont touch page_count) because it breaks the driver.
The local page counting added by this changeset did not account
for the asynchronous page count changes done by kfree_skb()
and friends.
The change adds extra atomics and on top of it all appears to be
totally unnecessary as well.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Nick Piggin <npiggin@suse.de>
Here's proposed fix for RX checksum handling in cassini; it affects
little-endian working with half-duplex gigabit, but obviously needs
testing on big-endian too.
The problem is, we need to convert checksum to fixed-endian *before*
correcting for (unstripped) FCS. On big-endian it won't matter
(conversion is no-op), on little-endian it will, but only if FCS is
not stripped by hardware; i.e. in half-duplex gigabit mode when
->crc_size is set.
cassini.c part is that fix, cassini.h one consists of trivial
endianness annotations. With that applied the sucker is endian-clean,
according to sparse.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a missing call to srp_remove_host() in srp_remove_one() so that we
don't leak SRP transport class list entries.
Tested-by: David Dillow <dillowda@ornl.gov>
Acked-by: FUJITA Tomonori <tomof@acm.org>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
The VID input level change has been reported to cause trouble. Be more
careful in this respect:
* Only change the level on the W83627EHF/EHG. The W83627DHG is more
complex in this respect.
* Don't change the level if the VID pins are in output mode.
* Only set the level to TTL if VRM 9.x is used.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
This reverts commit 6f5391c283 ("[SCSI]
Get rid of scsi_cmnd->done") that was supposed to be a cleanup commit,
but apparently it causes regressions:
Bug 9370 - v2.6.24-rc2-409-g9418d5d: attempt to access beyond end of device
http://bugzilla.kernel.org/show_bug.cgi?id=9370
this patch should be reintroduced in a more split-up form to make
testing of it easier.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Matthew Wilcox <matthew@wil.cx>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
A recent bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=9674
Was caused because the ULDs now set their own prep functions, but
don't necessarily reset the prep function back to the SCSI default
when they are removed. This leads to panics if commands are sent to
the device after the module is removed because the prep_fn is still
pointing to the old module code. The fix for this is to implement a
bus remove method that resets the prep_fn pointer correctly before
calling the ULD specific driver remove method.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Covert leds_list_lock to a rw_sempahore to match previous LED trigger
locking fixes, fixing lock ordering.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
We're exporting an __init function, oops :-)
The core issue here is that add_preferred_console() is marked
as __init, this makes it impossible to invoke this thing from
a driver probe routine which is what the Sparc serial drivers
need to do.
There is no harm in dropping the __init marker. This code will
actually work properly when invoked from a modular driver,
except that init will probably not pick up the console change
without some other support code.
Then we can drop the __init from sunserial_console_match()
and we're no longer exporting an __init function to modules.
Signed-off-by: David S. Miller <davem@davemloft.net>
It appears that some PCI-E bridges do the wrong thing in the presense of
CRS Software Visibility and MMCONFIG. In particular, it looks like an
ATI bridge (device ID 7936) will return 0001 in the vendor ID field of
any bridged devices indefinitely.
Not enabling CRS SV avoids the problem, and as we currently do not
really make good use of the feature anyway (we just time out rather than
do any threaded discovery as suggested by the CRS specs), we're better
off just not enabling it.
This should fix a slew of problem reports with random devices (generally
graphics adapters or fairly high-performance networking cards, since it
only affected PCI-E) not getting properly recognized on these AMD systems.
If we really want to use CRS-SV, we may end up eventually needing a
whitelist of systems where this should be enabled, along with some kind
of "pcibios_enable_crs()" query to call the system-specific code.
Suggested-by: Loic Prylli <loic@myri.com>
Tested-by: Kai Ruhnau <kai@tragetaschen.dyndns.org>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The xcryptecb instruction always processes an even number of blocks so
we need to ensure th existence of an extra block if we have to process
an odd number of blocks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Move veth.h from net/ to linux/ since it is a user api, and add it to
user header processing Kbuild.
[ Use header-y as suggested by Sam Ravnborg. -DaveM ]
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is a trivial fix of debug message.
When a persist flag is set, the message should say "enabled".
Signed-off-by: Toyo Abe <tabe@miraclelinux.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 528a572dae ("ide: add ->chipset field
to ide_pci_device_t") broke hwif->chipset setup (it is now set to ide_cmd646
for CMD648 instead of CMD646). It seems that the breakage happend while
I was moving patches around (cmd64x_chipsets[] entries for CMD646 and CMD648
are identical except for 'name' field). Fix it and bump driver version.
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Mask 'ireason' variable so only the valid interrupt reason bits
will be reported on "drive appears confused" error.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Mask 'ireason' variable with 0x3 so the valid interrupt reason value
is passed to cdrom_write_check_ireason() for checking.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Use ide_cd_release() to do the cleanup if ide_cdrom_setup() fails.
It fixes:
- the default drive->dsc_overlap value not being restored
- the default drive->queue's prep_rq_fn not being restored
- struct gendisk 'g' not being freed
- wrong function name being reported on unregister_cdrom() error
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
cdi->mask is cleared by ide_cdrom_register() which is called after the quirk.
Fix it by adding new ->no_speed_select flag to struct ide_cd_config_flags
and using it in ide_cdrom_register() to set CDC_SELECT_SPEED flag.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
USB: New device ID for the CP2101 driver
USB: VID/PID update for sierra
USB: Unbreak fsl_usb2_udc
Commit 5a52bd4a2d introduced a subtle logic
change in tty_wait_until_sent(). The original version would only error out
of the 'do { ... } while (timeout)' loop if signal_pending() evaluated to
true; a timeout or break due to an empty buffer would fall out of the loop
and into the tty->driver->wait_until_sent handling. The current
implementation will error out on either a pending signal or an empty
buffer, falling through to the tty->driver->wait_until_sent handling only
on a timeout.
The ->wait_until_sent() will not be reached if the buffer empties before
timeout jiffies have elapsed. This behavior differs from that prior to commit
5a52bd4a2d.
I turned this up while using a little serial download utility to bootstrap an
ARM-based eval board. The util worked fine on 2.6.22.x, but consistently
failed on 2.6.23.x. Once I'd determined that, I narrowed things down with git
bisect, and found the above difference in logic in tty_wait_until_sent() by
inspection.
This change reverts the logic flow in tty_wait_until_sent() to match that
prior to the aforementioned commit.
Signed-off-by: Cory T. Tusar <ctusar@videon-central.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Acked-by: Jiri Slaby <jirislaby@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Init section confusion. There will likely be some other similar
issues, introduced by I'm-not-sure-what-patch.
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>
This stray down would cause a permanent sleep which doesn't seem correct.
The other uses of this semaphore appear fairly mutex like it's even
initialized with init_MUTEX() .. So here a patch for removing this one
down().
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Daniel Walker <dwalker@mvista.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
attached please find a new device ID for CP2101 driver. This device is a
usb stick from Dynastream to communicate with ANT wireless devices which
I suppose is fairly similar to the ANT dev board having product id 0x1003.
From: Martin Kusserow <kusserow@ife.ee.ethz.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Adds VID/PID for the MC8775 found internally in the Thinkpad X61s laptop
(and likely others). For commercial reasons the driver maintainer cannot
add VID/PIDs for laptop OEM devices himself.
Signed-off-by: Kevin R Page <linux-kernel@krp.org.uk>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Initially transmit buffer pointers were only reset. But buffer
descriptors were possibly still set as ready, and buffer in upper
layer was not freed. This caused driver hang under big load. Now
reset clean properly the buffer descriptor and freed upper layer.
Signed-off-by: Gregory CLEMENT <gclement00@gmail.com>
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Same story as with olympic - htons(readw()) when swab16(readw()) is needed,
missing conversions to le32 when dealing with shared descriptors, etc.
Olympic got those fixes in 2.4.0-test2, 3c359 didn't.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
If you need to find a difference between addresses of two
struct members, subtract offsetof() or cast addresses to
char * and subtract those if you prefer it that way. Doing
that same with s/char */u32/, OTOH...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Both store MAC address in CIS; there's no decoder for that
type (0x88) so the drivers work with raw data. It is
byteswapped, so ntohs() works for little-endian, but for
big-endian it's wrong. ntohs(le16_to_cpu()) does the
right thing on both (and always expands to swab16()).
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
* shift before cpu_to_le64(), not after it
* writel() converts to l-e itself
* misc missing conversions
* in set_multicast() hash_table[] is host-endian; we feed it to card
via writel() and populate it as host-endian, so we'd better put the
first element into it also in host-endian
* pci_unmap_single() et.al. expect host-endian, not little-endian
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
pci_unmap_single() and friends getting a little-endian address...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
* usb_control_message() to/from stack (breaks on e.g. arm); some
places did kmalloc() for buffer, some just worked from stack.
Added kmalloc()/memcpy()/kfree() in asix_read_cmd()/asix_write_cmd(),
removed that crap from callers.
* Fixed a leak in ax88172_bind() - on success it forgot to kfree() the
buffer.
* Endianness bug in ax88178_bind() - we read a word from eeprom and work with
it without converting to host-endian
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
txlo_dma_addr should be host-endian; we pass it to typhoon_tso_fill(),
which does arithmetics on it, converts to l-e and passes it to card.
Unfortunately, we forgot le32_to_cpu() when initializing it from
face->txLoAddr, which sits in shared memory and is little-endian.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
rxBuffCleared is little-endian; we miss le32_to_cpu() in checks for
rx ring overruns.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
One cpu_to_le16() too many when passing argument for TYPHOON_CMD_XCVR_SELECT;
we end up passing host-endian while the hardware expects little-endian. The
other place doing that (typhoon_start_runtime()) does the right thing, so the
card will recover at the next ifconfig up/tx timeout/resume, which limits the
amount of mess, but still, WTF?
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
in typhoon_get_drvinfo() .parm2 is little-endian; not critical
since we just get the firmware id flipped in get_drvinfo output
on big-endian boxen, but...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
txBytes and rxBytesGood are both 64bit; using le32_to_cpu() won't work
on big-endian for obvious reasons.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Fix possible max_phys_segments violation in cloned dm-crypt bio.
In write operation dm-crypt needs to allocate new bio request
and run crypto operation on this clone. Cloned request has always
the same size, but number of physical segments can be increased
and violate max_phys_segments restriction.
This can lead to data corruption and serious hardware malfunction.
This was observed when using XFS over dm-crypt and at least
two HBA controller drivers (arcmsr, cciss) recently.
Fix it by using bio_add_page() call (which tests for other
restrictions too) instead of constructing own biovec.
All versions of dm-crypt are affected by this bug.
Cc: stable@kernel.org
Cc: dm-crypt@saout.de
Signed-off-by: Milan Broz <mbroz@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Make sure dm honours max_hw_sectors of underlying devices
We still have no firm testing evidence in support of this patch but
believe it may help to resolve some bug reports. - agk
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Insert a missing KOBJ_CHANGE notification when a device is renamed.
Cc: Scott James Remnant <scott@ubuntu.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Fix BIO_UPTODATE test for write io.
Cc: stable@kernel.org
Cc: dm-crypt@saout.de
Signed-off-by: Milan Broz <mbroz@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
With CONFIG_SCSI=n __scsi_print_sense() is never linked in.
drivers/built-in.o: In function `hp_sw_end_io':
dm-mpath-hp-sw.c:(.text+0x914f8): undefined reference to `__scsi_print_sense'
Caught with a randconfig on current git.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
This patch fixes a panic on shrinking a DM device if there is
outstanding I/O to the part of the device that is being removed.
(Normally this doesn't happen - a filesystem would be resized first,
for example.)
The bug is that __clone_and_map() assumes dm_table_find_target()
always returns a valid pointer. It may fail if a bio arrives from the
block layer but its target sector is no longer included in the DM
btree.
This patch appends an empty entry to table->targets[] which will
be returned by a lookup beyond the end of the device.
After calling dm_table_find_target(), __clone_and_map() and target_message()
check for this condition using
dm_target_is_valid().
Sample test script to trigger oops:
if log_len is larger than 4K then we are killing the stack.
allocate on heap instead and limit size to what practically can
be used (PAGE_SIZE)
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch moves _cancel_deferred_work out of mutex protection and removes
unnecessary mutex in pci_suspend and pci_resume.
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some people would like to know what p54 is.
Signed-off-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
