linux-kernel - Re: [PATCH v2 2/6] leds: trigger: Create a new LED netdev trigger for collision

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: <e1936774-14bf-4ae5-9754-e21f5a0c59b3@bootlin.com>
Date: Thu, 29 Feb 2024 08:24:29 +0100
From: Bastien Curutchet <bastien.curutchet@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Pavel Machek <pavel@....cz>,
 Lee Jones <lee@...nel.org>, Richard Cochran <richardcochran@...il.com>,
 Heiner Kallweit <hkallweit1@...il.com>, Russell King
 <linux@...linux.org.uk>, linux-kernel@...r.kernel.org,
 netdev@...r.kernel.org, devicetree@...r.kernel.org,
 linux-leds@...r.kernel.org, Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 herve.codina@...tlin.com, maxime.chevallier@...tlin.com,
 christophercordahi@...ometrics.ca
Subject: Re: [PATCH v2 2/6] leds: trigger: Create a new LED netdev trigger for
 collision

Hi Andrew,

On 2/27/24 17:03, Andrew Lunn wrote:
> On Tue, Feb 27, 2024 at 10:39:41AM +0100, Bastien Curutchet wrote:
>> Collisions on link does not fit into one of the existing netdev triggers.
>>
>> Add TRIGGER_NETDEV_COLLISION in the enum led_trigger_netdev_modes.
>> Add its definition in Documentation.
>> Add its handling in ledtrig-netdev, it can only be supported by hardware
>> so no software fallback is implemented.
> How useful is collision? How did you test this? How did you cause
> collisions to see if the LED actually worked?
Indeed I am not able to generate collision on my setup so I did not test 
this
collision part.
My use case is that the hardware strap configuration that selects the 
LED output mode
can not be trusted so I have to force configuration with software. I 
added this collision
part because I wanted to cover all the LED configuration modes offered 
by the PHY.
> As far as i can see, this is just a normal 100Base-T PHY. Everybody
> uses that point-to-point nowadays. If it was an 100Base-T1, with a
> shared medium, good old CSMA/CD then collision might actually be
> useful.
>
> I also disagree with not having software fallback:
>
> ip -s link show eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
>      link/ether 80:ee:73:83:60:27 brd ff:ff:ff:ff:ff:ff
>      RX:     bytes    packets errors dropped  missed   mcast
>      4382213540983 2947876747      0       0       0  154890
>      TX:     bytes    packets errors dropped carrier collsns
>        18742773651  197507119      0       0       0       0
>
> collsns = 0. The information is there in a standard format. However,
> when did you last see it not 0?

Ok, I could add the software callback but I will not be able to test it ...

Best regards,
Bastien