All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Milo Kim <milo.kim@ti.com>
Cc: Jacek Anaszewski <j.anaszewski@samsung.com>, linux-leds@vger.kernel.org
Subject: Re: Problem with resetting LED in led_classdev_unregister in case of USB LED device removal
Date: Tue, 19 Jan 2016 07:46:54 +0100	[thread overview]
Message-ID: <569DDBDE.9070300@gmail.com> (raw)
In-Reply-To: <569D7F31.8060905@ti.com>

Am 19.01.2016 um 01:11 schrieb Milo Kim:
> On 01/19/2016 05:52 AM, Heiner Kallweit wrote:
>> Setting such a flag from the driver might cause significant effort in different layers.
>> When we talk about thingm as an example, it uses the hid subsystem with the usbhid low level driver.
>> We would need a callback in the usbhid driver (to be notified when the device is unplugged)
>> and a way to propagate this event to the hid core.
>>
>> Maybe simpler: We could ignore ENODEV errors if a function is called from led_classdev_unregister.
>> This way we wouldn't have to touch drivers. I think of something like this:
> 
> Well, simple solution is good but I'm thinking about more generic handling.
> 
> 
> LED subsystem                HID LED driver
> -------------                --------------
>                     Create a LED device
> 
> Registers an event notifier
> 
>                     Device is unplugged,
>                     notify an event to LED
>                     subsystem
> 
> Notification callback sets
> a flag which means HW is removed
> 
> Set-brightness scheduler work
> function checks this flag and
> ignore the brightness update
> 
Most likely not the LED subsystem but the respective driver would have to register the notifier as only the driver
knows what kind of subsystem (usb, ..) is used.

I agree that this would be somewhat cleaner. However I have my doubts that the relatively small benefit of getting read of one
a little annoying error message justifies the required efforts.
> 
> blocking_notifier_chain_register() and blocking_notifier_call_chain() helpers can be used for this implementation.
> 
> However, I'm not sure how much latency will exist between step 3 (device is unplugged) and step 5 (check the flag and ignore brightness-set).
> 
At a first glance I dont't think this is an issue because the notifier chain is blocking.

> Best regards,
> Milo
> 
Regards, Heiner

  reply	other threads:[~2016-01-19  6:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-16 21:34 Problem with resetting LED in led_classdev_unregister in case of USB LED device removal Heiner Kallweit
2016-01-18  0:20 ` Milo Kim
2016-01-18  6:37   ` Heiner Kallweit
2016-01-18  8:46     ` Jacek Anaszewski
2016-01-18 20:52       ` Heiner Kallweit
2016-01-19  0:11         ` Milo Kim
2016-01-19  6:46           ` Heiner Kallweit [this message]
2016-01-19  9:10         ` Jacek Anaszewski
2016-01-19 20:23           ` Heiner Kallweit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=569DDBDE.9070300@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=j.anaszewski@samsung.com \
    --cc=linux-leds@vger.kernel.org \
    --cc=milo.kim@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.