[tip: locking/core] x86/jump_label: Mark arguments as const to satisfy asm constraints

The following commit has been merged into the locking/core branch of tip: Commit-ID: 864b435514b286c0be2a38a02f487aa28d990ef8 Gitweb: https://git.kernel.org/tip/864b435514b286c0be2a38a02f487aa28d990ef8 Author:Jason Gerecke AuthorDate:Thu, 11 Feb 2021 13:48:48 -08:00

[tip: locking/core] x86/jump_label: Mark arguments as const to satisfy asm constraints

The following commit has been merged into the locking/core branch of tip: Commit-ID: 566a9522381495d27b596ee3bdc9578ba02a895d Gitweb: https://git.kernel.org/tip/566a9522381495d27b596ee3bdc9578ba02a895d Author:Jason Gerecke AuthorDate:Thu, 11 Feb 2021 13:48:48 -08:00

Re: [PATCH] RFC: x86/jump_label: Mark arguments as const to satisfy asm constraints

On Fri, Feb 12, 2021 at 7:27 AM Peter Zijlstra wrote: > > On Fri, Feb 12, 2021 at 09:40:59AM -0500, Steven Rostedt wrote: > > On Thu, 11 Feb 2021 13:48:48 -0800 > > Jason Gerecke wrote: > > > > > When compiling an external kernel module with `-O0` or `-O1`, t

[PATCH] RFC: x86/jump_label: Mark arguments as const to satisfy asm constraints

hese lower optimization levels prevent GCC from detecting that the key/branch arguments can be treated as constants and used as immediate operands. To work around this, explicitly add the `const` label. Signed-off-by: Jason Gerecke Cc: Steven Rostedt Cc: Ard Biesheuvel --- Marked RFC since I'm no

Re: linux-next: Fixes tag needs some work in the hid tree

My apologies. I copied the wrong commit SHA when generating this commit. Commit cd47de45b855 is the reference to this commit in our input-wacom tree, not upstream. The correct Fixes tag should indeed be: Fixes: 912c6aa67ad4 ("HID: wacom: Add 2nd gen Intuos Pro Small support") Thanks, Jason ---

Re: [PATCH 2/2] HID: wacom: do not call hid_set_drvdata(hdev, NULL)

On Mon, Aug 12, 2019 at 9:29 AM Benjamin Tissoires wrote: > > This is a common pattern in the HID drivers to reset the drvdata. > However, this is actually already handled by driver core, so there > is no need to do it manually. > > Signed-off-by: Benjamin Tissoires Acked

Re: [PATCH v2 3/5] Input: add KEY_ROTATE_LOCK_TOGGLE

, 2017 at 10:50 AM, Jason Gerecke <killert...@gmail.com> wrote: > Looks like this might also be needed for the MobileStudio Pro... > > https://bugzilla.kernel.org/show_bug.cgi?id=197991 > > Jason > --- > Now instead of four in the eights place / > you’ve g

Re: [PATCH v2 3/5] Input: add KEY_ROTATE_LOCK_TOGGLE

, 2017 at 10:50 AM, Jason Gerecke wrote: > Looks like this might also be needed for the MobileStudio Pro... > > https://bugzilla.kernel.org/show_bug.cgi?id=197991 > > Jason > --- > Now instead of four in the eights place / > you’ve got three, ‘Cause you added one /

Re: [PATCH v2 3/5] Input: add KEY_ROTATE_LOCK_TOGGLE

Looks like this might also be needed for the MobileStudio Pro... https://bugzilla.kernel.org/show_bug.cgi?id=197991 Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So

Re: [PATCH v2 3/5] Input: add KEY_ROTATE_LOCK_TOGGLE

Looks like this might also be needed for the MobileStudio Pro... https://bugzilla.kernel.org/show_bug.cgi?id=197991 Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So

Re: [PATCH] HID: Wacom: switch Dell canvas into highres mode

g with a descriptor quite like it. That said, there's a good chance that we'll see something similar in the future... I'm still not entirely happy with the one-off approach, but I'll but my stamp of approval on it. We can work out a more generic way to detect and configure these dual-resolution

Re: [PATCH] HID: Wacom: switch Dell canvas into highres mode

