The UAS driver requires SG support by the HCD operating the device. This
patch stops UAS from operating on a HCD without sg support and prints a
message to let him know.
The spec says:
|For [USB2] backward compatibility, the device shall present [BOT] as
|alternate interface zero (primary) and [UAS] as alternate interface one
|(secondary). A device which does not need backward compatibility with
|[BOT] shall present [UAS] as alternate interface zero. In [USB2]
|systems, the [BOT] driver or an associated filter driver may need to
|issue a SET INTERFACE request for alternate interface one and then allow
|the [UAS] driver to load.
If the user used usb_modeswitch to switch to UAS then he can go back to
BOT or use a different HCD. In case UAS is the only interface then there
is currently no way out.
In future usb_sg_wait() should be extended to provide a non-blocking
interface so it can work with the UAS driver.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Added a check on the direct register access.
Checks that the address is in the lower ragnge (0x0-0x2000),
which belongs to CSR, HBUS and FH registers.
Signed-off-by: Amit Beka <amit.beka@intel.com>
Signed-off-by: Wey-Yi W Guy <wey-yi.w.guy@intel.com>
smatch correctly complains:
iwl-trans-pcie.c +1528 iwl_trans_pcie_start_hw(50) warn: 'trans->irq' was not released on error
Fix it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi W Guy <wey-yi.w.guy@intel.com>
The routines dealing with the ucode are spread through several files.
Move them all to the same file and create a iwl-ucode.h file with the
ucode file definitions.
Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
There is nothing device specific in the initialization of the
bcast_sta_id so move it to the common inititalization routine.
Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The message was misleading when a queue is deactivated. The fifo
number is irrelevant then, so don't print it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This trans_ops->stop_hw leaves the RFKILL interrupt enabled,
we can call that one instead of enable_rfkill_int. By that,
we reduce the numbers of acceesses to the NIC from the upper
layers.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Get this information from the transport layer which is now in charge
of the APM too.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This handler was called from the transport layer only. Merge it
to the transport's apm_init.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Now there is only one transport function that launch a specific fw:
trans_ops->start_fw. This one replaces trans_ops->start_device and
trans_ops->kick_nic. The code that actually loads the fw to the
device has been moved to the transport specific code.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This handler stops the HW and puts it in low power state.
It will allow to clean up the flows in the upper layers.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
From now on, the transport layer in charge of providing access to the
device. So change all the driver to give a pointer to the transport
to all the low level functions that actually access the device.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
All DAPM routes are configured via device tree, and there is no need in
DAPM route structures in board file.
Signed-off-by: Leon Romanovsky <leon@leon.nu>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This patch is adding device tree support of headset autodetection on PAZ00 board.
Signed-off-by: Leon Romanovsky <leon@leon.nu>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Change the way we alloc the transport on the way.
Since the transport is allocated from a bus specific area, we can
give the bus specific parameters (i.e. pci_dev for PCI) to the
transport. This will be useful when the bus layer will be killed.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Allocating the shrd area dynamically will allow more agility
while revamping the flows.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Fix for a -Warray-bounds warning. mixer_notify_update() tries to
write to ((CAPI_MSG *) msg)->info.facility_req.structs[3] while
structs is defined as byte structs[1]. Set all 'structs' which are
part of the typdefs in the info union to 'byte structs[0]'.
v2: set all info.*.structs to byte structs[0]
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
We've moving to a model where dst_entry objects to not have
a reference to the associated neighbour entry, instead such
neighbours must be looked up on-demand.
Here in qeth_l3_fill_header() it's actually much simpler to
use the information in the route itself. The code is
already conditionalized upon protocol type.
Signed-off-by: David S. Miller <davem@davemloft.net>
Tested-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
There is no link between the two. Ensure that the NIC is on outside
the code of the EEPROM handling.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This patch connects IDI transport to driver. It does so
by using a number of ifdefs at this stage.
IDI is a new transport that is under development.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Define a new handler in the transport layer API: fw_alive.
Move iwl_reset_ict to this new handler, and move the content
of tx_start to this handler.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The receive FIFO wakeup latency estimate in the omap-serial driver is
three orders of magnitude too small. This effectively prevents the
MPU from going to a low-power state when CONFIG_CPU_IDLE=y. This is a
major power management regression and masks some other FIFO-related
bugs in the driver.
Fix by correcting the most egregious problem in the RX wakeup latency
estimate. There are several other flaws in the estimator; these will
be fixed by a separate patch series intended for 3.4.
The difference in low-power states with this patch can be observed via
debugfs in pm_debug/count.
This estimate does not have any effect when CONFIG_CPU_IDLE=n.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Alan Cox <alan@linux.intel.com>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prevent OMAP UARTs from going idle while they are still transferring
data in PIO mode. This works around an oversight in the OMAP UART
hardware present in OMAP34xx and earlier: an idle UART won't send a
wakeup when the TX FIFO threshold is reached. This causes long delays
during data transmission when the MPU powerdomain enters a low-power
mode. The MPU interrupt controller is not able to respond to
interrupts when it's in a low-power state, so the TX buffer is not
refilled until another wakeup event occurs.
This fix changes the erratum i291 DMA idle workaround. Rather than
toggling between force-idle and no-idle, it will toggle between
smart-idle and no-idle. The important part of the workaround is the
no-idle part, so this shouldn't result in any change in behavior.
This fix should work on all OMAP UARTs. Future patches intended for
the 3.4 merge window will make this workaround conditional on a
"feature" flag, and will use the OMAP36xx+ TX event wakeup support.
Thanks to Kevin Hilman <khilman@ti.com> for mentioning the erratum i291
workaround, which led to the development of this approach.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the (default) PIO mode, use a one-byte RX FIFO threshold. The OMAP
UART IP blocks do not appear to be capable of waking the system under
an RX timeout condition. Since the previous RX FIFO threshold was 16
bytes, this meant that omap-serial.c did not become aware of any
received data until all those bytes arrived or until another UART
interrupt occurred. This made the serial console and presumably other
serial applications (GPS, serial Bluetooth) unusable or extremely
slow. A 1-byte RX FIFO threshold also allows the MPU to enter a
low-power consumption state while waiting for the FIFO to fill.
This can be verified using the serial console by comparing the
behavior when "0123456789abcde" is pasted in from another window, with
the behavior when "0123456789abcdef" is pasted in. Since the former
string is less than sixteen bytes long, the string is not echoed for
some time, while the latter string is echoed immediately.
DMA operation is unaffected by this patch.
Thanks to Russell King - ARM Linux <linux@arm.linux.org.uk> for some
additional information on the standard behavior of the RX timeout
event, which was used to improve this commit description.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Govindraj Raja <govindraj.r@ti.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The rbd_client structure uses a kref to arrange for cleaning up and
freeing an instance when its last reference is dropped. The cleanup
routine is rbd_client_release(), and one of the things it does is
delete the rbd_client from rbd_client_list. It acquires node_lock
to do so, but the way it is done is still not safe.
The problem is that when attempting to reuse an existing rbd_client,
the structure found might already be in the process of getting
destroyed and cleaned up.
Here's the scenario, with "CLIENT" representing an existing
rbd_client that's involved in the race:
Thread on CPU A | Thread on CPU B
--------------- | ---------------
rbd_put_client(CLIENT) | rbd_get_client()
kref_put() | (acquires node_lock)
kref->refcount becomes 0 | __rbd_client_find() returns CLIENT
calls rbd_client_release() | kref_get(&CLIENT->kref);
| (releases node_lock)
(acquires node_lock) |
deletes CLIENT from list | ...and starts using CLIENT...
(releases node_lock) |
and frees CLIENT | <-- but CLIENT gets freed here
Fix this by having rbd_put_client() acquire node_lock. The result
could still be improved, but at least it avoids this problem.
Signed-off-by: Alex Elder <elder@dreamhost.com>
Signed-off-by: Sage Weil <sage@newdream.net>
This fixes the race in process_vm_core found by Oleg (see
http://article.gmane.org/gmane.linux.kernel/1235667/
for details).
This has been updated since I last sent it as the creation of the new
mm_access() function did almost exactly the same thing as parts of the
previous version of this patch did.
In order to use mm_access() even when /proc isn't enabled, we move it to
kernel/fork.c where other related process mm access functions already
are.
Signed-off-by: Chris Yeoh <yeohc@au1.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If an existing rbd client is found to be suitable for use in
rbd_get_client(), the rbd_options structure is not being
freed as it should. Fix that.
Signed-off-by: Alex Elder <elder@dreamhost.com>
Signed-off-by: Sage Weil <sage@newdream.net>
Lockdep was reporting a possible circular lock dependency in
dentry_lease_is_valid(). That function needs to sample the
session's s_cap_gen and and s_cap_ttl fields coherently, but needs
to do so while holding a dentry lock. The s_cap_lock field was
being used to protect the two fields, but that can't be taken while
holding a lock on a dentry within the session.
In most cases, the s_cap_gen and s_cap_ttl fields only get operated
on separately. But in three cases they need to be updated together.
Implement a new lock to protect the spots updating both fields
atomically is required.
Signed-off-by: Alex Elder <elder@dreamhost.com>
Reviewed-by: Sage Weil <sage@newdream.net>
"len" is read from network and thus needs validation. Otherwise, given
a bogus "len" value, p+len could be an out-of-bounds pointer, which is
used in further parsing.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Sage Weil <sage@newdream.net>
Initializing debufs under monc->mutex introduces a lock dependency for
sb->s_type->i_mutex_key, which (combined with several other dependencies)
leads to an annoying lockdep warning. There's no particular reason to do
the debugfs setup under this lock, so move it out.
It used to be the case that our first monmap could come from the OSD; that
is no longer the case with recent servers, so we will reliably set up the
client entry during the initial authentication.
We don't have to worry about racing with debugfs teardown by
ceph_debugfs_client_cleanup() because ceph_destroy_client() calls
ceph_msgr_flush() first, which will wait for the message dispatch work
to complete (and the debugfs init to complete).
Fixes: #1940
Signed-off-by: Sage Weil <sage@newdream.net>
The virtual extended attribute named "ceph.layout" is meaningful
only for regular files. Change its name to be "ceph.file.layout" to
more directly reflect that in the ceph xattr namespace. Preserve
the old "ceph.layout" name for the time being (until we decide it's
safe to get rid of it entirely).
Add a missing initializer for "readonly" in the terminating entry.
Signed-off-by: Alex Elder <elder@dreamhost.com>
Reviewed-by: Sage Weil <sage@newdream.net>
The Netlogic XLP SoC's on-chip USB controller appears as a PCI
USB device, but does not need the EHCI/OHCI handoff done in
usb/host/pci-quirks.c.
The pci-quirks.c is enabled for all vendors and devices, and is
enabled if USB and PCI are configured.
If we do not skip the qurik handling on XLP, the readb() call in
ehci_bios_handoff() will cause a crash since byte access is not
supported for EHCI registers in XLP.
Signed-off-by: Jayachandran C <jayachandranc@netlogicmicro.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Andrzej Siewior