lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 16 Jun 2014 12:33:04 -0400
From:	Benjamin Tissoires <>
To:	Ping Cheng <>
Cc:	Dmitry Torokhov <>,
	Jason Gerecke <>,
	linux-input <>,
	"" <>
Subject: Re: [PATCH] Input - wacom: put a flag when the led are initialized

Hi Ping,

On Jun 13 2014 or thereabouts, Ping Cheng wrote:
> Hi Benjamin,
> On Fri, Jun 13, 2014 at 1:29 PM, Benjamin Tissoires
> <> wrote:
> > This solves a bug with the wireless receiver:
> Your patch does get rid of the crash. But, it does not fix it at the
> root cause.

True, it fixes the crash, does not get rid of the root cause, but it is
still required. See later.

> > - at plug, the wireless receiver does not know which Wacom device it is
> >   connected to, so it does not actually creates all the LEDs
> This is the root cause - LEDs are not created for wireless devices.
> Neither here, nor later when a real device is connected.


> > - when the tablet connects, wacom->wacom_wac.features.type is set to the
> >   proper device so that wacom_wac can understand the packets
> LEDs are not created for any wireless devices since we don't call
> wacom_initialize_leds() when real tablets are connected.


> > - when the receiver is unplugged, it detects that a LED should have been
> >   created (based on wacom->wacom_wac.features.type) and tries to remove
> >   it: crash when removing the sysfs group.
> When receiver is unplugged, it remembers the last tablet that
> connected to it. If that tablet supports LEDs, wacom_destroy_leds() is
> called. But, no LEDs were initialized. That's why it crashes.


> > Side effect, we can now safely call several times wacom_destroy_leds().
> led_initialized will never be true if we keep wacom_initialize_leds()
> inside probe().

If you are talking about wireless devices only, yes, this value will
never be true. That's the purpose of this patch actually :)

> To make initialize_leds() and desctroy_leds() work for wireless
> devices, we need to move them to wacom_wireless_work() where we know
> what type of tablet is connected/disconnected.

Unfortunately, this does not work:
- we *can* create the LEDs sysfs in the wireless work
- this will prevent the crash
- the user will think it can control the LEDs
- actually these LEDs control will do nothing because LEDs handling for
  wireless devices goes through the WL interface, and not the PEN
  interface of the WL receiver.
- we need to implement a specific led_handling for the wireless receiver
  (which will need to know which type of tablet is connected to it)
- we still need a way to say that the pen intf which is declared as the
  connected device does not has a LED sysfs.

We could add a quirk to the wacom_wac->features saying that the
connection is wireless, so there is no LED attached to the interface.

Still, there will be some work to do to properly handle the LED
configuration from the WL receiver. This work has to be done in the
kernel, but also in the user space (g-s-d) because now, the led control
will not be on the pen device, but on a plain usb device without input.

If you prefer, I can add such a quirk. But my only concern is here to
fix the kernel oops, not to add features which would require more
testing across different hardware and development on the user space

> > Signed-off-by: Benjamin Tissoires <>
> Thank you for your support. But, sorry
> NAKed-by: Ping Cheng <>

Please reconsider it or validate the quirk approach I mentioned.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists