[PATCH net-next] net: intel: fix PCI device ID conflict between i40e and ipw2200

[PATCH net-next] net: intel: fix PCI device ID conflict between i40e and ipw2200

[Ethan Nelson-Moore]

The ID 8086:104f is matched by both i40e and ipw2200. The same device
ID should not be in more than one driver, because in that case, which
driver is used is unpredictable. Fix this by taking advantage of the
fact that i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200
devices use PCI_CLASS_NETWORK_OTHER to differentiate the devices.

Fixes: 2e45d3f4677a ("i40e: Add support for X710 B/P & SFP+ cards")
Cc: stable@vger.kernel.org
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
 drivers/net/ethernet/intel/i40e/i40e_main.c  | 8 +++++++-
 drivers/net/wireless/intel/ipw2x00/ipw2200.c | 8 +++++++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 0b1cc0481027..2c8f449ad659 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -75,7 +75,13 @@ static const struct pci_device_id i40e_pci_tbl[] = {
 	{PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_BASE_T4), 0},
 	{PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_BASE_T_BC), 0},
 	{PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_SFP), 0},
-	{PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_B), 0},
+	/*
+	 * This ID conflicts with ipw2200, but the devices can be differentiated
+	 * because i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200
+	 * devices use PCI_CLASS_NETWORK_OTHER.
+	 */
+	{PCI_DEVICE(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_10G_B),
+		PCI_CLASS_NETWORK_ETHERNET << 8, 0xffff00, 0},
 	{PCI_VDEVICE(INTEL, I40E_DEV_ID_KX_X722), 0},
 	{PCI_VDEVICE(INTEL, I40E_DEV_ID_QSFP_X722), 0},
 	{PCI_VDEVICE(INTEL, I40E_DEV_ID_SFP_X722), 0},
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index 09035a77e775..b0e769da9415 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -11387,7 +11387,13 @@ static const struct pci_device_id card_ids[] = {
 	{PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2754, 0, 0, 0},
 	{PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2761, 0, 0, 0},
 	{PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2762, 0, 0, 0},
-	{PCI_VDEVICE(INTEL, 0x104f), 0},
+	/*
+	 * This ID conflicts with i40e, but the devices can be differentiated
+	 * because i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200
+	 * devices use PCI_CLASS_NETWORK_OTHER.
+	 */
+	{PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x104f),
+		PCI_CLASS_NETWORK_OTHER << 8, 0xffff00, 0},
 	{PCI_VDEVICE(INTEL, 0x4220), 0},	/* BG */
 	{PCI_VDEVICE(INTEL, 0x4221), 0},	/* BG */
 	{PCI_VDEVICE(INTEL, 0x4223), 0},	/* ABG */
-- 
2.43.0

Re: [PATCH net-next] net: intel: fix PCI device ID conflict between i40e and ipw2200

[Johannes Berg]

On Wed, 2026-02-04 at 23:54 -0800, Ethan Nelson-Moore wrote:
> The ID 8086:104f is matched by both i40e and ipw2200. The same device
> ID should not be in more than one driver, because in that case, which
> driver is used is unpredictable. Fix this by taking advantage of the
> fact that i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200
> devices use PCI_CLASS_NETWORK_OTHER to differentiate the devices.

Right, good solution. How did you figure out that ipw2200 uses OTHER?
I'd thought about this but was afraid it'd also just use ETHERNET.

Acked-by: Johannes Berg <johannes@sipsolutions.net>

(FWIW, I've found the database internally, but not who maintains it nor
any historic information in it ... still digging I guess, if only to
avoid this happening again in the future)

johannes

Re: [PATCH net-next] net: intel: fix PCI device ID conflict between i40e and ipw2200

[Ethan Nelson-Moore]

Hi, Johannes,

