Please pull the following change since commit
68353984d63d8d7ea728819dbdb7aecc5f32d360:
Merge tag '5.6-smb3-fixes-and-dfs-and-readdir-improvements' of
git://git.samba.org/sfrench/cifs-2.6 (2020-01-28 15:34:03 -0800)
are available in the Git repository at:
git://git.samba.org/sfrench/cifs-2.6.git tags/5.6-rc-small-smb3-fix-for-stable
for you to fetch changes up to b581098482e6f177a4f64ea021fd5a9327ea08d5:
cifs: update internal module version number (2020-01-31 15:13:22 -0600)
----------------------------------------------------------------
Small SMB3 fix for stable (fixes problem with reconnect for soft mounts)
----------------------------------------------------------------
Ronnie Sahlberg (1):
cifs: fix soft mounts hanging in the reconnect code
Steve French (1):
cifs: update internal module version number
fs/cifs/cifsfs.h | 2 +-
fs/cifs/smb2pdu.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
Thanks,
Steve
In year 2007 high performance SSD was still expensive, in order to
save more space for real workload or meta data, the readahead I/Os
for non-meta data was bypassed and not cached on SSD.
In now days, SSD price drops a lot and people can find larger size
SSD with more comfortable price. It is unncessary to alway bypass
normal readahead I/Os to save SSD space for now.
This patch adds options for readahead data cache policies via sysfs
file /sys/block/bcache<N>/readahead_cache_policy, the options are,
- "all": cache all readahead data I/Os.
- "meta-only": only cache meta data, and bypass other regular I/Os.
If users want to make bcache continue to only cache readahead request
for metadata and bypass regular data readahead, please set "meta-only"
to this sysfs file. By default, bcache will back to cache all read-
ahead requests now.
Cc: stable(a)vger.kernel.org
Signed-off-by: Coly Li <colyli(a)suse.de>
Acked-by: Eric Wheeler <bcache(a)linux.ewheeler.net>
Cc: Michael Lyle <mlyle(a)lyle.org>
---
drivers/md/bcache/bcache.h | 3 +++
drivers/md/bcache/request.c | 17 ++++++++++++-----
drivers/md/bcache/sysfs.c | 22 ++++++++++++++++++++++
3 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/md/bcache/bcache.h b/drivers/md/bcache/bcache.h
index adf26a21fcd1..74a9849ea164 100644
--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -330,6 +330,9 @@ struct cached_dev {
*/
atomic_t has_dirty;
+#define BCH_CACHE_READA_ALL 0
+#define BCH_CACHE_READA_META_ONLY 1
+ unsigned int cache_readahead_policy;
struct bch_ratelimit writeback_rate;
struct delayed_work writeback_rate_update;
diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
index 73478a91a342..820d8402a1dc 100644
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -379,13 +379,20 @@ static bool check_should_bypass(struct cached_dev *dc, struct bio *bio)
goto skip;
/*
- * Flag for bypass if the IO is for read-ahead or background,
- * unless the read-ahead request is for metadata
+ * If the bio is for read-ahead or background IO, bypass it or
+ * not depends on the following situations,
+ * - If the IO is for meta data, always cache it and no bypass
+ * - If the IO is not meta data, check dc->cache_reada_policy,
+ * BCH_CACHE_READA_ALL: cache it and not bypass
+ * BCH_CACHE_READA_META_ONLY: not cache it and bypass
+ * That is, read-ahead request for metadata always get cached
* (eg, for gfs2 or xfs).
*/
- if (bio->bi_opf & (REQ_RAHEAD|REQ_BACKGROUND) &&
- !(bio->bi_opf & (REQ_META|REQ_PRIO)))
- goto skip;
+ if ((bio->bi_opf & (REQ_RAHEAD|REQ_BACKGROUND))) {
+ if (!(bio->bi_opf & (REQ_META|REQ_PRIO)) &&
+ (dc->cache_readahead_policy != BCH_CACHE_READA_ALL))
+ goto skip;
+ }
if (bio->bi_iter.bi_sector & (c->sb.block_size - 1) ||
bio_sectors(bio) & (c->sb.block_size - 1)) {
diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
index 733e2ddf3c78..3470fae4eabc 100644
--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -27,6 +27,12 @@ static const char * const bch_cache_modes[] = {
NULL
};
+static const char * const bch_reada_cache_policies[] = {
+ "all",
+ "meta-only",
+ NULL
+};
+
/* Default is 0 ("auto") */
static const char * const bch_stop_on_failure_modes[] = {
"auto",
@@ -100,6 +106,7 @@ rw_attribute(congested_write_threshold_us);
rw_attribute(sequential_cutoff);
rw_attribute(data_csum);
rw_attribute(cache_mode);
+rw_attribute(readahead_cache_policy);
rw_attribute(stop_when_cache_set_failed);
rw_attribute(writeback_metadata);
rw_attribute(writeback_running);
@@ -168,6 +175,11 @@ SHOW(__bch_cached_dev)
bch_cache_modes,
BDEV_CACHE_MODE(&dc->sb));
+ if (attr == &sysfs_readahead_cache_policy)
+ return bch_snprint_string_list(buf, PAGE_SIZE,
+ bch_reada_cache_policies,
+ dc->cache_readahead_policy);
+
if (attr == &sysfs_stop_when_cache_set_failed)
return bch_snprint_string_list(buf, PAGE_SIZE,
bch_stop_on_failure_modes,
@@ -353,6 +365,15 @@ STORE(__cached_dev)
}
}
+ if (attr == &sysfs_readahead_cache_policy) {
+ v = __sysfs_match_string(bch_reada_cache_policies, -1, buf);
+ if (v < 0)
+ return v;
+
+ if ((unsigned int) v != dc->cache_readahead_policy)
+ dc->cache_readahead_policy = v;
+ }
+
if (attr == &sysfs_stop_when_cache_set_failed) {
v = __sysfs_match_string(bch_stop_on_failure_modes, -1, buf);
if (v < 0)
@@ -467,6 +488,7 @@ static struct attribute *bch_cached_dev_files[] = {
&sysfs_data_csum,
#endif
&sysfs_cache_mode,
+ &sysfs_readahead_cache_policy,
&sysfs_stop_when_cache_set_failed,
&sysfs_writeback_metadata,
&sysfs_writeback_running,
--
2.16.4
The following commit has been merged into the timers/urgent branch of tip:
Commit-ID: febac332a819f0e764aa4da62757ba21d18c182b
Gitweb: https://git.kernel.org/tip/febac332a819f0e764aa4da62757ba21d18c182b
Author: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru>
AuthorDate: Fri, 31 Jan 2020 19:08:59 +03:00
Committer: Thomas Gleixner <tglx(a)linutronix.de>
CommitterDate: Sat, 01 Feb 2020 11:07:56 +01:00
clocksource: Prevent double add_timer_on() for watchdog_timer
Kernel crashes inside QEMU/KVM are observed:
kernel BUG at kernel/time/timer.c:1154!
BUG_ON(timer_pending(timer) || !timer->function) in add_timer_on().
At the same time another cpu got:
general protection fault: 0000 [#1] SMP PTI of poinson pointer 0xdead000000000200 in:
__hlist_del at include/linux/list.h:681
(inlined by) detach_timer at kernel/time/timer.c:818
(inlined by) expire_timers at kernel/time/timer.c:1355
(inlined by) __run_timers at kernel/time/timer.c:1686
(inlined by) run_timer_softirq at kernel/time/timer.c:1699
Unfortunately kernel logs are badly scrambled, stacktraces are lost.
Printing the timer->function before the BUG_ON() pointed to
clocksource_watchdog().
The execution of clocksource_watchdog() can race with a sequence of
clocksource_stop_watchdog() .. clocksource_start_watchdog():
expire_timers()
detach_timer(timer, true);
timer->entry.pprev = NULL;
raw_spin_unlock_irq(&base->lock);
call_timer_fn
clocksource_watchdog()
clocksource_watchdog_kthread() or
clocksource_unbind()
spin_lock_irqsave(&watchdog_lock, flags);
clocksource_stop_watchdog();
del_timer(&watchdog_timer);
watchdog_running = 0;
spin_unlock_irqrestore(&watchdog_lock, flags);
spin_lock_irqsave(&watchdog_lock, flags);
clocksource_start_watchdog();
add_timer_on(&watchdog_timer, ...);
watchdog_running = 1;
spin_unlock_irqrestore(&watchdog_lock, flags);
spin_lock(&watchdog_lock);
add_timer_on(&watchdog_timer, ...);
BUG_ON(timer_pending(timer) || !timer->function);
timer_pending() -> true
BUG()
I.e. inside clocksource_watchdog() watchdog_timer could be already armed.
Check timer_pending() before calling add_timer_on(). This is sufficient as
all operations are synchronized by watchdog_lock.
Fixes: 75c5158f70c0 ("timekeeping: Update clocksource with stop_machine")
Signed-off-by: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: stable(a)vger.kernel.org
Link: https://lore.kernel.org/r/158048693917.4378.13823603769948933793.stgit@buzz
---
kernel/time/clocksource.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index fff5f64..428beb6 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -293,8 +293,15 @@ static void clocksource_watchdog(struct timer_list *unused)
next_cpu = cpumask_next(raw_smp_processor_id(), cpu_online_mask);
if (next_cpu >= nr_cpu_ids)
next_cpu = cpumask_first(cpu_online_mask);
- watchdog_timer.expires += WATCHDOG_INTERVAL;
- add_timer_on(&watchdog_timer, next_cpu);
+
+ /*
+ * Arm timer if not already pending: could race with concurrent
+ * pair clocksource_stop_watchdog() clocksource_start_watchdog().
+ */
+ if (!timer_pending(&watchdog_timer)) {
+ watchdog_timer.expires += WATCHDOG_INTERVAL;
+ add_timer_on(&watchdog_timer, next_cpu);
+ }
out:
spin_unlock(&watchdog_lock);
}
Hi,
On 1/31/20 6:17 PM, Z R wrote:
> Hi Benjamin,
> in last log touchpad.log (omg, should be keyboard.log), I pressed fn-f3 multiple times. I got one two liner:
>
> # ReportID: 3 / Wireless Radio Button: 0 | #
> E: 000007.606583 2 03 00
>
> every time i release f3. Does not matter what is happening with fn-key. (could be released already or still pushed down). This log was collected with last patch from Hans applied.
>
> Sorry for the mess I caused :-) I still don't get how you guys manage to have your emails so well polished and readable.
I don't think you've, caused a mess. Thank you both for the bug report and for your
help in testing this.
One last test request, can you run evemu-record on a kernel with my latest simplified patch,
select the keyboard device and then press (and release) the "rfkill" key and see it generates
a RF_KILL key press + release evdev event?
What would also be helpful is the output of:
ls -l /sys/bus/hid/devices/0003*/driver
Regards,
Hans
> pá 31. 1. 2020 v 18:00 odesílatel Benjamin Tissoires <benjamin.tissoires(a)redhat.com <mailto:benjamin.tissoires@redhat.com>> napsal:
>
> On Fri, Jan 31, 2020 at 5:09 PM Z R <zdenda.rampas(a)gmail.com <mailto:zdenda.rampas@gmail.com>> wrote:
> >
> > I believe I pressed wifi button on both replays for keyboard.
>
> Yep, I can see that. Just to double check, on the last log, you
> pressed the wifi button twice?
>
> Anyway, thanks for all the logs, I should have enough to implement the
> regression tests.
>
> Cheers,
> Benjamin
>
> >
> > With latest patch from Hans on top of v5.5.0 touchpads "two finger scrolling" is working again. Attaching current hid-record for keyboard with Wifi button pressed. Events in log appeared after f3 button was "released".
> >
> > Thanks
> >
> > Zdeněk
> >
> > pá 31. 1. 2020 v 16:45 odesílatel Hans de Goede <hdegoede(a)redhat.com <mailto:hdegoede@redhat.com>> napsal:
> >>
> >> Hi,
> >>
> >> On 1/31/20 4:38 PM, Z R wrote:
> >> > Hi Benjamin,
> >> > hid-record for keyboard and touchpad. With Commit 8f18eca9ebc5 reverted and from unmodified kernel.
> >> >
> >> > I hope it is what you asked for :-)
> >> >
> >> > Currently waiting for reworked patch from Hans.
> >>
> >> I just send you the reworked patch.
> >>
> >> Does the recordning include pressing of the wlan on/off key (Fn + F3 I believe) ?
> >> That is the whole reason why the special hid-ite driver is necessary.
> >>
> >> Benjamin about the wlan on/off key. AFAICR on a press + release of the key a
> >> single hid input report for the generic-desktop Wireless Radio Controls group
> >> is send. This input-report only has the one button with usage code HID_GD_RFKILL_BTN
> >> in there and it is always 0. It is as if the input-report is only send on release
> >> and not on press. So the hid-ite code emulates a press + release whenever the
> >> input-report is send.
> >>
> >> IOW the receiving of the input report is (ab)used as indication of the button
> >> having been pressed.
> >>
> >> Regards,
> >>
> >> Hans
> >>
> >>
> >> >
> >> > Bye for now
> >> > Zdeněk
> >> >
> >> > pá 31. 1. 2020 v 15:12 odesílatel Benjamin Tissoires <benjamin.tissoires(a)redhat.com <mailto:benjamin.tissoires@redhat.com> <mailto:benjamin.tissoires@redhat.com <mailto:benjamin.tissoires@redhat.com>>> napsal:
> >> >
> >> > On Fri, Jan 31, 2020 at 3:04 PM Hans de Goede <hdegoede(a)redhat.com <mailto:hdegoede@redhat.com> <mailto:hdegoede@redhat.com <mailto:hdegoede@redhat.com>>> wrote:
> >> > >
> >> > > Hi,
> >> > >
> >> > > On 1/31/20 2:54 PM, Benjamin Tissoires wrote:
> >> > > > On Fri, Jan 31, 2020 at 2:41 PM Hans de Goede <hdegoede(a)redhat.com <mailto:hdegoede@redhat.com> <mailto:hdegoede@redhat.com <mailto:hdegoede@redhat.com>>> wrote:
> >> > > >>
> >> > > >> Hi,
> >> > > >>
> >> > > >> On 1/31/20 2:10 PM, Benjamin Tissoires wrote:
> >> > > >>> Hi Hans,
> >> > > >>>
> >> > > >>> On Fri, Jan 31, 2020 at 1:46 PM Hans de Goede <hdegoede(a)redhat.com <mailto:hdegoede@redhat.com> <mailto:hdegoede@redhat.com <mailto:hdegoede@redhat.com>>> wrote:
> >> > > >>>>
> >> > > >>>> Commit 8f18eca9ebc5 ("HID: ite: Add USB id match for Acer SW5-012 keyboard
> >> > > >>>> dock") added the USB id for the Acer SW5-012's keyboard dock to the
> >> > > >>>> hid-ite driver to fix the rfkill driver not working.
> >> > > >>>>
> >> > > >>>> Most keyboard docks with an ITE 8595 keyboard/touchpad controller have the
> >> > > >>>> "Wireless Radio Control" bits which need the special hid-ite driver on the
> >> > > >>>> second USB interface (the mouse interface) and their touchpad only supports
> >> > > >>>> mouse emulation, so using generic hid-input handling for anything but
> >> > > >>>> the "Wireless Radio Control" bits is fine. On these devices we simply bind
> >> > > >>>> to all USB interfaces.
> >> > > >>>>
> >> > > >>>> But unlike other ITE8595 using keyboard docks, the Acer Aspire Switch 10
> >> > > >>>> (SW5-012)'s touchpad not only does mouse emulation it also supports
> >> > > >>>> HID-multitouch and all the keys including the "Wireless Radio Control"
> >> > > >>>> bits have been moved to the first USB interface (the keyboard intf).
> >> > > >>>>
> >> > > >>>> So we need hid-ite to handle the first (keyboard) USB interface and have
> >> > > >>>> it NOT bind to the second (mouse) USB interface so that that can be
> >> > > >>>> handled by hid-multitouch.c and we get proper multi-touch support.
> >> > > >>>>
> >> > > >>>> This commit adds a match callback to hid-ite which makes it only
> >> > > >>>> match the first USB interface when running on the Acer SW5-012,
> >> > > >>>> fixing the regression to mouse-emulation mode introduced by adding the
> >> > > >>>> keyboard dock USB id.
> >> > > >>>>
> >> > > >>>> Note the match function only does the special only bind to the first
> >> > > >>>> USB interface on the Acer SW5-012, on other devices the hid-ite driver
> >> > > >>>> actually must bind to the second interface as that is where the
> >> > > >>>> "Wireless Radio Control" bits are.
> >> > > >>>
> >> > > >>> This is not a full review, but a couple of things that popped out
> >> > > >>> while scrolling through the patch.
> >> > > >>>
> >> > > >>>>
> >> > > >>>> Cc: stable(a)vger.kernel.org <mailto:stable@vger.kernel.org> <mailto:stable@vger.kernel.org <mailto:stable@vger.kernel.org>>
> >> > > >>>> Fixes: 8f18eca9ebc5 ("HID: ite: Add USB id match for Acer SW5-012 keyboard dock")
> >> > > >>>> Reported-by: Zdeněk Rampas <zdenda.rampas(a)gmail.com <mailto:zdenda.rampas@gmail.com> <mailto:zdenda.rampas@gmail.com <mailto:zdenda.rampas@gmail.com>>>
> >> > > >>>> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com <mailto:hdegoede@redhat.com> <mailto:hdegoede@redhat.com <mailto:hdegoede@redhat.com>>>
> >> > > >>>> ---
> >> > > >>>> drivers/hid/hid-ite.c | 34 ++++++++++++++++++++++++++++++++++
> >> > > >>>> 1 file changed, 34 insertions(+)
> >> > > >>>>
> >> > > >>>> diff --git a/drivers/hid/hid-ite.c b/drivers/hid/hid-ite.c
> >> > > >>>> index c436e12feb23..69a4ddfd033d 100644
> >> > > >>>> --- a/drivers/hid/hid-ite.c
> >> > > >>>> +++ b/drivers/hid/hid-ite.c
> >> > > >>>> @@ -8,9 +8,12 @@
> >> > > >>>> #include <linux/input.h>
> >> > > >>>> #include <linux/hid.h>
> >> > > >>>> #include <linux/module.h>
> >> > > >>>> +#include <linux/usb.h>
> >> > > >>>>
> >> > > >>>> #include "hid-ids.h"
> >> > > >>>>
> >> > > >>>> +#define ITE8595_KBD_USB_INTF 0
> >> > > >>>> +
> >> > > >>>> static int ite_event(struct hid_device *hdev, struct hid_field *field,
> >> > > >>>> struct hid_usage *usage, __s32 value)
> >> > > >>>> {
> >> > > >>>> @@ -37,6 +40,36 @@ static int ite_event(struct hid_device *hdev, struct hid_field *field,
> >> > > >>>> return 0;
> >> > > >>>> }
> >> > > >>>>
> >> > > >>>> +static bool ite_match(struct hid_device *hdev, bool ignore_special_driver)
> >> > > >>>> +{
> >> > > >>>> + struct usb_interface *intf;
> >> > > >>>> +
> >> > > >>>> + if (ignore_special_driver)
> >> > > >>>> + return false;
> >> > > >>>> +
> >> > > >>>> + /*
> >> > > >>>> + * Most keyboard docks with an ITE 8595 keyboard/touchpad controller
> >> > > >>>> + * have the "Wireless Radio Control" bits which need this special
> >> > > >>>> + * driver on the second USB interface (the mouse interface). On
> >> > > >>>> + * these devices we simply bind to all USB interfaces.
> >> > > >>>> + *
> >> > > >>>> + * The Acer Aspire Switch 10 (SW5-012) is special, its touchpad
> >> > > >>>> + * not only does mouse emulation it also supports HID-multitouch
> >> > > >>>> + * and all the keys including the "Wireless Radio Control" bits
> >> > > >>>> + * have been moved to the first USB interface (the keyboard intf).
> >> > > >>>> + *
> >> > > >>>> + * We want the hid-multitouch driver to bind to the touchpad, so on
> >> > > >>>> + * the Acer SW5-012 we should only bind to the keyboard USB intf.
> >> > > >>>> + */
> >> > > >>>> + if (hdev->bus != BUS_USB || hdev->vendor != USB_VENDOR_ID_SYNAPTICS ||
> >> > > >>>> + hdev->product != USB_DEVICE_ID_SYNAPTICS_ACER_SWITCH5_012)
> >> > > >>>
> >> > > >>> Isn't there an existing matching function we can use here, instead of
> >> > > >>> checking each individual field?
> >> > > >>
> >> > > >> There is hid_match_one_id() but that is not exported (can be fixed) and it
> >> > > >> requires a struct hid_device_id, which either requires declaring an extra
> >> > > >> standalone struct hid_device_id for the SW5-012 kbd-dock, or hardcoding an
> >> > > >> index into the existing hid_device_id array for the driver (with the hardcoding
> >> > > >> being error prone, so not a good idea).
> >> > > >>
> >> > > >> Given the problems with using hid_match_one_id() I decided to just go with
> >> > > >> the above.
> >> > > >
> >> > > > right. An other solution would be to have a local macro/function that
> >> > > > does that. Because as soon as you start adding a quirk, an other comes
> >> > > > right after.
> >> > > >
> >> > > >>
> >> > > >> But see below.
> >> > > >>
> >> > > >>>
> >> > > >>>> + return true;
> >> > > >>>> +
> >> > > >>>> + intf = to_usb_interface(hdev->dev.parent);
> >> > > >>>
> >> > > >>> And this is oops-prone. You need:
> >> > > >>> - ensure hid_is_using_ll_driver(hdev, &usb_hid_driver) returns true.
> >> > > >>> - add a dependency on USBHID in the KConfig now that you are checking
> >> > > >>> on the USB transport layer.
> >> > > >>>
> >> > > >>> That being said, I would love instead:
> >> > > >>> - to have a non USB version of this match, where you decide which
> >> > > >>> component needs to be handled based on the report descriptor
> >> > > >>
> >> > > >> Actually your idea to use the desciptors is not bad, but since what
> >> > > >> we really want is to not bind to the interface which is marked for the
> >> > > >> hid-multitouch driver I just realized we can just check that.
> >> > > >>
> >> > > >> So how about:
> >> > > >>
> >> > > >> static bool ite_match(struct hid_device *hdev, bool ignore_special_driver)
> >> > > >> {
> >> > > >> if (ignore_special_driver)
> >> > > >> return false;
> >> > > >>
> >> > > >> /*
> >> > > >> * Some keyboard docks with an ITE 8595 keyboard/touchpad controller
> >> > > >> * support the HID multitouch protocol for the touchpad, in that
> >> > > >> * case the "Wireless Radio Control" bits which we care about are
> >> > > >> * on the other interface; and we should not bind to the multitouch
> >> > > >> * capable interface as that breaks multitouch support.
> >> > > >> */
> >> > > >> return hdev->group != HID_GROUP_MULTITOUCH_WIN_8;
> >> > > >> }
> >> > > >
> >> > > > Yep, I like that very much :)
> >> > >
> >> > > Actually if we want to check the group and there are only 2 interfaces we do
> >> > > not need to use the match callback at all, w e can simply match on the
> >> > > group of the interface which we do want:
> >> > >
> >> > > diff --git a/drivers/hid/hid-ite.c b/drivers/hid/hid-ite.c
> >> > > index db0f35be5a8b..21bd48f16033 100644
> >> > > --- a/drivers/hid/hid-ite.c
> >> > > +++ b/drivers/hid/hid-ite.c
> >> > > @@ -56,8 +56,9 @@ static const struct hid_device_id ite_devices[] = {
> >> > > { HID_USB_DEVICE(USB_VENDOR_ID_ITE, USB_DEVICE_ID_ITE8595) },
> >> > > { HID_USB_DEVICE(USB_VENDOR_ID_258A, USB_DEVICE_ID_258A_6A88) },
> >> > > /* ITE8595 USB kbd ctlr, with Synaptics touchpad connected to it. */
> >> > > - { HID_USB_DEVICE(USB_VENDOR_ID_SYNAPTICS,
> >> > > - USB_DEVICE_ID_SYNAPTICS_ACER_SWITCH5_012) },
> >> > > + { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
> >> > > + USB_VENDOR_ID_SYNAPTICS,
> >> > > + USB_DEVICE_ID_SYNAPTICS_ACER_SWITCH5_012) },
> >> > > { }
> >> > > };
> >> > > MODULE_DEVICE_TABLE(hid, ite_devices);
> >> > >
> >> > > Much cleaner
> >> >
> >> > yep
> >> >
> >> > > (and now I don't need to write a test, which is always
> >> > > a good motivation to come up with a cleaner solution :)
> >> >
> >> > Hehe, too bad, you already picked up my curiosity on this one, and I
> >> > really would like to see the report descriptors and some events of the
> >> > keys that are fixed by hid-ite.c.
> >> > <with a low voice>This will be a hard requirement to accept this patch </joke>.
> >> >
> >> > More seriously, Zdeněk, can you run hid-recorder from
> >> > https://gitlab.freedesktop.org/libevdev/hid-tools/ and provide me the
> >> > report descriptor for all of your ITE HID devices? I'll add the
> >> > matching tests in hid-tools and be sure we do not regress in the
> >> > future.
> >> >
> >> > >
> >> > > Let me turn this into a proper patch and then I will send that to
> >> > > Zdeněk (off-list) for him to test (note don't worry if you do
> >> > > not have time to test this weekend, then I'll do it on Monday).
> >> > >
> >> > > Regards,
> >> > >
> >> > > Hans
> >> > >
> >> > > p.s.
> >> > >
> >> > > 1. My train is approaching Brussels (Fosdem) so my email response
> >> > > time will soon become irregular.
> >> >
> >> > How dare you? :)
> >> >
> >> > >
> >> > > 2. Benjamin will you be at Fosdem too ?
> >> > >
> >> >
> >> > Unfortunately no. Already got my quota of meeting people for this year
> >> > between Kernel Recipes in September, XDC in October and LCA last week.
> >> > So I need to keep in a quiet environment for a little bit :)
> >> >
> >> > Cheers,
> >> > Benjamin
> >> >
> >>
>