linux-kernel - Re: [PATCH net-next] net: ti: icssg-prueth: Read firmware-names from device tree

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: <20250611170211.7398b083@kernel.org>
Date: Wed, 11 Jun 2025 17:02:11 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: MD Danish Anwar <danishanwar@...com>
Cc: Meghana Malladi <m-malladi@...com>, Paolo Abeni <pabeni@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>, "David S. Miller"
 <davem@...emloft.net>, Andrew Lunn <andrew+netdev@...n.ch>,
 <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
 <linux-arm-kernel@...ts.infradead.org>, <srk@...com>, Vignesh Raghavendra
 <vigneshr@...com>, Roger Quadros <rogerq@...nel.org>
Subject: Re: [PATCH net-next] net: ti: icssg-prueth: Read firmware-names
 from device tree

On Tue, 10 Jun 2025 10:55:01 +0530 MD Danish Anwar wrote:
> Refactor the way firmware names are handled for the ICSSG PRUETH driver.
> Instead of using hardcoded firmware name arrays for different modes (EMAC,
> SWITCH, HSR), the driver now reads the firmware names from the device tree
> property "firmware-name". Only the EMAC firmware names are specified in the
> device tree property. The firmware names for all other supported modes are
> generated dynamically based on the EMAC firmware names by replacing
> substrings (e.g., "eth" with "sw" or "hsr") as appropriate.

Could you include an example?

> This improves flexibility and allows firmware names to be customized via
> the device tree, reducing the need for code changes when firmware names
> change for different platforms.

You seem to be deleting the old constants. Is there no need to keep
backward compatibility with DT blobs which don't have the firmware-name
properties ?
-- 
pw-bot: cr