On Thu, Feb 5, 2026 at 12:13 AM Johannes Berg <johannes@sipsolutions.net> wrote:
> Right, good solution. How did you figure out that ipw2200 uses OTHER?
> I'd thought about this but was afraid it'd also just use ETHERNET.
I used linux-hardware.org, which is a database of user-contributed
hardware probes. It didn't have any entries for this particular device
ID (which implies the devices affected are rare in the wild and might
explain why no one noticed this before), but I looked at other ipw2200
and i40e IDs - it shows the class code if you click on the individual
probe ID.

> (FWIW, I've found the database internally, but not who maintains it nor
> any historic information in it ... still digging I guess, if only to
> avoid this happening again in the future)
Thanks for looking into this. Have a nice day.

Ethan

RE: [PATCH net-next] net: intel: fix PCI device ID conflict between i40e and ipw2200

[Loktionov, Aleksandr]

> -----Original Message-----
> From: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> Sent: Thursday, February 5, 2026 8:55 AM
> To: netdev@vger.kernel.org; linux-wireless@vger.kernel.org
> Cc: Johannes Berg <johannes@sipsolutions.net>; Ethan Nelson-Moore
> <enelsonmoore@gmail.com>; stable@vger.kernel.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Stanislav Yakovlev <stas.yakovlev@gmail.com>;
> Alice Michael <alice.michael@intel.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>
> Subject: [PATCH net-next] net: intel: fix PCI device ID conflict
> between i40e and ipw2200
> 
> The ID 8086:104f is matched by both i40e and ipw2200. The same device
> ID should not be in more than one driver, because in that case, which
> driver is used is unpredictable. Fix this by taking advantage of the
> fact that i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200
> devices use PCI_CLASS_NETWORK_OTHER to differentiate the devices.
> 
Commit message could be more detailed.
- Why the PCI ID is being reused (if known) Is this actually a reuse after EOL, or is there a misunderstanding? The commit message hand-waves this critical detail.
- Whether this is documented in hardware datasheets
- If there are bug reports of the conflict in the wild


> Fixes: 2e45d3f4677a ("i40e: Add support for X710 B/P & SFP+ cards")
If it's quite critical fix why not to send it to [PATCH net] ? 


> Cc: stable@vger.kernel.org
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> ---
>  drivers/net/ethernet/intel/i40e/i40e_main.c  | 8 +++++++-
> drivers/net/wireless/intel/ipw2x00/ipw2200.c | 8 +++++++-
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index 0b1cc0481027..2c8f449ad659 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -75,7 +75,13 @@ static const struct pci_device_id i40e_pci_tbl[] =
> {
>  	{PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_BASE_T4), 0},
>  	{PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_BASE_T_BC), 0},
>  	{PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_SFP), 0},
> -	{PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_B), 0},
> +	/*
> +	 * This ID conflicts with ipw2200, but the devices can be
> differentiated
> +	 * because i40e devices use PCI_CLASS_NETWORK_ETHERNET and
> ipw2200
> +	 * devices use PCI_CLASS_NETWORK_OTHER.
> +	 */
> +	{PCI_DEVICE(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_10G_B),
> +		PCI_CLASS_NETWORK_ETHERNET << 8, 0xffff00, 0},
>  	{PCI_VDEVICE(INTEL, I40E_DEV_ID_KX_X722), 0},
>  	{PCI_VDEVICE(INTEL, I40E_DEV_ID_QSFP_X722), 0},
>  	{PCI_VDEVICE(INTEL, I40E_DEV_ID_SFP_X722), 0}, diff --git
> a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
> b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
> index 09035a77e775..b0e769da9415 100644
> --- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
> +++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
> @@ -11387,7 +11387,13 @@ static const struct pci_device_id card_ids[]
> = {
>  	{PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2754, 0, 0, 0},
>  	{PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2761, 0, 0, 0},
>  	{PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2762, 0, 0, 0},
> -	{PCI_VDEVICE(INTEL, 0x104f), 0},
> +	/*
> +	 * This ID conflicts with i40e, but the devices can be
> differentiated
> +	 * because i40e devices use PCI_CLASS_NETWORK_ETHERNET and
> ipw2200
> +	 * devices use PCI_CLASS_NETWORK_OTHER.
> +	 */
> +	{PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x104f),
> +		PCI_CLASS_NETWORK_OTHER << 8, 0xffff00, 0},
>  	{PCI_VDEVICE(INTEL, 0x4220), 0},	/* BG */
>  	{PCI_VDEVICE(INTEL, 0x4221), 0},	/* BG */
>  	{PCI_VDEVICE(INTEL, 0x4223), 0},	/* ABG */
> --
> 2.43.0

