Re: [PATCH net-next v2 1/2] net: sfp: allow prefix matching in quirk lookup

Martino Dell'Ambrogio <[email protected]>
Newsgroups org.kernel.vger.netdev,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On Mon, 10 Aug 2026 17:14:27 -0700, Jakub Kicinski wrote:
> [Severity: Low]
> Should the commit message describe what this patch alone does?
>
> At this commit SFP_QUIRK_F_PREFIX has no users: every entry in
> sfp_quirks[] still uses SFP_QUIRK/SFP_QUIRK_S/SFP_QUIRK_F, so
> q->prefix_match is false for all entries and the new branch in
> sfp_match() is not reachable.

Fair point. I'll reword it in v3 so it describes just the mechanism,
and leave the user-visible symptom to the patch that adds the entries.

> [Severity: Medium]
> Was it intended for the prefix relaxation to apply to vendor_name as
> well as vendor_pn?

No, it wasn't. The PN field is the only one I have ever seen garbage
in, and your Hisense-Leox/Hisense example shows the vendor loosening
could bite for real given the first-match table semantics.

v3 scopes the flag to the part field only (part_prefix_match, vendor
comparison always exact). As it turns out the FS entry does not need
prefix matching at all (see my reply on 2/2), so the only remaining
user is the XGSPONST2001 entry, whose "OEM" vendor string then matches
exactly.

Thanks,
Martino
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.