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