Re: [PATCH net-next] net: intel: fix PCI device ID conflict between i40e and ipw2200

[Johannes Berg]

On Thu, 2026-02-05 at 08:13 +0000, Loktionov, Aleksandr wrote:
> > 
> Commit message could be more detailed.
> - Why the PCI ID is being reused (if known) Is this actually a reuse after EOL, or is there a misunderstanding? The commit message hand-waves this critical detail.

Well, if you and I can't figure this out internally to Intel, I doubt
anyone _else_ can. Sure, ipw2200 is EOL for *long*, but Intel still
shouldn't have reused the IDs even if the old ones got carried forward
from PCI to PCIe.

> - Whether this is documented in hardware datasheets

Good luck finding any documentation on ipw2200 these days. Those devices
shipped 20+ years ago.

> - If there are bug reports of the conflict in the wild

Does it matter? If you have a system with either of those, you'll get
lucky if it works, and get a mess if it doesn't. ipw2200 driver will
probably bind to just about any device with the right IDs since it
doesn't do much in probe().

johannes

Re: [PATCH net-next] net: intel: fix PCI device ID conflict between i40e and ipw2200

[Ethan Nelson-Moore]

Hi, Alexandr,

On Thu, Feb 5, 2026 at 12:13 AM Loktionov, Aleksandr
<aleksandr.loktionov@intel.com> wrote:
> Commit message could be more detailed.
> - Why the PCI ID is being reused (if known) Is this actually a reuse after EOL, or is there a misunderstanding? The commit message hand-waves this critical detail.
> - Whether this is documented in hardware datasheets
> - If there are bug reports of the conflict in the wild
I don't know any of this information. I found this conflict via a
script I was motivated to write by noticing an ID conflict between
r8169 and 8139too.

> If it's quite critical fix why not to send it to [PATCH net] ?
I used that prefix because the patch is against net-next. It will make
it into stable versions regardless.

Ethan

RE: [PATCH net-next] net: intel: fix PCI device ID conflict between i40e and ipw2200

[Loktionov, Aleksandr]

> -----Original Message-----
> From: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> Sent: Thursday, February 5, 2026 9:18 AM
> To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> Cc: netdev@vger.kernel.org; linux-wireless@vger.kernel.org; Johannes
> Berg <johannes@sipsolutions.net>; stable@vger.kernel.org; Nguyen,
> Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Stanislav Yakovlev <stas.yakovlev@gmail.com>;
> Alice Michael <alice.michael@intel.com>
> Subject: Re: [PATCH net-next] net: intel: fix PCI device ID conflict
> between i40e and ipw2200
> 
> Hi, Alexandr,
> 
> On Thu, Feb 5, 2026 at 12:13 AM Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com> wrote:
> > Commit message could be more detailed.
> > - Why the PCI ID is being reused (if known) Is this actually a reuse
> after EOL, or is there a misunderstanding? The commit message hand-
> waves this critical detail.
> > - Whether this is documented in hardware datasheets
> > - If there are bug reports of the conflict in the wild
> I don't know any of this information. I found this conflict via a
> script I was motivated to write by noticing an ID conflict between
> r8169 and 8139too.
> 
> > If it's quite critical fix why not to send it to [PATCH net] ?
> I used that prefix because the patch is against net-next. It will make
> it into stable versions regardless.
> 
> Ethan

I thought 'fix' patches must go to net first, isn't it?