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>] [day] [month] [year] [list]
Message-ID: <CAJD4rqFKYrvg4oFOffCAUss1bmEXDFsTedwLZK3jX3QWTF8VXQ@mail.gmail.com>
Date:   Tue, 7 Nov 2023 01:34:00 +0200
From:   Rani Hod <rani.hod@...il.com>
To:     robh@...nel.org
Cc:     conor+dt@...nel.org, devicetree@...r.kernel.org,
        krzysztof.kozlowski+dt@...aro.org, lee@...nel.org,
        linux-kernel@...r.kernel.org, linux-leds@...r.kernel.org,
        oliver@...inagl.nl, pavel@....cz, yangshiji66@...look.com
Subject: Re: [PATCH v2 2/2] dt-bindings: leds: add "internet" and "rssi"
 function definitions

On Tue, Oct 31, 2023 at 09:29:01PM +0800, Shiji Yang wrote:
> These two types of LEDs are widely used in routers and NICs. The
> RSSI (Received Signal Strength Indicator) LED is used to display
> the Wi-Fi signal strength, and the Internet LED can indicate
> whether the device can access a specific server.

Two more LED functions somewhat common to wireless APs that should be
considered here IMHO are

(i) a function for cellular (3g/4g/5g/...) connectivity or activity.
LED_FUNCTION_LTE might age poorly, but LED_FUNCTION_WWAN [1] could fit
in with existing network functions.
Alternatively, LED_FUNCTION_MODEM seems both more inclusive and more specific.

(ii) a function for signaling mesh (= wireless inter-AP) connectivity
or activity.
LED_FUNCTION_MESH jumps to mind first, but perhaps there's a better
name that could fit wireless repeaters as well.
This function is close to, but does not fall IMHO under the suggested
LED_FUNCTION_SIGNAL, as this one serves to indicate activity on a
wireless connection between wireless APs (e.g. 802.11s) regardless of
signal quality.

Thanks and best,
R.

P.S.
Sorry if it looks like trying to steal the focus from OP, but I
believe it makes sense to discuss these additions here rather than
restart the discussion wrt a separate patch.

[1] name suggested here:
https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg61810.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