You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
VID, PID and SUBDEV are all unsigned 16bit values (per PCI specification).
As the corresponding struct uses signed 16bit values (on most architectures, implemented as short) and the bdx_get_phy_by_id function uses signed ints (32bit on most architectures) as arguments. This will cause an unintended sign extension e.g. for the "Edimax 10 Gigabit Ethernet SFP+ PCI Express Adapter" which has a subdev ID of 0x8103 (which will get extended to 0xffff8103) thus failing the comparison.
Fixing the struct to use ints instead was successful in our quick and dirty test, however, using u16 everywhere might be cleaner.
The text was updated successfully, but these errors were encountered:
I spend an afternoon digging though the code and found exactly the same issue:
[13177.288528] tn40xx 0000:06:00.0: Comparing [1fc9:4022:8103] with table [1fc9:4022:ffff8103] <-- this test fails
Also, it would more clear if bdx_get_phy_by_id() returned PHY_TYPE_NA instead of 0.
The value would be the same, since PHY_TYPE_NA is the first in the enum list.
And bdx_phy_init() has 4 code paths that can return PHY_TYPE_NA, the first being the call to bdx_get_phy_by_id().
The first 2 paths do the return without mentioning anything in dmesg, making it difficult to differentiate between the two causes.
Testing on an Ubuntu 24.04 machine, before upgrading the Ubuntu 22.04 machine where this card worked fine, with an old driver.
VID, PID and SUBDEV are all unsigned 16bit values (per PCI specification).
As the corresponding struct uses signed 16bit values (on most architectures, implemented as short) and the
bdx_get_phy_by_id
function uses signed ints (32bit on most architectures) as arguments. This will cause an unintended sign extension e.g. for the "Edimax 10 Gigabit Ethernet SFP+ PCI Express Adapter" which has a subdev ID of0x8103
(which will get extended to0xffff8103
) thus failing the comparison.Fixing the struct to use ints instead was successful in our quick and dirty test, however, using u16 everywhere might be cleaner.
The text was updated successfully, but these errors were encountered: