netdev - Re: [RFC] net: phy: air_en8811h: add Airoha AN8811HB support

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <878qfjn4cw.fsf@miraculix.mork.no>
Date: Wed, 03 Dec 2025 13:21:03 +0100
From: Bjørn Mork <bjorn@...k.no>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, "Lucien.Jheng" <lucienzx159@...il.com>,
        Daniel Golle <daniel@...rotopia.org>,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [RFC] net: phy: air_en8811h: add Airoha AN8811HB support

Andrew Lunn <andrew@...n.ch> writes:

> Maybe look at having two different probe functions, with a helper for
> any common code? That might mean you don't need as many switch
> statements. And this is a common pattern when dealing with variants of
> hardware. You have a collection of helpers which are generic, and then
> version specific functions which make use of the helpers are
> appropriate.
>
> This patch is also quite large. See if you can break it
> up. Refactoring the existing code into helpers can be a patch of its
> own.

Thaks a lot for the valuable feedback! It all made a lot of sense to me.
Will be fixed in the next version if/when there is one.

But I'll let this rest for a while, to see if I can get the firmware and
testing issues resolved first.


Bjørn