quite like it. That said, there's a good chance that we'll see something similar in the future... I'm still not entirely happy with the one-off approach, but I'll but my stamp of approval on it. We can work out a more generic way to detect and configure these dual-resolution devices going forward :) Reviewed-by: Jason Gerecke Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours

Re: [PATCH] HID: Wacom: switch Dell canvas into highres mode

On November 3, 2017 10:29:47 AM PDT, Benjamin Tissoires wrote: >The Dell Canvas exports 2 collections for the Pen part. The only >difference between the 2 is that the default one has half the >resolution >of the second one. > >The Windows driver switches the tablet

Re: [PATCH] HID: Wacom: switch Dell canvas into highres mode

On November 3, 2017 10:29:47 AM PDT, Benjamin Tissoires wrote: >The Dell Canvas exports 2 collections for the Pen part. The only >difference between the 2 is that the default one has half the >resolution >of the second one. > >The Windows driver switches the tablet into the second mode, so we

Re: [PATCH] drivers: Adding driver support for "One by Wacom CTL472/672" (parameters transferred from CTL471/671 since only difference is the force resolution)

225. >> + BAMBOO_PEN, WACOM_INTUOS_RES, WACOM_INTUOS_RES }; >> +static const struct wacom_features wacom_features_0x37B = >> + { "One by Wacom CTL672", 21648, 13530, 2047, 63, Replace "CTL672" in name with "M". Resolution should be 21600 x

Re: [PATCH] drivers: Adding driver support for "One by Wacom CTL472/672" (parameters transferred from CTL471/671 since only difference is the force resolution)

M_INTUOS_RES }; >> +static const struct wacom_features wacom_features_0x37B = >> + { "One by Wacom CTL672", 21648, 13530, 2047, 63, Replace "CTL672" in name with "M". Resolution should be 21600 x 13500, not 21648 x 13530. >> + BAMBOO_P

Re: [PATCH] HID: wacom: add USB_HID dependency

On Fri, Jul 28, 2017 at 7:29 AM, Arnd Bergmann <a...@arndb.de> wrote: > On Fri, Jul 28, 2017 at 4:24 PM, Jason Gerecke <killert...@gmail.com> wrote: >> On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann <a...@arndb.de> wrote: >>> On Fri, Jul 28, 2017 at 4:07 PM,

Re: [PATCH] HID: wacom: add USB_HID dependency

On Fri, Jul 28, 2017 at 7:29 AM, Arnd Bergmann wrote: > On Fri, Jul 28, 2017 at 4:24 PM, Jason Gerecke wrote: >> On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann wrote: >>> On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke wrote: > >>> #ifdef CONFIG_USB_HID >>&

Re: [PATCH] HID: wacom: add USB_HID dependency

On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann <a...@arndb.de> wrote: > On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke <killert...@gmail.com> wrote: >> On July 28, 2017 6:18:00 AM PDT, Arnd Bergmann <a...@arndb.de> wrote: >>>The driver has gained a compile-time

Re: [PATCH] HID: wacom: add USB_HID dependency

On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann wrote: > On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke wrote: >> On July 28, 2017 6:18:00 AM PDT, Arnd Bergmann wrote: >>>The driver has gained a compile-time dependency that we should >>>express in Kconf

Re: [PATCH] HID: wacom: add USB_HID dependency

On July 28, 2017 6:18:00 AM PDT, Arnd Bergmann wrote: >The driver has gained a compile-time dependency that we should >express in Kconfig to avoid this link error: > Would conditional compilation be an acceptable alternative to adding a dependency? The USB_HID code is only used

Re: [PATCH] HID: wacom: add USB_HID dependency

On July 28, 2017 6:18:00 AM PDT, Arnd Bergmann wrote: >The driver has gained a compile-time dependency that we should >express in Kconfig to avoid this link error: > Would conditional compilation be an acceptable alternative to adding a dependency? The USB_HID code is only used to check if the

Re: [PATCH 1/3] HID: Wacom: Use devm_kcalloc() in two functions

Going through old mail and noticed that these three patches seem to have been overlooked (at least, I don't see them in Jiri's branches...). For the set: Reviewed-by: Jason Gerecke <jason.gere...@wacom.com> Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you

Re: [PATCH 1/3] HID: Wacom: Use devm_kcalloc() in two functions

Going through old mail and noticed that these three patches seem to have been overlooked (at least, I don't see them in Jiri's branches...). For the set: Reviewed-by: Jason Gerecke Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say

Re: [PATCH 0/3] HID-Wacom: Fine-tuning for seven function implementations

Came across these and noticed that it doesn't appear anything has happened with them. The set looks good to me: Reviewed-by: Jason Gerecke <jason.gere...@wacom.com> Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to t

Re: [PATCH 0/3] HID-Wacom: Fine-tuning for seven function implementations

Came across these and noticed that it doesn't appear anything has happened with them. The set looks good to me: Reviewed-by: Jason Gerecke Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take

Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

allow new hardware to work with the hid-generic driver. Jason Gerecke, Linux Software Engineer Wacom Technology Corporation tel: 360-896-9833 ext. 229 (direct) / fax: 360-896-9724 http://www.wacom.com On 02/21/2017 01:03 PM, Jiri Kosina wrote: > On Tue, 21 Feb 2017, Benjamin Tissoires wro

Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

allow new hardware to work with the hid-generic driver. Jason Gerecke, Linux Software Engineer Wacom Technology Corporation tel: 360-896-9833 ext. 229 (direct) / fax: 360-896-9724 http://www.wacom.com On 02/21/2017 01:03 PM, Jiri Kosina wrote: > On Tue, 21 Feb 2017, Benjamin Tissoires wro

Re: [PATCH 0/4] HID: wacom: fixes for next

Patches 1/3 look reasonable to me, though I've not run into the bugs they aim to fix. For those: Acked-by: Jason Gerecke <jason.gere...@wacom.com> As for patch 4, I have some additional reservations about hiding the message... We can discuss that further in its thread. Jason --- Now i

Re: [PATCH 0/4] HID: wacom: fixes for next

Patches 1/3 look reasonable to me, though I've not run into the bugs they aim to fix. For those: Acked-by: Jason Gerecke As for patch 4, I have some additional reservations about hiding the message... We can discuss that further in its thread. Jason --- Now instead of four in the eights place

Re: [PATCH 4/4] HID: wacom: do not shout an error on LED control

I'm not super comfortable with hiding this error. If the tablet reacts appropriately, I wouldn't think we'd get an EPIPE. Although its not fatal, it still might be a symptom of something deeper... Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That

Re: [PATCH 4/4] HID: wacom: do not shout an error on LED control

I'm not super comfortable with hiding this error. If the tablet reacts appropriately, I wouldn't think we'd get an EPIPE. Although its not fatal, it still might be a symptom of something deeper... Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That

Re: [patch] HID: wacom: Don't clear bits unintentionally

On 11/10/2016 11:25 AM, Dan Carpenter wrote: > This is trying to clear the lower 32 bits but the type is wrong so it > clears everything. > > Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com> > Reviewed-by: Jason Gerecke <jason.gere...@wacom.com> Ja

Re: [patch] HID: wacom: Don't clear bits unintentionally

On 11/10/2016 11:25 AM, Dan Carpenter wrote: > This is trying to clear the lower 32 bits but the type is wrong so it > clears everything. > > Signed-off-by: Dan Carpenter > Reviewed-by: Jason Gerecke Jason --- Now instead of four in the eights place / you’ve got three, ‘Caus

Re: [PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours On Sun, Nov 29, 2015 at 2:29 AM, Ioan-Adrian Ratiu wrote: > On Fri, 20 Nov 2015

Re: [PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours On Sun, Nov 29, 2015 at 2:29 AM, Ioan-Adrian Ratiu wrote: > On

Re: [PATCH] HID: wacom: remove the extra Pen interface for Wacom Bamboo PAD

Nit: Looks like I forgot to update this comment to say WACOM_DEVICETYPE_TOUCH. Mind fixing that in this patch since you're here anyway? Otherwise, looks good :) Reviewed-by: Jason Gerecke -- Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say,

Re: [PATCH] HID: wacom: remove the extra Pen interface for Wacom Bamboo PAD

since you're here anyway? Otherwise, looks good :) Reviewed-by: Jason Gerecke jason.gere...@wacom.com -- Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look

[PATCH 2/3] HID: wacom: Discover device_type from HID descriptor for all devices

a similar vendor-defined usage that we can trigger on. Signed-off-by: Jason Gerecke --- drivers/hid/wacom_sys.c | 23 +-- drivers/hid/wacom_wac.c | 8 +--- drivers/hid/wacom_wac.h | 6 +- 3 files changed, 23 insertions(+), 14 deletions(-) diff --git a/drivers/hid

[PATCH 3/3] HID: wacom: Fail probe if HID_GENERIC device has unknown device_type

there is no a priori guarantee that it is a tablet or touchpad. If the device_type is still uninitialized for a HID_GENERIC device then we assume that it isn't something the driver can work with and so fail the probe. Signed-off-by: Jason Gerecke --- drivers/hid/wacom_sys.c | 8 +++- 1 file changed, 7

[PATCH 1/3] HID: wacom: Do not add suffix to name of devices with an unknown type

This patch updates the logic so that no suffix will be added to the device name if the device type is unknown. Signed-off-by: Jason Gerecke --- drivers/hid/wacom_sys.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_s

[PATCH 1/3] HID: wacom: Do not add suffix to name of devices with an unknown type

updates the logic so that no suffix will be added to the device name if the device type is unknown. Signed-off-by: Jason Gerecke jason.gere...@wacom.com --- drivers/hid/wacom_sys.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/hid/wacom_sys.c b/drivers/hid

[PATCH 3/3] HID: wacom: Fail probe if HID_GENERIC device has unknown device_type

there is no a priori guarantee that it is a tablet or touchpad. If the device_type is still uninitialized for a HID_GENERIC device then we assume that it isn't something the driver can work with and so fail the probe. Signed-off-by: Jason Gerecke jason.gere...@wacom.com --- drivers/hid/wacom_sys.c | 8

[PATCH 2/3] HID: wacom: Discover device_type from HID descriptor for all devices

a similar vendor-defined usage that we can trigger on. Signed-off-by: Jason Gerecke jason.gere...@wacom.com --- drivers/hid/wacom_sys.c | 23 +-- drivers/hid/wacom_wac.c | 8 +--- drivers/hid/wacom_wac.h | 6 +- 3 files changed, 23 insertions(+), 14 deletions(-) diff

[PATCH] HID: wacom: Simplify check for presence of single-finger touch

To determine if a touch is present in the single-touch case, we can simply check if the BTN_TOUCH key is active or not. This will work for both HID_GENERIC and other device types. Signed-off-by: Jason Gerecke --- drivers/hid/wacom_wac.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions

[PATCH] HID: wacom: Simplify check for presence of single-finger touch

To determine if a touch is present in the single-touch case, we can simply check if the BTN_TOUCH key is active or not. This will work for both HID_GENERIC and other device types. Signed-off-by: Jason Gerecke jason.gere...@wacom.com --- drivers/hid/wacom_wac.c | 5 ++--- 1 file changed, 2

Re: [PATCH v2] HID: wacom: ask for a in-prox report when it was missed

On 3/16/2015 2:04 PM, Benjamin Tissoires wrote: On Mar 16 2015 or thereabouts, Jason Gerecke wrote: On 3/16/2015 12:27 PM, Benjamin Tissoires wrote: On Mar 16 2015 or thereabouts, Jason Gerecke wrote: On 3/16/2015 7:50 AM, Jiri Kosina wrote: On Thu, 5 Mar 2015, Benjamin Tissoires wrote

Re: [PATCH v2] HID: wacom: ask for a in-prox report when it was missed

On 3/16/2015 2:04 PM, Benjamin Tissoires wrote: On Mar 16 2015 or thereabouts, Jason Gerecke wrote: On 3/16/2015 12:27 PM, Benjamin Tissoires wrote: On Mar 16 2015 or thereabouts, Jason Gerecke wrote: On 3/16/2015 7:50 AM, Jiri Kosina wrote: On Thu, 5 Mar 2015, Benjamin Tissoires wrote

Re: [PATCH v2] HID: wacom: ask for a in-prox report when it was missed

On 3/16/2015 12:27 PM, Benjamin Tissoires wrote: On Mar 16 2015 or thereabouts, Jason Gerecke wrote: On 3/16/2015 7:50 AM, Jiri Kosina wrote: On Thu, 5 Mar 2015, Benjamin Tissoires wrote: If noone listens to the input device when a tool comes in proximity, the tablet does not send

Re: [PATCH v2] HID: wacom: ask for a in-prox report when it was missed

g. for debugging), but in the typical case where X is started shortly after boot and hotplugs devices as soon as they're available it shouldn't pose a problem. If Benjamin has any ideas I'd like to hear them, but in the meantime I'm comfortable seeing this go upstream: Acked-by: Jason Gerecke -

Re: [PATCH v2] HID: wacom: ask for a in-prox report when it was missed

On 3/16/2015 12:27 PM, Benjamin Tissoires wrote: On Mar 16 2015 or thereabouts, Jason Gerecke wrote: On 3/16/2015 7:50 AM, Jiri Kosina wrote: On Thu, 5 Mar 2015, Benjamin Tissoires wrote: If noone listens to the input device when a tool comes in proximity, the tablet does not send

Re: [PATCH v2] HID: wacom: ask for a in-prox report when it was missed

On 3/16/2015 2:04 PM, Benjamin Tissoires wrote: On Mar 16 2015 or thereabouts, Jason Gerecke wrote: On 3/16/2015 12:27 PM, Benjamin Tissoires wrote: On Mar 16 2015 or thereabouts, Jason Gerecke wrote: On 3/16/2015 7:50 AM, Jiri Kosina wrote: On Thu, 5 Mar 2015, Benjamin Tissoires wrote

Re: [PATCH v2] HID: wacom: ask for a in-prox report when it was missed

On 3/16/2015 2:04 PM, Benjamin Tissoires wrote: On Mar 16 2015 or thereabouts, Jason Gerecke wrote: On 3/16/2015 12:27 PM, Benjamin Tissoires wrote: On Mar 16 2015 or thereabouts, Jason Gerecke wrote: On 3/16/2015 7:50 AM, Jiri Kosina wrote: On Thu, 5 Mar 2015, Benjamin Tissoires wrote

Re: [PATCH v2] HID: wacom: ask for a in-prox report when it was missed

pose a problem. If Benjamin has any ideas I'd like to hear them, but in the meantime I'm comfortable seeing this go upstream: Acked-by: Jason Gerecke killert...@gmail.com -- Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight

Re: [PATCH] HID: wacom: ask for a in-prox report when it was missed

On 3/3/2015 9:20 AM, Benjamin Tissoires wrote: If noone listens to the input device when a tool comes in proximity, the tablet does not send the in-prox event when a client becomes available. That means that no events will be sent until the tool is taken out of proximity. In this situation, ask

Re: [PATCH] HID: wacom: ask for a in-prox report when it was missed

On 3/3/2015 9:20 AM, Benjamin Tissoires wrote: If noone listens to the input device when a tool comes in proximity, the tablet does not send the in-prox event when a client becomes available. That means that no events will be sent until the tool is taken out of proximity. In this situation, ask

Re: [PATCH 2/2] HID: wacom: add support of the Pen of the Bamboo Pad

r to have a HD_DG_PEN physical collection, so I also don't see any potential for regression. For both patches: Reviewed-by: Jason Gerecke Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven f

Re: [PATCH 2/2] HID: wacom: add support of the Pen of the Bamboo Pad

for appear to have a HD_DG_PEN physical collection, so I also don't see any potential for regression. For both patches: Reviewed-by: Jason Gerecke killert...@gmail.com Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two

Re: [PATCH v2] HID: wacom: Prevent potential null dereference after disconnect

On Wed, Oct 8, 2014 at 5:28 PM, Dmitry Torokhov wrote: > On Wed, Oct 08, 2014 at 05:24:32PM -0700, Jason Gerecke wrote: >> On Wed, Oct 8, 2014 at 2:40 PM, Dmitry Torokhov >> wrote: >> > On Wed, Oct 08, 2014 at 11:25:42AM -0700, Jason Gerecke wrote: >> >> Repe

Re: [PATCH v2] HID: wacom: Prevent potential null dereference after disconnect

On Wed, Oct 8, 2014 at 2:40 PM, Dmitry Torokhov wrote: > On Wed, Oct 08, 2014 at 11:25:42AM -0700, Jason Gerecke wrote: >> Repeated connect/disconnect cycles under GNOME can trigger an occasional >> OOPS from within e.g. wacom_led_select_store, presumably due to a timing >>

[PATCH v2] HID: wacom: Prevent potential null dereference after disconnect

Repeated connect/disconnect cycles under GNOME can trigger an occasional OOPS from within e.g. wacom_led_select_store, presumably due to a timing issue where userspace begins setting a value immediately before the device disconnects and our shared data is whisked away. Signed-off-by: Jason

[PATCH v2] HID: wacom: Prevent potential null dereference after disconnect

Repeated connect/disconnect cycles under GNOME can trigger an occasional OOPS from within e.g. wacom_led_select_store, presumably due to a timing issue where userspace begins setting a value immediately before the device disconnects and our shared data is whisked away. Signed-off-by: Jason

Re: [PATCH v2] HID: wacom: Prevent potential null dereference after disconnect

On Wed, Oct 8, 2014 at 2:40 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Oct 08, 2014 at 11:25:42AM -0700, Jason Gerecke wrote: Repeated connect/disconnect cycles under GNOME can trigger an occasional OOPS from within e.g. wacom_led_select_store, presumably due to a timing

Re: [PATCH v2] HID: wacom: Prevent potential null dereference after disconnect

On Wed, Oct 8, 2014 at 5:28 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Oct 08, 2014 at 05:24:32PM -0700, Jason Gerecke wrote: On Wed, Oct 8, 2014 at 2:40 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Oct 08, 2014 at 11:25:42AM -0700, Jason Gerecke wrote

[PATCH] HID: wacom: Prevent potential null dereference after disconnect

Repeated connect/disconnect cycles under GNOME can trigger an occasional OOPS from within e.g. wacom_led_select_store, presumably due to a timing issue where userspace begins setting a value immediately before the device disconnects and our shared data is whisked away. Signed-off-by: Jason

[PATCH] HID: wacom: Prevent potential null dereference after disconnect

Repeated connect/disconnect cycles under GNOME can trigger an occasional OOPS from within e.g. wacom_led_select_store, presumably due to a timing issue where userspace begins setting a value immediately before the device disconnects and our shared data is whisked away. Signed-off-by: Jason

Re: [PATCH 0/5] HID: wacom: introduce generic HID handling

On Tue, Sep 30, 2014 at 10:27 AM, Benjamin Tissoires wrote: > On Sep 26 2014 or thereabouts, Jason Gerecke wrote: >> On Fri, Sep 26, 2014 at 4:03 AM, Jiri Kosina wrote: >> > On Tue, 23 Sep 2014, Benjamin Tissoires wrote: >> > >> >> Hi guys, >> >

Re: [PATCH 0/5] HID: wacom: introduce generic HID handling

On Tue, Sep 30, 2014 at 10:27 AM, Benjamin Tissoires benjamin.tissoi...@redhat.com wrote: On Sep 26 2014 or thereabouts, Jason Gerecke wrote: On Fri, Sep 26, 2014 at 4:03 AM, Jiri Kosina jkos...@suse.cz wrote: On Tue, 23 Sep 2014, Benjamin Tissoires wrote: Hi guys, So, this patch

Re: [PATCH 0/5] HID: wacom: introduce generic HID handling

On Fri, Sep 26, 2014 at 4:03 AM, Jiri Kosina wrote: > On Tue, 23 Sep 2014, Benjamin Tissoires wrote: > >> Hi guys, >> >> So, this patch series aims at supporting natively any future HID compliant >> wacom >> tablet. Those found on the various laptops (ISDv4/5) already are HID >> compliant >>

Re: [PATCH 0/5] HID: wacom: introduce generic HID handling

On Fri, Sep 26, 2014 at 4:03 AM, Jiri Kosina jkos...@suse.cz wrote: On Tue, 23 Sep 2014, Benjamin Tissoires wrote: Hi guys, So, this patch series aims at supporting natively any future HID compliant wacom tablet. Those found on the various laptops (ISDv4/5) already are HID compliant and

Re: [PATCH 0/5] Input - wacom: split out pad data from the stylus input device

t; > drivers/input/tablet/wacom.h | 2 + > drivers/input/tablet/wacom_sys.c | 63 +++- > drivers/input/tablet/wacom_wac.c | 328 > ------- > drivers/input/tablet/wacom_wac.h | 2 + > 4 files changed, 259 insertions(+), 136

Re: [PATCH 00/15] Input - Wacom: switch from an USB to a HID driver

On Wed, Jul 2, 2014 at 4:33 PM, Jason Gerecke wrote: > On Mon, Jun 30, 2014 at 2:26 PM, Benjamin Tissoires > wrote: >> Hi guys, >> >> this patch series is a cleanup for the Wacom USB driver. >> >> I started working on this topic when I saw patches floating

Re: [PATCH 05/15] Input - wacom: compute the HID report size to get the actual packet size

On Mon, Jun 30, 2014 at 2:26 PM, Benjamin Tissoires wrote: > This removes an USB dependency and is more accurate: the computed pktlen > is the actual maximum size of the reports forwarded by the device. > > Given that the pktlen is correctly computed/validated, we can store it now > in the

Re: [PATCH 1/5] Input - wacom: create a separate input device for pads

On Mon, Jun 23, 2014 at 1:57 PM, Benjamin Tissoires wrote: > Currently, the pad events are sent through the stylus input device > for the Intuos/Cintiqs, and through the touch input device for the > Bamboos. > > To differentiate the buttons pressed on the pad from the ones pressed > on the

Re: [PATCH 08/15] Input - wacom: remove usb dependency for siblings devices

On Mon, Jun 30, 2014 at 2:26 PM, Benjamin Tissoires wrote: > Wacom tablets can share different physical sensors on one physical device. > These are called siblings in the code. The current way of implementation > relies on the USB topology to be able to share data amongs those sensors. > > We can

Re: [PATCH 08/15] Input - wacom: remove usb dependency for siblings devices

On Mon, Jun 30, 2014 at 2:26 PM, Benjamin Tissoires benjamin.tissoi...@redhat.com wrote: Wacom tablets can share different physical sensors on one physical device. These are called siblings in the code. The current way of implementation relies on the USB topology to be able to share data amongs

Re: [PATCH 1/5] Input - wacom: create a separate input device for pads

On Mon, Jun 23, 2014 at 1:57 PM, Benjamin Tissoires benjamin.tissoi...@redhat.com wrote: Currently, the pad events are sent through the stylus input device for the Intuos/Cintiqs, and through the touch input device for the Bamboos. To differentiate the buttons pressed on the pad from the ones

Re: [PATCH 05/15] Input - wacom: compute the HID report size to get the actual packet size

On Mon, Jun 30, 2014 at 2:26 PM, Benjamin Tissoires benjamin.tissoi...@redhat.com wrote: This removes an USB dependency and is more accurate: the computed pktlen is the actual maximum size of the reports forwarded by the device. Given that the pktlen is correctly computed/validated, we can

Re: [PATCH 00/15] Input - Wacom: switch from an USB to a HID driver

On Wed, Jul 2, 2014 at 4:33 PM, Jason Gerecke killert...@gmail.com wrote: On Mon, Jun 30, 2014 at 2:26 PM, Benjamin Tissoires benjamin.tissoi...@redhat.com wrote: Hi guys, this patch series is a cleanup for the Wacom USB driver. I started working on this topic when I saw patches floating

Re: [PATCH 0/5] Input - wacom: split out pad data from the stylus input device

, 259 insertions(+), 136 deletions(-) -- 1.9.0 These look fine to me as well (aside from the one minor comment): Reviewed-by: Jason Gerecke killert...@gmail.com Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two

Re: [PATCH 00/15] Input - Wacom: switch from an USB to a HID driver

On Mon, Jun 30, 2014 at 2:26 PM, Benjamin Tissoires wrote: > Hi guys, > > this patch series is a cleanup for the Wacom USB driver. > > I started working on this topic when I saw patches floating around which > implemented a report descriptor parser within the wacom.ko module. > However, we

Re: [PATCH 00/15] Input - Wacom: switch from an USB to a HID driver

On Mon, Jun 30, 2014 at 2:26 PM, Benjamin Tissoires benjamin.tissoi...@redhat.com wrote: Hi guys, this patch series is a cleanup for the Wacom USB driver. I started working on this topic when I saw patches floating around which implemented a report descriptor parser within the wacom.ko