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: <20240710154937.0dbcbd0c@wsk>
Date: Wed, 10 Jul 2024 15:49:37 +0200
From: Lukasz Majewski <lukma@...x.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: Pavel Machek <pavel@....cz>, Lee Jones <lee@...nel.org>, Heiner Kallweit
 <hkallweit1@...il.com>, Christian Marangi <ansuelsmth@...il.com>, Jakub
 Kicinski <kuba@...nel.org>, Marek BehĂșn <kabel@...nel.org>,
 Daniel Golle <daniel@...rotopia.org>, Li Zetao <lizetao1@...wei.com>,
 linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 net-next] leds: trigger: netdev: Add support for
 tx_err and rx_err notification with LEDs

Hi Andrew,

> On Wed, Jul 10, 2024 at 12:06:51PM +0200, Lukasz Majewski wrote:
> > This patch provides support for enabling blinking of LEDs when RX
> > or TX errors are detected.
> > 
> > Approach taken in this patch is similar to one for TX or RX data
> > transmission indication (i.e. TRIGGER_NETDEV_TX/RX attribute).
> > 
> > One can inspect transmission errors with:
> > ip -s link show eth0
> > 
> > Example LED configuration:
> > cd /sys/devices/platform/amba_pl@...001a000.leds/leds/
> > echo netdev > mode:blue/trigger && \
> > echo eth0 > mode:blue/device_name && \
> > echo 1 > mode:blue/tx_err  
> 
> When i look at the machines around me, they all have an error count of
> 0. 

This is mostly true for ethernet. However, it happens on some low-level
drivers that errors field is not zero when e.g. the received frame is
malformed due to harsh work environment.

> Do you have a real customer use case for this? 

Yes.

The problem is apparent mostly with can interfaces and transmission for
it.

> What sort of systems
> do you have which do have sufficient errors to justify an LED?

In my case it is an embedded industrial/automotive controller with 10+
RGB LEDs. It only has LEDs to communicate with user.

The way how and when they blink shows the status of the device.

With this patch one is able to spot if some transmission is failing
(among other things).

> 
> There is no standardisation of LEDs. Every vendor implements something
> different. What i don't want is lots of different blink patterns,
> which nobody ever uses.

As you can assess from the code - this patch extends neatly the current
code, with use case valid for my customer.

> 
> 	Andrew




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...x.de

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