Age | Commit message (Collapse) | Author |
|
commit f0ad30d3d2dc924decc0e10b1ff6dc32525a5d99 upstream.
Some cards (like mvsas) have issue troubles if non-NCQ commands are
mixed with NCQ ones. Fix this by using the libata default NCQ check
routine which waits until all NCQ commands are complete before issuing
a non-NCQ one. The impact to cards (like aic94xx) which don't need
this logic should be minimal
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 1a03ae0f556a931aa3747b70e44b78308f5b0590 upstream.
Following a site power outage which re-enabled all the ports on my FC
switches, my system subsequently booted with far too many luns! I had
let it run hoping it would make multi-user. It didn't. :( It hung solid
after exhausting the last sd device, sdzzz, and attempting to create sdaaaa
and beyond. I was unable to get a dump.
Discovered using a 2.6.32.13 based system.
correct this by detecting when the last index is utilized and failing
the sd probe of the device. Patch applies to scsi-misc-2.6.
Signed-off-by: Michael Reed <mdr@sgi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 56626a72a47bf3e50875d960d6b5f17b9bee0ab2 upstream.
A few devices (such as the RCA VR5220 voice recorder) are so
non-compliant with the USB spec that they have invalid maxpacket sizes
for endpoint 0. Nevertheless, as long as we can safely use them, we
may as well do so.
This patch (as1432) softens our acceptance criterion by allowing
high-speed devices to have ep0-maxpacket sizes other than 64. A
warning is printed in the system log when this happens, and the
existing error message is clarified.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: James <bjlockie@lockie.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 97cd8dc4ca9a1a5efb2cc38758e01492e3b013e2 upstream.
The bulk-read callback had two bugs:
a) The bulk-in packet's leading two zeros were returned (and the two last
bytes truncated)
b) The wrong URB was transmitted for the second (and later) read requests,
causing further reads to return the entire packet (including leading
zeros)
Signed-off-by: Alon Ziv <alon-git@nolaviz.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 80f0cf3947889014d3a3dc0ad60fb87cfda4b12a upstream.
This patch (as1430) fixes a bug in usbcore. When a device
configuration change occurs or a device is removed, the endpoints for
the old config should be completely disabled. However it turns out
they aren't; this is because usb_unbind_interface() calls
usb_enable_interface() or usb_set_interface() to put interfaces back
in altsetting 0, which re-enables the interfaces' endpoints.
As a result, when a device goes through a config change or is
unconfigured, the ep_in[] and ep_out[] arrays may be left holding old
pointers to usb_host_endpoint structures. If the device is
deauthorized these structures get freed, and the stale pointers cause
errors when the the device is eventually unplugged.
The solution is to disable the endpoints after unbinding the
interfaces instead of before. This isn't as large a change as it
sounds, since usb_unbind_interface() disables all the interface's
endpoints anyway before calling the driver's disconnect routine,
unless the driver claims to support "soft" unbind.
This fixes Bugzilla #19192. Thanks to "Tom" Lei Ming for diagnosing
the underlying cause of the problem.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Carsten Sommer <carsten_sommer@ymail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 969affff54702785330de553b790372e261e93f9 upstream.
to ensure gpio_is_valid return false
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 93ad03d60b5b18897030038234aa2ebae8234748 upstream.
The WAGO 750-923 USB Service Cable is used for configuration and firmware
updates of several industrial automation products from WAGO Kontakttechnik GmbH.
Bus 004 Device 002: ID 1be3:07a6
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1be3
idProduct 0x07a6
bcdDevice 1.00
iManufacturer 1 Silicon Labs
iProduct 2 WAGO USB Service Cable
iSerial 3 1277796751
. . .
Signed-off-by: Anders Larsen <al@alarsen.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 2f1136d1d08a63dcdbcd462621373f30d8dfe590 upstream.
RX610 development board by Renesas
Bus 001 Device 024: ID 045b:0053 Hitachi, Ltd
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x045b Hitachi, Ltd
idProduct 0x0053
bcdDevice 1.00
iManufacturer 1 Silicon Labs
iProduct 2 RX-Stick
iSerial 3 0001
. . .
http://am.renesas.com/rx610stick
Signed-off-by: DJ Delorie <dj@delorie.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit ecfa153ef616b901e86d9a051b329fcda7a6ce7b upstream.
There are lots of ZTE USB id's currently not covered by usb/serial. Adds them,
to allow those devices to work properly on Linux.
While here, put the USB ID's for 0x2002/0x2003 at the sorted order.
This patch is based on zte.c file found on MF645.
PS.: The ZTE driver is commenting the USB ID for 0x0053. It also adds, commented,
an USB ID for 0x0026.
Not sure why, but I think that 0053 is used by their devices in storage mode only.
So, I opted to keep the comment on this patch.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 00be545e49d83485d49a598d3b7e090088934be8 upstream.
Blackfin's musb_platform_init() needs to call gpio_free() for error cleanup iff
otg_get_transceiver() call returns NULL.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 0f266abd70cd83571eca019f764b5f1992da7361 upstream.
This adds the requested device ids to the ftdi_sio driver.
Reported-by: Ewan Bingham <ewan@auc.co.uk>
Cc: Kuba Ober <kuba@mareimbrium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 59c6ccd9f9aecfa59c99ceba6d4d34b180547a05 upstream.
This patch for FTDI USB serial driver ads new VID/PIDs used on various
devices manufactured by Papouch (http://www.papouch.com). These devices
have their own VID/PID, although they're using standard FTDI chip. In
ftdi_sio.c, I also made small cleanup to have declarations for all
Papouch devices together.
Signed-off-by: Daniel Suchy <danny@danysek.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 99c1e4f89d1033444ce4d0c064bd2826e81c3775 upstream.
The OpenDCC project is developing a new hardware. This patch adds its
PID to the list of known FTDI devices. The PID can be found at
http://www.opendcc.de/elektronik/usb/opendcc_usb.html
Signed-off-by: Rainer Keller <mail@rainerkeller.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 3126d8236ca6f68eb8292c6af22c2e59afbeef24 upstream.
Adds support for Accesio USB to Serial adapters, which are built around
FTDI FT232 UARTs. Tested with the Accesio USB-COM-4SM.
Signed-off-by: Rich Mattes <richmattes@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 0d91f22b75347d9503b17a42b6c74d3f7750acd6 upstream.
In this code, 0 is returned on memory allocation failure, even though other
failures return -ENOMEM or other similar values.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression ret;
expression x,e1,e2,e3;
@@
ret = 0
... when != ret = e1
*x = \(kmalloc\|kcalloc\|kzalloc\)(...)
... when != ret = e2
if (x == NULL) { ... when != ret = e3
return ret;
}
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 1a92795dac419128eb511dce30a6aad672064b88 upstream.
Source:
http://www.wikidevi.com/wiki/Intersil/p54/usb/windows
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 11791a6f7534906b4a01ffb54ba0b02ca39398ef upstream.
The ISL3887 chip needs a USB reset, whenever the
usb-frontend module "p54usb" is reloaded.
This patch fixes an off-by-one bug, if the user
is running a kernel without the CONFIG_PM option
set and for some reason (e.g.: compat-wireless)
wants to switch between different p54usb modules.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit c19483cc5e56ac5e22dd19cf25ba210ab1537773 upstream.
Fortunately this is only exploitable on very unusual hardware.
[Reported a while ago but nothing happened so just fixing it]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 5b917a1420d3d1a9c8da49fb0090692dc9aaee86 upstream.
Structure new_line is copied to userland with some padding fields unitialized.
It leads to leaking of stack memory.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 584c5b7cf06194464240280483ee0376cdddbbae upstream.
The way the event handler works can cause it to delay
events until eventual wakeup for another event.
For example, on device detach (vhci):
- Write to sysfs detach file
-> usbip_event_add(VDEV_EVENT_DOWN)
-> wakeup()
#define VDEV_EVENT_DOWN (USBIP_EH_SHUTDOWN | USBIP_EH_RESET).
- Event thread wakes up and passes the event to
event_handler() to process.
- It processes and clears the USBIP_EH_SHUTDOWN
flag then returns.
- The outer event loop (event_handler_loop()) calls
wait_event_interruptible().
The processing of the second flag which is part of
VDEV_EVENT_DOWN (USBIP_EH_RESET) did not happen yet.
It is delayed until the next event.
This means the ->reset callback may not happen for
a long time (if ever), leaving the usbip port in a
weird state which prevents its reuse.
This patch changes the handler to process all flags
before waiting for another wakeup.
I have verified this change to fix a problem which
prevented reattach of a usbip device. It also helps
for socket errors which missed the RESET as well.
The delayed event processing also affects the stub
side of usbip and the error handling there.
Signed-off-by: Max Vozeler <mvz@vozeler.com>
Reported-by: Marco Lancione <marco@optikam.com>
Tested-by: Luc Jalbert <ljalbert@optikam.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 0c9a32f0192e656daa2ff3c9149f6d71b4a1b873 upstream.
This patch changes vhci to behave like dummy and
other hcds when disconnecting a device.
Previously detaching a device from the root hub
did not notify the usb core of the disconnect and
left the device visible.
Signed-off-by: Max Vozeler <mvz@vozeler.com>
Reported-by: Marco Lancione <marco@optikam.com>
Tested-by: Luc Jalbert <ljalbert@optikam.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 337279ce3aa85d81d34c0f837d1c204df105103b upstream.
Disable the Windows Vista (SP1) compatibility for Toshiba P305D.
http://bugzilla.kernel.org/show_bug.cgi?id=14736
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 64a32307b710c100beb101e9c78f8022f0e8ba61 upstream.
per comments in the bug report, this entry
seems to hurt at much as it helps.
https://bugzilla.kernel.org/show_bug.cgi?id=10807
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 7a1d602f5fc35d14907b7da98d5627acb69589d1 upstream.
https://bugzilla.kernel.org/show_bug.cgi?id=12641
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 4731fdcf6f7bdab3e369a3f844d4ea4d4017284d upstream.
When the Lenovo Ideapad S10-3 is booted with HT enabled,
it hits a boot hang in the intel_idle driver.
This occurs when entering ATM-C4 for the first time,
unless BM_STS is first cleared.
acpi_idle doesn't see this because it first checks
and clears BM_STS, but it would hit the same hang
if that check were disabled.
http://bugs.meego.com/show_bug.cgi?id=7093
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/634702
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 573b638158029898caf9470c8214b7ddd29751e3 upstream.
Section 4.7.3.1.1 (PM1 Status Registers) of version 4.0 of
the ACPI spec concerning PCIEXP_WAKE_STS points out in
in the final note field in table 4-11 that if this bit is
set to 1 and the system is put into a sleeping state then
the system will not automatically wake.
This bit gets set by hardware to indicate that the system
woke up due to a PCI Express wakeup event, so clear it during
acpi_hw_clear_acpi_status() calls to enable subsequent
resumes to work.
BugLink: http://bugs.launchpad.net/bugs/613381
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit bcf64aa379fcadd074449cbf0c049da70071b06f upstream.
For carrier detection to work properly when binding the driver with a cable
unplugged, netif_carrier_off() should be called after register_netdev(),
not before.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This was fixed in mainline by the interface change made in commit
f9dcbcc9e338d08c0f7de7eba4eaafbbb7f81249.
After walking the multicast list to set up the hash filter, this
function will walk off the end of the list when filling the
exact-match entries. This was fixed in mainline by the interface
change made in commit f9dcbcc9e338d08c0f7de7eba4eaafbbb7f81249.
Reported-by: spamalot@hispeed.ch
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=15355
Reported-by: Jason Heeris <jason.heeris@gmail.com>
Reference: http://bugs.debian.org/600155
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 3bcf8229a8c49769e48d3e0bd1e20d8e003f8106 upstream.
As reported in <https://bugzilla.kernel.org/show_bug.cgi?id=15355>, r6040_
multicast_list currently crashes. This is due a wrong maximum of multicast
entries. This patch fixes the following issues with multicast:
- number of maximum entries if off-by-one (4 instead of 3)
- the writing of the hash table index is not necessary and leads to invalid
values being written into the MCR1 register, so the MAC is simply put in a non
coherent state
- when we exceed the maximum number of mutlticast address, writing the
broadcast address should be done in registers MID_1{L,M,H} instead of
MID_O{L,M,H}, otherwise we would loose the adapter's MAC address
[bwh: Adjust for 2.6.32; should also apply to 2.6.27]
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit aeb19f6052b5e5c8a24aa444fbff73b84341beac upstream.
We have fedora bug report where driver fail to initialize after
suspend/resume because of memory allocation errors:
https://bugzilla.redhat.com/show_bug.cgi?id=629158
To fix use GFP_KERNEL allocation where possible.
Tested-by: Neal Becker <ndbecker2@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 392bd0cb000d4aac9e88e4f50823db85e7220688 upstream.
Skge devices installed on some Gigabyte motherboards are not able to
perform 64 dma correctly due to board PCI implementation, so limit
DMA to 32bit if such boards are detected.
Bug was reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=447489
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Tested-by: Luya Tshimbalanga <luya@fedoraproject.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
[ Upstream commit 7e96dc7045bff8758804b047c0dfb6868f182500 ]
skb->truesize is set in core network.
Dont change it unless dealing with fragments.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit ec5a32f67c603b11d68eb283d94eb89a4f6cfce1 upstream.
adapter->cmb.cmb is initialized when the device is opened and freed when
it's closed. Accessing it unconditionally during resume results either
in a crash (NULL pointer dereference, when the interface has not been
opened yet) or data corruption (when the interface has been used and
brought down adapter->cmb.cmb points to a deallocated memory area).
Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Acked-by: Chris Snook <chris.snook@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 6abb930af064fb1cf4177d32e2c7bfb89eee0fe5 upstream.
ret is still -1, if during the polling read_byte() returns at once
with I2C_PCA_CON_SI set. So ret > 0 would lead *_waitforcompletion()
to return 0, in spite of the proper behavior.
The routine was rewritten, so that ret has always a proper value,
before returning.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit cc60f8878eab892c03d06b10f389232b9b66bd83 upstream.
When using simultaneously the two DMA channels on a same engine, some
transfers are never completed. For example, an endless lock can occur
while writing heavily on a RAID5 array (with async-tx offload support
enabled).
Note that this issue can also be reproduced by using the DMA test
client.
On a same engine, the interrupt cause register is shared between two
DMA channels. This patch make sure that the cause bit is only cleared
for the requested channel.
Signed-off-by: Simon Guinot <sguinot@lacie.com>
Tested-by: Luc Saillard <luc@saillard.org>
Acked-by: saeed bishara <saeed.bishara@gmail.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d2520a426dc3033c00077e923a553fc6c98c7564 upstream.
Fixed JSIOCSAXMAP ioctl to update absmap, the map from hardware axis to
event axis in addition to abspam. This fixes a regression introduced
by 999b874f.
Signed-off-by: Kenneth Waters <kwwaters@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 08be64be3d1e5ecd72e7ba3147aea518e527f08e upstream.
Some customers has problem with quality of DVB-T
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446575
After this patch http://patchwork.kernel.org/patch/23345/
This is patch for fix regression with DVB-T. Tested with many people.
Signed-off-by: Alexey Osipov <lion-simba@pridelands.ru>
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov <d.belimov@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit c10469c637602c2385e2993d8c730cc44fd47d23 upstream.
As reported by: Carlos Americo Domiciano <c_domiciano@yahoo.com.br>:
[ 220.033500] cx231xx v4l2 driver loaded.
[ 220.033571] cx231xx #0: New device Conexant Corporation Polaris AV Capturb @ 480 Mbps (1554:5010) with 6 interfaces
[ 220.033577] cx231xx #0: registering interface 0
[ 220.033591] cx231xx #0: registering interface 1
[ 220.033654] cx231xx #0: registering interface 6
[ 220.033910] cx231xx #0: Identified as Unknown CX231xx video grabber (card=0)
[ 220.033946] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 220.033955] IP: [<ffffffffa0d3c8bd>] cx231xx_pre_card_setup+0x5d/0xb0 [cx231xx]
Thanks-to: Carlos Americo Domiciano <c_domiciano@yahoo.com.br>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 3e645d6b485446c54c6745c5e2cf5c528fe4deec upstream.
The compat code for the VIDIOCSMICROCODE ioctl is totally buggered.
It's only used by the VIDEO_STRADIS driver, and that one is scheduled to
staging and eventually removed unless somebody steps up to maintain it
(at which point it should use request_firmware() rather than some magic
ioctl). So we'll get rid of it eventually.
But in the meantime, the compatibility ioctl code is broken, and this
tries to get it to at least limp along (even if Mauro suggested just
deleting it entirely, which may be the right thing to do - I don't think
the compatibility translation code has ever worked unless you were very
lucky).
Reported-by: Kees Cook <kees.cook@canonical.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 9320f7cbbdd5febf013b0e91db29189724057738 upstream.
If not all clocks have been defined in platform data, the driver will
cause a null pointer dereference when it is removed. This patch fixes
this issue.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit bec658ff31453a5726b1c188674d587a5d40c482 upstream.
The HW by default has RX coalescing on. For iWARP connections, this
causes a 100ms delay in connection establishement due to the ingress
MPA Start message being stalled in HW. So explicitly turn RX
coalescing off when setting up iWARP connections.
This was causing very bad performance for NP64 gather operations using
Open MPI, due to the way it sets up connections on larger jobs.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit a666e3e6098a9f56310e4ec2705f1dad124a34b5 upstream.
Commit 46034dca515bc4ddca0399ae58106d1f5f0d809f (USB: musb_gadget_ep0: stop
abusing musb_gadget_set_halt()) forgot to restart a queued request after
clearing the endpoint halt feature. This results in a couple of USB resets
while enumerating the file-backed storage gadget due to CSW packet not being
sent for the MODE SENSE(10) command.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit bd2e74d657fc7d514881cc2117e323790b257914 upstream.
For shared fifo hw endpoint(with FIFO_TXRX style), only ep_in
field of musb_hw_ep is intialized in musb_g_init_endpoints, and
ep_out is not initialized, but musb_g_rx and rxstate may access
ep_out field of musb_hw_ep by the method below:
musb_ep = &musb->endpoints[epnum].ep_out
which can cause the kernel panic[1] below, this patch fixes the issue
by getting 'musb_ep' from '&musb->endpoints[epnum].ep_in' for shared fifo
endpoint.
[1], kernel panic
[root@OMAP3EVM /]# musb_interrupt 1583: ** IRQ peripheral usb0008 tx0000 rx4000
musb_stage0_irq 460: <== Power=f0, DevCtl=99, int_usb=0x8
musb_g_rx 772: <== (null), rxcsr 4007 ffffffe8
musb_g_rx 786: iso overrun on ffffffe8
Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c0004000
[00000008] *pgd=00000000
Internal error: Oops: 17 [#1] PREEMPT
last sysfs file: /sys/devices/platform/musb_hdrc/usb1/usb_device/usbdev1.1/dev
Modules linked in: g_zero
CPU: 0 Tainted: G W (2.6.35-rc6-gkh-wl+ #92)
PC is at musb_g_rx+0xfc/0x2ec
LR is at vprintk+0x3f4/0x458
pc : [<c02c07a4>] lr : [<c006ccb0>] psr: 20000193
sp : c760bd78 ip : c03c9d70 fp : c760bdbc
r10: 00000000 r9 : fa0ab1e0 r8 : 0000000e
r7 : c7e80158 r6 : ffffffe8 r5 : 00000001 r4 : 00004003
r3 : 00010003 r2 : c760bcd8 r1 : c03cd030 r0 : 0000002e
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 8778c019 DAC: 00000017
Process kmemleak (pid: 421, stack limit = 0xc760a2e8)
Stack: (0xc760bd78 to 0xc760c000)
bd60: ffffffe8 c04b1b58
bd80: ffffffe8 c7c01ac0 00000000 c7e80d24 c0084238 00000001 00000001 c7e80158
bda0: 0000000e 00000008 00000099 000000f0 c760be04 c760bdc0 c02bcd68 c02c06b4
bdc0: 00000099 00000008 00004000 c760bdd8 c03cc4f8 00000000 00000002 c7e80158
bde0: c7d2e300 60000193 c760a000 0000005c 00000000 00000000 c760be24 c760be08
be00: c02bcecc c02bc1ac c7d2e300 c7d2e300 0000005c c760a000 c760be54 c760be28
be20: c00ad698 c02bce6c 00000000 c7d2e300 c067c258 0000005c c067c294 00000001
be40: c760a000 00000000 c760be74 c760be58 c00af984 c00ad5fc 0000005c 00000000
be60: 00000000 00000002 c760be8c c760be78 c0039080 c00af8d0 ffffffff fa200000
be80: c760beec c760be90 c0039b6c c003900c 00000001 00000000 c7d1e240 00000000
bea0: 00000000 c068bae8 00000000 60000013 00000001 00000000 00000000 c760beec
bec0: c0064ecc c760bed8 c00ff7d0 c003a0a8 60000013 ffffffff 00000000 c068bae8
bee0: c760bf24 c760bef0 c00ff7d0 c0064ec4 00000001 00000000 c00ff700 00000000
bf00: c0087f00 00000000 60000013 c0d76a70 c0e23795 00000001 c760bf4c c760bf28
bf20: c00ffdd8 c00ff70c c068bb08 c068bae8 60000013 c0100938 c068bb30 00000000
bf40: c760bf84 c760bf50 c010014c c00ffd84 00000001 00000000 c010000c 00012c00
bf60: c7c33f04 00012c00 c7c33f04 00000000 c0100938 00000000 c760bf9c c760bf88
bf80: c01009a8 c0100018 c760bfa8 c7c33f04 c760bff4 c760bfa0 c0088000 c0100944
bfa0: c760bf98 00000000 00000000 00000001 dead4ead ffffffff ffffffff c08ba2bc
bfc0: 00000000 c049e7fa 00000000 c0087f70 c760bfd0 c760bfd0 c7c33f04 c0087f70
bfe0: c006f5e8 00000013 00000000 c760bff8 c006f5e8 c0087f7c 7f0004ff df2000ff
Backtrace:
[<c02c06a8>] (musb_g_rx+0x0/0x2ec) from [<c02bcd68>] (musb_interrupt+0xbc8/0xcc0)
[<c02bc1a0>] (musb_interrupt+0x0/0xcc0) from [<c02bcecc>] (generic_interrupt+0x6c/0x84)
[<c02bce60>] (generic_interrupt+0x0/0x84) from [<c00ad698>] (handle_IRQ_event+0xa8/0x1ec)
r7:c760a000 r6:0000005c r5:c7d2e300 r4:c7d2e300
[<c00ad5f0>] (handle_IRQ_event+0x0/0x1ec) from [<c00af984>] (handle_level_irq+0xc0/0x13c)
[<c00af8c4>] (handle_level_irq+0x0/0x13c) from [<c0039080>] (asm_do_IRQ+0x80/0xa0)
r7:00000002 r6:00000000 r5:00000000 r4:0000005c
[<c0039000>] (asm_do_IRQ+0x0/0xa0) from [<c0039b6c>] (__irq_svc+0x4c/0xb4)
Exception stack(0xc760be90 to 0xc760bed8)
be80: 00000001 00000000 c7d1e240 00000000
bea0: 00000000 c068bae8 00000000 60000013 00000001 00000000 00000000 c760beec
bec0: c0064ecc c760bed8 c00ff7d0 c003a0a8 60000013 ffffffff
r5:fa200000 r4:ffffffff
[<c0064eb8>] (sub_preempt_count+0x0/0x100) from [<c00ff7d0>] (find_and_get_object+0xd0/0x110)
r5:c068bae8 r4:00000000
[<c00ff700>] (find_and_get_object+0x0/0x110) from [<c00ffdd8>] (scan_block+0x60/0x104)
r8:00000001 r7:c0e23795 r6:c0d76a70 r5:60000013 r4:00000000
[<c00ffd78>] (scan_block+0x0/0x104) from [<c010014c>] (kmemleak_scan+0x140/0x484)
[<c010000c>] (kmemleak_scan+0x0/0x484) from [<c01009a8>] (kmemleak_scan_thread+0x70/0xcc)
r8:00000000 r7:c0100938 r6:00000000 r5:c7c33f04 r4:00012c00
[<c0100938>] (kmemleak_scan_thread+0x0/0xcc) from [<c0088000>] (kthread+0x90/0x98)
r5:c7c33f04 r4:c760bfa8
[<c0087f70>] (kthread+0x0/0x98) from [<c006f5e8>] (do_exit+0x0/0x684)
r7:00000013 r6:c006f5e8 r5:c0087f70 r4:c7c33f04
Code: e3002312 e58d6000 e2833e16 eb0422d5 (e5963020)
---[ end trace f3d5e96f75c297b7 ]---
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Reviewed-by: Sergei Shtylyov <sshtylyov@mvista.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 0026e00523a85b90a92a93ddf6660939ecef3e54 upstream.
Recent changes in the usbhid layer exposed a bug in usbcore. If
CONFIG_USB_DYNAMIC_MINORS is enabled then an interface may be assigned
a minor number of 0. However interfaces that aren't registered as USB
class devices also have their minor number set to 0, during
initialization. As a result usb_find_interface() may return the
wrong interface, leading to a crash.
This patch (as1418) fixes the problem by initializing every
interface's minor number to -1. It also cleans up the
usb_register_dev() function, which besides being somewhat awkwardly
written, does not unwind completely on all its error paths.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Philip J. Turmel <philip@turmel.org>
Tested-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
Tested-by: Alex Riesen <raa.lkml@gmail.com>
Tested-by: Matthias Bayer <jackdachef@gmail.com>
CC: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Correctly name the irq_chip structure to fix an immediate failure when booting
as a xen pv_ops guest with a NULL pointer exception. The missing 'x' was
introduced in commit [fb412a178502dc498430723b082a932f797e4763] applied to
2.6.3[25]-stable trees. The commit to mainline was
[aaca49642b92c8a57d3ca5029a5a94019c7af69f] which did not have the problem.
Signed-off-by: James Dingwall <james@dingwall.me.uk>
Reported-by: Pawel Zuzelski <pawelz@pld-linux.org>
Tested-by: Pawel Zuzelski <pawelz@pld-linux.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d831692a1a8e9ceaaa9bb16bb3fc503b7e372558 upstream.
SIS 760 is listed in the device tables for both amd64-agp and sis-agp.
amd64-agp is apparently preferable since it has workarounds for some
BIOS misconfigurations that sis-agp doesn't handle.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 750e519da7b3f470fe1b5b55c8d8f52d6d6371e4 upstream.
PDC2026x chipsets need the same treatment as PDC20246 one.
This is completely untested but will hopefully fix UDMA issues
that people have been reporting against pata_pdc202xx_old for
the last couple of years.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit a75032e8772d13dab5e3501413d7e14a148281b4 upstream.
On Monday 04 January 2010 02:30:24 pm Russell King wrote:
> Found the problem - getting rid of the read of the alt status register
> after the command has been written fixes the UDMA CRC errors on write:
>
> @@ -676,7 +676,8 @@ void ata_sff_exec_command(struct ata_port *ap, const struct
> ata_taskfile *tf)
> DPRINTK("ata%u: cmd 0x%X\n", ap->print_id, tf->command);
>
> iowrite8(tf->command, ap->ioaddr.command_addr);
> - ata_sff_pause(ap);
> + ndelay(400);
> +// ata_sff_pause(ap);
> }
> EXPORT_SYMBOL_GPL(ata_sff_exec_command);
>
>
> This rather makes sense. The PDC20247 handles the UDMA part of the
> protocol. It has no way to tell the PDC20246 to wait while it suspends
> UDMA, so that a normal register access can take place - the 246 ploughs
> on with the register access without any regard to the state of the 247.
>
> If the drive immediately starts the UDMA protocol after a write to the
> command register (as it probably will for the DMA WRITE command), then
> we'll be accessing the taskfile in the middle of the UDMA setup, which
> can't be good. It's certainly a violation of the ATA specs.
Fix it by adding custom ->sff_exec_command method for UDMA33 chipsets.
Debugged-by: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 15e184afa83a45cf8bafdb9dc906b97a8fbc974f upstream.
Input core displays capabilities bitmasks in form of one or more longs printed
in hex form and separated by spaces. Unfortunately it does not work well
for 32-bit applications running on 64-bit kernels since applications expect
that number is "worth" only 32 bits when kernel advances by 64 bits.
Fix that by ensuring that output produced for compat tasks uses 32-bit units.
Reported-and-tested-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 0f4da2d77e1bf424ac36424081afc22cbfc3ff2b upstream.
"hostap: Protect against initialization interrupt" (which reinstated
"wireless: hostap, fix oops due to early probing interrupt")
reintroduced Bug 16111. This is because hostap_pci wasn't setting
dev->base_addr, which is now checked in prism2_interrupt. As a result,
initialization was failing for PCI-based hostap devices. This corrects
that oversight.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|