- 05 Aug, 2016 28 commits
-
-
Benjamin Tissoires authored
When upowerd detects a new device, it tries to map this new device to an input to guess its kind. It works OK for wired tablets when the wireless module and its battery are attached, but not so well when connected over wireless. In that case, the battery is attached to the wireless HID node, not the Pen or Pad HID node. So there is no input node as a parent of the reported battery, which means it will be showed as a computer battery in gnome-control-center. If we set the power supply type to USB, upowerd has a heuristic that detects "wacom_" in the name of the power_supply, and set the type to tablet. So it's now clear that the reported battery of from a tablet. (see https://cgit.freedesktop.org/upower/tree/src/linux/up-device-supply.c) Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by:
Ping Cheng <pingc@wacom.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
Benjamin Tissoires authored
The 24HD has 1 button per LED (first three buttons of each group). We need a special treatment for them as it's not a uniq button that switches between the LEDs. Signed-off-by:
-
Benjamin Tissoires authored
The code for 21UX2 and 24HD makes the LED group 1 on the left, and the group 0 on the right. The buttons are ordered in the other way, but libwacom already exports those that way. So we simply can't reassign LED group 0 to the left buttons, and have to quirk the incoming data... Signed-off-by:
-
Benjamin Tissoires authored
The EKR switches the LED directly, and there is no point in having userspace handling the switch it self when it's easy enough to do in the kernel. The other benefit is that now userspace does not need to have root access to the LED but need only to read them with user privileges. Signed-off-by:
-
Benjamin Tissoires authored
There is a bug (?) in devm_led_classdev_register() in which its increments the refcount of the parent. If the parent is an input device, that means the ref count never reaches 0 when devm_input_device_release() gets called. This means that the LEDs and all the devres resources attached to the input device are not released. Manually force the release of the group so that the leds are released once we are done using them. Signed-off-by:
-
Benjamin Tissoires authored
The now obsolete sysfs files for LEDs and EKRemote are kept for backward compatibility. Both the EKR (read-only) and the regular Cintiqs and Intuos are now sharing the same led API. Signed-off-by:
-
Benjamin Tissoires authored
Or Gnome complains about an empty battery. Signed-off-by:
-
Benjamin Tissoires authored
Previously, all the remotes attached to the same receiver would share the same power_supply. That's not good as the remotes will constantly change the battery information according to their own state. To have something generic enough, we introduce struct wacom_battery which regroups all the information we need for a battery. Signed-off-by:
-
Benjamin Tissoires authored
Thanks to devres, we can now afford to create more than one input node without having to overload the remove/failure paths. Having one input node per remote is something which should have been implemented from start but the probability of having users with several remotes is quite low. Anyway, still, better looking at the future and implement things properly. Remote input nodes will be freed/unregistered magically as they are created in the devres group &remote->remotes[index]. We need to open the hid node now that the remotes are dynamically allocated. Signed-off-by:
-
Benjamin Tissoires authored
No functional changes, just a prep patch for the one after. Signed-off-by:
-
Benjamin Tissoires authored
This will be useful when each remote will be assigned its own input device. We won't need to unregister each input and sysfs and other elements one at a time. Signed-off-by:
-
Benjamin Tissoires authored
The wacom_remote_create_attr_group() and wacom_remote_destroy_attr_group() functions were both allocating/destroying the sysfs groups but also initializing the parameters for the remotes. Have proper functions that can be called and extended. Signed-off-by:
-
Benjamin Tissoires authored
Thanks to devres management, we don't need to remember a lot of failure path. One or two is enough. Signed-off-by:
-
Benjamin Tissoires authored
If we want to have one input device per remote, it's better to have our own struct wacom_remote which is dynamically allocated. Signed-off-by:
-
Benjamin Tissoires authored
wacom_remote_status_irq() sends information of addition/removal of EKR. We want to allocate one input node per remote, so better having this in a separate worker, not handled in the IRQ directly. Signed-off-by:
-
Benjamin Tissoires authored
We need to add an action to ensure wacom->led.groups is null when wacom_led_control() gets called after the resources has been freed. This also prevents to send a LED command when there is no support from the device. Signed-off-by:
-
Benjamin Tissoires authored
wacom_release_shared_data() and wacom_remove_shared_data() are moved up so they can be referenced in wacom_add_shared_data(). There is no point in explicitly setting wacom_wac1->shared->type to 0 in wacom_wireless_work() (plus this would give an oops). Signed-off-by:
-
Benjamin Tissoires authored
We started switching the driver to devres, so we should use it as much as possible. Signed-off-by:
-
Benjamin Tissoires authored
The sysfs group was indeed removed by kobject_put(wacom->remote_dir) in wacom_remove(), but the name of the group was never freed. Also remove the misplaced kobject_put(wacom->remote_dir) in the error path of wacom_remote_create_attr_group(). Signed-off-by:
-
Benjamin Tissoires authored
Use our own wacom_devm_sysfs_create_group() as there is currently no generic one. It has been requested at least twice [1][2] but has been always rejected. However, in the Wacom case, for the wirelessly connected devices, we need to be able to release the created sysfs files without removing the parent kobject. [1] https://patchwork.kernel.org/patch/7526551/ [2] https://lkml.org/lkml/2013/3/14/728Signed-off-by:
-
Benjamin Tissoires authored
We currently have a complex clean_inputs() function while this can be handled all by devres. Set a group that we can destroy in wireless_work(). Signed-off-by:
-
Benjamin Tissoires authored
Simplifying the error code paths. We need to keep wacom_clean_inputs() around for now as the wireless module is using it to dynamically remove the inputs on disconnect. Signed-off-by:
-
Benjamin Tissoires authored
Simplifying the error code paths. We need to keep wacom_destroy_battery() around for now as the wireless module and the remotes are using it to dynamically remove the battery supply on disconnect. Signed-off-by:
-
Benjamin Tissoires authored
Looks like the battery hijacked the wireless worker. That's not fair so use a work queue per task. Signed-off-by:
-
Benjamin Tissoires authored
Like remotes, LEDs should be handled by themself, not magically behind the inputs as they have a complete different life. Signed-off-by:
-
Benjamin Tissoires authored
wacom->remote_dir has nothing to do with inputs, so better not magically removing it when cleaning inputs. Signed-off-by:
-
Benjamin Tissoires authored
The type is never set but we check for it in wacom_wireless_irq(). It looks like this is a big hack from the beginning, so fill in the gap only. Untested. Signed-off-by:
-
Benjamin Tissoires authored
Since fd5f92b6 ("HID: wacom: reuse wacom_parse_and_register() in wireless_work"), wacom->shared->type is not set. Send the information of the battery if we have one. Signed-off-by:
-
- 28 Jul, 2016 11 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hidLinus Torvalds authored
Pull HID updates from Jiri Kosina: - new hid-alps driver for ALPS Touchpad-Stick device, from Masaki Ota - much improved and generalized HID led handling, and merge of specialized hid-thingm driver into this generic hid-led one, from Heiner Kallweit - i2c-hid power management improvements from Fu Zhonghui and Guohua Zhong - uhid initialization race fix from Roderick Colenbrander * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (21 commits) HID: add usb device id for Apple Magic Keyboard HID: hid-led: fix Delcom support on big endian systems HID: hid-led: add support for Greynut Luxafor HID: hid-led: add support for Delcom Visual Signal Indicator G2 HID: hid-led: remove report id from struct hidled_config HID: alps: a few cleanups HID: remove ThingM blink(1) driver HID: hid-led: add support for ThingM blink(1) HID: hid-led: add support for reading from LED devices HID: hid-led: add support for devices with multiple independent LEDs HID: i2c-hid: set power sleep before shutdown HID: alps: match alps devices in core HID: thingm: simplify debug output code HID: alps: pass correct sizes to hid_hw_raw_request() HID: alps: struct u1_dev *priv is internal to the driver HID: add Alps I2C HID Touchpad-Stick support HID: led: fix config usb: misc: remove outdated USB LED driver HID: migrate USB LED driver from usb misc to hid HID: i2c_hid: enable i2c-hid devices to suspend/resume asynchronously ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivialLinus Torvalds authored
Pull trivial tree updates from Jiri Kosina. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: fat: fix error message for bogus number of directory entries fat: fix typo s/supeblock/superblock/ ASoC: max9877: Remove unused function declaration dw2102: don't output spurious blank lines to the kernel log init: fix Kconfig text ARM: io: fix comment grammar ocfs: fix ocfs2_xattr_user_get() argument name scsi/qla2xxx: Remove erroneous unused macro qla82xx_get_temp_val1()
-
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fsLinus Torvalds authored
Pull quota update from Jan Kara: "time64 support for quota" * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: quota: use time64_t internally
-
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/randomLinus Torvalds authored
Pull random driver fix from Ted Ts'o: "Fix a boot failure on systems with non-contiguous NUMA id's" * tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random: random: use for_each_online_node() to iterate over NUMA nodes
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull vfs updates from Al Viro: "Assorted cleanups and fixes. Probably the most interesting part long-term is ->d_init() - that will have a bunch of followups in (at least) ceph and lustre, but we'll need to sort the barrier-related rules before it can get used for really non-trivial stuff. Another fun thing is the merge of ->d_iput() callers (dentry_iput() and dentry_unlink_inode()) and a bunch of ->d_compare() ones (all except the one in __d_lookup_lru())" * 'work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (26 commits) fs/dcache.c: avoid soft-lockup in dput() vfs: new d_init method vfs: Update lookup_dcache() comment bdev: get rid of ->bd_inodes Remove last traces of ->sync_page new helper: d_same_name() dentry_cmp(): use lockless_dereference() instead of smp_read_barrier_depends() vfs: clean up documentation vfs: document ->d_real() vfs: merge .d_select_inode() into .d_real() unify dentry_iput() and dentry_unlink_inode() binfmt_misc: ->s_root is not going anywhere drop redundant ->owner initializations ufs: get rid of redundant checks orangefs: constify inode_operations missed comment updates from ->direct_IO() prototype change file_inode(f)->i_mapping is f->f_mapping trim fsnotify hooks a bit 9p: new helper - v9fs_parent_fid() debugfs: ->d_parent is never NULL or negative ...
-
Linus Torvalds authored
This changes the vfs dentry hashing to mix in the parent pointer at the _beginning_ of the hash, rather than at the end. That actually improves both the hash and the code generation, because we can move more of the computation to the "static" part of the dcache setup, and do less at lookup runtime. It turns out that a lot of other hash users also really wanted to mix in a base pointer as a 'salt' for the hash, and so the slightly extended interface ends up working well for other cases too. Users that want a string hash that is purely about the string pass in a 'salt' pointer of NULL. * merge branch 'salted-string-hash': fs/dcache.c: Save one 32-bit multiply in dcache lookup vfs: make the string hashes salt the hash
-
Jiri Kosina authored
Conflicts: drivers/hid/hid-thingm.c
-
Jiri Kosina authored
Merge branches 'for-4.8/alps', 'for-4.8/apple', 'for-4.8/i2c-hid', 'for-4.8/uhid-offload-hid-device-add' and 'for-4.8/upstream' into for-linus
-
Theodore Ts'o authored
This fixes a crash on s390 with fake NUMA enabled. Reported-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Fixes: 1e7f583a ("random: make /dev/urandom scalable for silly userspace programs") Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Linus Torvalds authored
Some of our "for_each_xyz()" macro constructs make gcc unhappy about lack of braces around if-statements inside or outside the loop, because the loop construct itself has a "if-then-else" statement inside of it. The resulting warnings look something like this: drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_dump_lrc’: drivers/gpu/drm/i915/i915_debugfs.c:2103:6: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wparentheses] if (ctx != dev_priv->kernel_context) ^ even if the code itself is fine. Since the warning is fairly easy to avoid by adding a braces around the if-statement near the for_each_xyz() construct, do so, rather than disabling the otherwise potentially useful warning. (The if-then-else statements used in the "for_each_xyz()" constructs are designed to be inherently safe even with no braces, but in this case it's quite understandable that gcc isn't really able to tell that). This finally leaves the standard "allmodconfig" build with just a handful of remaining warnings, so new and valid warnings hopefully will stand out. Signed-off-by:Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
Newer versions of gcc warn about the use of __builtin_return_address() with a non-zero argument when "-Wall" is specified: kernel/trace/trace_irqsoff.c: In function ‘stop_critical_timings’: kernel/trace/trace_irqsoff.c:433:86: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Wframe-address] stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1); [ .. repeats a few times for other similar cases .. ] It is true that a non-zero argument is somewhat dangerous, and we do not actually have very many uses of that in the kernel - but the ftrace code does use it, and as Stephen Rostedt says: "We are well aware of the danger of using __builtin_return_address() of > 0. In fact that's part of the reason for having the "thunk" code in x86 (See arch/x86/entry/thunk_{64,32}.S). [..] it adds extra frames when tracking irqs off sections, to prevent __builtin_return_address() from accessing bad areas. In fact the thunk_32.S states: 'Trampoline to trace irqs off. (otherwise CALLER_ADDR1 might crash)'." For now, __builtin_return_address() with a non-zero argument is the best we can do, and the warning is not helpful and can end up making people miss other warnings for real problems. So disable the frame-address warning on compilers that need it. Acked-by:Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
- 27 Jul, 2016 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsiLinus Torvalds authored
Pull HSI updates from Sebastian Reichel: - proper runtime pm support for omap-ssi and ssi-protocol - misc fixes * tag 'hsi-for-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi: (24 commits) HSI: omap_ssi: drop pm_runtime_irq_safe HSI: omap_ssi_port: use rpm autosuspend API HSI: omap_ssi: call msg->complete() from process context HSI: omap_ssi_port: ensure clocks are kept enabled during transfer HSI: omap_ssi_port: replace pm_runtime_put_sync with non-sync variant HSI: omap_ssi_port: avoid calling runtime_pm_*_sync inside spinlock HSI: omap_ssi_port: avoid pm_runtime_get_sync in ssi_start_dma and ssi_start_pio HSI: omap_ssi_port: switch to threaded pio irq HSI: omap_ssi_core: remove pm_runtime_get_sync call from tasklet HSI: omap_ssi_core: use pm_runtime_put instead of pm_runtime_put_sync HSI: omap_ssi_port: prepare start_tx/stop_tx for blocking pm_runtime calls HSI: core: switch port event notifier from atomic to blocking HSI: omap_ssi_port: replace wkin_cken with atomic bitmap operations HSI: omap_ssi: convert cawake irq handler to thread HSI: ssi_protocol: fix ssip_xmit invocation HSI: ssi_protocol: replace spin_lock with spin_lock_bh HSI: ssi_protocol: avoid ssi_waketest call with held spinlock HSI: omap_ssi: do not reset module HSI: omap_ssi_port: remove useless newline hsi: Only descend into hsi directory when CONFIG_HSI is set ...
-
