HI!

> Many an ethernet PHY chip has pins dedicated for LEDs. On some PHYs it
> can be configured via registers whether the LED should be ON, OFF, or
> whether its state should depend on events within the chip (link, rx/tx
> activity and so on).
> 
> Add support for probing such LEDs.
> 
> A PHY driver wishing to utilize this API must implement methods
> led_init() and led_brightness_set(). Methods led_blink_set() and
> led_trigger_offload() are optional.
> 
> Signed-off-by: Marek BehĂșn <[email protected]>
> ---
>  drivers/net/phy/phy_device.c | 140 +++++++++++++++++++++++++++++++++++
>  include/linux/phy.h          |  50 +++++++++++++
>  2 files changed, 190 insertions(+)

> +     led = devm_kzalloc(dev, sizeof(*led), GFP_KERNEL);
> +     if (!led)
> +             return -ENOMEM;
> +
> +     led->addr = -1;
> +     if (!fwnode_property_read_u32(fwnode, "reg", &reg))
> +             led->addr = reg;
> +
> +     led->active_low = !fwnode_property_read_bool(fwnode,
> +                                                  "enable-active-high");
> +     led->tristate = fwnode_property_read_bool(fwnode, "tristate");

Does this need binding documentation?

>       mutex_unlock(&phydev->lock);
>  
> +     /* LEDs have to be registered with phydev mutex unlocked, because some
> +      * operations can be called during registration that lock the mutex.
> +      */
> +     if (!err)
> +             err = phy_probe_leds(phydev);
> +
>       return err;
>  }

Is it safe to do the probing without the mutex?

Should error in LED probing fail the whole phy probe?

Best regards,
                                                                Pavel
-- 
http://www.livejournal.com/~pavelmachek

Attachment: signature.asc
Description: PGP signature

Reply via email to