The IRQF_DISABLED is a NOOP and scheduled to be removed. According to
commit e58aa3d2d0 ("genirq: Run irq handlers with interrupts
disabled") running IRQ handlers with interrupts enabled can cause stack
overflows when the interrupt line of the issuing device is still active.
This patch removes using this deprecated flag and additionally removes
redundantly setting IRQF_SHARED for isp1760_udc_register().
Signed-off-by: Valentin Rothberg <Valentin.Rothberg@lip6.fr>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
A recent bug fix I did that was marked for stable backports
introduced a slightly wrong dependency on CONFIG_OMAP_CONTROL_PHY.
I was missing the fact that the PHY driver already stubs out the
omap_control_usb_set_mode, and we only need to add a dependency
to prevent the musb-omap2430 driver from being built-in when
the phy driver is a loadable module, but we should not prevent it
from being built altogether when the phy driver is disabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: ca784be36c ("usb: start using the control module driver")
Cc: <stable@vger.kernel.org> # v3.9+
Acked-by: Acked-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Some archs (specifically PowerPC), are sensitive with the ordering of
the enabling of the calls to function tracing and setting of the
function to use to be traced.
That is, update_ftrace_function() sets what function the ftrace_caller
trampoline should call. Some archs require this to be set before
calling ftrace_run_update_code().
Another bug was discovered, that ftrace_startup_sysctl() called
ftrace_run_update_code() directly. If the function the ftrace_caller
trampoline changes, then it will not be updated. Instead a call
to ftrace_startup_enable() should be called because it tests to see
if the callback changed since the code was disabled, and will
tell the arch to update appropriately. Most archs do not need this
notification, but PowerPC does.
The problem could be seen by the following commands:
# echo 0 > /proc/sys/kernel/ftrace_enabled
# echo function > /sys/kernel/debug/tracing/current_tracer
# echo 1 > /proc/sys/kernel/ftrace_enabled
# cat /sys/kernel/debug/tracing/trace
The trace will show that function tracing was not active.
Cc: stable@vger.kernel.org # 2.6.27+
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
When ftrace is enabled globally through the proc interface, we must check if
ftrace_graph_active is set. If it is set, then we should also pass the
FTRACE_START_FUNC_RET command to ftrace_run_update_code(). Similarly, when
ftrace is disabled globally through the proc interface, we must check if
ftrace_graph_active is set. If it is set, then we should also pass the
FTRACE_STOP_FUNC_RET command to ftrace_run_update_code().
Consider the following situation.
# echo 0 > /proc/sys/kernel/ftrace_enabled
After this ftrace_enabled = 0.
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
Since ftrace_enabled = 0, ftrace_enable_ftrace_graph_caller() is never
called.
# echo 1 > /proc/sys/kernel/ftrace_enabled
Now ftrace_enabled will be set to true, but still
ftrace_enable_ftrace_graph_caller() will not be called, which is not
desired.
Further if we execute the following after this:
# echo nop > /sys/kernel/debug/tracing/current_tracer
Now since ftrace_enabled is set it will call
ftrace_disable_ftrace_graph_caller(), which causes a kernel warning on
the ARM platform.
On the ARM platform, when ftrace_enable_ftrace_graph_caller() is called,
it checks whether the old instruction is a nop or not. If it's not a nop,
then it returns an error. If it is a nop then it replaces instruction at
that address with a branch to ftrace_graph_caller.
ftrace_disable_ftrace_graph_caller() behaves just the opposite. Therefore,
if generic ftrace code ever calls either ftrace_enable_ftrace_graph_caller()
or ftrace_disable_ftrace_graph_caller() consecutively two times in a row,
then it will return an error, which will cause the generic ftrace code to
raise a warning.
Note, x86 does not have an issue with this because the architecture
specific code for ftrace_enable_ftrace_graph_caller() and
ftrace_disable_ftrace_graph_caller() does not check the previous state,
and calling either of these functions twice in a row has no ill effect.
Link: http://lkml.kernel.org/r/e4fbe64cdac0dd0e86a3bf914b0f83c0b419f146.1425666454.git.panand@redhat.com
Cc: stable@vger.kernel.org # 2.6.31+
Signed-off-by: Pratyush Anand <panand@redhat.com>
[
removed extra if (ftrace_start_up) and defined ftrace_graph_active as 0
if CONFIG_FUNCTION_GRAPH_TRACER is not set.
]
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
When /proc/sys/kernel/ftrace_enabled is set to zero, all function
tracing is disabled. But the records that represent the functions
still hold information about the ftrace_ops that are hooked to them.
ftrace_ops may request "REGS" (have a full set of pt_regs passed to
the callback), or "TRAMP" (the ops has its own trampoline to use).
When the record is updated to represent the state of the ops hooked
to it, it sets "REGS_EN" and/or "TRAMP_EN" to state that the callback
points to the correct trampoline (REGS has its own trampoline).
When ftrace_enabled is set to zero, all ftrace locations are a nop,
so they do not point to any trampoline. But the _EN flags are still
set. This can cause the accounting to go wrong when ftrace_enabled
is cleared and an ops that has a trampoline is registered or unregistered.
For example, the following will cause ftrace to crash:
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
# echo 0 > /proc/sys/kernel/ftrace_enabled
# echo nop > /sys/kernel/debug/tracing/current_tracer
# echo 1 > /proc/sys/kernel/ftrace_enabled
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
As function_graph uses a trampoline, when ftrace_enabled is set to zero
the updates to the record are not done. When enabling function_graph
again, the record will still have the TRAMP_EN flag set, and it will
look for an op that has a trampoline other than the function_graph
ops, and fail to find one.
Cc: stable@vger.kernel.org # 3.17+
Reported-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Peripheral clock is named pclk and system clock is named hclk (those are
the names expected by the at91_udc driver).
Drop the deprecated usb_clk (formerly used to configure the usb clock rate
which is now directly configurable through hclk).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
byRFType is not set prior to registration of mac80211 causing
unpredictable operation after channel scans.
With byRFType unset all channels are enabled this causes tx power
to be set to values not present its eeprom.
Move setting of this variable to vt6655_probe.
byRFType must have a mask set. byRevId not used by driver and
is removed.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Cc: <stable@vger.kernel.org> # v3.19+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the driver sets this rate a power of zero value is set causing
data flow stoppage until another rate is tried.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the driver sets this rate a power of zero value is set causing
data flow stoppage until another rate is tried.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Cc: <stable@vger.kernel.org> # v3.17+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds Marc Kleine-Budde as a co maintainer for the CAN networking
layer.
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
As gitorious will shut down at the end of May 2015, the linux-can website moved
to github. This patch reflects this change.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The Kvaser firmware can only read and write messages that are
not crossing the USB endpoint's wMaxPacketSize boundary. While
receiving commands from the CAN device, if the next command in
the same URB buffer crossed that max packet size boundary, the
firmware puts a zero-length placeholder command in its place
then moves the real command to the next boundary mark.
The driver did not recognize such behavior, leading to missing
a good number of rx events during a heavy rx load session.
Moreover, a tx URB context only gets freed upon receiving its
respective tx ACK event. Over time, the free tx URB contexts
pool gets depleted due to the missing ACK events. Consequently,
the netif transmission queue gets __permanently__ stopped; no
frames could be sent again except after restarting the CAN
newtwork interface.
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Upon a URB submission failure, the driver calls usb_free_urb()
but then manually frees the URB buffer by itself. Meanwhile
usb_free_urb() has alredy freed out that transfer buffer since
we're the only code path holding a reference to this URB.
Remove two of such invalid manual free().
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Fixes a missing initialization of ctrlmode and ctrlmode_supported fields,
for all other CAN devices than the first one. This fix only concerns
the PCAN-USB Pro FD dual-channels CAN-FD device made by PEAK-System.
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
When accessing CAN network interfaces with AF_PACKET sockets e.g. by dhclient
this can lead to a skb_under_panic due to missing skb initialisations.
Add the missing initialisations at the CAN skbuff creation times on driver
level (rx path) and in the network layer (tx path).
Reported-by: Austin Schuh <austin@peloton-tech.com>
Reported-by: Daniel Steer <daniel.steer@mclaren.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The commit [63e51fd708: ALSA: hda - Don't take unresponsive D3
transition too serious] introduced a conditional fallback behavior to
the HD-audio controller depending on the flag set. However, it
introduced a silly bug, too, that the flag was evaluated in a reverse
way. This resulted in a regression of HD-audio controller driver
where it can't go to the fallback mode at communication errors.
Unfortunately (or fortunately?) this didn't come up until recently
because the affected code path is an error handling that happens only
on an unstable hardware chip. Most of recent chips work stably, thus
they didn't hit this problem. Now, we've got a regression report with
a VIA chip, and this seems indeed requiring the fallback to the
polling mode, and finally the bug was revealed.
The fix is a oneliner to remove the wrong logical NOT in the check.
(Lesson learned - be careful about double negation.)
The bug should be backported to stable, but the patch won't be
applicable to 3.13 or earlier because of the code splits. The stable
fix patches for earlier kernels will be posted later manually.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94021
Fixes: 63e51fd708 ('ALSA: hda - Don't take unresponsive D3 transition too serious')
Cc: <stable@vger.kernel.org> # v3.14+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There is still a problem that dma_idx is causing packets to
go onto the wrong tx path.
Protect dma_idx fully with the present first lock and
use pTDInfo->byFlags TD_FLAGS_NETIF_SKB to set MACvTransmit.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lenovo X250 has a PnpID of LEN0046, but it does not have the top software
button requirement.
For the record, Lenovo T450s and W541 have a PnpID of LEN200f and LEN004a,
so they are not on the top software button list.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Lenovo decided to switch back to physical buttons for the trackstick on
their latest series. The PNPId list was provided before they reverted back
to physical buttons, so it contains the new models too. We can know from
the touchpad capabilities that the touchpad has physical buttons, so
removing the ids from the list is not mandatory. It is still nicer to
remove the wrong ids, so start by removing the X1 Carbon 3rd gen, with the
PNPId of LEN0048.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The 2015 series of the Lenovo thinkpads added back the hardware buttons on
top of the touchpad for the trackstick.
Unfortunately, they are wired to the touchpad, and not the trackstick.
Thus, they are seen as extra buttons from the kernel point of view.
This leads to a problem in user space because extra buttons on synaptics
devices used to be used as scroll up/down buttons. So in the end, the
experience for the user is scroll events for buttons left and right when
using the trackstick. Yay!
Fortunately, the firmware advertises such behavior in the extended
capability $10, and so we can re-route the buttons through the pass-through
interface.
Hallelujah-expressed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The 2015 series of the Lenovo thinkpads added back the hardware buttons on
top of the touchpad for the trackstick.
Unfortunately, Lenovo used the PNPIDs that are supposed to be "5 buttons"
touchpads, so the new laptops also have the INPUT_PROP_TOPBUTTONPAD. Yay!
Instead of manually removing each of the new ones, or hoping that we know
all the current ones, we can consider that the PNPIDs list that were given
contains touchpads that have the trackstick buttons, either physically
wired to them, or emulated with the top software button property.
Thanks to the extra buttons capability in query $10, we can reliably detect
the physical buttons from the software ones, and so we can remove the
TOPBUTTONPAD property even if it was declared as such.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Newer Synaptics touchpads need to get information from the query $10.
Retrieve it if available.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The board id capability has been added in firmware 7.5.
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The Fimware 8.1 has a bug in which the extra buttons are only sent when the
ExtBit is 1. This should be fixed in a future FW update which should have
a bump of the minor version.
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
On the X1 Carbon 3rd gen (with a 2015 broadwell cpu), the physical middle
button of the trackstick (attached to the touchpad serio device, of course)
seems to get lost.
Actually, the touchpads reports 3 extra buttons, which falls in the switch
below to the '2' case. Let's handle the case of odd numbers also, so that
the middle button finds its way back.
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Post-2013 Lenovo laptops provide correct min/max dimensions, which are
different with the ones currently quirked. According to
https://bugzilla.kernel.org/show_bug.cgi?id=91541 the following board ids
are assigned in the post-2013 touchpads:
t440p/t440s: LEN0036 -> 2964/2962
t540p: LEN0034 -> 2964
Using 2961 as the common minimum makes these 3 laptops OK. We may need
to update those values later if other pnp_ids has a lower board_id.
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Add a min/max range for board ids to the min/max coordinates quirk. This
makes it possible to restrict quirks to specific models based upon their
board id. The define ANY_BOARD_ID (0) serves as a wild card.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Martin <daniel.martin@secunet.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The firmware of the X240 (LEN0035, 2013/12) exposes the same values
x [1232..5710], y [1156..4696]
as the quirk applies.
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Query the min dimensions even if the check
SYN_EXT_CAP_REQUESTS(priv->capabilities) >= 7 fails, but we know that the
firmware version 8.1 is safe.
With that we don't need quirks for post-2013 models anymore as they expose
correct min and max dimensions.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
re-order the tests to check SYN_CAP_MIN_DIMENSIONS even on FW 8.1
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Logging the dimension values we queried and the values we use from a quirk
to overwrite can be helpful for debugging.
This partly relates to bug:
https://bugzilla.kernel.org/show_bug.cgi?id=91541
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Split the function synaptics_resolution() into synaptics_resolution() and
synaptics_quirks(). synaptics_resolution() will be called before
synaptics_quirks() to query dimensions and resolutions before overwriting
them with quirks.
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
When reading from the error queue, msg_name and msg_control are only
populated for some errors. A new exception for empty timestamp skbs
added a false positive on icmp errors without payload.
`traceroute -M udpconn` only displayed gateways that return payload
with the icmp error: the embedded network headers are pulled before
sock_queue_err_skb, leaving an skb with skb->len == 0 otherwise.
Fix this regression by refining when msg_name and msg_control
branches are taken. The solutions for the two fields are independent.
msg_name only makes sense for errors that configure serr->port and
serr->addr_offset. Test the first instead of skb->len. This also fixes
another issue. saddr could hold the wrong data, as serr->addr_offset
is not initialized in some code paths, pointing to the start of the
network header. It is only valid when serr->port is set (non-zero).
msg_control support differs between IPv4 and IPv6. IPv4 only honors
requests for ICMP and timestamps with SOF_TIMESTAMPING_OPT_CMSG. The
skb->len test can simply be removed, because skb->dev is also tested
and never true for empty skbs. IPv6 honors requests for all errors
aside from local errors and timestamps on empty skbs.
In both cases, make the policy more explicit by moving this logic to
a new function that decides whether to process msg_control and that
optionally prepares the necessary fields in skb->cb[]. After this
change, the IPv4 and IPv6 paths are more similar.
The last case is rxrpc. Here, simply refine to only match timestamps.
Fixes: 49ca0d8bfa ("net-timestamp: no-payload option")
Reported-by: Jan Niehusmann <jan@gondor.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
----
Changes
v1->v2
- fix local origin test inversion in ip6_datagram_support_cmsg
- make v4 and v6 code paths more similar by introducing analogous
ipv4_datagram_support_cmsg
- fix compile bug in rxrpc
Signed-off-by: David S. Miller <davem@davemloft.net>
On my test environment the throughput of a file transfer drops
from 4.4MBps to 116KBps due the number of repeated warning
messages. This patch removes the warning messages as DMA works
correctly with addresses using 0xC0000000 bits.
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
POLL_OUT isn't what callers of ->poll() are expecting to see; it's
actually __SI_POLL | 2 and it's a siginfo code, not a poll bitmap
bit...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@vger.kernel.org
Cc: Bruce Fields <bfields@fieldses.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Here's a round of USB fixes for 4.0-rc3.
Nothing major, the usual gadget, xhci and usb-serial fixes and a few new
device ids as well.
All have been in linux-next successfully.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlT8Q2oACgkQMUfUDdst+ym9cgCgloBq7GqYw5lnW+zVy6fmyS3U
zHMAoMYPLjpUuO4tHfXt46NxVHIMzGsg
=TMtd
-----END PGP SIGNATURE-----
Merge tag 'usb-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here's a round of USB fixes for 4.0-rc3.
Nothing major, the usual gadget, xhci and usb-serial fixes and a few
new device ids as well.
All have been in linux-next successfully"
* tag 'usb-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (36 commits)
xhci: Workaround for PME stuck issues in Intel xhci
xhci: fix reporting of 0-sized URBs in control endpoint
usb: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boards
USB: ch341: set tty baud speed according to tty struct
USB: serial: cp210x: Adding Seletek device id's
USB: pl2303: disable break on shutdown
USB: mxuport: fix null deref when used as a console
USB: serial: clean up bus probe error handling
USB: serial: fix port attribute-creation race
USB: serial: fix tty-device error handling at probe
USB: serial: fix potential use-after-free after failed probe
USB: console: add dummy __module_get
USB: ftdi_sio: add PIDs for Actisense USB devices
Revert "USB: serial: make bulk_out_size a lower limit"
cdc-acm: Add support for Denso cradle CU-321
usb-storage: support for more than 8 LUNs
uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS539
USB: usbfs: don't leak kernel data in siginfo
xhci: Clear the host side toggle manually when endpoint is 'soft reset'
xhci: Allocate correct amount of scratchpad buffers
...
Any access to the component_list, codec_list and platform_list needs to be
properly locked by the client_mutex. Otherwise undefined behavior can occur
if the list is modified in one thread and concurrently accessed from another
thread.
This patch adds the missing locking to the debugfs file handlers that
display the registered components, as well as the various components
unregister functions.
Furthermore the client_lock is now held for the whole
snd_soc_instantiate_card() sequence to make sure that component removal does
not race against the card registration.
Reported-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Normally _regulator_do_enable() isn't called on an already-enabled
rdev. That's because the main caller, _regulator_enable() always
calls _regulator_is_enabled() and only calls _regulator_do_enable() if
the rdev was not already enabled.
However, there is one caller of _regulator_do_enable() that doesn't
check: regulator_suspend_finish(). While we might want to make
regulator_suspend_finish() behave more like _regulator_enable(), it's
probably also a good idea to make _regulator_do_enable() robust if it
is called on an already enabled rdev.
At the moment, _regulator_do_enable() is _not_ robust for already
enabled rdevs if we're using an ena_pin. Each time
_regulator_do_enable() is called for an rdev using an ena_pin the
reference count of the ena_pin is incremented even if the rdev was
already enabled. This is not as intended because the ena_pin is for
something else: for keeping track of how many active rdevs there are
sharing the same ena_pin.
Here's how the reference counting works here:
* Each time _regulator_enable() is called we increment
rdev->use_count, so _regulator_enable() calls need to be balanced
with _regulator_disable() calls.
* There is no explicit reference counting in _regulator_do_enable()
which is normally just a warapper around rdev->desc->ops->enable()
with code for supporting delays. It's not expected that the
"ops->enable()" call do reference counting.
* Since regulator_ena_gpio_ctrl() does have reference counting
(handling the sharing of the pin amongst multiple rdevs), we
shouldn't call it if the current rdev is already enabled.
Note that as part of this we cleanup (remove) the initting of
ena_gpio_state in regulator_register(). In _regulator_do_enable(),
_regulator_do_disable() and _regulator_is_enabled() is is clear that
ena_gpio_state should be the state of whether this particular rdev has
requested the GPIO be enabled. regulator_register() was initting it
as the actual state of the pin.
Fixes: 967cfb18c0 ("regulator: core: manage enable GPIO list")
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
The _regulator_do_enable() call ought to be a no-op when called on an
already-enabled regulator. However, as an optimization
_regulator_enable() doesn't call _regulator_do_enable() on an already
enabled regulator. That means we never test the case of calling
_regulator_do_enable() during normal usage and there may be hidden
bugs or warnings. We have seen warnings issued by the tps65090 driver
and bugs when using the GPIO enable pin.
Let's match the same optimization that _regulator_enable() in
regulator_suspend_finish(). That may speed up suspend/resume and also
avoids exposing hidden bugs.
[Use much clearer commit message from Doug Anderson]
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Here are some tty and serial driver fixes for 4.0-rc3.
Along with the atime fix that you know about, here are some other serial
driver bugfixes as well. Most notable is a wait_until_sent bugfix that
was traced back to being around since before 2.6.12 that Johan has fixed
up.
All have been in linux-next successfully.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlT8RCYACgkQMUfUDdst+yk62QCgycxS4giC2hyRver3dyvaNR6g
zYYAn2w0uRndW+AqP4Tls54isRz6owpF
=gA2k
-----END PGP SIGNATURE-----
Merge tag 'tty-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial fixes from Greg KH:
"Here are some tty and serial driver fixes for 4.0-rc3.
Along with the atime fix that you know about, here are some other
serial driver bugfixes as well. Most notable is a wait_until_sent
bugfix that was traced back to being around since before 2.6.12 that
Johan has fixed up.
All have been in linux-next successfully"
* tag 'tty-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
TTY: fix tty_wait_until_sent maximum timeout
TTY: fix tty_wait_until_sent on 64-bit machines
USB: serial: fix infinite wait_until_sent timeout
TTY: bfin_jtag_comm: remove incorrect wait_until_sent operation
net: irda: fix wait_until_sent poll timeout
serial: uapi: Declare all userspace-visible io types
serial: core: Fix iotype userspace breakage
serial: sprd: Fix missing spin_unlock in sprd_handle_irq()
console: Fix console name size mismatch
tty: fix up atime/mtime mess, take four
serial: 8250_dw: Fix get_mctrl behaviour
serial:8250:8250_pci: delete unneeded quirk entries
serial:8250:8250_pci: fix redundant entry report for WCH_CH352_2S
Change email address for 8250_pci
serial: 8250: Revert "tty: serial: 8250_core: read only RX if there is something in the FIFO"
Revert "tty/serial: of_serial: add DT alias ID handling"
Here are some IIO and staging driver fixes for 4.0-rc3.
Details are in the shortlog, nothing major, mostly IIO fixes for
reported issues.
All have been in linux-next successfully.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlT8RKEACgkQMUfUDdst+ylRTACeJHh8MIafzeNX1mn+YJKSvVVa
ks0AoIcvKsvIeEiWvJsNepHaHlfMs4R6
=Ppc/
-----END PGP SIGNATURE-----
Merge tag 'staging-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver fixes from Greg KH:
"Here are some IIO and staging driver fixes for 4.0-rc3.
Details are in the shortlog, nothing major, mostly IIO fixes for
reported issues.
All have been in linux-next successfully"
* tag 'staging-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (23 commits)
staging: comedi: adv_pci1710: fix AI INSN_READ for non-zero channel
staging: comedi: vmk80xx: remove "firmware version" kernel messages
staging: comedi: comedi_isadma: fix "stalled" detect in comedi_isadma_disable_on_sample()
iio: ak8975: fix AK09911 dependencies
iio: common: ssp_sensors: Protect PM-only functions to kill warning
IIO: si7020: Allocate correct amount of memory in devm_iio_device_alloc
Revert "iio:humidity:si7020: fix pointer to i2c client"
iio: light: gp2ap020a00f: Select REGMAP_I2C
iio: light: jsa1212: Select REGMAP_I2C
iio: ad5686: fix optional reference voltage declaration
iio:adc:mcp3422 Fix incorrect scales table
iio: mxs-lradc: fix iio channel map regression
iio: imu: adis16400: Fix sign extension
staging: iio: ad2s1200: Fix sign extension
iio: mxs-lradc: only update the buffer when its conversions have finished
iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions
iio: mxs-lradc: make ADC reads not disable touchscreen interrupts
iio: mxs-lradc: separate touchscreen and buffer virtual channels
iio: imu: inv_mpu6050: Prevent dereferencing NULL
iio: iadc: wait_for_completion_timeout time in jiffies
...
Here are 2 char/misc fixes for 4.0-rc3.
One is a reported binder driver fix needed due to a change in the mm
core that happened in 4.0-rc1. Another is a mei driver fix that
resolves a reported issue in that driver.
Both have been in linux-next for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlT8RSoACgkQMUfUDdst+yk7GACgwoWKdslTxl1cib5yllhpaedl
YCYAoNGyb4C4VgdH5Lpve3j4gNRw7dy+
=1tzF
-----END PGP SIGNATURE-----
Merge tag 'char-misc-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Here are two char/misc fixes for 4.0-rc3.
One is a reported binder driver fix needed due to a change in the mm
core that happened in 4.0-rc1. Another is a mei driver fix that
resolves a reported issue in that driver.
Both have been in linux-next for a while"
* tag 'char-misc-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
mei: make device disabled on stop unconditionally
android: binder: fix binder mmap failures
This file tries to set the rational basis for our code reviews, gives
some advice on how to conduct them, and provides an excalation channel
for any kernel developers if they so desire it.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlTwygoACgkQMUfUDdst+yk8ZQCdFYB9t3ZIzxiobR1pQy/PJ6Ld
dxEAnRrKzKn1FaJKCkHg35YrInKVwScZ
=tRWZ
-----END PGP SIGNATURE-----
Merge tag 'cc-4.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull "code of conflict" from Greg KH:
"This file tries to set the rational basis for our code reviews, gives
some advice on how to conduct them, and provides an excalation channel
for any kernel developers if they so desire it"
[ Let's see how this works ]
* tag 'cc-4.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
Code of Conflict
Final methods start with get_ready_ep(), which will fail unless we have
->state == STATE_EP_ENABLED. So they'd be failing just fine until that
first write() anyway. Let's do the following:
* get_ready_ep() gets a new argument - true when called from
ep_write_iter(), false otherwise.
* make it quiet when it finds STATE_EP_READY (no printk, that is;
the case won't be impossible after that change).
* when that new argument is true, treat STATE_EP_READY the same
way as STATE_EP_ENABLED (i.e. return zero and do not unlock).
* in ep_write_iter(), after success of get_ready_ep() turn
if (!usb_endpoint_dir_in(&epdata->desc)) {
into
if (epdata->state == STATE_EP_ENABLED &&
!usb_endpoint_dir_in(&epdata->desc)) {
- that logics only applies after config.
* have ep_config() take kernel-side buffer (i.e. use memcpy()
instead of copy_from_user() in there) and in the "let's call ep_io or
ep_aio" (again, in ep_write_iter()) add "... or ep_config() in case it's
not configured yet"
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
It's unsafe to change the configurations of an activated ITS directly
since this will lead to unpredictable results. This patch guarantees
the ITSes being initialized are quiescent.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Yun Wu <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-12-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Define macros for GITS_CTLR fields to avoid using magic numbers.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Yun Wu <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-11-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
When required size of Device Table is out of the page allocator's
capability, the whole ITS will fail in probing. This actually is
not the hardware's problem and is mainly a limitation of the kernel
page allocator. This patch will keep ITS going on to the next
initializaion stage with an explicit warning.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Yun Wu <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-10-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
