Re: [PATCH] net: ethernet: marvell: skge: remove incorrect conflicting PCI ID

[Stephen Hemminger <stephen@networkplumber.org>]

On Thu,  5 Feb 2026 23:17:14 -0800
Ethan Nelson-Moore <enelsonmoore@gmail.com> wrote:

> The ID 1186:4302 is matched by both r8169 and skge. The same device ID
> should not be in more than one driver, because in that case, which
> driver is used is unpredictable. I downloaded the latest drivers for
> all hardware revisions of the D-Link DGE-530T from D-Link's website,
> and the only drivers which contain this ID are Realtek drivers.
> Therefore, remove this device ID from skge.
> 
> In the kernel bug report which requested addition of this device ID,
> someone created a patch to add the ID to skge. Then, it was pointed
> out that this device is an "r8169 in disguise", and a patch was created
> to add it to r8169. Somehow, both of these patches got merged. See the
> link below.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=38862
> Fixes: c074304c2bcf ("add pci-id for DGE-530T")
> Cc: stable@vger.kernel.org
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>

I was intrigued as to how this happened, and sent of AI to find out.

D-Link DGE-530T: Chipset History and Driver Confusion
=====================================================

D-Link shipped multiple hardware revisions of the DGE-530T under the
same product name and packaging, but with completely different chipsets:

  Rev A1 - Marvell 88E8003 (SysKonnect Yukon)
  Rev B1 - Marvell 88E8001 (SysKonnect Yukon)
  Rev B2 - Marvell 88E8001-LKJ1 (SysKonnect Yukon)
  Rev C1 - D-Link DLG10028C, a rebadged Realtek RTL8169

The Marvell-based revisions (A/B) used PCI ID 1186:4b01 and were
driven by skge (the SysKonnect/Marvell Yukon driver, originally
sk98lin). The Realtek-based Rev C1 used PCI ID 1186:4302 and
required the r8169 driver.

So the PCI device IDs were actually different across chipset families,
but they shared the same D-Link vendor ID (1186) and identical product
branding.

Driver history and the VPD problem
-----------------------------------

The original SysKonnect vendor driver (sk98lin) had the D-Link
1186:4c00 entry commented out in its PCI table:

  /* DLink card does not have valid VPD so this driver gags
   * { PCI_VENDOR_ID_DLINK, 0x4c00, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
   */

The issue wasn't really that the card had bad VPD — D-Link simply
didn't populate the Vital Product Data fields the way SysKonnect's
own boards did, and sk98lin's probe path depended on reading VPD
during initialization. When skge was written as a clean replacement
for sk98lin, it had no VPD dependency, so the D-Link entry (1186:4c00)
went in unconditionally. The 1186:4b01 entry for Rev B was added
later as users reported it.

When the Rev C1 appeared with a Realtek RTL8169 chip, the 1186:4302
PCI ID was added to both the r8169 driver (by Lennart Sorensen in
commit 93a3aa25933461d, July 2011) and to skge's PCI table. This
meant both modules would match the Rev C1 card, even though skge
could never actually drive it — the probe would bail out when it
read the chip ID and got something that wasn't a Yukon. The result
was that lspci would report "Kernel modules: skge, r8169" for the
C1, which was harmless but untidy.

The bogus 1186:4302 entry has since been removed from skge upstream,
though it's unlikely any DGE-530T cards of any revision still exist
in the wild at this point.

The chipset swap was widely regarded as a cost-cutting move that
degraded performance significantly. The Marvell Yukon was well
respected; the Realtek 8169 was not. Many users and integrators
stopped recommending the DGE-530T after the C1 appeared.