From: Florian Fainelli <florian@openwrt.org>
To: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: netdev <netdev@vger.kernel.org>, David Miller <davem@davemloft.net>
Subject: Re: [PATCH 2/2] drivers: net: phy: at803x: LED control via led subsystem
Date: Fri, 12 Jul 2013 08:19:03 +0100 [thread overview]
Message-ID: <CAGVrzcZn+dAzWV9ObyfLn5cyE0D7rXgUkmdKOZ8rE0q1r4J3Hg@mail.gmail.com> (raw)
In-Reply-To: <CAGXE3d8WRU2fmRZ9DAQ4_Y=WZQwNmt9DVbLys=LkJaRPz=7FAw@mail.gmail.com>
2013/7/11 Helmut Schaa <helmut.schaa@googlemail.com>:
>>
>> I do like this and I believe that there is nothing specific that would
>> prevent you from making software controllable LEDs from being used
>> with other PHYs. How about you create a small LED class helper that
>> PHY drivers supporting controllable LEDs can hook into and provide
>> their own callback and LED name for setting the LED state?
>
> Hmm, nice idea. However, there is not much complexity in the code. The only
> thing worth to make generic would be the delayed register access via workqueue.
> The rest is just registering the led device :)
>
> I thought about moving the code into the generic phy code and using a new
> phy_driver callback for setting the LED state but there might be more then one
> LED pin on some PHYs (activity, speed, duplexmode etc.).
I think that the same callback for all LEDs and just take actions
based on which led_classdev pointer we get passed should be enough. I
agree with you that there is not much complexity, but for sure, if we
add support for LEDs to another PHY driver there will be similar stuff
done (registering a LED classdev, etc...) so we might just want to
specialize the led_brightness_set() callback and the number of LEDs.
One thing with moving this closer to the PHY state machine would be to
allow for better integration, like setting the LED brightness to 0
when the link goes down etc...
>
>>> +
>>> +static void at8035_led_brightness_set(struct led_classdev *led,
>>> + enum led_brightness brightness)
>>> +{
>>> + struct at8035_priv *priv = container_of(led, struct at8035_priv, led);
>>> +
>>> + /* MDIO bus can only be used from process context */
>>> + if (!priv->stop)
>>> + schedule_work(&priv->led_work);
>>
>> It seems to me that you could remove the stop boolean if you move
>> led_classdev_unregister upper, provided that it guarantees it will not
>> schedule the workqueue.
>
> led_classdev_unregister will try to set brightness to 0 and thus schedule
> the work.
Ok, thanks!
--
Florian
next prev parent reply other threads:[~2013-07-12 7:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-11 11:57 [PATCH 1/2] drivers: net: phy: at803x: Add missing mdio device id Helmut Schaa
2013-07-11 11:57 ` [PATCH 2/2] drivers: net: phy: at803x: LED control via led subsystem Helmut Schaa
2013-07-11 12:15 ` Florian Fainelli
2013-07-11 12:57 ` Helmut Schaa
2013-07-12 7:19 ` Florian Fainelli [this message]
2013-07-16 6:56 ` Helmut Schaa
2013-07-11 18:54 ` David Miller
2013-07-11 19:04 ` Helmut Schaa
2013-07-11 18:54 ` [PATCH 1/2] drivers: net: phy: at803x: Add missing mdio device id David Miller
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=CAGVrzcZn+dAzWV9ObyfLn5cyE0D7rXgUkmdKOZ8rE0q1r4J3Hg@mail.gmail.com \
--to=florian@openwrt.org \
--cc=davem@davemloft.net \
--cc=helmut.schaa@googlemail.com \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).