commit 4d907069bc upstream.
The Davicom DM9100 and DM9102 chips are used on the motherboards of
some SPARC systems (supported by the tulip driver) and also in PCI
expansion cards (supported by the dmfe driver). There is no
difference in the PCI device ids for the two different configurations,
so these drivers both claim the device ids. However, it is possible
to distinguish the two configurations by the presence of Open Firmware
properties for them, so we do that.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 35bb5cadc8 upstream.
velocity_open() calls velocity_give_many_rx_descs(), which gives RX
descriptors to the NIC, before installing an interrupt handler or
calling velocity_init_registers(). I think this is very unsafe and it
appears to explain the bug report <http://bugs.debian.org/508527>.
On MTU change, velocity_give_many_rx_descs() is again called before
velocity_init_registers(). I'm not sure whether this is unsafe but
it does look wrong.
Therefore, move the calls to velocity_give_many_rx_descs() after
request_irq() and velocity_init_registers().
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Jan Ceuleers <jan.ceuleers@computer.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit c2572b78aa upstream.
This patch fixes resource reclaim in error path of acm_probe:
1. In the case of "out of memory (read urbs usb_alloc_urb)\n")", there
is no need to call acm_read_buffers_free(acm) here. Fix it by goto
alloc_fail6 instead of alloc_fail7.
2. In the case of "out of memory (write urbs usb_alloc_urb)",
usb_alloc_urb may fail in any iteration of the for loop. Current
implementation does not properly free allocated snd->urb. Fix it by
goto alloc_fail8 instead of alloc_fail7.
3. In the case of device_create_file(&intf->dev,&dev_attr_iCountryCodeRelDate)
fail, acm->country_codes is kfreed. As a result, device_remove_file
for dev_attr_wCountryCodes will not be executed in acm_disconnect.
Fix it by calling device_remove_file for dev_attr_wCountryCodes
before goto skip_countries.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 6a1a82df91 upstream.
Call set_mctrl() and clear_mctrl() according to the flow control mode
selected. This makes serial communication for FT232 connected devices
work when CRTSCTS is not set.
This fixes a regression introduced by 4175f3e31 ("tty_port: If we are
opened non blocking we still need to raise the carrier"). This patch
calls the low-level driver's dtr_rts() function which consequently sets
TIOCM_DTR | TIOCM_RTS. A later call to set_termios() without CRTSCTS in
cflags, however, does not reset these bits, and so data is not actually
sent out on the serial wire.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Johan Hovold <jhovold@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 2d62f3eea9 upstream.
After software resets an xHCI host controller, it must wait for the
"Controller Not Ready" (CNR) bit in the status register to be cleared.
Software is not supposed to ring any doorbells or write to any registers
except the status register until this bit is cleared.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit ed07453fd3 upstream.
When the run bit is set in the xHCI command register, it may take a few
microseconds for the host to start running. We cannot ring any doorbells
until the host is actually running, so wait until the status register says
the host is running.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Shinya Saito <shinya.saito.sx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 8b27ff4cf6 upstream.
vt6421 has problems talking to recent WD drives. It causes a lot of
transmission errors while high bandwidth transfer as reported in the
following bugzilla entry.
https://bugzilla.kernel.org/show_bug.cgi?id=15173
Joseph Chan provided the following fix. I don't have any idea what it
does but I can verify the issue is gone with the patch applied.
Signed-off-by: Tejun Heo <tj@kernel.org>
Originally-from: Joseph Chan <JosephChan@via.com.tw>
Reported-by: Jorrit Tijben <sjorrit@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit f3faf8fc3f upstream.
On mcp55, nIEN gets stuck once set and liteon blueray rom iHOS104-08
violates ATA specification and fails to set I on D2H Reg FIS if nIEN
is set when the command was issued. When the other party is following
the spec, both devices can work fine but when the two flaws are put
together, they can't talk to each other.
mcp55 has its own IRQ masking mechanism and there's no reason to mess
with nIEN in the first place. Fix it by dropping nIEN diddling from
nv_mcp55_freeze/thaw().
This was originally reported by Cengiz. Although Cengiz hasn't
verified the fix yet, I could reproduce this problem and verfiy the
fix. Even if Cengiz is experiencing different or additional problems,
this patch is needed.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Cengiz Günay <cgunay@emory.edu>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 1038953674 upstream.
Per IEEE 1394 clause 8.4.2.3, a contender for the IRM role shall check
whether the current IRM complies to 1394a-2000 or later. If not force a
compliant node (e.g. itself) to become IRM. This was implemented in the
older ieee1394 driver but not yet in firewire-core.
An older Sony camcorder (Sony DCR-TRV25) which implements 1394-1995 IRM
but neither 1394a-2000 IRM nor BM was now found to cause an
interoperability bug:
- Camcorder becomes root node when plugged in, hence gets IRM role.
- firewire-core successfully contends for BM role, proceeds to perform
gap count optimization and resets the bus.
- Sony camcorder ignores presence of a BM (against the spec, this is
a firmware bug), performs its idea of gap count optimization and
resets the bus.
- Preceding two steps are repeated endlessly, bus never settles,
regular I/O is practically impossible.
http://thread.gmane.org/gmane.linux.kernel.firewire.user/3913
This is an interoperability regression from the old to the new drivers.
Fix it indirectly by adding the 1394a IRM check. The spec suggests
three and a half methods to determine 1394a compliance of a remote IRM;
we choose the method of testing the Config_ROM.Bus_Info.generation
field. This is data that firewire-core should have readily available at
this point, i.e. does not require extra I/O.
Reported-by: Clemens Ladisch <clemens@ladisch.de> (missing 1394a check)
Reported-by: H. S. <hs.samix@gmail.com> (issue with Sony DCR-TRV25)
Tested-by: H. S. <hs.samix@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 4daedcfe8c upstream.
JMB362 is a new variant of jmicron controller which is similar to
JMB360 but has two SATA ports instead of one. As there is no PATA
port, single function AHCI mode can be used as in JMB360. Add pci
quirk for JMB362.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Aries Lee <arieslee@jmicron.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 6b5dcccb49 upstream.
Commit 56d1de0a21, "ath5k: clean up
filter flags setting" introduced a regression in monitor mode such
that the promisc filter flag would get lost.
Although we set the promisc flag when it changed, we did not
preserve it across subsequent calls to configure_filter. This patch
restores the original functionality.
Bisected-by: weedy2887@gmail.com
Tested-by: weedy2887@gmail.com
Tested-by: Rick Farina <sidhayn@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit f4d7c3565c upstream.
Based on the sh_tmu change in 66f49121ff
("clocksource: sh_tmu: compute mult and shift before registration").
The same issues impact the sh_cmt driver, so we take the same approach
here.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit ebe8622342 upstream.
Correct at least one of the incorrect specs for a national instrument
data acquisition card DAQCard-6024E. This card has only four different
gain settings (+-10V, +-5V, +-0.5V, +-0.05V).
Signed-off-by: Martin Homuth-Rosemann <homuth-rosemann@gmx.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 9f75c1b12c upstream.
BugLink: https://launchpad.net/bugs/587546
Symptom: On the reporter's ASUS M2V, using PulseAudio in Ubuntu 10.04 LTS
results in the PA daemon crashing shortly after attempting playback of an
audio file.
Test case: Using Ubuntu 10.04 LTS (Linux 2.6.32.12), Linux 2.6.33, or
Linux 2.6.34, attempt playback of an audio file while PulseAudio is
active.
Resolution: add SSID for this machine to the position_fix quirk table,
explicitly specifying the LPIB method.
Reported-and-Tested-By: D Tangman
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit b90c076424 upstream.
BugLink: https://launchpad.net/bugs/580749
Symptom: on the original reporter's VIA VT1708-based board, the
PulseAudio daemon dies shortly after the user attempts to play an audio
file.
Test case: boot from Ubuntu 10.04 LTS live cd; attempt to play an audio
file.
Resolution: add SSID for the original reporter's hardware to the
position_fix quirk table, explicitly specifying the LPIB method.
Reported-and-Tested-By: Harald
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 26fd74fc01 upstream.
BugLink: https://launchpad.net/bugs/542550
Symptom: On the reporter's iMac, in Ubuntu 10.04 LTS neither playback
nor capture appear audible out-of-the-box.
Test case: Boot from an Ubuntu 10.04 LTS live cd or from an installed
configuration and attempt to play or capture audio.
Resolution: Specify the mb31 quirk for this machine in the codec SSID
table.
Reported-and-Tested-By: f3a97
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit dd37f8e865 upstream.
BugLink: https://launchpad.net/bugs/465942
Symptom: On the reporter's ASUS device, using PulseAudio in Ubuntu 10.04
LTS results in the PA daemon crashing shortly after attempting to select
capture or to configure the audio hardware profile.
Test case: Using Ubuntu 10.04 LTS (Linux 2.6.32.12), Linux 2.6.33, or
Linux 2.6.34, adjust the HDA device's capture volume with PulseAudio.
Resolution: add SSID for this machine to the position_fix quirk table,
explicitly specifying the LPIB method.
Reported-and-Tested-By: Irihapeti
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit b3831cb55d upstream.
Since the device we are resuming could be the device containing the
swap device we should ensure that the allocation cannot cause
IO.
On resume, this path is triggered when the running system tries to
continue using its devices. If it cannot then the resume will fail;
to try to avoid this we let it dip into the emergency pools.
The majority of these changes were made when linux-2.6.18-xen.hg
changeset e8b49cfbdac0 was ported upstream in
a144ff09bc but somehow this hunk was
dropped.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit cd52e17ea8 upstream.
The core suspend/resume code is run from stop_machine on CPU0 but
parts of the suspend/resume machinery (including xen_arch_resume) are
run on whichever CPU happened to schedule the xenwatch kernel thread.
As part of the non-core resume code xen_arch_resume is called in order
to restart the timer tick on non-boot processors. The boot processor
itself is taken care of by core timekeeping code.
xen_arch_resume uses smp_call_function which does not call the given
function on the current processor. This means that we can end up with
one CPU not receiving timer ticks if the xenwatch thread happened to
be scheduled on CPU > 0.
Use on_each_cpu instead of smp_call_function to ensure the timer tick
is resumed everywhere.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 3d6e77a3dd upstream.
The low-memory corruption checker triggers during suspend/resume, so we
need to reserve the low 64k. Don't be fooled that the BIOS identifies
itself as "Dell Inc.", it's still Phoenix BIOS.
[ hpa: I think we blacklist almost every BIOS in existence. We should
either change this to a whitelist or just make it unconditional. ]
Signed-off-by: Gabor Gombas <gombasg@digikabel.hu>
LKML-Reference: <201005241913.o4OJDIMM010877@imap1.linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
