netdev - Re: [PATCH RFC leds + net-next 6/7] net: phy: add support for LEDs connected to ethernet PHYs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210301105210.GE31897@duo.ucw.cz>
Date:   Mon, 1 Mar 2021 11:52:10 +0100
From:   Pavel Machek <pavel@....cz>
To:     Marek Behún <kabel@...nel.org>
Cc:     netdev@...r.kernel.org, linux-leds@...r.kernel.org,
        Dan Murphy <dmurphy@...com>,
        Russell King <linux@...linux.org.uk>,
        Andrew Lunn <andrew@...n.ch>,
        Matthias Schiffer <matthias.schiffer@...tq-group.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Ben Whitten <ben.whitten@...il.com>
Subject: Re: [PATCH RFC leds + net-next 6/7] net: phy: add support for LEDs
 connected to ethernet PHYs

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@...nel.org>
> ---
>  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

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)