| Age | Commit message (Collapse) | Author |
|---|
|
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 [63e51fd708f5: 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: 63e51fd708f5 ('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: 49ca0d8bfaf3 ("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>
|
|
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: 967cfb18c0e3 ("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
|
|
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"
|
|
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
...
|
|
... for ep0 as well
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
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
|
|
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>
|
|
The field of page size in register GITS_BASERn might be read-only
if an implementation only supports a single, fixed page size. But
currently the ITS driver will throw out an error when PAGE_SIZE
is less than the minimum size supported by an ITS. So addressing
this problem by using 64KB pages as default granule for all the
ITS base tables.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
[maz: fixed bug breaking non Device Table allocations]
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-9-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
Some kind of brain-dead implementations chooses to insert ITEes in
rapid sequence of disabled ITEes, and an un-zeroed ITT will confuse
ITS on judging whether an ITE is really enabled or not. Considering
the implementations are still supported by the GICv3 architecture,
in which ITT is not required to be zeroed before being handled to
hardware, we do the favor in ITS driver.
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-8-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
While playing with KASan support for arm64/arm the following appeared on boot:
==================================================================
BUG: AddressSanitizer: out of bounds access in __asan_load8+0x14/0x1c at addr ffffffc000ad0dc0
Read of size 8 by task swapper/0/1
page:ffffffbdc202b400 count:1 mapcount:0 mapping: (null) index:0x0
flags: 0x400(reserved)
page dumped because: kasan: bad access detected
Address belongs to variable __cpu_logical_map+0x200/0x220
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc6-next-20150129+ #481
Hardware name: FVP Base (DT)
Call trace:
[<ffffffc00008a794>] dump_backtrace+0x0/0x184
[<ffffffc00008a928>] show_stack+0x10/0x1c
[<ffffffc00075e46c>] dump_stack+0xa0/0xf8
[<ffffffc0001df490>] kasan_report_error+0x23c/0x264
[<ffffffc0001e0188>] check_memory_region+0xc0/0xe4
[<ffffffc0001dedf0>] __asan_load8+0x10/0x1c
[<ffffffc000431294>] gic_raise_softirq+0xc4/0x1b4
[<ffffffc000091fc0>] smp_send_reschedule+0x30/0x3c
[<ffffffc0000f0d1c>] try_to_wake_up+0x394/0x434
[<ffffffc0000f0de8>] wake_up_process+0x2c/0x6c
[<ffffffc0000d9570>] wake_up_worker+0x38/0x48
[<ffffffc0000dbb50>] insert_work+0xac/0xec
[<ffffffc0000dbd38>] __queue_work+0x1a8/0x374
[<ffffffc0000dbf60>] queue_work_on+0x5c/0x7c
[<ffffffc0000d8a78>] call_usermodehelper_exec+0x170/0x188
[<ffffffc0004037b8>] kobject_uevent_env+0x650/0x6bc
[<ffffffc000403830>] kobject_uevent+0xc/0x18
[<ffffffc00040292c>] kset_register+0xa8/0xc8
[<ffffffc0004d6c88>] bus_register+0x134/0x2e8
[<ffffffc0004d73b4>] subsys_virtual_register+0x2c/0x5c
[<ffffffc000a76a4c>] wq_sysfs_init+0x14/0x20
[<ffffffc000082a28>] do_one_initcall+0xa8/0x1fc
[<ffffffc000a70db4>] kernel_init_freeable+0x1ec/0x294
[<ffffffc00075aa5c>] kernel_init+0xc/0xec
Memory state around the buggy address:
ffffff80003e0820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffff80003e0830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffff80003e0840: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
^
ffffff80003e0850: 00 00 fa fa fa fa fa fa 00 00 00 00 00 00 00 00
==================================================================
The reason for that cpumask_next() returns >= nr_cpu_ids if no further cpus
set, but "==" condition is checked only, so we end up with out-of-bounds
access to cpu_logical_map.
Fix is by using the condition check for cpumask_next.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-7-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
When compiled with CONFIG_LOCKDEP, the kernel shouts badly, saying
that the locking in the GIC code is unsafe. I'm afraid the kernel
is right:
CPU0
----
lock(irq_controller_lock);
<Interrupt>
lock(irq_controller_lock);
*** DEADLOCK ***
This can happen while enabling, disabling, setting the type
or the affinity of an interrupt.
The fix is to take the interrupt_controller_lock with interrupts
disabled in these cases.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-6-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
When compiled with CONFIG_LOCKDEP, the kernel shouts badly, saying
that my locking is unsafe. I'm afraid the kernel is right:
CPU0 CPU1
---- ----
lock(&its->lock);
local_irq_disable();
lock(&irq_desc_lock_class);
lock(&its->lock);
<Interrupt>
lock(&irq_desc_lock_class);
*** DEADLOCK ***
The fix is to always take its->lock with interrupts disabled.
Reported-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-5-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
The current PCI/MSI support in the GICv3 ITS doesn't really deal
with systems where different PCI devices end-up using the same
RequesterID (as it would be the case with non-transparent bridges,
for example). It is likely that none of these devices would
actually generate any interrupt, as the ITS is programmed with
the device's own ID, and not that of the bridge.
A solution to this is to iterate over the PCI hierarchy to
discover what the device aliases too. We also use this
to discover the upper bound of the number of MSIs that this
sub-hierarchy can generate.
With this in place, PCI aliases can be supported.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-4-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
The ITS table allocator is only allocating a single page per table.
This works fine for most things, but leads to silent lack of
interrupt delivery if we end-up with a device that has an ID that is
out of the range defined by a single page of memory. Even worse, depending
on the page size, behaviour changes, which is not a very good experience.
A solution is actually to allocate memory for the full range of ID that
the ITS supports. A massive waste memory wise, but at least a safe bet.
Tested on a Phytium SoC.
Tested-by: Chen Baozi <chenbaozi@kylinos.com.cn>
Acked-by: Chen Baozi <chenbaozi@kylinos.com.cn>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-3-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
We skip initialisation of ITS in case the device-tree has no
corresponding description, but we are still accessing to ITS bits while
setting CPU interface what leads to the kernel panic:
ITS: No ITS available, not enabling LPIs
CPU0: found redistributor 0 region 0:0x000000002f100000
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = ffffffc0007fb000
[00000000] *pgd=00000000fc407003, *pud=00000000fc407003, *pmd=00000000fc408003, *pte=006000002f000707
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc2+ #318
Hardware name: FVP Base (DT)
task: ffffffc00077edb0 ti: ffffffc00076c000 task.ti: ffffffc00076c000
PC is at its_cpu_init+0x2c/0x320
LR is at gic_cpu_init+0x168/0x1bc
It happens in gic_rdists_supports_plpis() because gic_rdists is NULL.
The gic_rdists is set to non-NULL only when ITS node is presented in
the device-tree.
Fix this by moving the call to gic_rdists_supports_plpis() inside the
!list_empty(&its_nodes) block, because it is that list that guards the
validity of the rest of the information in this driver.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
On the Cortex-A9-based Armada SoCs, the MPIC is not the primary interrupt
controller. Yet, it still has to handle some per-cpu interrupt.
To do so, it is chained with the GIC using a per-cpu interrupt. However, the
current code only call irq_set_chained_handler, which is called and enable that
interrupt only on the boot CPU, which means that the parent per-CPU interrupt
is never unmasked on the secondary CPUs, preventing the per-CPU interrupt to
actually work as expected.
This was not seen until now since the only MPIC PPI users were the Marvell
timers that were not working, but not used either since the system use the ARM
TWD by default, and the ethernet controllers, that are faking there interrupts
as SPI, and don't really expect to have interrupts on the secondary cores
anyway.
Add a CPU notifier that will enable the PPI on the secondary cores when they
are brought up.
Cc: <stable@vger.kernel.org> # 3.15+
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1425378443-28822-1-git-send-email-maxime.ripard@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
Apparently, the threshold for large contact area seems to be rather low on
some devices, causing the touchpad to frequently freeze during normal
usage. Because we do now know how we are supposed to use the value in
question, this commit just drops the related code completely.
Signed-off-by: Mathias Gottschlag <mgottschlag@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
These PS/2 commands make some touchpads stop responding, so this commit
adds some dummy functions to replace the generic implementation. Because
scale changes were not encapsulated in a method of struct psmouse yet, this
commit adds a method set_scale to psmouse.
Signed-off-by: Mathias Gottschlag <mgottschlag@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
We don't know whether x_max or y_max really hold the maximum possible
coordinates, and we don't know for sure whether we correctly interpret the
coordinates sent by the touchpad, so we clamp the reported values to
prevent confusion in userspace code.
Signed-off-by: Mathias Gottschlag <mgottschlag@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
The size has in most cases already been fetched from the touchpad, the
hardcoded values should have been removed.
Signed-off-by: Mathias Gottschlag <mgottschlag@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
