All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Milo Kim <milo.kim@ti.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 10:10:00 +0100	[thread overview]
Message-ID: <569DFD68.9050200@samsung.com> (raw)
In-Reply-To: <569D508A.8010906@gmail.com>

Hi Heiner,

On 01/18/2016 09:52 PM, Heiner Kallweit wrote:

>> Yes, this seems to be the best solution. Driver should set this flag
>> before calling led_classdev_unregister. If the flag is set the -ENODEV
>> error will not be reported. It could be named LED_HW_ABSENT for
>> instance. Feel free to propose other ideas.
>>
> 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:

Ignoring -ENODEV errors for all devices would filter out also valid
error cases and hinder debugging.

How about adding a flag LED_HW_PLUGGABLE in addition to
LED_UNREGISTERING, and make the pluggable LED class drivers having set
it all the time. The -ENODEV error would be reported only
if !(LED_UNREGISTERING && LED_HW_PLUGGABLE).

-- 
Best Regards,
Jacek Anaszewski

  parent reply	other threads:[~2016-01-19  9:10 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
2016-01-19  9:10         ` Jacek Anaszewski [this message]
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=569DFD68.9050200@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=hkallweit1@gmail.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.