Remove the unneeded struct device *dev argument from dwc2_hcd_init()
and dwc2_hcd_remove(), and pass in the value through the hsotg->dev
member instead
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Allow BPF_XOR based ALU instructions.
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Will Drewry <wad@chromium.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>
To simplify locking, the previous patches expanded wq->mutex to
protect all fields of each workqueue instance including the pwqs list
leaving pwq_lock without any user. Remove the unused pwq_lock.
tj: Rebased on top of the current dev branch. Updated description.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
We're expanding wq->mutex to cover all fields specific to each
workqueue with the end goal of replacing pwq_lock which will make
locking simpler and easier to understand.
This patch makes wq->saved_max_active protected by wq->mutex instead
of pwq_lock. As pwq_lock locking around pwq_adjust_mac_active() is no
longer necessary, this patch also replaces pwq_lock lockings of
for_each_pwq() around pwq_adjust_max_active() to wq->mutex.
tj: Rebased on top of the current dev branch. Updated description.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
We're expanding wq->mutex to cover all fields specific to each
workqueue with the end goal of replacing pwq_lock which will make
locking simpler and easier to understand.
init_and_link_pwq() and pwq_unbound_release_workfn() already grab
wq->mutex when adding or removing a pwq from wq->pwqs list. This
patch makes it official that the list is wq->mutex protected for
writes and updates readers accoridingly. Explicit IRQ toggles for
sched-RCU read-locking in flush_workqueue_prep_pwqs() and
drain_workqueues() are removed as the surrounding wq->mutex can
provide sufficient synchronization.
Also, assert_rcu_or_pwq_lock() is renamed to assert_rcu_or_wq_mutex()
and checks for wq->mutex too.
pwq_lock locking and assertion are not removed by this patch and a
couple of for_each_pwq() iterations are still protected by it.
They'll be removed by future patches.
tj: Rebased on top of the current dev branch. Updated description.
Folded in assert_rcu_or_wq_mutex() renaming from a later patch
along with associated comment updates.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
We're expanding wq->mutex to cover all fields specific to each
workqueue with the end goal of replacing pwq_lock which will make
locking simpler and easier to understand.
wq->nr_drainers and ->flags are specific to each workqueue. Protect
->nr_drainers and ->flags with wq->mutex instead of pool_mutex.
tj: Rebased on top of the current dev branch. Updated description.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Currently pwq->flush_mutex protects many fields of a workqueue
including, especially, the pwqs list. We're going to expand this
mutex to protect most of a workqueue and eventually replace pwq_lock,
which will make locking simpler and easier to understand.
Drop the "flush_" prefix in preparation.
This patch is pure rename.
tj: Rebased on top of the current dev branch. Updated description.
Use WQ: and WR: instead of Q: and QR: for synchronization labels.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
wq->flush_mutex will be renamed to wq->mutex and cover all fields
specific to each workqueue and eventually replace pwq_lock, which will
make locking simpler and easier to understand.
Rename wq_mutex to wq_pool_mutex to avoid confusion with wq->mutex.
After the scheduled changes, wq_pool_mutex won't be protecting
anything specific to each workqueue instance anyway.
This patch is pure rename.
tj: s/wqs_mutex/wq_pool_mutex/. Rewrote description.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Support for the WindRiver SBC8560 board was removed in v3.6. But there
are still a few lines depending on its obsolete Kconfig macro. Remove
these now.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Automatic Flow Control capability is not tied to this
property. This is only one way of detecting it. The property
is limited to be used only with 8250 driver.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Previously, when an active urb was dequeued, its host channel would
not always be released. There is some special handling for this in
dwc2_hc_chhltd_intr_dma, but when it was the last urb/qtd in its qh, a
safeguard in dwc2_hc_n_intr would short-circuit and prevent the regular
interrupt handlers from running, without releasing the channel.
This is easily triggered when using a 3G modem using the option driver.
Opening and closing any ttyUSBx device will eat up a host channel that
is forever unusable from that point on.
Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
[paulz@synopsys.com: fixed comment style and added a couple of NULL checks]
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When pMgmt->uScanChannel > pDevice->byMaxChannel scanning ends
but no SIOCGIWSCAN(scan done) message is sent. This section of code is
duplicate of that in WLAN_CMD_SCAN_END which sends scan done.
So remove it and jump eCommandState to WLAN_CMD_SCAN_END.
Increment uScanChannel on !ChannelValid.
At WLAN_CMD_SCAN_END reset uScanChannel to 0 when done.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Boot ROM has an issue which will cause the driver to
lock up as pending irqs are not being cleared. With them
cleared it prevents that issue.
This patch is needed for the current (3.9-rc3) mainline kernel. I guess
it went unnoticed, because it was only tested with u-boot up until now.
And u-boot maybe handles this.
[s.trumtrar@pengutronix.de: cherry-picked from linux-xlnx.git]
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
They were introduced by mistake in 3.7. Let's deprecate them now. For
the reasons, see the text in Kconfig below.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In 3.7 the 8250 module name was changed unintentionally from 8250 to
8250_core by commit 835d844d1a
(8250_pnp: do pnp probe before legacy probe). We then had to
re-introduce the old module options to ensure the old good
8250.nr_uart & co. still work. This can be done only by a very dirty
hack and we did it in f2b8dfd9e4
(serial: 8250: Keep 8250.<xxxx> module options functional after driver
rename).
That is so damn ugly so that I decided to revert to the old module
name and deprecate the new 8250_core options present in 3.7 and 3.8
only. The deprecation will happen in the following patch.
Note that this patch changes the hack above to support "8250_core.*",
because we now have "8250.*" natively.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The libfc discovery layer is being initialized in the
'create' paths for both legacy libfcoe module parameters
and fcoe_sysfs control interfaces. The problem is that
for VN2VN mode the discovery layer is initialized as if
it were in 'fabric' mode and it is not re-configured when
the mode is changed to 'vn2vn'.
This patch splits out code that needs to be initialized
once and code that can, and should be, re-configured when
the mode changes. Additionally this patch makes that change
so that the discovery layer can be reconfigured to the
libfcoe implementation when in 'vn2vn' mode.
Signed-off-by: Robert Love <robert.w.love@intel.com>
Tested-by: Jack Morgan <jack.morgan@intel.com>
Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Split discovery initialization in code that is setup once (fcoe_disc_init)
and code that can be re-configured (fcoe_disc_config).
Signed-off-by: Robert Love <robert.w.love@intel.com>
Tested-by: Jack Morgan <jack.morgan@intel.com>
Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Currently libfcoe is doing some libfc discovery layer initialization outside of
libfc. This patch moves this code into libfc and sets up a split in discovery
(one time) initialization code and (re-configurable) settings that will come in
the next patch.
Signed-off-by: Robert Love <robert.w.love@intel.com>
Tested-by: Jack Morgan <jack.morgan@intel.com>
Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Fix a null pointer deference by acpi_driver_data() if device is
null. We should only set pr and check this is OK after we are
sure device is not null.
Smatch analysis:
drivers/acpi/processor_thermal.c:223 processor_get_max_state() warn:
variable dereferenced before check 'device' (see line 221)
drivers/acpi/processor_thermal.c:237 processor_get_cur_state() warn:
variable dereferenced before check 'device' (see line 235)
drivers/acpi/processor_thermal.c:255 processor_set_cur_state() warn:
variable dereferenced before check 'device' (see line 251)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Fix a null pointer deference by acpi_driver_data() if device is
null. We should only set cdev and check this is OK after we are
sure device is not null.
Smatch analysis:
drivers/acpi/fan.c:179 acpi_fan_remove() warn: variable dereferenced
before check 'device' (see line 177)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
that cause system hangs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJRULSwAAoJEOa6n1xeVN+C69QP/jBdyAGZE2EK9YKtbYY/IjeJ
fuJsxm8AhXFkCVbdOm0YCzA99cbiTobNBMY/sP5PxNWSLiTB6w1VlKDLF5gd3XTA
RJgsdCeWRL2uBcjqrq+PxuAWWGC0OMSFmD4tYwM7hbJLhEV0KNIlcfUPuABS88BA
A6JtmACVxTTilm4c0CsxVjGwPK/EVdsMQOBrMeLvbrg2XbO8Y9vGvVIT2Qjz38DB
7xh4kfmRqCb4EuayEmpZHZfyUbhvxEk4sAPhAaXeGMHAL9RHIdhcp5ClI8KcQ/K5
qU6U/d+mCcXQ7dAVXTcmm7G4HgDk9BVtNUWQXgx/nw9aJg7s9z2CiB6bRQDvAmAb
evTs4YgjwpESlFgOf2Qx7foH14756yOPjXKrNSHOE4Xb6kNV6UKGhI/n2bP8eTzf
SRnimElB8iEQb2pYTyUjXv8JP8QD/JaKH5yqjluVEYpXFrUfZvLQE21CkkDnZwuf
q+lp6qYcwA78ccZhzWhuah8+RT1VZmwX0dE1dj6iklVNoF+PgulBr0rq0F61NFhz
dmTl9hQI3BnxqcNmaWPbxwBWoaa51WFm1J04RNV9dh9LTyqXpnfav2X/goafteN6
tbSRJpNpv0Yo/D86NZnfFrgN/xjwAn7+nejSYYT+FWtFJ3Ux9Stv2J1pybxITQAt
iuRkrmBzSGZ2PRzERb0k
=xMpr
-----END PGP SIGNATURE-----
Merge tag 'msm-fix-3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm into fixes
From David Brown <davidb@codeaurora.org>:
This fix is intended for v3.9. It fixes a timer bug on MSM targets
that cause system hangs.
* tag 'msm-fix-3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm:
ARM: msm: Stop counting before reprogramming clockevent
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
For 32-bit, CONFIG_EPAPR_PARAVIRT pulls in both epapr_paravirt.c
and epapr_hcalls.c which contains the 32-bit paravirt idle loop.
For 64-bit, the paravirt idle loop is in idle_book3e.S and that
source file is included only if CONFIG_PPC_BOOK3E_64 defined.
This patch makes that dependency for 64-bit explicit.
Fixes these build errors:
arch/powerpc/kernel/built-in.o: In function `restore_pblist_ptr':
ftrace.c:(.toc+0xdc0): undefined reference to `epapr_ev_idle_start'
ftrace.c:(.toc+0xdd0): undefined reference to `epapr_ev_idle'
Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
After commit 6865ff222c ("TTY: do not warn about setting
speed via SPD_*"), we are seeing a build error when DEBUG_FS is
enabled:
drivers/net/caif/caif_serial.c: In function 'update_tty_status':
drivers/net/caif/caif_serial.c:94:11: error: 'struct tty_struct' has no member named 'warned'
Fix the error by removing the reference to the variable as it was
not set in the last decade (as documented in the changelog of the
commit above).
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Sjur Braendeland <sjur.brandeland@stericsson.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The datesheet clearly states, that writing low bits to the
XUARTPS_IDR register have no effect. Remove the write.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Support for SH7367 and SH7377 got removed in v3.8. Now remove their
last Kconfig macros.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This will reduce the need for extra types in 8250.c just
in case the fifo size differs from the standard.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In most cases the tx_loadsz is the same as fifosize. This
will store the fifosize in it if it was not separately
delivered from the driver.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use dev_{set,get}_drvdata for managing private data attached to a trigger
instead of using a custom field in the iio_trigger struct.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Introduce iio_tigger_{set,get}_drvdata which allows to attach driver specific
data to a trigger. The functions wrap access to the triggers private_data field
and all current users are updated to use iio_tigger_{set,get}_drvdata instead of
directly accessing the private_data field. This is the first step towards
removing the private_data field from the iio_trigger struct.
The following coccinelle script has been used to update the drivers:
<smpl>
@@
struct iio_trigger *trigger;
expression priv;
@@
-trigger->private_data = priv
+iio_trigger_set_drv_data(trigger, priv)
@@
struct iio_trigger *trigger;
@@
-trigger->private_data
+iio_trigger_get_drv_data(trigger)
</smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
[Description written by Alan Stern]
Soeren tracked down a very difficult bug in ehci-hcd's DMA pool
management of iTD and siTD structures. Some background: ehci-hcd
gives each isochronous endpoint its own set of active and free itd's
(or sitd's for full-speed devices). When a new itd is needed, it is
taken from the head of the free list, if possible. However, itd's
must not be used twice in a single frame because the hardware
continues to access the data structure for the entire duration of a
frame. Therefore if the itd at the head of the free list has its
"frame" member equal to the current value of ehci->now_frame, it
cannot be reused and instead a new itd is allocated from the DMA pool.
The entries on the free list are not released back to the pool until
the endpoint is no longer in use.
The bug arises from the fact that sometimes an itd can be moved back
onto the free list before itd->frame has been set properly. In
Soeren's case, this happened because ehci-hcd can allocate one more
itd than it actually needs for an URB; the extra itd may or may not be
required depending on how the transfer aligns with a frame boundary.
For example, an URB with 8 isochronous packets will cause two itd's to
be allocated. If the URB is scheduled to start in microframe 3 of
frame N then it will require both itds: one for microframes 3 - 7 of
frame N and one for microframes 0 - 2 of frame N+1. But if the URB
had been scheduled to start in microframe 0 then it would require only
the first itd, which could cover microframes 0 - 7 of frame N. The
second itd would be returned to the end of the free list.
The itd allocation routine initializes the entire structure to 0, so
the extra itd ends up on the free list with itd->frame set to 0
instead of a meaningful value. After a while the itd reaches the head
of the list, and occasionally this happens when ehci->now_frame is
equal to 0. Then, even though it would be okay to reuse this itd, the
driver thinks it must get another itd from the DMA pool.
For as long as the isochronous endpoint remains in use, this flaw in
the mechanism causes more and more itd's to be taken slowly from the
DMA pool. Since none are released back, the pool eventually becomes
exhausted.
This reuslts in memory allocation failures, which typically show up
during a long-running audio stream. Video might suffer the same
effect.
The fix is very simple. To prevent allocations from the pool when
they aren't needed, make sure that itd's sent back to the free list
prematurely have itd->frame set to an invalid value which can never be
equal to ehci->now_frame.
This should be applied to -stable kernels going back to 3.6.
Signed-off-by: Soeren Moch <smoch@web.de>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove bogus disconnect test for serial device being NULL in close. This
can never happen as close is guaranteed to be called before the last tty
reference is dropped (and port->serial is cleared).
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove bogus disconnect test for serial device being NULL in read bulk
callback. This can never happen as the port read urb is killed (and
poisoned) at close, which in turn is guaranteed to be called before the
last tty reference is dropped (and port->serial is cleared).
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove bogus disconnect test for serial device being NULL in close. This
can never happen as close is guaranteed to be called before the last tty
reference is dropped (and port->serial is cleared).
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Always try to disable the uart on close.
Since the switch to tty ports, close will be called as part of shutdown
before disconnect returns. Hence there is no need to check the
disconnected flag, and we can put devices in disabled states also on
driver unbind.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Always try to disable the uart on close.
Since the switch to tty ports, close will be called as part of shutdown
before disconnect returns. Hence there is no need to check the
disconnected flag, and we can put devices in disabled states also on
driver unbind.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove unnecessary disconnect test in tiocmset. No ioctls will be made
after disconnect returns.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure we return 0 or a negative error number appropriate for
userspace on errors.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove unnecessary disconnect test in tiocmset. No ioctls will be made
after disconnect returns.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure we return 0 or a negative error number appropriate for
userspace on errors.
Currently 1 rather than 0 is returned on successful operation.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Always try to disable the uart on close.
Since the switch to tty ports, close will be called as part of shutdown
before disconnect returns. Hence there is no need to check the
disconnected flag, and we can put devices in disabled states also on
driver unbind.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Always try to disable the uart on close.
Since the switch to tty ports, close will be called as part of shutdown
before disconnect returns. Hence there is no need to check the
disconnected flag, and we can put devices in disabled states also on
driver unbind.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Always try to disable the uart on close.
Since the switch to tty ports, close will be called as part of shutdown
before disconnect returns. Hence there is no need to check the
disconnected flag, and we can put devices in disabled states also on
driver unbind.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Always try to disable the uart on close.
Since the switch to tty ports, close will be called as part of shutdown
before disconnect returns. Hence there is no need to check the
disconnected flag, and we can put devices in disabled states also on
driver unbind.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove disconnected test from close which did not protect any device IO
at all.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Always try to disable the uart on close.
Since the switch to tty ports, close will be called as part of shutdown
before disconnect returns. Hence there is no need to check the
disconnected flag, and we can put devices in disabled states also on
driver unbind.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the port MSR-wait queue now that all drivers have been migrated
to the tty-port queue.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
