linux-kernel - Re: [PATCH RFC leds + net-next v4 1/2] net: phy: add API for LEDs controlled by PHY HW

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: <20200728161800.GJ1705504@lunn.ch>
Date:   Tue, 28 Jul 2020 18:18:00 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Marek Behún <marek.behun@....cz>
Cc:     netdev@...r.kernel.org, linux-leds@...r.kernel.org,
        Pavel Machek <pavel@....cz>, jacek.anaszewski@...il.com,
        Dan Murphy <dmurphy@...com>,
        Ondřej Jirman <megous@...ous.com>,
        Russell King <linux@...linux.org.uk>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Gregory Clement <gregory.clement@...tlin.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC leds + net-next v4 1/2] net: phy: add API for LEDs
 controlled by PHY HW

> +static int of_phy_register_led(struct phy_device *phydev, struct device_node *np)
> +{
> +	struct led_init_data init_data = {};
> +	struct phy_device_led *led;
> +	u32 reg;
> +	int ret;
> +
> +	ret = of_property_read_u32(np, "reg", &reg);
> +	if (ret < 0)
> +		return ret;
> +
> +	led = devm_kzalloc(&phydev->mdio.dev, sizeof(struct phy_device_led), GFP_KERNEL);
> +	if (!led)
> +		return -ENOMEM;
> +
> +	led->cdev.brightness_set_blocking = phy_led_brightness_set;
> +	led->cdev.trigger_type = &phy_hw_led_trig_type;
> +	led->addr = reg;
> +
> +	of_property_read_string(np, "linux,default-trigger", &led->cdev.default_trigger);

Hi Marek

I think we need one more optional property. If the trigger has been
set to the PHY hardware trigger, we then should be able to set which
of the different blink patterns we want the LED to use. I guess most
users will never actually make use of the sys/class/led interface, if
the default in device tree is sensible. But that requires DT can fully
configure the LED.

   Andrew