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:   Mon, 20 Sep 2021 21:19:13 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Ansuel Smith <ansuelsmth@...il.com>
Cc:     Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [net-next RFC PATCH 1/2] drivers: net: dsa: qca8k: add support
 for led config

> Yes, can you point me to the discussion?

It has gone through many cycles :-(

The linux-led list is probably the better archive to look through, it
is a lot lower volume than netdev.

https://www.spinics.net/lists/linux-leds/msg18652.html

https://www.spinics.net/lists/linux-leds/msg18527.html


> I post this as RFC for this exact reason... I read somehwere that there
> was a discussion on how to implementd leds for switch but never ever
> found it.

Most of the discussion so far has been about PHY LEDs, where the PHY
driver controls the LEDs. However some Ethernet switches also have LED
controls, which are not part of the PHY. And then there are some MAC
drivers which control the PHY in firmware, and have firmware calls for
controlling the LEDs. We need a generic solution which scales across
all this. And it needs to work without DT, or at least, not block ACPI
being added later.

But progress is slow. I hope that the PHY use case will drive things
forward, get the ABI defined. We can then scale it out to include
switches, maybe with a bit of code refactoring.

	  Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