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 <kabel@xxxxxxxxxx> > --- > 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", ®)) > + 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
