netdev - Re: [PATCH 0/3] Control ethernet PHY LEDs via LED subsystem

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]

Date:	Thu, 24 Mar 2016 18:35:44 +0100
From:	Vishal Thanki <vishalthanki@...il.com>
To:	Andrew Lunn <andrew@...n.ch>
Cc:	Florian Fainelli <f.fainelli@...il.com>,
	Matus Ujhelyi <ujhelyi.m@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH 0/3] Control ethernet PHY LEDs via LED subsystem

>> >> The eth-phy-activity trigger uses the blink_set which I think uses the
>> >> hardware acceleration if available. I am not sure how to handles LEDs
>> >> which does not have hardware acceleration for this (eth-phy-activity)
>> >> trigger.
>> >
>> > We want the LED to blink on activity, real packets coming in and
>> > out. The PHY can do this, so let the PHY control the LED. In this
>> > case, the trigger is just mechanism for the user to say what the LED
>> > should be used for. The trigger is not itself controlling the LED, it
>> > has no idea about packets coming and going.
>> >
>>
>> Yes, I understand that. But PHY can only control the LEDs attached to
>> it directly. The at803x led driver configures the PHY to blink the
>> activity LED based on traffic but I think it is not possible for PHY
>> to control other LEDs in system, for example some other LEDs in system
>> controlled only via GPIO. In such cases, putting PHY activity trigger
>> on the GPIO LEDs would not make sense. Correct me if I am wrong.
>
> Hi Vishal
>
> All correct. Which is why i said in my original email, you need to
> extend the LED core to associate triggers to LEDs. You can then
> associate the eth-phy-activity trigger to only PHY leds which can
> implement that functionality.
>
> drivers/leds/led-triggers.c contains a global list
> LIST_HEAD(trigger_list) which triggers get added to using
> led_trigger_register(). You could add a second list to the
> led_classdev structure, and add an led_trigger_register_to_led()

Hi Andrew,

I still have some questions. Will the phylib call this
led_trigger_register_to_led() function for registering the trigger
instead of calling led_trigger_register()?

> function which registers a trigger to a specific LED, on its own
> trigger list. led_trigger_store() and led_trigger_show() would use
> both lists.

In case of led_trigger_store(), how to stop the non-PHY LEDs to
register themselves from eth-phy-activity trigger. Should there be a
LED class field which distinguishes different LEDs types (GPIO, PHY
etc..) ? And only PHY LEDs have the privilege to register to
eth-phy-activity trigger?

Thanks you very much for your guidance and patience with me.

Regards,
Vishal

>
>      Andrew