My Inspiron 14 Plus laptop runs openSUSE Leap 15.5, and I wanted to know which drivers handle its two network connections:

  • Wi-Fi
  • Wired Ethernet through a USB adapter

The built-in Wi-Fi

The Wi-Fi device is built in, so I expected to find it on the PCIe bus:

yinspiron:~ # lspci
0000:00:00.0 Host bridge: Intel Corporation Device a706
0000:00:01.0 PCI bridge: Intel Corporation Device a70d
0000:00:02.0 VGA compatible controller: Intel Corporation Raptor Lake-P [Iris Xe Graphics] (rev 04)
0000:00:04.0 Signal processing controller: Intel Corporation Device a71d
0000:00:06.0 System peripheral: Intel Corporation RST VMD Managed Controller
0000:00:07.0 PCI bridge: Intel Corporation Device a76e
0000:00:08.0 System peripheral: Intel Corporation GNA Scoring Accelerator module
0000:00:0d.0 USB controller: Intel Corporation Device a71e
0000:00:0d.2 USB controller: Intel Corporation Device a73e
0000:00:0e.0 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller Intel Corporation
0000:00:12.0 Serial controller: Intel Corporation Alder Lake-P Integrated Sensor Hub (rev 01)
0000:00:14.0 USB controller: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host Controller (rev 01)
0000:00:14.2 RAM memory: Intel Corporation Alder Lake PCH Shared SRAM (rev 01)
0000:00:14.3 Network controller: Intel Corporation Device 51f1 (rev 01)
0000:00:15.0 Serial bus controller: Intel Corporation Alder Lake PCH Serial IO I2C Controller #0 (rev 01)
0000:00:15.1 Serial bus controller: Intel Corporation Alder Lake PCH Serial IO I2C Controller #1 (rev 01)
0000:00:16.0 Communication controller: Intel Corporation Alder Lake PCH HECI Controller (rev 01)
0000:00:1f.0 ISA bridge: Intel Corporation Device 519d (rev 01)
0000:00:1f.3 Multimedia audio controller: Intel Corporation Device 51ca (rev 01)
0000:00:1f.4 SMBus: Intel Corporation Alder Lake PCH-P SMBus Host Controller (rev 01)
0000:00:1f.5 Serial bus controller: Intel Corporation Alder Lake-P PCH SPI Controller (rev 01)
0000:01:00.0 VGA compatible controller: NVIDIA Corporation AD107M [GeForce RTX 4050 Max-Q / Mobile] (rev a1)
0000:01:00.1 Audio device: NVIDIA Corporation Device 22be (rev a1)
10000:e0:06.0 PCI bridge: Intel Corporation Device a74d
10000:e1:00.0 Non-Volatile memory controller: SK hynix Device 1d59 (rev 03)
yinspiron:~ #

The network controller is easy to spot:

0000:00:14.3 Network controller: Intel Corporation Device 51f1 (rev 01)

Its MSI IRQs are exposed through sysfs:

yinspiron:~ # ls /sys/bus/pci/devices/0000:00:14.3/msi_irqs
181  182  183  184  185  186  187  188  189  190  191  192  193  194  195  196
yinspiron:~ #

From IRQ to driver

The irq command in the crash utility can find the struct irqaction for a given IRQ. That structure contains the IRQ handler address, which sym can translate into a function name and kernel module.

Of course, crash needs the debug information for the running kernel. I picked IRQ 181 from the list above:

yinspiron:~ # crash

...
WARNING: kernel relocated [634MB]: patching 120049 gdb minimal_symbol values

      KERNEL: /boot/vmlinux-5.14.21-150500.55.28-default.gz  [TAINTED]
  DEBUGINFO: /usr/lib/debug/boot/vmlinux-5.14.21-150500.55.28-default.debug
    DUMPFILE: /proc/kcore
        CPUS: 20
        DATE: Thu Aug 22 12:34:25 CST 2024
      UPTIME: 108 days, 18:33:17
LOAD AVERAGE: 1.00, 0.60, 0.38
      TASKS: 2634
    NODENAME: yinspiron
    RELEASE: 5.14.21-150500.55.28-default
    VERSION: #1 SMP PREEMPT_DYNAMIC Fri Sep 22 10:04:29 UTC 2023 (c11336f)
    MACHINE: x86_64  (2900 Mhz)
      MEMORY: 31.7 GB
        PID: 31342
    COMMAND: "crash"
        TASK: ffff968eea1e28c0  [THREAD_INFO: ffff968eea1e28c0]
        CPU: 4
      STATE: TASK_RUNNING (ACTIVE)

crash> irq 181
IRQ  IRQ_DESC/_DATA      IRQACTION      NAME
181  ffff968c87dd2c00  ffff968ca2024200  "iwlwifi:default_queue"
crash> struct irqaction ffff968ca2024200
struct irqaction {
  handler = 0xffffffffc150e890,
  dev_id = 0xffff968e81fda9a8,
  percpu_dev_id = 0x0,
  next = 0x0,
  thread_fn = 0xffffffffc150d810,
  thread = 0xffff968c83f028c0,
  secondary = 0x0,
  irq = 181,
  flags = 128,
  thread_flags = 16,
  thread_mask = 0,
  name = 0xffffffffc1540328 "iwlwifi:default_queue",
  dir = 0xffff968c82997a40
}
crash> sym 0xffffffffc150e890
ffffffffc150e890 (T) iwl_pcie_msix_isr [iwlwifi]
crash> q

The IRQ belongs to iwl_pcie_msix_isr in the iwlwifi module. The module list shows that iwlmvm is loaded too:

yinspiron:~ # lsmod | grep iwlwifi
iwlwifi              405504  1 iwlmvm
cfg80211            1052672  3 iwlmvm,iwlwifi,mac80211

iwlwifi owns the PCIe transport and interrupt handling, while iwlmvm provides the device-specific MAC operations and depends on iwlwifi. The driver here is iwlwifi, not iwlmvm.

The USB Ethernet adapter

The wired connection uses an external USB adapter, so its IRQ does not belong to a PCI network controller in the same way as the built-in Wi-Fi. But there is a much easier tool for finding its driver: ethtool.

First, list the network configuration files:

yinspiron:~ # ls /etc/sysconfig/network
config  if-down.d  ifcfg-eth0  ifcfg-wlan0    ifroute-eth0            providers  routes.YaST2save
dhcp    if-up.d    ifcfg-lo    ifcfg.template  ifroute-wlan0.YaST2save  routes    scripts

Then ask the interface about itself:

yinspiron:~ # ethtool -i eth0
driver: r8152
version: v1.12.13
firmware-version: rtl8153b-2 v2 04/27/23
expansion-rom-version:
bus-info: usb-0000:00:0d.0-1.2
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
yinspiron:~ #

The USB adapter uses the r8152 driver. As a bonus, ethtool can also answer the Wi-Fi question without archaeology in a kernel crash dump:

yinspiron:~ # ethtool -i wlan0
driver: iwlwifi
version: 5.14.21-150500.55.28-default
firmware-version: 72.a764baac.0 so-a0-gf-a0-72.uc
expansion-rom-version:
bus-info: 0000:00:14.3
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
yinspiron:~ #

So the final score is iwlwifi for Wi-Fi and r8152 for the USB Ethernet adapter. Inspecting the IRQ path was useful for understanding how the hardware, the PCIe device, and the driver connect, but ethtool -i wins when I only need the driver name.