linux-kernel - Re: [PATCH V2 4/4] arm64: dts: mediatek: Add Cudy WR3000 V1

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <9c114a61-ad19-4852-96c8-dbcbe8d8e38c@collabora.com>
Date: Mon, 26 Feb 2024 09:58:50 +0100
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Rafał Miłecki <zajec5@...il.com>,
 Matthias Brugger <matthias.bgg@...il.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>
Cc: Chen-Yu Tsai <wenst@...omium.org>, Hsin-Yi Wang <hsinyi@...omium.org>,
 Nícolas F . R . A . Prado <nfraprado@...labora.com>,
 Heiko Stuebner <heiko.stuebner@...rry.de>,
 Jernej Skrabec <jernej.skrabec@...il.com>,
 Chris Morgan <macromorgan@...mail.com>,
 Linus Walleij <linus.walleij@...aro.org>, Sean Wang
 <sean.wang@...iatek.com>, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
 linux-kernel@...r.kernel.org, Rafał Miłecki
 <rafal@...ecki.pl>
Subject: Re: [PATCH V2 4/4] arm64: dts: mediatek: Add Cudy WR3000 V1

Il 23/02/24 11:17, Rafał Miłecki ha scritto:
> From: Rafał Miłecki <rafal@...ecki.pl>
> 
> Cudy WR3000 V1 is an MT7981B (AKA Filogic 820) based wireless router. It
> has 256 MiB of RAM, some LEDs & buttons and (not described yet) 4
> Ethernet ports.
> 
> There is one slightly uncommon LED with a label of globe icon described
> in the Quick Installation Guide as having 2 meanings:
> 1. "Not connected to the Internet"
> 2. "Connected to the Internet"
> 
> Vendor designed it to light up when some Internet-accessible IP can be
> reached. This change will be follow by an attempt to define some
> predefined FUNCTION for it.

Can we please try to add that predefined function before adding this devicetree
which would anyway be modified again to use that new definition?

That just makes more sense...

..if you can't get the new definition picked, I will take this one as is, but
please try that first.

Cheers,
Angelo