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

From: Martino Dell'Ambrogio

Date: Wed Aug 12 2026 - 11:23:29 EST


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