When uhid_get_report() or uhid_set_report() are called, they emit on the
char device a UHID_GET_REPORT or UHID_SET_REPORT message. Then, the
protocol says that the user space asnwers with UHID_GET_REPORT_REPLY
or UHID_SET_REPORT_REPLY.
Unfortunatelly, the current code waits for an event of type UHID_GET_REPORT
or UHID_SET_REPORT instead of the reply one.
Add 1 to UHID_GET_REPORT or UHID_SET_REPORT to actually wait for the
reply, and validate the reply.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is a second mouse sharing the same vendor strings but different IDs.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
ISDv4 and v5 are plain HID devices. We can directly implement a generic
HID parsing/handling and remove the need to manually add those PID in
the list of supported devices.
This patch implements the pen support only. The finger part will come in
a later patch.
To be properly notified of an .event() and a .report(), we need to force
hid-core to go through the HID parsing. By default, wacom.ko binds only
hidraw, so the hid parsing is not done by hid-core. When a true HID device
is there, we add the flag HID_CLAIMED_DRIVER to hid->claimed which will
force hid-core to parse the incoming reports.
(Note that this can be easily backported by directly setting the .claimed
flag to HID_CLAIMED_DRIVER even if hid-core does not support
HID_CONNECT_DRIVER)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This allows to have the input devices ready in while parsing the reports
descriptor.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If the input can be created earlier during probe, we can already populate
them while reading the report descriptor. This way, we can rely on the
hid subsystem directly for tablets which already provide a meaningful
report descriptor (like ISDv4-5).
This patch only splits the allocation and registration, but do not
change where we allocate the input. This will come in a later patch.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When we have to deal with new elements in probe, having the exit labels
named sequencially is a pain to maintain. Put a meaningful name instead
so that we do not have to renumber them on inserts.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The DualShock 4 touchpad has been measured to have a resolution of
44.86 dots/mm which equates to 1920x942.
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some Wacom tablets (at least the ISDv4 found in the Lenovo X230) timeout
during probe while retrieving the input reports.
The only time this information is valuable is during the feature_mapping
stage, so we can ask for it there and discard the generic input reports
retrieval.
This gives a code path closer to the wacom.ko driver when it was in the
input subtree (not HID).
Cc: stable@vger.kernel.org # requires cherry-pick of c64d883476
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Set the DualShock4 touchpad bits in the input_configured callback
so that they are registered properly for any input devices created
during hid_hw_start.
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Update the file header and correct an outdated comment block.
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Fix a few minor issues in the HID descriptor:
- A 6 bit entry had a logical maximum of 255 when the largest it can be is 63.
- A logical max value was incorrectly being set to -1 instead of 255.
- Set the min/max of the gyroscopes to -8192/8191 as that is the range of
values which represent the true controller orientation. Any values beyond
those extents are just noise.
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In the Dell XPS 13 9333, it appears that sometimes the bus get confused
and corrupts the incoming data. It fills the input report with the
sentinel value "ff". Synaptics told us that such behavior does not comes
from the touchpad itself, so we filter out such reports here.
Unfortunately, we can not simply discard the incoming data because they
may contain useful information. Most of the time, the misbehavior is
quite near the end of the report, so we can still use the valid part of
it.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1123584
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Currently, tablets connected to the WL receiver all share the same
VID/PID. There is no way for the user space to know which one is which
besides parsing the name. We can force the PID to be set to the
actual hardware. This way, the input device will have the correct PID
which can be match in libwacom.
With only this trick, the pad input does not inherit the ID_INPUT_TABLET
udev property from its parent. We can force udev to accept it by declaring
a BTN_STYLUS which is never used.
This way, tablets connected through WL can be used from the user point of
view in the same way they are used while connected through wire.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
And associate all LED/OLED to PAD device
Signed-off-by: Ping Cheng <pingc@wacom.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
It is assigned in buf[0] anyway.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
changed to scnprintf(buf, PAGE_SIZE, ... ) as suggested in sysfs.txt
for show functions
Signed-off-by: Paul A. Tessier <phernost@gmail.com>
Signed-Off-by: Ping Cheng <pingc@wacom.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This mouse keeps disconnecting in runlevel 3. It needs the ALWAYS_POLL quirk.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The report descriptor for the HOLTEK USB ID 04d9:a0c2 (ETEKCITY Scroll
T-140 Gaming Mouse) is set to a very large amount of consumer usages
(2^16), exceeding HID_MAX_USAGES. Added id, bindings and comments for
the mouse, added to hid_have_special_driver, and reduced the usage and
logical maximums to 0x2fff, consistent with the other mice in the
category. Tested on the hardware.
Signed-off-by: John C. DeSilva <desilvjo@umich.edu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Enable the always-poll quirk for Elan Touchscreens found on some recent
Samsung laptops.
Without this quirk the device keeps disconnecting from the bus (and is
re-enumerated) unless opened (and kept open, should an input event
occur).
Note that while the device can be run-time suspended, the autosuspend
timeout must be high enough to allow the device to be polled at least
once before being suspended. Specifically, using autosuspend_delay_ms=0
will still cause the device to disconnect on input events.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add quirk to make sure that a device is always polled for input events
even if it hasn't been opened.
This is needed for devices that disconnects from the bus unless the
interrupt endpoint has been polled at least once or when not responding
to an input event (e.g. after having shut down X).
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch adds a seperate hid-penmount driver to work
around an issue with the HID report descriptor. The
descriptor does not contain the ContactID usage and as
result the touchscreen is represented as normal mouse
to the system.
This driver maps the button 0 emitted by the touchscreen
to BTN_TOUCH. This makes it possible to use touch events
in userspace.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
thingm_remove_rgb() needs to flush the workqueue after all the LED classes
have been unregistered, otherwise the removal might race with another LED
event coming, causing thingm_led_set() to schedule additional work after
thingm_remove_rgb() has flushed it. This obviously causes oops later, as
the scheduled work has been freed in the meantime.
In addition to that, move the hid_hw_stop() to an earlier place, so that
dmesg is not polluted by failure messages about not being able to write
the LED while the device is being shut down.
Reported-and-tested-by: Dylan Alex Simon <dylan-kernel@dylex.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Adding USB_DEVICE_ID_STM_HID_SENSOR again in the quirk table. During 3.16 merge
cycle somehow quirk for device id USB_DEVICE_ID_STM_HID_SENSOR is missing.
I see commit dde3b45cd7 ("HID: hid-sensor-hub: new device id and quirk
for STM Sensor hub") added new id USB_DEVICE_ID_STM_HID_SENSOR_1,
but didn't really delete the old device id.
Anyway we need to add this back, otherwise it breaks ST sensor hubs.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In case of an unsupported firmware, the driver bails out without setting
the LEDs interfaces, but forget to set the proper error code.
err is then still equal to 0 and the hid subsytem consider the device
to be in perfect shape.
When removing it, thingm_remove() tries to unbind the rgb LEDs which
has not been created, leading to a segfault.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Wacom Cintiq Companion shares the same sensor than the Cintiq
Companion Hybrid, with the exception of the different PIDs.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch changes the way usbhid carries out Clear-Halt and reset.
Currently, after a Clear-Halt on the interrupt-IN endpoint, the driver
immediately restarts the interrupt URB, even if the Clear-Halt failed.
This doesn't work out well when the reason for the failure was that
the device was disconnected (when a low- or full-speed device is
connected through a hub to an EHCI controller, transfer errors caused
by disconnection are reported as stalls by the hub). Instead now the
driver will attempt a reset after a failed Clear-Halt.
The way resets are carried out is also changed. Now the driver will
call usb_queue_reset_device() instead of calling usb_reset_device()
directly. This avoids a deadlock that would arise when a device is
unplugged: The hid_reset() routine runs as a workqueue item, a reset
attempt after the device has been unplugged will fail, failure will
cause usbhid to be unbound, and the disconnect routine will try to do
cancel_work_sync(). The usb_queue_reset_device() implementation is
carefully written to handle scenarios like this one properly.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Bit 3 in byte 31 of the Sixaxis report indicates whether the battery is
charging or not charging as opposed to whether or not the cable is plugged in.
As a result, when connected via USB and fully charged, the power_supply status
is wrongly reported as 'Discharging' instead of 'Full'.
Use the battery level value to set the cable state so that the power status
is reported correctly as that seems to be the only reliable way to determine the
cable status on the Sixaxis.
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
picolcd device is not expected to send any report with size larger than
64 bytes.
If this impossible event happens (sic!), print also a report ID to allow
for easier debugging.
Suggested-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We can do once the test of the validity of the dj_device, which removes
some duplicated code in various functions.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull HID fixes from Jiri Kosina:
- fixes for potential memory corruption problems in magicmouse and
picolcd drivers (the HW would have to be manufactured to be
deliberately evil to trigger those) which were found by Steven
Vittitoe
- fix for false error message appearing in dmesg from logitech-dj
driver, from Benjamin Tissoires
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: picolcd: sanity check report size in raw_event() callback
HID: magicmouse: sanity check report size in raw_event() callback
HID: logitech-dj: prevent false errors to be shown
Pull btrfs fixes from Chris Mason:
"The biggest of these comes from Liu Bo, who tracked down a hang we've
been hitting since moving to kernel workqueues (it's a btrfs bug, not
in the generic code). His patch needs backporting to 3.16 and 3.15
stable, which I'll send once this is in.
Otherwise these are assorted fixes. Most were integrated last week
during KS, but I wanted to give everyone the chance to test the
result, so I waited for rc2 to come out before sending"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: (24 commits)
Btrfs: fix task hang under heavy compressed write
Btrfs: fix filemap_flush call in btrfs_file_release
Btrfs: fix crash on endio of reading corrupted block
btrfs: fix leak in qgroup_subtree_accounting() error path
btrfs: Use right extent length when inserting overlap extent map.
Btrfs: clone, don't create invalid hole extent map
Btrfs: don't monopolize a core when evicting inode
Btrfs: fix hole detection during file fsync
Btrfs: ensure tmpfile inode is always persisted with link count of 0
Btrfs: race free update of commit root for ro snapshots
Btrfs: fix regression of btrfs device replace
Btrfs: don't consider the missing device when allocating new chunks
Btrfs: Fix wrong device size when we are resizing the device
Btrfs: don't write any data into a readonly device when scrub
Btrfs: Fix the problem that the replace destroys the seed filesystem
btrfs: Return right extent when fiemap gives unaligned offset and len.
Btrfs: fix wrong extent mapping for DirectIO
Btrfs: fix wrong write range for filemap_fdatawrite_range()
Btrfs: fix wrong missing device counter decrease
Btrfs: fix unzeroed members in fs_devices when creating a fs from seed fs
...
condition variable (waiters_pending) was set before being added to
the poll queue via poll_wait(). This allowed for a small race window
to happen where an event could come in, check the condition variable
see it set to true, clear it, and then wake all the waiters. But because
the waiter set the variable before adding itself to the queue, the
waker could have cleared the variable after it was set and then miss
waking it up as it wasn't added to the queue yet.
Discussing this bug, we realized that a memory barrier needed to be added
too, for the rare case that something polls for a single trace event
to happen (and just one, no more to come in), and miss the wakeup due
to memory ordering. Ideally, a memory barrier needs to be added on the
writer side too, but as that will kill tracing performance and this is
for a situation that tracing wasn't even designed for (who traces one
instance of an event, use a printk instead!), this isn't worth adding the
barrier. But we can in the future add the barrier for when the buffer
goes from empty to the first event, as that would cover this case.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJT/IgUAAoJEKQekfcNnQGumJgIALG63LVR4ZS+bjHGTxyovCiL
EE6Aic7/hHB8ajn/QZJAaVbaxf0woIyPaU6NP5p17rgF44gTtaEzg3hDqOXkBXvh
aMLTEz2Xm6nu1VQ5vk//9qqplE+WMXWS6YjjnxErRja90cBZblFy9h9LzwwexLkm
oXmhjVF1ke5AKFiXQ+Dj9LJse80MvSEEFk1eeUR7oNqK/4rwzKmkefkUnk2NbST4
cFkOAbTfZnMXlhUhB2EY2Ptprty3scrA7bpe00ClzFmoQ9MxDVlLJBN9aEjaTnxM
zKiXsxy/eJ+0IPSOSEajh3IJb96sbqZnt++28vDhck3e6k3G4CQwbuktPdQXUo8=
=jful
-----END PGP SIGNATURE-----
Merge tag 'trace-fixes-v3.17-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull trace buffer epoll hang fix from Steven Rostedt:
"Josef Bacik found a bug in the ring_buffer_poll_wait() where the
condition variable (waiters_pending) was set before being added to the
poll queue via poll_wait(). This allowed for a small race window to
happen where an event could come in, check the condition variable see
it set to true, clear it, and then wake all the waiters. But because
the waiter set the variable before adding itself to the queue, the
waker could have cleared the variable after it was set and then miss
waking it up as it wasn't added to the queue yet.
Discussing this bug, we realized that a memory barrier needed to be
added too, for the rare case that something polls for a single trace
event to happen (and just one, no more to come in), and miss the
wakeup due to memory ordering. Ideally, a memory barrier needs to be
added on the writer side too, but as that will kill tracing
performance and this is for a situation that tracing wasn't even
designed for (who traces one instance of an event, use a printk
instead!), this isn't worth adding the barrier. But we can in the
future add the barrier for when the buffer goes from empty to the
first event, as that would cover this case"
* tag 'trace-fixes-v3.17-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
trace: Fix epoll hang when we race with new entries
The report passed to us from transport driver could potentially be
arbitrarily large, therefore we better sanity-check it so that raw_data
that we hold in picolcd_pending structure are always kept within proper
bounds.
Cc: stable@vger.kernel.org
Reported-by: Steven Vittitoe <scvitti@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The report passed to us from transport driver could potentially be
arbitrarily large, therefore we better sanity-check it so that
magicmouse_emit_touch() gets only valid values of raw_id.
Cc: stable@vger.kernel.org
Reported-by: Steven Vittitoe <scvitti@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull s390 updates from Martin Schwidefsky:
- wire up the system calls seccomp, getrandom and memfd_create
- use static system information as input to add_device_randomness
- .. and three bug fixes
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/sclp: remove unnecessary XTABS flag
s390/3215: fix tty output containing tabs
s390: wire up memfd_create syscall
s390: add system information as device randomness
s390/kdump: Clear subchannel ID to signal non-CCW/SCSI IPL
s390: wire up seccomp and getrandom syscalls
Update the description for per cpu operations to clarify use cases of
this_cpu operations and add considerations for remote access.
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
Signed-off-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix scripts/kernel-doc to recognize __meminit in a function prototype
and to strip it, as done with many other attributes.
Fixes this warning:
Warning(..//mm/page_alloc.c:2973): cannot understand function prototype: 'void * __meminit alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask) '
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Atmel 840B digitizer presents a stylus interface which reports twice
the X coordinate and then twice the Y coordinate. In its current
implementation, hid-input assign the first X to X, then the second to Y,
then the first Y to Z, then the second one to RX.
This is wrong, and X should always be mapped to X, no matter what.
A solution consists in forcing X, Y, Z, RX, RY, RZ to be mapped to their
correct user space counter part.
Reported-by: Éric Brunet <Eric.Brunet@lps.ens.fr>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Epoll on trace_pipe can sometimes hang in a weird case. If the ring buffer is
empty when we set waiters_pending but an event shows up exactly at that moment
we can miss being woken up by the ring buffers irq work. Since
ring_buffer_empty() is inherently racey we will sometimes think that the buffer
is not empty. So we don't get woken up and we don't think there are any events
even though there were some ready when we added the watch, which makes us hang.
This patch fixes this by making sure that we are actually on the wait list
before we set waiters_pending, and add a memory barrier to make sure
ring_buffer_empty() is going to be correct.
Link: http://lkml.kernel.org/p/1408989581-23727-1-git-send-email-jbacik@fb.com
Cc: stable@vger.kernel.org # 3.10+
Cc: Martin Lau <kafai@fb.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Highlights:
- More fixes for read/write codepath regressions
- Sleeping while holding the inode lock
- Stricter enforcement of page contiguity when coalescing requests
- Fix up error handling in the page coalescing code
- Don't busy wait on SIGKILL in the file locking code
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJT+0LpAAoJEGcL54qWCgDyWfsP/imrpge47aZywi95chV8vgjM
O85ITZbupTFwXbB7kE63CrcaxRGhFrSStk4UDhDCDkHfFb1ksjZaPR1mnkwvkR2p
4+JUoq0fkPfeX21+rqKCYmnhstpne/N8K8FJBsEs3/TqiCBWxWOelLXdyWun4H5B
9JBYQ7FYitUazeSiSiDXcl7Di/E09cFPi0H5VPKRyuNdYxySabnsBOELBE/28iXr
egW1I9UKQR2EtBrvgazBbWE5XmB9XAm4X3sD1l0QD65mfSNkbnNhPFSiCdT7f/d6
9uxECR0Y4wNYgYAfVLBew5/MXJajcv03BFMKmTUeGj9fOQzycpBT4Dx2KxEWqfnt
Xk2nNbISxBnO0koMflmo+LPv2lv+Br3kQ+eZCHHKknvBrX2a6bJdTCZkwACVtND9
LdbAveFQpdaeLrm/28TnRoE927r+VeAVM19yOSG8sNAskFFg4Yy51tR0e1GivkJT
+qmmTRx+l78HjHvoPXOYdNgBC954r6APH5ST7su/7WxNClM36fEK6XxA9xbDLJWm
wUzlGKvpwEeBJJhgjbQLwuU8BiksjFz/CaiObNvPOpc/d2GoKIhnTg19kNhg2R//
UCDa2d5fep4z0Bo9p0s1KZm9pSBkkLjvRp9dm8WEIxLcdaF1jBK3dJECepm6ccvw
dmEmEfjbMudVdt/ZhapJ
=2wRt
-----END PGP SIGNATURE-----
Merge tag 'nfs-for-3.17-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
Pull NFS client fixes from Trond Myklebust:
"Highlights:
- more fixes for read/write codepath regressions
* sleeping while holding the inode lock
* stricter enforcement of page contiguity when coalescing requests
* fix up error handling in the page coalescing code
- don't busy wait on SIGKILL in the file locking code"
* tag 'nfs-for-3.17-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
nfs: Don't busy-wait on SIGKILL in __nfs_iocounter_wait
nfs: can_coalesce_requests must enforce contiguity
nfs: disallow duplicate pages in pgio page vectors
nfs: don't sleep with inode lock in lock_and_join_requests
nfs: fix error handling in lock_and_join_requests
nfs: use blocking page_group_lock in add_request
nfs: fix nonblocking calls to nfs_page_group_lock
nfs: change nfs_page_group_lock argument
* Confine SH_INTC to platforms that need it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJT+oswAAoJENfPZGlqN0++/A8QAK2yp96zl7gABtddgkunNJiV
xWCm4wcP+7dIrLpwizxtt/6HMPj9ZJHYtcxRRKVlzquwcukeVCIkfZ3Qvn2JilWM
+b4rVRGzQ+z0M7SCpNGjtgFc1IFrVrzuxZpPwgseQ5I6HQsZJKUi3qn5rRJSEax2
w+ANis2eZfmSBdu3Qsx2QBDXvS7ZPlLpimoAE+rjr60dZnljcrvBrVHQvSgpEHxn
4rXPbYrrkIee32J4lxLRDPtn5fvAsrr+vcLXEYqyFr2292U2PAxIrjZgrRzZYNtD
L6xmhZAhdmIpC0gLDLyKQhwj/9pfGFxFErZX9jeGdPT2KTEEYPkSxb75kdTwmxP4
DEtZG9Nuu6CQCBldrMt6kpujn+XCYRl94cSyUffJ5KVhNUiqB+e+JP80Yj9HB7QU
nGUfs2hQ/azY8XEiwvnls0314thkB5gN7KHxmlaFa9Wz7cgYFwWAguHH8qrq839U
+i+7dUg7nlmVoIAvzYIIA+L7x3xX4gEwsf88x3i04DPp0A8/oDAwGrqM5QzsaZpD
ghodnKRG7foc+29RLYka5CxF/MqKzpJu675sSBCVB3uW9NZpoGSwml/NN9yUu1JD
uvU2FECcbxF5OU6RHfq8FFql0fAOVeVWsMCEXgkjpZOXynKU15VTf1K2d+qkUZ/Y
gV45Jj+yCZhYs0wbXUml
=QSyy
-----END PGP SIGNATURE-----
Merge tag 'renesas-sh-drivers-for-v3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas
Pull SH driver fix from Simon Horman:
"Confine SH_INTC to platforms that need it"
* tag 'renesas-sh-drivers-for-v3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
sh: intc: Confine SH_INTC to platforms that need it
Pull MIPS fixes from Ralf Baechle:
"Pretty much all across the field so with this we should be in
reasonable shape for the upcoming -rc2"
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: OCTEON: make get_system_type() thread-safe
MIPS: CPS: Initialize EVA before bringing up VPEs from secondary cores
MIPS: Malta: EVA: Rename 'eva_entry' to 'platform_eva_init'
MIPS: EVA: Add new EVA header
MIPS: scall64-o32: Fix indirect syscall detection
MIPS: syscall: Fix AUDIT value for O32 processes on MIPS64
MIPS: Loongson: Fix COP2 usage for preemptible kernel
MIPS: NL: Fix nlm_xlp_defconfig build error
MIPS: Remove race window in page fault handling
MIPS: Malta: Improve system memory detection for '{e, }memsize' >= 2G
MIPS: Alchemy: Fix db1200 PSC clock enablement
MIPS: BCM47XX: Fix reboot problem on BCM4705/BCM4785
MIPS: Remove duplicated include from numa.c
MIPS: Add common plat_irq_dispatch declaration
MIPS: MSP71xx: remove unused plat_irq_dispatch() argument
MIPS: GIC: Remove useless parens from GICBIS().
MIPS: perf: Mark pmu interupt IRQF_NO_THREAD
separate trampolines had a design flaw with the interaction between
the function and function_graph tracers.
The main flaw was the simplification of the use of multiple tracers having
the same filter (like function and function_graph, that use the
set_ftrace_filter file to filter their code). The design assumed that the
two tracers could never run simultaneously as only one tracer can be
used at a time. The problem with this assumption was that the function
profiler could be implemented on top of the function graph tracer, and
the function profiler could run at the same time as the function tracer.
This caused the assumption to be broken and when ftrace detected this
failed assumpiton it would spit out a nasty warning and shut itself down.
Instead of using a single ftrace_ops that switches between the function
and function_graph callbacks, the two tracers can again use their own
ftrace_ops. But instead of having a complex hierarchy of ftrace_ops,
the filter fields are placed in its own structure and the ftrace_ops
can carefully use the same filter. This change took a bit to be able
to allow for this and currently only the global_ops can share the same
filter, but this new design can easily be modified to allow for any
ftrace_ops to share its filter with another ftrace_ops.
The first four patches deal with the change of allowing the ftrace_ops
to share the filter (and this needs to go to 3.16 as well).
The fifth patch fixes a bug that was also caused by the new changes
but only for archs other than x86, and only if those archs implement
a direct call to the function_graph tracer which they do not do yet
but will in the future. It does not need to go to stable, but needs
to be fixed before the other archs update their code to allow direct
calls to the function_graph trampoline.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJT+hqSAAoJEKQekfcNnQGulvcH/0O4NMXX4HH1dQlYgKEaSYxE
Nh8WdiewopF5iaeNvo+8Nzdq8D2k3KgMOqSlzJ4JVmzd7gjOBSGeKDfqFwR+IbTk
9LcaJJCI3oG3MEf6m7gZMdjKPKyxkeYHDtG7kRHo8z94eliV9pKC6fUnEWayQO3o
Kv6IBupdkF8ICAiKRae5Uo0c9wjZ9YP0bZS7fxI2hJw3h/NMFnhnhUL03URIx8e3
dqgpweYg+P3KPfp2Jz6safdJqLTPK9rqqhkZhylbDl7o78xEzRN7wCyB6Nak00xz
swRgsW6vFP7ci/YSNx+B6HCIf7NTm3WLDrrIhitNHcJUZwUMU3CRO9IJHGsTuEE=
=J5lZ
-----END PGP SIGNATURE-----
Merge tag 'trace-fixes-v3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull fix for ftrace function tracer/profiler conflict from Steven Rostedt:
"The rewrite of the ftrace code that makes it possible to allow for
separate trampolines had a design flaw with the interaction between
the function and function_graph tracers.
The main flaw was the simplification of the use of multiple tracers
having the same filter (like function and function_graph, that use the
set_ftrace_filter file to filter their code). The design assumed that
the two tracers could never run simultaneously as only one tracer can
be used at a time. The problem with this assumption was that the
function profiler could be implemented on top of the function graph
tracer, and the function profiler could run at the same time as the
function tracer. This caused the assumption to be broken and when
ftrace detected this failed assumpiton it would spit out a nasty
warning and shut itself down.
Instead of using a single ftrace_ops that switches between the
function and function_graph callbacks, the two tracers can again use
their own ftrace_ops. But instead of having a complex hierarchy of
ftrace_ops, the filter fields are placed in its own structure and the
ftrace_ops can carefully use the same filter. This change took a bit
to be able to allow for this and currently only the global_ops can
share the same filter, but this new design can easily be modified to
allow for any ftrace_ops to share its filter with another ftrace_ops.
The first four patches deal with the change of allowing the ftrace_ops
to share the filter (and this needs to go to 3.16 as well).
The fifth patch fixes a bug that was also caused by the new changes
but only for archs other than x86, and only if those archs implement a
direct call to the function_graph tracer which they do not do yet but
will in the future. It does not need to go to stable, but needs to be
fixed before the other archs update their code to allow direct calls
to the function_graph trampoline"
* tag 'trace-fixes-v3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
ftrace: Use current addr when converting to nop in __ftrace_replace_code()
ftrace: Fix function_profiler and function tracer together
ftrace: Fix up trampoline accounting with looping on hash ops
ftrace: Update all ftrace_ops for a ftrace_hash_ops update
ftrace: Allow ftrace_ops to use the hashes from other ops
Remove legacy bits, refer people to hid-transport.txt and add descriptions
for all new features.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This makes UHID_START include a "dev_flags" field that describes details
of the hid-device in the kernel. The first flags we introduce describe
whether a given report-type uses numbered reports. This is useful for
transport layers that force report-numbers and therefore might have to
prefix kernel-provided HID-messages with the report-number.
Currently, only HoG needs this and the spec only talks about "global
report numbers". That is, it's a global boolean not a per-type boolean.
However, given the quirks we already have in kernel-space, a per-type
value seems much more appropriate.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
