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

[Alexander Jacocks <jjacocks%gmail.com@localhost>]

> On Aug 31, 2025, at 10:26 AM, Jason Thorpe <thorpej%me.com@localhost> wrote:
> 
> 
> 
>> On Aug 31, 2025, at 10:19 AM, Jason Thorpe <thorpej%me.com@localhost> wrote:
> 
> Oh, WAIT.
> 
> I completely overlooked a detail in your “pcictl dump” output (apologies, I just got off a red-eye flight and am still consuming coffee in a futile effort to regain conciousness).
> 
>    Vendor Name: Lite-On Communications (0x11ad)
>    Device Name: 82C115 (PNIC II) 10/100 Ethernet (0xc115)
> 
> So the question you posed at the end of that email:
> 
> <quote>
> If anyone would like to help me, I'd like to submit a patch to add this card 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>
> 
> would seem to not be applicable; no patch should be required, as that combination of vendor ID / product ID is already covered by the existing entry in the compatibility data table:
> 
>  { .id = PCI_ID_CODE(PCI_VENDOR_LITEON, PCI_PRODUCT_LITEON_82C115),
>    .value = TULIP_CHIP_82C115 },
> 
> Can you please confirm that it works as expected with **no patch at all** now that the card edge fingers have been cleaned?
> 
>> 
>> 
>> 
>>>> On Aug 30, 2025, at 1:49 PM, Alexander Jacocks <jjacocks%gmail.com@localhost> wrote:
>>> 
>>> If anyone would like to help me, I'd like to submit a patch to add this card 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.
>> 
>>> { .id = PCI_ID_CODE(PCI_VENDOR_WYSE, PCI_PRODUCT_WYSE_82C115),
>>> .value = TULIP_CHIP_82C115 },
>> 
>> If that addition made it Go(tm), then you pretty much did the right thing.  Looks like WYSE simply re-used LiteOn’s existing PCI device ID, which is completely within their right, since they own their ID namespace.  I don’t think it’s really necessary to define a redundant WYSE version of the product ID.  Can you verify this works for you?
>> 
>> Index: if_tlp_pci.c
>> ===================================================================
>> 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 = PCI_ID_CODE(PCI_VENDOR_LITEON, PCI_PRODUCT_LITEON_82C115),
>>   .value = TULIP_CHIP_82C115 },
>> -
>> + { .id = PCI_ID_CODE(PCI_VENDOR_WYSE, PCI_PRODUCT_LITEON_82C115),
>> +   .value = TULIP_CHIP_82C115 },
>>     { .id = PCI_ID_CODE(PCI_VENDOR_MACRONIX, PCI_PRODUCT_MACRONIX_MX98713),
>> 

Jason,

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

NetBSD!

$ lspci -nn | grep Lite-On
00:0a.0 Ethernet controller [0200]: Lite-On Communications Inc LNE100TX [Linksys 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=0 ttl=55 time=16.560485 ms
64 bytes from 4.2.2.2: icmp_seq=1 ttl=55 time=16.958022 ms
64 bytes from 4.2.2.2: icmp_seq=2 ttl=55 time=14.458263 ms
64 bytes from 4.2.2.2: icmp_seq=3 ttl=55 time=15.559240 ms
64 bytes from 4.2.2.2: icmp_seq=4 ttl=55 time=14.001500 ms

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

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

- Alex