Johan Hovold [Thu, 21 Mar 2013 11:37:15 +0000 (12:37 +0100)]
USB: mos7840: remove smp barriers from icount handling
Remove SMP memory barriers from icount handling and rely on the barriers
implied by wait_event, sleep and locks, while using the port lock to
guarantee atomicity.
This is a step in moving over to the generic icount implementations.
Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 21 Mar 2013 11:37:14 +0000 (12:37 +0100)]
USB: mos7720: remove broken get_icount and TIOCMIWAIT
Remove broken get_icount and TIOCMIWAIT support.
The driver has an icount structure but it is never been updated which
makes get_icount rather pointless and causes TIOCMIWAIT to always return
-EIO.
Note that the TIOCMIWAIT implementation has always been broken and would
not work even if icount support was added as it does not wait for the
modem status to change (does not use a work queue at all).
Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 21 Mar 2013 11:37:11 +0000 (12:37 +0100)]
USB: iuu_phoenix: remove unused MSR-wait queue
Remove unused, private modem-status wait queue from driver. If
TIOCMIWAIT is ever implemented it must not rely on a private wait queue
which may have been released when woken up.
Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove unused, private modem-status wait queue from driver. If
TIOCMIWAIT is ever implemented it must not rely on a private wait queue
which may have been released when woken up.
Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 21 Mar 2013 11:37:01 +0000 (12:37 +0100)]
USB: ch341: fix TIOCMIWAIT and disconnect
Use tty-port modem-status-change wait queue on which processes are woken
up at hangup and disconnect.
Currently a process waiting on modem-status changes will not be woken on
device disconnect as wake up was only done in dtr_rts which isn't
guaranteed to be called (e.g. if HUPCL is not set).
Also remove the redundant wake-up call from dtr_rts.
Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 21 Mar 2013 11:36:53 +0000 (12:36 +0100)]
USB: serial: wake up MSR-wait queue on disconnect
Make sure processes waiting for modem-status changes are woken up at
disconnect.
This is needed for custom subdriver TIOCMIWAIT-implementations which do
not yet handle hangup.
Even though processes on the tty-port wait queue are woken up at hangup
the wake-up call in usb-serial disconnect is still needed if a woken-up
process may go back to sleep (e.g. due to an incomplete
TIOCMIWAIT-implementation). If a disconnect occurs after a hangup, any
process waiting for changes will not be woken up a second time by the
tty-layer as the port will then have been disassociated from the tty.
Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add generic TIOCMIWAIT implementation which correctly handles hangup,
USB-device disconnect, does not rely on the deprecated sleep_on
functions and hence does not suffer from the races currently affecting
several usb-serial drivers.
This makes it much easier to add TIOCMIWAIT support to subdrivers as the
tricky details related to hangup and disconnect (e.g. atomicity, that
the private port data may have been freed when woken up, and waking up
processes at disconnect) have been handled once and for all.
To add support to a subdriver, simply set the tiocmiwait-port-operation
field, update the port icount fields and wake up any process sleeping on
the tty-port modem-status-change wait queue on changes.
Note that the tty-port initialised flag can be used to detect
disconnected as the port will be hung up as part of disconnect (and
cannot be reactivated due to the disconnected flag). However, as the
tty-port implementation currently wakes up processes before calling port
shutdown, the tty-hupping flag must also be checked to detect hangup for
now.
Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 21 Mar 2013 11:36:50 +0000 (12:36 +0100)]
USB: serial: clean up usb-serial bus device removal
Make sure to unregister the tty-device before calling subdriver
port_remove.
This way remove will reverse probe, and specifically any port data
released in port_remove will be available throughout tty unregister.
Note that the order currently does not matter as the tty-layer can make
callbacks also after the device has been unregistered. This is
handled in usb-serial core using the disconnected flag, which is
already set when usb-serial bus device remove is called.
Cc: Peter Hurley <peter@hurleysoftware.com> Reported-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 21 Mar 2013 11:36:48 +0000 (12:36 +0100)]
USB: fix urb-poison imbalance
The calls to usb_poison_urb and usb_unpoison_urb are expected to be
balanced. However, if an urb that has not yet been submitted is
poisoned, its reject counter will not be increased as its ep-field is
NULL. A consecutive call to unpoison will thus in fact poison the urb
as its reject counter will be decremented to a negative value,
effectively preventing the urb from being submitted.
Note that there are currently no in-kernel drivers affected by this.
Cc: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 21 Mar 2013 11:36:46 +0000 (12:36 +0100)]
USB: serial: fix port release
We should not call kill_traffic (and usb_kill_urb) once disconnect
returns. Any pending urbs are killed at disconnect and new submissions
are prevented by usb_unbind_interface (and usb_disable_interface).
Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 21 Mar 2013 11:36:45 +0000 (12:36 +0100)]
USB: cyberjack: fix disconnect handling
Make sure the interrupt urb submitted in port_probe is killed in
port_remove.
The interrupt-urb completion handler references the port and may get
called after port_remove has returned and the port has been
unregistered (although this is currently prevented by usb-serial core as
we are using a non-private urb).
Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 21 Mar 2013 11:36:44 +0000 (12:36 +0100)]
USB: serial: clean up generic-operation handling
Most USB serial drivers are, and should be, using as much of the generic
implementation as possible.
Rename the fixup_generic function to a more descriptive name.
Reword the related debug message in a more neutral tone (and remember to
add the missing newline).
Finally, move the operations initialisation to after the initial sanity
checks.
Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no need for the generic disconnect callback to stop the read
and write urbs a second time as this has already been taken care of by
close (which is called from hangup as part of disconnect).
Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 21 Mar 2013 11:36:18 +0000 (12:36 +0100)]
USB: ftdi_sio: remove obsolete port data refcounting
Remove the port data refcounting and release the private data
explicitly at port remove.
The port data refcounting was used to make sure the port data was not
freed until the last tty reference was closed. Since moving over to tty
ports, the underlying assumptions are no longer valid as close is now
called as part of tty port shutdown, which can occur before the final
tty reference is dropped on device disconnect.
This means that the private port data refcounting is now completely
useless, as the last reference will always be dropped on port_remove.
Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Fri, 22 Mar 2013 17:32:10 +0000 (13:32 -0400)]
USB: EHCI: remove unused variable in unlink_empty_async()
This patch (as1669) removes the check_unlinks_later flag in ehci-hcd's
unlink_empty_async(). It wasn't being used for anything and should
have been removed in an earlier patch, but I forgot about it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Fri, 22 Mar 2013 17:31:58 +0000 (13:31 -0400)]
USB: EHCI: improve end_unlink_async()
This patch (as1665) changes the way ehci-hcd's end_unlink_async()
routine works in order to avoid recursive execution and to be more
efficient:
Now when an IAA cycle ends, a new one gets started up right
away (if it is needed) instead of waiting until the
just-unlinked QH has been processed.
The async_iaa list is renamed to async_idle, which better
expresses its new purpose: It is now the list of QHs which are
now completely idle and are waiting to be processed by
end_unlink_async().
A new flag is added to track whether an IAA cycle is in
progress, because the list formerly known as async_iaa no
longer stores the QHs waiting for the IAA to finish.
The decision about how many QHs to process when an IAA cycle
ends is now made at the end of the cycle, when we know the
current state of the hardware, rather than at the beginning.
This means a bunch of logic got moved from start_iaa_cycle()
to end_unlink_async().
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Fri, 22 Mar 2013 17:31:45 +0000 (13:31 -0400)]
USB: EHCI: convert singly-linked lists to list_heads
This patch (as1664) converts ehci-hcd's async_unlink, async_iaa, and
intr_unlink from singly-linked lists to standard doubly-linked
list_heads. Originally it didn't seem necessary to use list_heads,
because items are always added to and removed from these lists in FIFO
order. But now with more list processing going on, it's easier to use
the standard routines than continue with a roll-your-own approach.
I don't know if the code ends up being notably shorter, but the
patterns will be more familiar to any kernel hacker.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Fri, 22 Mar 2013 17:31:29 +0000 (13:31 -0400)]
USB: EHCI: consolidate code in ehci_urb_dequeue()
This patch (as1668) consolidates two nearly identical code paths in
ehci_urb_dequeue(). The test for !qh can be removed because it will
never succeed; the fact that usb_hcd_check_unlink_urb() returned 0
means that urb must be queued and therefore urb->hcpriv must point to
a QH.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Fri, 22 Mar 2013 17:31:11 +0000 (13:31 -0400)]
USB: EHCI: split needs_rescan into two flags
This patch (as1662) does some more QH-related cleanup in ehci-hcd.
The qh->needs_rescan flag is currently used for two different
purposes; the patch replaces it with two separate flags for greater
clarity: qh->dequeue_during_giveback indicates that a completion
handler dequeued an URB (implying that a rescan is needed), and
qh->exception indicates that the QH is in an exceptional state
requiring an unlink (either it encountered an I/O error or an unlink
was requested).
The new flags get set where the dequeue, exception, or unlink request
occurred, rather than where the unlink is started. This is so that in
the future, if we need to, we will be able to tell apart unlinks that
truly were required from those that were carried out merely because
the QH wasn't being used.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Fri, 22 Mar 2013 17:30:56 +0000 (13:30 -0400)]
USB: EHCI: change return value of qh_completions()
This patch (as1658) cleans up the usage of qh_completions() in
ehci-hcd. Currently the function's return value indicates whether any
URBs were given back; the idea was that the caller can scan the QH
over again to handle any URBs that were dequeued by a completion
handler. This is not necessary; when qh_completions() is ready to
give back dequeued URBs, it does its own rescanning.
Therefore the new return value will be a flag indicating whether the
caller needs to unlink the QH. This is more convenient than forcing
the caller to check qh->needs_rescan, and it makes a lot more sense --
why should "needs_rescan" imply that an unlink is needed? The callers
are also changed to remove the unneeded rescans.
Lastly, the check for whether qh->qtd_list is non-empty is removed
from the start of qh_completions(). Two of the callers have to make
this test anyway, so the same test can simply be added to the other
two callers.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Fri, 22 Mar 2013 17:30:43 +0000 (13:30 -0400)]
USB: EHCI: changes related to qh_refresh()
This patch (as1638) makes several changes to the ehci-hcd driver, all
related to the qh_refresh() function. This function must be called
whenever an idle QH gets linked back into either the async or the
periodic schedule.
Change a BUG_ON() in the qh_update routine to a WARN_ON().
Since this code runs in atomic context, a BUG_ON() would
immediately freeze the whole system.
Remove two unneeded calls to qh_refresh(), one when a QH is
initialized and one when a QH becomes idle. Adjust the
adjacent comments accordingly.
Move the qh_refresh() and qh_link_periodic() calls for new
interrupt URBs to after the new TDs have been added.
As a result of the previous two changes, qh_refresh() is never
called when the qtd_list is empty. The corresponding check in
qh_refresh() can be removed, along with an indentation level.
These changes should not cause any alteration of behavior.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Du Xing [Wed, 20 Mar 2013 12:47:46 +0000 (20:47 +0800)]
USB: usb-skeleton.c: fix blocked forever in skel_read
In skel_read,the reader blocked in wait_for_completion before submit
bulk in urb.
Using processed_urb is for retaining the completion in the case that
previous interruptible wait in skel_read was interrupted and complete
before next skel_read. Replacing completion with waitqueue can avoid
working around the counting nature of completions
and fix the bug.
Signed-off-by: Du Xing duxing2007@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Sun, 17 Mar 2013 20:00:06 +0000 (21:00 +0100)]
USB: cdc-wdm: implement IOCTL_WDM_MAX_COMMAND
Userspace applications need to know the maximum supported message
size.
The cdc-wdm driver translates between a character device stream
and a message based protocol. Each message is transported as a
usb control message with no further encapsulation or syncronization.
Each read or write on the character device should translate to
exactly one usb control message to ensure that message boundaries
are kept intact. That means that the userspace application must
know the maximum message size supported by the device and driver,
making this size a vital part of the cdc-wdm character device API.
CDC WDM and CDC MBIM functions export the maximum supported
message size through CDC functional descriptors. The cdc-wdm and
cdc_mbim drivers will parse these descriptors and use the value
chosen by the device. The only current way for a userspace
application to retrive the value is by duplicating the descriptor
parsing. This is an unnecessary complex task, and application
writers are likely to postpone it, using a fixed value and adding
a "todo" item.
QMI functions have no way to tell the host what message size they
support. The qmi_wwan driver use a fixed value based on protocol
recommendations and observed device behaviour. Userspace
applications must know and hard code the same value. This scheme
will break if we ever encounter a QMI device needing a device
specific message size quirk. We are currently unable to support
such a device because using a non default size would break the
implicit userspace API.
The message size is currently a hidden attribute of the cdc-wdm
userspace API. Retrieving it is unnecessarily complex, increasing
the possibility of drivers and applications using different limits.
The resulting errors are hard to debug, and can only be replicated
on identical hardware.
Exporting the maximum message size from the driver simplifies the
task for the userspace application, and creates a unified
information source independent of device and function class. It also
serves to document that the message size is part of the cdc-wdm
userspace API.
This proposed API extension has been presented for the authors of
userspace applications and libraries using the current API: libmbim,
libqmi, uqmi, oFono and ModemManager. The replies were:
Aleksander Morgado:
"We do really need max message size for MBIM; and as you say, it may be
good to have the max message size info also for QMI, so the new ioctl
seems a good addition. So +1 from my side, for what it's worth."
Dan Williams:
"Yeah, +1 here. I'd prefer the sysfs file, but the fact that that
doesn't work for fd passing pretty much kills it."
No negative replies are so far received.
Cc: Aleksander Morgado <aleksander@lanedo.com> Cc: Dan Williams <dcbw@redhat.com> Signed-off-by: Bjørn Mork <bjorn@mork.no> Acked-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Linares [Mon, 25 Mar 2013 10:50:27 +0000 (10:50 +0000)]
USB: hub: Avoid NULL pointer dereference when hub doesn't have any ports
Return an error if hub->descriptor->bNbrPorts==0. Without this additional
check, we can end up doing a "hub->ports = kzalloc(0, GFP_KERNEL)".
This hub->ports pointer will therefore be non-NULL and will be used.
Example of dmesg:
INIT: usb 1-1: New USB device found, idVendor=0424, idProduct=2512
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-1:1.0: USB hub found
version 2.86 bootinghub 1-1:1.0: 0 ports detected
Unable to handle kernel NULL pointer dereference at virtual address 00000010
Signed-off-by: David Linares <dlinares.linux@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ming Lei [Fri, 15 Mar 2013 04:08:59 +0000 (12:08 +0800)]
usbnet: smsc75xx: don't recover device if suspend fails in system sleep
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.
Also add comments on this case.
Acked-by: David S. Miller <davem@davemloft.net> Cc: Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ming Lei [Fri, 15 Mar 2013 04:08:58 +0000 (12:08 +0800)]
usbnet: smsc95xx: don't recover device if suspend fails in system sleep
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.
Also add comments on the case.
Acked-by: David S. Miller <davem@davemloft.net> Cc: Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ming Lei [Fri, 15 Mar 2013 04:08:57 +0000 (12:08 +0800)]
usbnet: qmi_wwan: comments on suspend failure
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch comments on the case and requires that both
usbnet_suspend() and subdriver->suspend() MUST return 0 in
system sleep context.
Acked-by: David S. Miller <davem@davemloft.net> Acked-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ming Lei [Fri, 15 Mar 2013 04:08:56 +0000 (12:08 +0800)]
usbnet: cdc_mbim: comments on suspend failure
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch comments on the case and requires that both
usbnet_suspend() and subdriver->suspend() MUST return 0 in
system sleep context.
Acked-by: David S. Miller <davem@davemloft.net> Acked-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ming Lei [Fri, 15 Mar 2013 04:08:55 +0000 (12:08 +0800)]
USBHID: don't recover device if suspend fails in system sleep
If suspend callback fails in system sleep context, usb core will
ignore the failure and let the system sleep go ahead further, so this
patch doesn't recover device under this situation, otherwise
may cause resume() confused.
Acked-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ming Lei [Fri, 15 Mar 2013 04:08:54 +0000 (12:08 +0800)]
USB: serial: comments on suspend failure
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch comments on the case and requires that serial->type->suspend()
MUST return 0 in system sleep context.
Acked-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ming Lei [Fri, 15 Mar 2013 04:08:53 +0000 (12:08 +0800)]
USB: adds comment on suspend callback
This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
device for this case and let resume/reset_resume callback
handle the suspend failure if needed.
Also kerneldoc for usb_suspend_both() is updated with the
fact.
Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull SCSI target fixes from Nicholas Bellinger:
"These are mostly minor fixes this time around. The iscsi-target CHAP
big-endian bugfix and bump FD_MAX_SECTORS=2048 default patch to allow
1MB sized I/Os for FILEIO backends on >= v3.5 code are both CC'ed to
stable.
Also, there is a persistent reservations regression that has recently
been reported for >= v3.8.x code, that is currently being tracked down
for v3.9."
* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
target/pscsi: Reject cross page boundary case in pscsi_map_sg
target/file: Bump FD_MAX_SECTORS to 2048 to handle 1M sized I/Os
tcm_vhost: Flush vhost_work in vhost_scsi_flush()
tcm_vhost: Add missed lock in vhost_scsi_clear_endpoint()
target: fix possible memory leak in core_tpg_register()
target/iscsi: Fix mutual CHAP auth on big-endian arches
target_core_sbc: use noop for SYNCHRONIZE_CACHE
Linus Torvalds [Sat, 23 Mar 2013 22:49:49 +0000 (15:49 -0700)]
Merge tag 'md-3.9-fixes' of git://neil.brown.name/md
Pull md fixes from NeilBrown:
"A few bugfixes for md
- recent regressions in raid5
- recent regressions in dmraid
- a few instances of CONFIG_MULTICORE_RAID456 linger
Several tagged for -stable"
* tag 'md-3.9-fixes' of git://neil.brown.name/md:
md: remove CONFIG_MULTICORE_RAID456 entirely
md/raid5: ensure sync and DISCARD don't happen at the same time.
MD: Prevent sysfs operations on uninitialized kobjects
MD RAID5: Avoid accessing gendisk or queue structs when not available
md/raid5: schedule_construction should abort if nothing to do.
Linus Torvalds [Sat, 23 Mar 2013 19:33:36 +0000 (12:33 -0700)]
Merge tag 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
Pull libata updates from Jeff Garzik:
"Simple stuff. See one-line summaries."
* tag 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
pata_samsung_cf: use module_platform_driver_probe()
[libata] Avoid specialized TLA's in ZPODD's Kconfig
libata-acpi.c: fix copy and paste mistake in ata_acpi_register_power_resource
sata_fsl: Remove redundant NULL check before kfree
ahci: Add Device IDs for Intel Wellsburg PCH
ata_piix: Add MODULE_PARM_DESC to prefer_ms_hyperv
Linus Torvalds [Sat, 23 Mar 2013 19:32:14 +0000 (12:32 -0700)]
Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
"One bugfix for the tegra driver. Two updates regarding email
addresses and MAINTAINERS which I like to have up-to-date so people
can be reached immediately. While we are here, there is on PCI_ID
addition."
* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
MAINTAINERS: add maintainer entry for atmel i2c driver
i2c: Fix my e-mail address in drivers and documentation
i2c: iSMT: add Intel Avoton DeviceIDs
i2c: tegra: check the clk_prepare_enable() return value
Linus Torvalds [Sat, 23 Mar 2013 19:30:39 +0000 (12:30 -0700)]
Merge git://www.linux-watchdog.org/linux-watchdog
Pull watchdog fixes from Wim Van Sebroeck:
"Fix a boot issues and correct the AcpiMmioSel bitmask in the
sp5100_tco watchdog device driver"
* git://www.linux-watchdog.org/linux-watchdog:
watchdog: sp5100_tco: Set the AcpiMmioSel bitmask value to 1 instead of 2
watchdog: sp5100_tco: Remove code that may cause a boot failure
Torsten Duwe [Sat, 23 Mar 2013 14:39:34 +0000 (15:39 +0100)]
KMS: fix EDID detailed timing frame rate
When KMS has parsed an EDID "detailed timing", it leaves the frame rate
zeroed. Consecutive (debug-) output of that mode thus yields 0 for
vsync. This simple fix also speeds up future invocations of
drm_mode_vrefresh().
While it is debatable whether this qualifies as a -stable fix I'd apply
it for consistency's sake; drm_helper_probe_single_connector_modes()
does the same thing already for all probed modes.
Torsten Duwe [Sat, 23 Mar 2013 14:38:22 +0000 (15:38 +0100)]
KMS: fix EDID detailed timing vsync parsing
EDID spreads some values across multiple bytes; bit-fiddling is needed
to retrieve these. The current code to parse "detailed timings" has a
cut&paste error that results in a vsync offset of at most 15 lines
instead of 63.
See
http://en.wikipedia.org/wiki/EDID
and in the "EDID Detailed Timing Descriptor" see bytes 10+11 show why
that needs to be a left shift.
Pull NVMe driver update from Matthew Wilcox:
"These patches have mostly been baking for a few months; sorry I didn't
get them in during the merge window. They're all bug fixes, except
for the addition of the SMART log and the addition to MAINTAINERS."
* git://git.infradead.org/users/willy/linux-nvme:
NVMe: Add namespaces with no LBA range feature
MAINTAINERS: Add entry for the NVMe driver
NVMe: Initialize iod nents to 0
NVMe: Define SMART log
NVMe: Add result to nvme_get_features
NVMe: Set result from user admin command
NVMe: End queued bio requests when freeing queue
NVMe: Free cmdid on nvme_submit_bio error
Linus Torvalds [Fri, 22 Mar 2013 23:41:44 +0000 (16:41 -0700)]
Merge branch 'akpm' (fixes from Andrew)
Merge misc fixes from Andrew Morton.
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
mqueue: sys_mq_open: do not call mnt_drop_write() if read-only
mm/hotplug: only free wait_table if it's allocated by vmalloc
dma-debug: update DMA debug API to better handle multiple mappings of a buffer
dma-debug: fix locking bug in check_unmap()
drivers/rtc/rtc-at91rm9200.c: use a variable for storing IMR
drivers/video/ep93xx-fb.c: include <linux/io.h> for devm_ioremap()
drivers/rtc/rtc-da9052.c: fix for rtc device registration
mm: zone_end_pfn is too small
poweroff: change orderly_poweroff() to use schedule_work()
mm/hugetlb: fix total hugetlbfs pages count when using memory overcommit accouting
printk: Provide a wake_up_klogd() off-case
irq_work.h: fix warning when CONFIG_IRQ_WORK=n
Vladimir Davydov [Fri, 22 Mar 2013 22:04:51 +0000 (15:04 -0700)]
mqueue: sys_mq_open: do not call mnt_drop_write() if read-only
mnt_drop_write() must be called only if mnt_want_write() succeeded,
otherwise the mnt_writers counter will diverge.
mnt_writers counters are used to check if remounting FS as read-only is
OK, so after an extra mnt_drop_write() call, it would be impossible to
remount mqueue FS as read-only. Besides, on umount a warning would be
printed like this one:
=====================================
[ BUG: bad unlock balance detected! ]
3.9.0-rc3 #5 Not tainted
-------------------------------------
a.out/12486 is trying to release lock (sb_writers) at:
mnt_drop_write+0x1f/0x30
but there are no more locks to release!
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Cc: Doug Ledford <dledford@redhat.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Alexander Duyck [Fri, 22 Mar 2013 22:04:49 +0000 (15:04 -0700)]
dma-debug: update DMA debug API to better handle multiple mappings of a buffer
There were reports of the igb driver unmapping buffers without calling
dma_mapping_error. On closer inspection issues were found in the DMA
debug API and how it handled multiple mappings of the same buffer.
The issue I found is the fact that the debug_dma_mapping_error would
only set the map_err_type to MAP_ERR_CHECKED in the case that the was
only one match for device and device address. However in the case of
non-IOMMU, multiple addresses existed and as a result it was not setting
this field once a second mapping was instantiated. I have resolved this
by changing the search so that it instead will now set MAP_ERR_CHECKED
on the first buffer that matches the device and DMA address that is
currently in the state MAP_ERR_NOT_CHECKED.
A secondary side effect of this patch is that in the case of multiple
buffers using the same address only the last mapping will have a valid
map_err_type. The previous mappings will all end up with map_err_type
set to MAP_ERR_CHECKED because of the dma_mapping_error call in
debug_dma_map_page. However this behavior may be preferable as it means
you will likely only see one real error per multi-mapped buffer, versus
the current behavior of multiple false errors mer multi-mapped buffer.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Cc: Joerg Roedel <joro@8bytes.org> Reviewed-by: Shuah Khan <shuah.khan@hp.com> Tested-by: Shuah Khan <shuah.khan@hp.com> Cc: Jakub Kicinski <kubakici@wp.pl> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Alexander Duyck [Fri, 22 Mar 2013 22:04:48 +0000 (15:04 -0700)]
dma-debug: fix locking bug in check_unmap()
In check_unmap() it is possible to get into a dead-locked state if
dma_mapping_error is called. The problem is that the bucket is locked in
check_unmap, and locked again by debug_dma_mapping_error which is called
by dma_mapping_error. To resolve that we must release the lock on the
bucket before making the call to dma_mapping_error.
[akpm@linux-foundation.org: restore 80-col trickery to be consistent with the rest of the file] Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Cc: Joerg Roedel <joro@8bytes.org> Reviewed-by: Shuah Khan <shuah.khan@hp.com> Tested-by: Shuah Khan <shuah.khan@hp.com> Cc: Jakub Kicinski <kubakici@wp.pl> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Nicolas Ferre [Fri, 22 Mar 2013 22:04:47 +0000 (15:04 -0700)]
drivers/rtc/rtc-at91rm9200.c: use a variable for storing IMR
On some revisions of AT91 SoCs, the RTC IMR register is not working.
Instead of elaborating a workaround for that specific SoC or IP version,
we simply use a software variable to store the Interrupt Mask Register
and modify it for each enabling/disabling of an interrupt. The overhead
of this is negligible anyway.
The interrupt mask register (IMR) for the RTC is broken on the AT91SAM9x5
sub-family of SoCs (good overview of the members here:
http://www.eewiki.net/display/linuxonarm/AT91SAM9x5 ). The "user visible
effect" is the RTC doesn't work.
That sub-family is less than two years old and only has devicetree (DT)
support and came online circa lk 3.7 . The dust is yet to settle on the
DT stuff at least for AT91 SoCs (translation: lots of stuff is still
broken, so much that it is hard to know where to start).
The fix in the patch is pretty simple: just shadow the silicon IMR
register with a variable in the driver. Some older SoCs (pre-DT) use the
the rtc-at91rm9200 driver (e.g. obviously the AT91RM9200) and they should
not be impacted by the change. There shouldn't be a large volume of
interrupts associated with a RTC.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Reported-by: Douglas Gilbert <dgilbert@interlog.com> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Cc: Ludovic Desroches <ludovic.desroches@atmel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
projects / mirror_ubuntu-disco-kernel.git / log