The laptop's NIC is an RTL8111H, and the request was to add it to LDLS.
Measuring it is what changed the answer, so the measurement is the commit
message: r8169.ko (6.18.52) has **183 undefined symbols, 130 of them not
implemented by ldls/kpi/, and 35 of those 130 are phylib** --
phy_connect_direct, phy_start, mdiobus_read, genphy_soft_reset and the rest.
phylib is a subsystem with a link state machine, not a set of leaf calls, and
LDLS's usual answer for an unimplemented symbol -- a stub that reports itself
and returns zero -- is exactly wrong for it. phy_start returning zero means the
link never comes up and there is nothing to look at. The 8139too that ldls.md
uses as its model has no phylib dependency, which is why that one was
tractable and this one is not.
So: a native driver. It reaches the PHY through the chip's own MII window --
PHYAR is one register that is a whole MII bus -- and skips the subsystem. Less
work than the port, no GPL entanglement, no firmware blob, no coupling to one
Linux version, and it covers the whole RTL8111/8168 family because all of it
answers to 10EC:8168. The register layout is a fact about the hardware, taken
the way ldls.md section 3 says facts may be taken; the expression is this
tree's, in the same shape as the e1000 beside it.
**It has not run on hardware, and that is not a hedge.** QEMU emulates rtl8139
and nothing else from Realtek, and the 8139 is a different programming model --
a circular receive buffer rather than descriptors -- so it is deliberately not
in the match table. What is verified: it builds, its presence changes nothing
on a machine without the device, and with an rtl8139 on the bus it correctly
leaves it unclaimed. What is not: every register write, on a real part.
The probe therefore says everything a first bug report needs, with cprintf
rather than kinfo so it reaches the screen of a machine with no serial port:
r8169: xid 5c0, 1c:1b:b5:xx:xx:xx, irq 11, link up (bmsr 796d)
xid is the hardware version from the top of TxConfig -- the PCI device id has
been 8168 for twenty years and says nothing. bmsr is MII register 1: bit 2 is
link, bit 5 is autonegotiation complete. Those four facts separate "the chip is
not there" from "the PHY sees nothing" from "the rings are wrong".
Two constants were wrong in the first draft and are recorded because both would
have worked quietly. RxConfig had 0x7700 for "unlimited": MXDMA is bits 8-10
and RXFTH is bits 13-15, so that was one bit short of a full burst and a
half-full FIFO threshold. And CPCR bit 3 was being set under a comment calling
it "PCI multiple read/write" -- bit 3 is PCIDAC, 64-bit addressing, and bit 4
is what the comment described; neither is wanted, so the write is gone.
Both supported configurations: one boot each, no traps, no panics, socktest and
memfdtest green.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
125 lines
4.8 KiB
C
125 lines
4.8 KiB
C
// The driver registry.
|
|
//
|
|
// One table, one line per driver. This is the same shape as
|
|
// kernel/sys/table.inc and kernel/dev/cdev.c's devsw: a single place that
|
|
// lists what exists, so a driver cannot be half-registered.
|
|
//
|
|
// It is a plain array rather than the linker-section trick a bigger kernel
|
|
// would use (a __attribute__((section(".drivers"))) entry per driver, walked
|
|
// between __start_ and __stop_ symbols). That approach lets a driver register
|
|
// itself by existing, which is genuinely nicer -- but it also means the list
|
|
// of what is in your kernel is not written down anywhere you can read, and
|
|
// a driver silently dropped by the linker looks exactly like one that was
|
|
// never written. At this size, being able to read the list wins.
|
|
//
|
|
// To add a driver: write kernel/drivers/<name>.c exporting a struct
|
|
// pci_driver, declare it here, and add it to the array and to the Makefile's
|
|
// KERN_DRIVERS.
|
|
|
|
#include "types.h"
|
|
#include "defs.h"
|
|
#include "param.h"
|
|
#include "spinlock.h"
|
|
#include "sleeplock.h"
|
|
#include "fs.h"
|
|
#include "file.h"
|
|
#include "pci.h"
|
|
|
|
#include "usb.h"
|
|
#include "device.h"
|
|
|
|
extern const struct pci_driver vga_pci_driver;
|
|
extern const struct pci_driver xhci_driver;
|
|
extern const struct pci_driver virtio_gpu_driver;
|
|
extern const struct pci_driver e1000_driver;
|
|
extern const struct pci_driver ac97_driver;
|
|
extern const struct pci_driver r8169_driver;
|
|
|
|
// Order matters here in one respect: virtio-gpu is offered the bus before the
|
|
// VBE framebuffer driver, so that on a machine with both, the device with real
|
|
// mode setting and an explicit flush wins the display class. vga_pci still
|
|
// claims the stdvga card underneath, which is what the boot splash and the
|
|
// text console are drawn on.
|
|
static const struct pci_driver *drivers[] = {
|
|
&virtio_gpu_driver,
|
|
&vga_pci_driver,
|
|
&e1000_driver,
|
|
&r8169_driver,
|
|
&xhci_driver,
|
|
&ac97_driver,
|
|
};
|
|
|
|
void
|
|
pci_bind_all(void)
|
|
{
|
|
for (unsigned i = 0; i < sizeof(drivers) / sizeof(drivers[0]); i++)
|
|
pci_bind(drivers[i]);
|
|
}
|
|
|
|
// USB class drivers, same arrangement and for the same reason. These are not
|
|
// found on the PCI bus -- they are offered a device by the USB core once its
|
|
// interface descriptor has been read -- but a driver you cannot find in a
|
|
// list is a driver nobody knows is there, whichever bus it sits on.
|
|
//
|
|
// To add one: write kernel/drivers/usb_<name>.c exporting a struct
|
|
// usb_driver, declare it here, add it to the array and to KERN_DRIVERS.
|
|
|
|
extern const struct usb_driver usb_hid_driver;
|
|
extern const struct usb_driver usb_storage_driver;
|
|
extern const struct usb_driver usb_hub_driver;
|
|
|
|
static const struct usb_driver *usb_drivers[] = {
|
|
&usb_hid_driver,
|
|
&usb_storage_driver,
|
|
&usb_hub_driver,
|
|
};
|
|
|
|
int usb_offer(const struct usb_driver *, struct usb_dev *);
|
|
|
|
void
|
|
usb_bind_all(struct usb_dev *dev)
|
|
{
|
|
for (unsigned i = 0; i < sizeof(usb_drivers) / sizeof(usb_drivers[0]); i++)
|
|
if (usb_offer(usb_drivers[i], dev)) {
|
|
// Same as the PCI path: publish it in the bus-agnostic list so that
|
|
// "what is attached" has one answer covering every bus. Class comes from
|
|
// the driver that claimed it rather than the USB class code, because a
|
|
// driver knows what it made of the device and the descriptor only says
|
|
// what the device claims to be.
|
|
const char *n = usb_drivers[i]->name;
|
|
struct device *d = device_add(n, DEVBUS_USB, usb_drivers[i]->devclass, n);
|
|
if (d)
|
|
device_set_desc(d, usb_drivers[i]->name);
|
|
return;
|
|
}
|
|
}
|
|
|
|
// Devices that are not enumerated by any bus -- they are simply known to be
|
|
// there on a PC, and the driver pokes fixed I/O ports to find out whether it
|
|
// is right. Listing them matters because a device manager that shows the
|
|
// graphics card but not the keyboard is not showing the machine.
|
|
//
|
|
// Registered here rather than inside each driver's init so that the whole set
|
|
// is visible in one place, which is the same reasoning as the driver arrays
|
|
// above.
|
|
void
|
|
platform_register_devices(uint64 fb_addr)
|
|
{
|
|
struct device *d;
|
|
|
|
// The framebuffer first, before anything that might want to draw. It is a
|
|
// driver call, and this file is where driver names belong -- main() used to
|
|
// call vga_init() directly, which put one display driver's name in the
|
|
// kernel's startup path and would have needed editing to boot on a machine
|
|
// whose framebuffer came from anywhere else.
|
|
vga_fb_init(fb_addr);
|
|
|
|
if ((d = device_add("kbd", DEVBUS_PLATFORM, DEVCLASS_INPUT, "ps2kbd")))
|
|
device_set_desc(d, "PS/2 keyboard");
|
|
if ((d = device_add("mouse", DEVBUS_PLATFORM, DEVCLASS_INPUT, "ps2mouse")))
|
|
device_set_desc(d, "PS/2 mouse");
|
|
if ((d = device_add("uart", DEVBUS_PLATFORM, DEVCLASS_OTHER, "uart8250")))
|
|
device_set_desc(d, "16550 serial port");
|
|
if ((d = device_add("ide", DEVBUS_PLATFORM, DEVCLASS_STORAGE, "ide")))
|
|
device_set_desc(d, "ATA disk controller");
|
|
}
|