| Age | Commit message (Collapse) | Author |
|---|
|
The TXMAXP and TXCSR registers were not set correctly for
the BULK OUT endpoints causing issues in Full speed in
Host mode.
Change-Id: If5f3552235d8909adef4777f08d612df432d8709
|
|
if we have more endpoints configured than
enabled on fifo_mode, then we need to be
careful on save/restore context operations,
otherwise we will try to access uninitialized
__iomem pointer.
Change-Id: Iacca00fbb3b97bf6e25f7d7652dd9d53fb9adc16
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Change-Id: I2fcf46d1fc4b0cd4c61e5be3654c43b80db86015
|
|
commit d15b774c2920d55e3d58275c97fbe3adc3afde38 upstream.
Destroy _minor_idr when unloading the core dm module. (Found by kmemleak.)
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I3afbaddb7e6a637ddd5f997af76595ca124c3c38
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35680
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 286f367dad40beb3234a18c17391d03ba939a7f3 upstream.
Avoid dereferencing a NULL pointer if the number of feature arguments
supplied is fewer than indicated.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: Ibef3dfbf352c21d53f8af9c157c8e366725554ce
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35679
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 762a80d9fc9f690a3a35983f3b4619a220650808 upstream.
This patch makes dm-snapshot flush disk cache when writing metadata for
merging snapshot.
Without cache flushing the disk may reorder metadata write and other
data writes and there is a possibility of data corruption in case of
power fault.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: Iea48c7db57774e0e0b841a42c67ddd7e1f2fad62
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35678
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit bb91bc7bacb906c9f3a9b22744c53fa7564b51ba upstream.
For normal kernel pages, CPU cache is synchronized by the dma layer.
However, this is not done for pages allocated with vmalloc. If we do I/O
to/from vmallocated pages, we must synchronize CPU cache explicitly.
Prior to doing I/O on vmallocated page we must call
flush_kernel_vmap_range to flush dirty cache on the virtual address.
After finished read we must call invalidate_kernel_vmap_range to
invalidate cache on the virtual address, so that accesses to the virtual
address return newly read data and not stale data from CPU cache.
This patch fixes metadata corruption on dm-snapshots on PA-RISC and
possibly other architectures with caches indexed by virtual address.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I84af92c869c7d04c2d9bef967a1ecbe7ff0c7002
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35677
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit bea1906620ce72b63f83735c4cc2642b25ec54ae upstream.
Fix the usage of mod_timer() and make the driver usable. mod_timer() must
be called with an absolute timeout in jiffies. The old implementation
used a relative timeout thus the hardware watchdog was never triggered.
Signed-off-by: David Engraf <david.engraf@sysgo.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Wim Van sebroeck <wim@iguana.be>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I28560fcf7ac83005990b6c0f53b668e815f59f7e
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35675
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 71e0b38c2914018b01f3f08b43ee9e3328197699 upstream.
Reported-by: Wim Vander Schelden <wim@fixnum.org>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: Iecb702f1fb883095a06bace36db211b4dac64eec
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35673
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 8c2381af0d3ef62a681dac5a141b6dabb27bf2e1 upstream.
Currently, the hvc_console_print() function drops console output if the
hvc backend's put_chars() returns 0. This patch changes this behavior
to allow a retry through returning -EAGAIN.
This change also affects the hvc_push() function. Both functions are
changed to handle -EAGAIN and to retry the put_chars() operation.
If a hvc backend returns -EAGAIN, the retry handling differs:
- hvc_console_print() spins to write the complete console output.
- hvc_push() behaves the same way as for returning 0.
Now hvc backends can indirectly control the way how console output is
handled through the hvc console layer.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Acked-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I475d5ab252ac3fecbf7c5f12f0f71a738e944ee9
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35668
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit f2eb3cdf14457fccb14ae8c4d7d7cee088cd3957 upstream.
Kconfig allows enabling console support for the SC26xx driver even when
it's configured as a module resulting in a:
ERROR: "uart_console_device" [drivers/tty/serial/sc26xx.ko] undefined!
modpost error since the driver was merged in
eea63e0e8a60d00485b47fb6e75d9aa2566b989b [SC26XX: New serial driver for
SC2681 uarts] in 2.6.25. Fixed by only allowing console support to be
enabled if the driver is builtin.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I6e4dcfd3b5e941b28685623a1e00e39288b3fcf3
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35666
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 5568181f188ae9485a0cdbea5ea48f63d186a298 upstream.
Commit 4539c24fe4f92c09ee668ef959d3e8180df619b9 "tty/serial: Add
explicit PORT_TEGRA type" introduced separate flags describing the need
for IER bits UUE and RTOIE. Both bits are required for the XSCALE port
type. While that patch updated uart_config[] as required, the auto-probing
code wasn't updated to set the RTOIE flag when an XSCALE port type was
detected. This caused such ports to stop working. This patch rectifies
that.
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: Ib83b0c4b9127625a27902ca1477d9284add68178
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35665
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit e04f5f7e423018bcec84c11af2058cdce87816f3 upstream.
This patch (as1480) fixes a rather obscure bug in ehci-hcd. The
qh_update() routine needs to know the number and direction of the
endpoint corresponding to its QH argument. The number can be taken
directly from the QH data structure, but the direction isn't stored
there. The direction is taken instead from the first qTD linked to
the QH.
However, it turns out that for interrupt transfers, qh_update() gets
called before the qTDs are linked to the QH. As a result, qh_update()
computes a bogus direction value, which messes up the endpoint toggle
handling. Under the right combination of circumstances this causes
usb_reset_endpoint() not to work correctly, which causes packets to be
dropped and communications to fail.
Now, it's silly for the QH structure not to have direct access to all
the descriptor information for the corresponding endpoint. Ultimately
it may get a pointer to the usb_host_endpoint structure; for now,
adding a copy of the direction flag solves the immediate problem.
This allows the Spyder2 color-calibration system (a low-speed USB
device that sends all its interrupt data packets with the toggle set
to 0 and hance requires constant use of usb_reset_endpoint) to work
when connected through a high-speed hub. Thanks to Graeme Gill for
supplying the hardware that allowed me to track down this bug.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Graeme Gill <graeme@argyllcms.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: Icbba610e0c884dfed9b7b5979e7154524f15962f
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35662
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 81463c1d707186adbbe534016cd1249edeab0dac upstream.
MAX4967 USB power supply chip we use on our boards signals over-current when
power is not enabled; once it's enabled, over-current signal returns to normal.
That unfortunately caused the endless stream of "over-current change on port"
messages. The EHCI root hub code reacts on every over-current signal change
with powering off the port -- such change event is generated the moment the
port power is enabled, so once enabled the power is immediately cut off.
I think we should only cut off power when we're seeing the active over-current
signal, so I'm adding such check to that code. I also think that the fact that
we've cut off the port power should be reflected in the result of GetPortStatus
request immediately, hence I'm adding a PORTSCn register readback after write...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I16ba15af47c0aee3fdf62dc0780d9c6f98c54a94
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35661
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit f086ced17191fa0c5712539d2b680eae3dc972a1 upstream.
FCS could be GSM0_SOF, so will break state machine...
[This byte isn't quoted in any way so a SOF here doesn't imply an error
occurred.]
Signed-off-by: Alek Du <alek.du@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
[Trivial but best backported once its in 3.1rc I think]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: Id1ae181f64525d175ab2da4b5293ee374af75cb1
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35660
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 703f03c896fdbd726b809066ae279df513992f0e upstream.
As stated in drivers/mfd/cs5535-mfd.c, the mfd driver exposes the BARs
which then make the GPIO, MFGPT, ACPI, etc. all visible to the system.
So the dependencies of the MFGPT stuff have changed, and most people
expect Kconfig to bring in the necessary dependencies. Without them, the
module fails to load and most people don't understand why because the
details of the rewrite aren't captured anywhere most people who know to
look.
This dependency needs to be reflected in Kconfig.
Signed-off-by: Philip A. Prindeville <philipp@redfish-solutions.com>
Acked-by: Alexandros C. Couloumbis <alex@ozo.com>
Acked-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I425c4ebef4af385a6690b0bded63e0120f3decc7
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35644
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 27c46a2546c75c6814562e85b751e3d64c188ad5 upstream.
Fix module tainting message:
sigma: module license 'unspecified' taints kernel.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I667de00dfea15dbe02c084df1ec9be7d5a8036f7
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35643
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: QABUILD
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 07d0c38e7d84f911c72058a124c7f17b3c779a65 upstream.
Most smartarrays will tolerate it, but some new ones don't.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Note: this is a regression caused by commit 1ddd5049
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I7405c467260e860f6a4c791675904263b40c674a
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35642
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 864d296cf948aef0fa32b81407541572583f7572 upstream.
The function pci_enable_ari() may mistakenly set the downstream port
of a v1 PCIe switch in ARI Forwarding mode. This is a PCIe v2 feature,
and with an SR-IOV device on that switch port believing the switch above
is ARI capable it may attempt to use functions 8-255, translating into
invalid (non-zero) device numbers for that bus. This has been seen
to cause Completion Timeouts and general misbehaviour including hangs
and panics.
Acked-by: Don Dutile <ddutile@redhat.com>
Tested-by: Don Dutile <ddutile@redhat.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I5e23c6c40e2dacb661ffbbcf1a8c98034687d1b3
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35641
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 4639dd21e759e32125adc7171abf6cb8140d54cf upstream.
Need to add vddci setting to pm init as well as
resume. Fixes hangs on load on some boards.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=38754
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I7087d0a0ab2e95b13458d6705f9fc64e51031af2
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35627
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 5a96a899bbdee86024ab9ea6d02b9e242faacbed upstream.
DPEncoderService newer than 1.1 can't properly program the DP (display port)
link training. When facing such version use the DIGxEncoderControl method
instead. Fix DP link training on some R7XX.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I6f1ff7594795c32d7eccc6c892c54bb40b1073a7
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35626
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 6dd666333ddee39903d86f870d5c40d9f100e0cc upstream.
Those chips have crt2_ddc bus.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=39672
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I073e1575884accc31406cec1bb466f25d1c1c885
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35625
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit fec62c368b9c8b05d5124ca6c3b8336b537f26f3 upstream.
Most smartarrays tolerate it, but a few new ones don't.
Without this change some newer Smart Arrays will lock up
and i/o will grind to a halt.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: Ief78ccf0d95588a52e13839c9d02d4c56f18bc2a
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35624
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: QABUILD
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit b5b515445f4f5a905c5dd27e6e682868ccd6c09d upstream.
There's a code path in pmcraid that can be reached via device ioctl that
causes all sorts of ugliness, including heap corruption or triggering the
OOM killer due to consecutive allocation of large numbers of pages.
First, the user can call pmcraid_chr_ioctl(), with a type
PMCRAID_PASSTHROUGH_IOCTL. This calls through to
pmcraid_ioctl_passthrough(). Next, a pmcraid_passthrough_ioctl_buffer
is copied in, and the request_size variable is set to
buffer->ioarcb.data_transfer_length, which is an arbitrary 32-bit
signed value provided by the user. If a negative value is provided
here, bad things can happen. For example,
pmcraid_build_passthrough_ioadls() is called with this request_size,
which immediately calls pmcraid_alloc_sglist() with a negative size.
The resulting math on allocating a scatter list can result in an
overflow in the kzalloc() call (if num_elem is 0, the sglist will be
smaller than expected), or if num_elem is unexpectedly large the
subsequent loop will call alloc_pages() repeatedly, a high number of
pages will be allocated and the OOM killer might be invoked.
It looks like preventing this value from being negative in
pmcraid_ioctl_passthrough() would be sufficient.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: Ie8eff0b5acf02c6437b104a8b556e832745a9be9
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35623
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit bfe159a51203c15d23cb3158fffdc25ec4b4dda1 upstream.
USB surprise removal of sr is triggering an oops in
scsi_dispatch_command(). What seems to be happening is that USB is
hanging on to a queue reference until the last close of the upper
device, so the crash is caused by surprise remove of a mounted CD
followed by attempted unmount.
The problem is that USB doesn't issue its final commands as part of
the SCSI teardown path, but on last close when the block queue is long
gone. The long term fix is probably to make sr do the teardown in the
same way as sd (so remove all the lower bits on ejection, but keep the
upper disk alive until last close of user space). However, the
current oops can be simply fixed by not allowing any commands to be
sent to a dead queue.
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I5106bb4ec29746f65016511878286b5dc2c61324
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35622
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 2a350cab9daf9a46322d83b091bb05cf54ccf6ab upstream.
Noticed that when the sysfs interface of the SCSI SES
driver was used to request a fault indication the LED
flashed but the buzzer didn't sound. So it was doing
what REQUEST IDENT (locate) should do.
Changelog:
- fix the setting of REQUEST FAULT for the device slot
and array device slot elements in the enclosure control
diagnostic page
- note the potentially defective code that reads the
FAULT SENSED and FAULT REQUESTED bits from the enclosure
status diagnostic page
The attached patch is against git/scsi-misc-2.6
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I10846eccc26fd3f0ea6ea7da957289b16ec15d49
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35621
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 79b9677d885d1a792bc103f2febb06f91f92de43 upstream.
Some broken devices indicates that media has changed on every
GET_EVENT_STATUS_NOTIFICATION. This translates into MEDIA_CHANGE
uevent on every open() which lets udev run into a loop.
Verify GET_EVENT result against TUR and if it generates spurious
events for several times in a row, ignore the GET_EVENT events, and
trust only the TUR status.
This is the log of a USB stick with a (broken) fake CDROM drive:
scsi 5:0:0:0: Direct-Access SanDisk U3 Cruzer Micro 8.02 PQ: 0 ANSI: 0 CCS
sd 5:0:0:0: Attached scsi generic sg3 type 0
scsi 5:0:0:1: CD-ROM SanDisk U3 Cruzer Micro 8.02 PQ: 0 ANSI: 0
sd 5:0:0:0: [sdb] Attached SCSI removable disk
sr2: scsi3-mmc drive: 48x/48x tray
sr 5:0:0:1: Attached scsi CD-ROM sr2
sr 5:0:0:1: Attached scsi generic sg4 type 5
sr2: GET_EVENT and TUR disagree continuously, suppress GET_EVENT events
sd 5:0:0:0: [sdb] 31777279 512-byte logical blocks: (16.2 GB/15.1 GiB)
sd 5:0:0:0: [sdb] No Caching mode page present
sd 5:0:0:0: [sdb] Assuming drive cache: write through
sd 5:0:0:0: [sdb] No Caching mode page present
sd 5:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1
-tj: Updated to consider only spurious GET_EVENT events among
different types of disagreement and allow using TUR for kernel
event polling after GET_EVENT is ignored.
Reported-By: Markus Rathgeb maggu2810@googlemail.com
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: Ie0b76b2c07b0b2c98231f2ce0e68fdf11ed15d0f
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35620
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 82103978189e9731658cd32da5eb85ab7b8542b8 upstream.
This patch resulted from the discussion at
https://bugzilla.novell.com/show_bug.cgi?id=679277,
https://bugzilla.novell.com/show_bug.cgi?id=681840 .
Signed-off-by: Werner Fink <werner@novell.com>
Signed-off-by: Ankit Jain <jankit@suse.de>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I22e2c18079c0798404ae7113c2ca6a84496514b2
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35619
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 1288aa4e80145d9f4196df32f717b4c1cf6aab61 upstream.
A typo causes routine rtl92cu_phy_rf6052_set_cck_txpower() to test the
same condition twice. The problem was found using cppcheck-1.49, and the
proper fix was verified against the pre-mac80211 version of the code.
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: Ifd3c92620dd4fe558f89a7ea63ed8dc6d556fa06
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35612
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 5911e963d3718e306bcac387b83e259aa4228896 upstream.
If expander discovery fails (sas_discover_expander()), remove the
expander from the port device list (sas_ex_discover_expander()),
before freeing it. Else the list is corrupted and, e.g., when we
attempt to send SMP commands to other devices, the kernel oopses.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Reviewed-by: Jack Wang <jack_wang@usish.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I78c093bbdd8786a6bd711224b7e2007b6f99bcf4
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35611
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit fd1b6c4a693c9cac59375ffb36ffe5d7c079037c upstream.
SCSI scanning of a channel:id:lun triplet in Linux works as follows
(function scsi_scan_target() in drivers/scsi/scsi_scan.c):
- If lun == SCAN_WILD_CARD, send a REPORT LUNS command to the target
and process the result.
- If lun != SCAN_WILD_CARD, send an INQUIRY command to the LUN
corresponding to the specified channel:id:lun triplet to verify
whether the LUN exists.
So a SCSI driver must either take the channel and target id values in
account in its quecommand() function or it should declare that it only
supports one channel and one target id.
Currently the ib_srp driver does neither. As a result scanning the
SCSI bus via e.g. rescan-scsi-bus.sh causes many duplicate SCSI
devices to be created. For each 0:0:L device, several duplicates are
created with the same LUN number and with (C:I) != (0:0). Fix this by
declaring that the ib_srp driver only supports one channel and one
target id.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Acked-by: David Dillow <dillowda@ornl.gov>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: Ic3a3d7ca60895d7890ed1f275db2f2fc49f75aac
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35610
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
event queuing
commit 93b37905f70083d6143f5f4dba0a45cc64379a62 upstream.
Between open(2) of a /dev/fw* and the first FW_CDEV_IOC_GET_INFO
ioctl(2) on it, the kernel already queues FW_CDEV_EVENT_BUS_RESET events
to be read(2) by the client. The get_info ioctl is practically always
issued right away after open, hence this condition only occurs if the
client opens during a bus reset, especially during a rapid series of bus
resets.
The problem with this condition is twofold:
- These bus reset events carry the (as yet undocumented) @closure
value of 0. But it is not the kernel's place to choose closures;
they are privat to the client. E.g., this 0 value forced from the
kernel makes it unsafe for clients to dereference it as a pointer to
a closure object without NULL pointer check.
- It is impossible for clients to determine the relative order of bus
reset events from get_info ioctl(2) versus those from read(2),
except in one way: By comparison of closure values. Again, such a
procedure imposes complexity on clients and reduces freedom in use
of the bus reset closure.
So, change the ABI to suppress queuing of bus reset events before the
first FW_CDEV_IOC_GET_INFO ioctl was issued by the client.
Note, this ABI change cannot be version-controlled. The kernel cannot
distinguish old from new clients before the first FW_CDEV_IOC_GET_INFO
ioctl.
We will try to back-merge this change into currently maintained stable/
longterm series, and we only document the new behaviour. The old
behavior is now considered a kernel bug, which it basically is.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org>
Change-Id: I790e269d95885c36b492d735bf457d4c2b103387
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35609
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: QABUILD
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit d873d794235efa590ab3c94d5ee22bb1fab19ac4 upstream.
On Jun 27 Linus Torvalds wrote:
> The correct error code for "I don't understand this ioctl" is ENOTTY.
> The naming may be odd, but you should think of that error value as a
> "unrecognized ioctl number, you're feeding me random numbers that I
> don't understand and I assume for historical reasons that you tried to
> do some tty operation on me".
[...]
> The EINVAL thing goes way back, and is a disaster. It predates Linux
> itself, as far as I can tell. You'll find lots of man-pages that have
> this line in it:
>
> EINVAL Request or argp is not valid.
>
> and it shows up in POSIX etc. And sadly, it generally shows up
> _before_ the line that says
>
> ENOTTY The specified request does not apply to the kind of object
> that the descriptor d references.
>
> so a lot of people get to the EINVAL, and never even notice the ENOTTY.
[...]
> At least glibc (and hopefully other C libraries) use a _string_ that
> makes much more sense: strerror(ENOTTY) is "Inappropriate ioctl for
> device"
So let's correct this in the <linux/firewire-cdev.h> ABI while it is
still young, relative to distributor adoption.
Side note: We return -ENOTTY not only on _IOC_TYPE or _IOC_NR mismatch,
but also on _IOC_SIZE mismatch. An ioctl with an unsupported size of
argument structure can be seen as an unsupported version of that ioctl.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I9f0f4399a939bae2d5127ad5f76461660b711619
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35608
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: QABUILD
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 94c5b41b327e08de0ddf563237855f55080652a1 upstream.
This patch add the missing dma_unmap().
Which solved the critical issue of system freeze on heavy load.
Michal Miroslaw's rejected patch:
[PATCH v2 10/46] net: jme: convert to generic DMA API
Pointed out the issue also, thank you Michal.
But the fix was incorrect. It would unmap needed address
when low memory.
Got lots of feedback from End user and Gentoo Bugzilla.
https://bugs.gentoo.org/show_bug.cgi?id=373109
Thank you all. :)
Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: Ia65baf3b19f0ede8b9b328a2d0e274a9d80f6f22
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35606
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 37c962d195005d009e130e65a9e55960996c3cab upstream.
Every few minutes, this message would appear in syslog:
ieee80211 ph0: wl_ops_bss_info_changed: BSS idle: true (implement)
The message has been deleted, the driver requires no special action on this
particular event (). See: https://bugzilla.kernel.org/show_bug.cgi?id=38162
Reported-by: David Hill <hilld@binarystorm.net>
Signed-off-by: Roland Vossen <rvossen@broadcom.com>
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Reviewed-by: Franky Lin <frankyl@broadcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Change-Id: Ic81a0d84f2a0f767b1fe881f19e3b59caedccf6f
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35605
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 0472ade031b5c0c69c21cf96acf64c50eb9ba3c2 upstream.
Decryping frames on key_miss handling shouldn't be done for Michael
MIC failed frames as h/w would have already decrypted such frames
successfully anyway.
Also leaving CRC and PHY error(where the frame is going to be dropped
anyway), we are left to prcoess Decrypt error for which s/w decrypt is
selected anway and so having key_miss as a separate check doesn't serve
anything. So making key_miss handling mutually exlusive with other RX
status handling makes much more sense.
This patch addresses an issue with STA not reporting MIC failure events
resulting in STA being disconnected immediately.
Signed-off-by: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: If170874527c63528f357b451f8085cf0d813eb56
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35603
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 98ab5c7755b5cc9e1a8f2a57ccb22eac5e13ec50 upstream.
When ath6kl module was resumed while a scan was ongoing, for example during
suspend, the driver would crash in ar6k_cfg80211_scanComplete_event():
[26581.586440] Call Trace:
[26581.586440] [<f99ffeda>] ? ar6k_cfg80211_scanComplete_event+0xaa/0xaa [ath6kl]
[26581.586440] [<f9a0a020>] wmi_iterate_nodes+0xb/0xd [ath6kl]
[26581.586440] [<f99ffe78>] ar6k_cfg80211_scanComplete_event+0x48/0xaa [ath6kl]
[26581.586440] [<f9a038ae>] ar6000_close+0x77/0x7e [ath6kl]
[26581.586440] [<c139c25d>] __dev_close_many+0x87/0xab
[26581.586440] [<c139c30a>] dev_close_many+0x54/0xab
[26581.586440] [<c139c437>] rollback_registered_many+0xa5/0x19e
[26581.586440] [<c139c595>] rollback_registered+0x23/0x2f
[26581.586440] [<c139c5ed>] unregister_netdevice_queue+0x4c/0x69
[26581.586440] [<c139c6b2>] unregister_netdev+0x18/0x1f
[26581.586440] [<f9a00d4c>] ar6000_destroy+0xf8/0x115 [ath6kl]
[26581.586440] [<f9a0c765>] ar6k_cleanup_module+0x20/0x29 [ath6kl]
[26581.586440] [<c1062843>] sys_delete_module+0x181/0x1d9
[26581.586440] [<c105876b>] ? lock_release_holdtime+0x2b/0xcd
[26581.586440] [<c10b55dc>] ? sys_munmap+0x3b/0x42
[26581.586440] [<c14a99dc>] ? restore_all+0xf/0xf
[26581.586440] [<c14aeb6c>] sysenter_do_call+0x12/0x32
[26581.586440] Code: 89 53 6c 75 07 89 d8 e8 c0 ff ff ff 89 f0 e8 2c f2 a9 c7 5b 5e 5d c3 55 89 e5 57 56 53 89 c3 83 ec 08 89 55 f0 8d 78 04 89 4d ec <8b> b0 b8 00 00 00 46 89 b0 b8 00 00 00 89 f8 e8 ae ed a9 c7 8b
Fix the function not to iterate nodes when the scan is aborted. The nodes
are already freed when the module is being unloaded. Patch "ath6kl: Fix a
kernel panic furing suspend/resume" tried to fix this already but it wasn't
enough as a pointer was still used even after the null check. This patch
removes the null check entirely as the wmi structure is not accessed anymore
during module unload.
Also fix a bug where the status was checked as a bitfield with '&' operator.
But it's not a bitfield, just a regular (enum like) value.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: If6eebd3738c1b46378cec6f0d39a6067e4e2b25e
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35602
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit b42a7b1bc7c0f535dfe35b2c934f239c60bb8d30 upstream.
Drivers should not request firmware during resume. Fix ath6kl to
cache the firmware instead.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: Ib6cde5c196da33787a9bc6c5efa9315227c33856
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35601
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit e57ee01750c4954fd0b5e3c6109cd4b870880eb9 upstream.
Using __SPIN_LOCK_UNLOCKED for a dynamically allocated lock is wrong and
breaks the build with PREEMPT_RT_FULL.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Andrew Chew <achew@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I28d31fa586ddab4be785d4bba1c2420ea0981161
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35596
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 431e2bcc371016824f419baa745f82388258f3ee upstream.
Due to the hrtimer self rearming mode a user can DoS the machine simply
because it's starved by hrtimer events.
The RTC hrtimer is self rearming. We really need to limit the frequency
to something sensible.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Ben Greear <greearb@candelatech.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I9c1217a3d2e04c0be8a12b028d0a921c708b91d9
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35595
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit b830ac1d9a2262093bb0f3f6a2fd2a1c8278daf5 upstream.
Ben reported a lockup related to rtc. The lockup happens due to:
CPU0 CPU1
rtc_irq_set_state() __run_hrtimer()
spin_lock_irqsave(&rtc->irq_task_lock) rtc_handle_legacy_irq();
spin_lock(&rtc->irq_task_lock);
hrtimer_cancel()
while (callback_running);
So the running callback never finishes as it's blocked on
rtc->irq_task_lock.
Use hrtimer_try_to_cancel() instead and drop rtc->irq_task_lock while
waiting for the callback. Fix this for both rtc_irq_set_state() and
rtc_irq_set_freq().
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Ben Greear <greearb@candelatech.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I2b1a13e50b81eda763e175c58c7886e7c7b7f692
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35594
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 2c4f57d12df7696d65b0247bfd57fd082a7719e6 upstream.
The code checks the correctness of the parameters, but unconditionally
arms/disarms the hrtimer.
The result is that a random task might arm/disarm rtc timer and surprise
the real owner by either generating events or by stopping them.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Ben Greear <greearb@candelatech.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: If7bc32fff7a770c0e8a374f0e47cca6a0e6fcaa3
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35593
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 004c19682884d4f40000ce1ded53f4a1d0b18206 upstream.
This patch (as1477) fixes a problem affecting a few types of EHCI
controller. Contrary to what one might expect, these controllers
automatically stop their internal frame counter when no ports are
enabled. Since ehci-hcd currently relies on the frame counter for
determining when it should unlink QHs from the async schedule, those
controllers run into trouble: The frame counter stops and the QHs
never get unlinked.
Some systems have also experienced other problems traced back to
commit b963801164618e25fbdc0cd452ce49c3628b46c8 (USB: ehci-hcd unlink
speedups), which made the original switch from using the system clock
to using the frame counter. It never became clear what the reason was
for these problems, but evidently it is related to use of the frame
counter.
To fix all these problems, this patch more or less reverts that commit
and goes back to using the system clock. But this can't be done
cleanly because other changes have since been made to the scan_async()
subroutine. One of these changes involved the tricky logic that tries
to avoid rescanning QHs that have already been seen when the scanning
loop is restarted, which happens whenever an URB is given back.
Switching back to clock-based unlinks would make this logic even more
complicated.
Therefore the new code doesn't rescan the entire async list whenever a
giveback occurs. Instead it rescans only the current QH and continues
on from there. This requires the use of a separate pointer to keep
track of the next QH to scan, since the current QH may be unlinked
while the scanning is in progress. That new pointer must be global,
so that it can be adjusted forward whenever the _next_ QH gets
unlinked. (uhci-hcd uses this same trick.)
Simplification of the scanning loop removes a level of indentation,
which accounts for the size of the patch. The amount of code changed
is relatively small, and it isn't exactly a reversion of the
b963801164 commit.
This fixes Bugzilla #32432.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Matej Kenda <matejken@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I620d5e977656740a84fcbc88a03453a736d0624c
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35592
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 6ea12a04d295235ed67010a09fdea58c949e3eb0 upstream.
The NVIDIA series of OHCI controllers continues to be troublesome. A
few people using the MCP67 chipset have reported that even with the
most recent kernels, the OHCI controller fails to handle new
connections and spams the system log with "unable to enumerate USB
port" messages. This is different from the other problems previously
reported for NVIDIA OHCI controllers, although it is probably related.
It turns out that the MCP67 controller does not like to be kept in the
RESET state very long. After only a few seconds, it decides not to
work any more. This patch (as1479) changes the PCI initialization
quirk code so that NVIDIA controllers are switched into the SUSPEND
state after 50 ms of RESET. With no interrupts enabled and all the
downstream devices reset, and thus unable to send wakeup requests,
this should be perfectly safe (even for non-NVIDIA hardware).
The removal code in ohci-hcd hasn't been changed; it will still leave
the controller in the RESET state. As a result, if someone unloads
ohci-hcd and then reloads it, the controller won't work again until
the system is rebooted. If anybody complains about this, the removal
code can be updated similarly.
This fixes Bugzilla #22052.
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: Ifa987254cbfa82aceca05093544e29d46e039619
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35591
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 5c5781b3f88567211ecaaada13431af15c8c6003 upstream.
On some loaded windows hosts, we have discovered that the host may not
respond to guest requests within the specified time (one second)
as evidenced by the guest timing out. Fix this problem by increasing
the timeout to 5 seconds.
It may be useful to apply this patch to the 3.0 kernel as well.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: If27c75ecc09d3b259325d7ceb210d2b18409b7d2
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35590
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 2dfde9644fe8c4a77f9c73f95b25d6300ca23b5d upstream.
On some loaded windows hosts, we have discovered that the host may not
respond to guest requests within the specified time (one second)
as evidenced by the guest timing out. Fix this problem by increasing
the timeout to 5 seconds.
It may be useful to apply this patch to the 3.0 kernel as well.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: If7edbf48ff9fba1003dd549482c0b0f9cf48dc0f
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35589
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 46d2eb6d82ef44be58ae192c35e8cd52485f02eb upstream.
On some loaded windows hosts, we have discovered that the host may not
respond to guest requests within the specified time (one second)
as evidenced by the guest timing out. Fix this problem by increasing
the timeout to 5 seconds.
It may be useful to apply this patch to the 3.0 kernel as well.
the 3.0 kernel as well.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I0834737d04e5f73d3bb139973bdd6b1170ca562e
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35588
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 819cbb120eaec7e014e5abd029260db1ca8c5735 upstream.
driver_name and board_name are pointers to strings, not buffers of size
COMEDI_NAMELEN. Copying COMEDI_NAMELEN bytes of a string containing
less than COMEDI_NAMELEN-1 bytes would leak some unrelated bytes.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: If5220b6600a85e49d657e4dfe005d6cc4677f1f8
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35587
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
rtl8192se
commit 1c50bf7e415cf6ce9545dbecc2ac0d89d3916c53 upstream.
There are two devices with PCI ID 0x10ec:0x8192, namely RTL8192E and
RTL8192SE. The method of distinguishing them is by the revision ID
at offset 0x8 of the PCI configuration space. If the value is 0x10,
then the device uses rtl8192se for a driver.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I7bcf1251f21bac64374464ad8b5c4a2c61352245
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35586
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
commit 8547d4cc2b616e4f1dafebe2c673fc986422b506 upstream.
When unbinding a device on the host which was still attached on the
client, I got a NULL pointer dereference on the client. This turned out
to be due to kthread_stop() being called on an already dead kthread.
Here is how I was able to reproduce the problem:
server:# usbip bind -b 1-2
client:# usbip attach -h server -b 1-2
server:# usbip unbind -b 1-2
This patch fixes the problem by checking the kthread before attempting
to kill it, as it is done on the opposite side in
stub_shutdown_connection().
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change-Id: I9aaa60ee923506237a325afdaf908a5dbd7be60e
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/35585
Tested-by: Per VAHLNE <per.xx.vahlne@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
