netdev - Re: [PATCH net-next 03/11] ixgbe: Add 10G-BX 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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fcca2ea0-b0d9-4332-91f1-153be2063788@intel.com>
Date: Mon, 1 Dec 2025 14:40:43 -0800
From: Tony Nguyen <anthony.l.nguyen@...el.com>
To: Birger Koblitz <mail@...ger-koblitz.de>, Jakub Kicinski <kuba@...nel.org>
CC: <davem@...emloft.net>, <pabeni@...hat.com>, <edumazet@...gle.com>,
	<andrew+netdev@...n.ch>, <netdev@...r.kernel.org>, Andrew Lunn
	<andrew@...n.ch>, Paul Menzel <pmenzel@...gen.mpg.de>, Aleksandr Loktionov
	<aleksandr.loktionov@...el.com>, Rinitha S <sx.rinitha@...el.com>
Subject: Re: [PATCH net-next 03/11] ixgbe: Add 10G-BX support



On 11/27/2025 10:48 AM, Birger Koblitz wrote:
> 
> On 27/11/2025 5:07 pm, Jakub Kicinski wrote:
>>>> link length requirement isn't met?
>>> The ixgbe_identify_sfp_module_generic detects SFP modules that it knows
>>> how to initialize in a positive manner, that is all the conditions have
>>> to be fulfilled. If this is not the case, then the default from
>>> ixgbe_main.c:ixgbe_probe() kicks in, which sets
>>>     hw->phy.sfp_type = ixgbe_sfp_type_unknown;
>>> before probing the SFP. The else is unnecessary.
>>>
>>> If the SFP module cannot be positively identified, then that functions
>>> logs an error:
>>>     e_dev_err("failed to load because an unsupported SFP+ or QSFP module
>>> type was detected.\n");
>>>     e_dev_err("Reload the driver after installing a supported module. 
>>> \n");
>>
>> Got it! perhaps add a note to the commit msg or a comment somewhere to
>> avoid AI flagging this again?
> On second thought, and while thinking how to formulate such a message, 
> maybe it is cleaner to set hw->phy.sfp_type = ixgbe_sfp_type_unknown
> explicitly in an additional else. Otherwise, if the context of how 
> ixgbe_identify_sfp_module_generic is called could change in the future 
> and then something unexpected might happen.
> 
> I tested adding the else and it works as expected by not doing anything, 
> the variable is already set to ixgbe_sfp_type_unknown. And I also 
> verified again that the current patch is also correct: I made only the 
> length-check fail and indeed the default kicks in with the correct 
> outcome, that the module is unsupported.
> 
> Since the patch is now submitted in a series from Tony, I guess the 
> decision is with him. I also am unsure who would submit a fixed patch or 
> added comment and where it would need to be sent to at this stage.

Hi Birger,

If you could send/treat it as a new version of the previous patch, and 
send it like before, I'll handle it from there.

Thanks,
Tony