Re: Attempt to Add a New Tulip PNIC2 82C115 NIC Not Working

> On Aug 31, 2025, at 10:26=E2=80=AFAM, Jason Thorpe <[email protected]> wrote:=

>=20
> =EF=BB=BF
>=20
>> On Aug 31, 2025, at 10:19=E2=80=AFAM, Jason Thorpe <[email protected]> wrote=
:
>=20
> Oh, WAIT.
>=20
> I completely overlooked a detail in your =E2=80=9Cpcictl dump=E2=80=9D out=
put (apologies, I just got off a red-eye flight and am still consuming coffe=
e in a futile effort to regain conciousness).
>=20
>    Vendor Name: Lite-On Communications (0x11ad)
>    Device Name: 82C115 (PNIC II) 10/100 Ethernet (0xc115)
>=20
> So the question you posed at the end of that email:
>=20
> <quote>
> If anyone would like to help me, I'd like to submit a patch to add this ca=
rd to the supported NICs. I'm sure that I did something that isn't kosher in=
 the changes that I made, so I'd love advice.
> </quote>
>=20
> would seem to not be applicable; no patch should be required, as that comb=
ination of vendor ID / product ID is already covered by the existing entry i=
n the compatibility data table:
>=20
>  { .id =3D PCI_ID_CODE(PCI_VENDOR_LITEON, PCI_PRODUCT_LITEON_82C115),
>    .value =3D TULIP_CHIP_82C115 },
>=20
> Can you please confirm that it works as expected with **no patch at all** n=
ow that the card edge fingers have been cleaned?
>=20
>>=20
>>=20
>>=20
>>>> On Aug 30, 2025, at 1:49=E2=80=AFPM, Alexander Jacocks <jjacocks@gmail.=
com> wrote:
>>>=20
>>> If anyone would like to help me, I'd like to submit a patch to add this c=
ard to the supported NICs. I'm sure that I did something that isn't kosher i=
n the changes that I made, so I'd love advice.
>>=20
>>> { .id =3D PCI_ID_CODE(PCI_VENDOR_WYSE, PCI_PRODUCT_WYSE_82C115),
>>> .value =3D TULIP_CHIP_82C115 },
>>=20
>> If that addition made it Go(tm), then you pretty much did the right thing=
.  Looks like WYSE simply re-used LiteOn=E2=80=99s existing PCI device ID, w=
hich is completely within their right, since they own their ID namespace.  I=
 don=E2=80=99t think it=E2=80=99s really necessary to define a redundant WYS=
E version of the product ID.  Can you verify this works for you?
>>=20
>> Index: if_tlp_pci.c
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> RCS file: /cvsroot/src/sys/dev/pci/if_tlp_pci.c,v
>> retrieving revision 1.131
>> diff -u -p -r1.131 if_tlp_pci.c
>> --- if_tlp_pci.c 20 Dec 2023 04:32:30 -0000 1.131
>> +++ if_tlp_pci.c 31 Aug 2025 14:17:48 -0000
>> @@ -132,10 +132,14 @@ static const struct device_compatible_en
>> /*
>> * Note: This is like a MX98725 with Wake-On-LAN and a
>> * 128-bit multicast hash table.
>> + *
>> + * This device also appears with a WYSE vendor ID and the regular
>> + * LITEON 82C115 product ID.
>> */
>> { .id =3D PCI_ID_CODE(PCI_VENDOR_LITEON, PCI_PRODUCT_LITEON_82C115),
>>   .value =3D TULIP_CHIP_82C115 },
>> -
>> + { .id =3D PCI_ID_CODE(PCI_VENDOR_WYSE, PCI_PRODUCT_LITEON_82C115),
>> +   .value =3D TULIP_CHIP_82C115 },
>>     { .id =3D PCI_ID_CODE(PCI_VENDOR_MACRONIX, PCI_PRODUCT_MACRONIX_MX987=
13),
>>=20

Jason,

Yes, it actually does! I had not noticed that cleaning the PCI contacts chan=
ged the PCI ID.

NetBSD!

$ lspci -nn | grep Lite-On
00:0a.0 Ethernet controller [0200]: Lite-On Communications Inc LNE100TX [Lin=
ksys EtherFast 10/100] [11ad:c115] (rev 25)
$ ping -c5 4.2.2.2
PING b.resolvers.level3.net (4.2.2.2): 56 data bytes
64 bytes from 4.2.2.2: icmp_seq=3D0 ttl=3D55 time=3D16.560485 ms
64 bytes from 4.2.2.2: icmp_seq=3D1 ttl=3D55 time=3D16.958022 ms
64 bytes from 4.2.2.2: icmp_seq=3D2 ttl=3D55 time=3D14.458263 ms
64 bytes from 4.2.2.2: icmp_seq=3D3 ttl=3D55 time=3D15.559240 ms
64 bytes from 4.2.2.2: icmp_seq=3D4 ttl=3D55 time=3D14.001500 ms

----b.resolvers.level3.net PING Statistics----
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev =3D 14.001500/15.507502/16.958022/1.283005 ms

Sorry for the waste of bandwidth, and thanks for the help!

- Alex