The PCI specification covers most issues related to computer interfaces. We are not going to cover it all here; in this section we are mainly concerned with how a PCI driver can find its hardware and gain access to it. The probing techniques discussed in "Automatic and Manual Configuration" in Chapter 2, "Building and Running Modules", and "Autodetecting the IRQ Number" in Chapter 9, "Interrupt Handling" can be used with PCI devices, but the specification offers a preferable alternative to probing.

The PCI architecture was designed as a replacement for the ISA standard, with three main goals: to get better performance when transferring data between the computer and its peripherals, to be as platform independent as possible, and to simplify adding and removing peripherals to the system.

What is most relevant to the driver writer, however, is the support for autodetection of interface boards. PCI devices are jumperless (unlike most older peripherals) and are automatically configured at boot time. The device driver, then, must be able to access configuration information in the device in order to complete initialization. This happens without the need to perform any probing.

PCI Addressing

For example, /proc/bus/pci/devices uses a single 16-bit field (to ease parsing and sorting), while /proc/bus/ busnumbersplits the address into three fields. The following shows how those addresses appear, showing only the beginning of the output lines:

rudo% 
lspci | cut -d: -f1-2
 00:00.0 Host bridge 00:01.0 PCI bridge 00:07.0 ISA bridge 00:07.1 IDE interface 00:07.3 Bridge 00:07.4 USB Controller 00:09.0 SCSI storage controller 00:0b.0 Multimedia video controller 01:05.0 VGA compatible controller rudo% 
cat /proc/bus/pci/devices | cut -d\        -f1,3
 0000    0 0008    0 0038    0 0039    0 003b    0 003c    b 0048    a 0058    b 0128    a 

The two lists of devices are sorted in the same order, since lspci uses the /procfiles as its source of information. Taking the VGA video controller as an example, 0x128 means 01:05.0 when split into bus (eight bits), device (five bits) and function (three bits). The second field in the two listings shown shows the class of device and the interrupt number, respectively.

As far as the driver is concerned, memory and I/O regions are accessed in the usual ways via inb, readb, and so forth. Configuration transactions, on the other hand, are performed by calling specific kernel functions to access configuration registers. With regard to interrupts, every PCI slot has four interrupt pins, and each device function can use one of them without being concerned about how those pins are routed to the CPU. Such routing is the responsibility of the computer platform and is implemented outside of the PCI bus. Since the PCI specification requires interrupt lines to be shareable, even a processor with a limited number of IRQ lines, like the x86, can host many PCI interface boards (each with four interrupt pins).

It should be clear from this description that the main innovation of the PCI interface standard over ISA is the configuration address space. Therefore, in addition to the usual driver code, a PCI driver needs the ability to access configuration space, in order to save itself from risky probing tasks.

Boot Time

When power is applied to a PCI device, the hardware remains inactive. In other words, the device will respond only to configuration transactions. At power on, the device has no memory and no I/O ports mapped in the computer's address space; every other device-specific feature, such as interrupt reporting, is disabled as well.

At system boot, the firmware (or the Linux kernel, if so configured) performs configuration transactions with every PCI peripheral in order to allocate a safe place for any address region it offers. By the time a device driver accesses the device, its memory and I/O regions have already been mapped into the processor's address space. The driver can change this default assignment, but it will never need to do that.

Configuration Registers and Initialization

PCI devices feature a 256-byte address space. The first 64 bytes are standardized, while the rest are device dependent. Figure 15-2 shows the layout of the device-independent configuration space.

As the figure shows, some of the PCI configuration registers are required and some are optional. Every PCI device must contain meaningful values in the required registers, whereas the contents of the optional registers depend on the actual capabilities of the peripheral. The optional fields are not used unless the contents of the required fields indicate that they are valid. Thus, the required fields assert the board's capabilities, including whether the other fields are usable or not.

Describing all the configuration items is beyond the scope of this book. Usually, the technical documentation released with each device describes the supported registers. What we're interested in is how a driver can look for its device and how it can access the device's configuration space.

Three or five PCI registers identify a device: vendorID, deviceID, and class are the three that are always used. Every PCI manufacturer assigns proper values to these read-only registers, and the driver can use them to look for the device. Additionally, the fields subsystem vendorID and subsystem deviceID are sometimes set by the vendor to further differentiate similar devices.

Let's look at these registers in more detail.

Based on this information, initialization for a typical device driver that handles a single device type will look like the following code. The code is for a hypothetical device jail and is Just Another Instruction List:

 #ifndef CONFIG_PCI #  error "This driver needs PCI support to be available" #endif  int jail_find_all_devices(void) {     struct pci_dev *dev = NULL;     int found;      if (!pci_present())     return -ENODEV;      for (found=0; found < JAIL_MAX_DEV;) {         dev = pci_find_device(JAIL_VENDOR, JAIL_ID, dev);         if (!dev) /* no more devices are there */             break;         /* do device-specific actions and count the device */         found += jail_init_one(dev);     }     return  (index == 0) ? -ENODEV : 0; } 

The role of jail_init_one is very device specific and thus not shown here. There are, nonetheless, a few things to keep in mind when writing that function:

• The function may need to perform additional probing to ensure that the device is really one of those it supports. Some PCI peripherals contain a general-purpose PCI interface chip and device-specific circuitry. Every peripheral board that uses the same interface chip has the same signature. Further probing can either be performed by reading the subsystem identifiers or reading specific device registers (in the device I/O regions, introduced later).

• Before accessing any device resource (I/O region or interrupt), the driver must call pci_enable_device. If the additional probing just discussed requires accessing device I/O or memory space, the function must be called before such probing takes place.

• A network interface driver should make dev->driver_data point to the struct net_device associated with this interface.

The function shown in the previous code excerpt returns 0 if it rejects the device and 1 if it accepts it (possibly based on the further probing just described).

The code excerpt shown is correct if the driver deals with only one kind of PCI device, identified by JAIL_VENDOR and JAIL_ID. If you need to support more vendor/device pairs, your best bet is using the technique introduced later in "Hardware Abstractions", unless you need to support older kernels than 2.4, in which case pci_find_class is your friend.

 struct devid {unsigned short vendor, device} devlist[] = {     {JAIL_VENDOR1, JAIL_DEVICE1},     {JAIL_VENDOR2, JAIL_DEVICE2},     /* ... */     { 0, 0 } };      /* ... */      for (found=0; found < JAIL_MAX_DEV;) {         struct devid *idptr;         dev = pci_find_class(JAIL_CLASS, dev);         if (!dev) /* no more devices are there */             break;         for (idptr = devlist; idptr->vendor; idptr++) {            if (dev->vendor != idptr->vendor) continue;            if (dev->device != idptr->device) continue;            break;         } 	if (!idptr->vendor) continue; /* not one of ours */         jail_init_one(dev); /* device-specific initialization */ 	found++;     }  

Accessing the Configuration Space

Because the microprocessor has no way to access the configuration space directly, the computer vendor has to provide a way to do it. To access configuration space, the CPU must write and read registers in the PCI controller, but the exact implementation is vendor dependent and not relevant to this discussion because Linux offers a standard interface to access the configuration space.

The best way to address the configuration variables using the pci_read_ functions is by means of the symbolic names defined in <linux/pci.h>. For example, the following two-line function retrieves the revision ID of a device by passing the symbolic name for where to pci_read_config_byte:

 unsigned char jail_get_revision(unsigned char bus, unsigned char fn) {     unsigned char *revision;      pci_read_config_byte(bus, fn, PCI_REVISION_ID, &revision);     return revision; } 

As suggested, when accessing multibyte values as single bytes the programmer must remember to watch out for byte-order problems.

Looking at a configuration snapshot

For example, our frame grabber appears fifth in /proc/pcidata and (currently) has the following configuration registers:

morgana% 
dd bs=256 skip=4 count=1 if=/proc/pcidata | od -Ax -t x1
 1+0 records in 1+0 records out 000000 86 80 23 12 06 00 00 02 00 00 00 04 00 20 00 00 000010 00 00 00 f1 00 00 00 00 00 00 00 00 00 00 00 00 000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000030 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00 000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 000100 

The pcidump code is not worth including here because the program is simply a long table, plus 10 lines of code that scan the table. Instead, let's look at some selected output lines:

morgana% 
dd bs=256 skip=4 count=1 if=/proc/pcidata | ./pcidump
 1+0 records in 1+0 records out         Compulsory registers: Vendor id: 8086 Device id: 1223 I/O space enabled: n Memory enabled: y Master enabled: y Revision id (decimal): 0 Programmer Interface: 00 Class of device: 0400 Header type: 00 Multi function device: n         Optional registers: Base Address 0: f1000000 Base Address 0 Is I/O: n Base Address 0 is 64-bits: n Base Address 0 is below-1M: n Base Address 0 is prefetchable: n Does generate interrupts: y Interrupt line (decimal): 10 Interrupt pin (decimal): 1 

Accessing the I/O and Memory Spaces

PCI I/O resources in Linux 2.4

Resource flags are used to define some features of the individual resource. For PCI resources associated with PCI I/O regions, the information is extracted from the base address registers, but can come from elsewhere for resources not associated with PCI devices.

All resource flags are defined in <linux/ioport.h>; the most important of them are listed here.

By making use of the pci_resource_ functions, a device driver can completely ignore the underlying PCI registers, since the system already used them to structure resource information.

Peeking at the base address registers

In this section we look at how base address registers behave and how they can be accessed. All of this is obviously superfluous if you can exploit resource management as shown previously.

We won't go into much detail here about the base address registers, because if you're going to write a PCI driver, you will need the hardware manual for the device anyway. In particular, we are not going to use either the prefetchable bit or the two "type'' bits of the registers, and we'll limit the discussion to 32-bit peripherals. It's nonetheless interesting to see how things are usually implemented and how Linux drivers deal with PCI memory.

The actual implementation and use of a programmable decoder is simplified by the fact that usually the number of bytes in a region is a power of two, for example, 32 bytes, 4 KB, or 2 MB. Moreover, it wouldn't make much sense to map a region to an unaligned address; 1 MB regions naturally align at an address that is a multiple of 1 MB, and 32-byte regions at a multiple of 32. The PCI specification exploits this alignment; it states that the address decoder must look only at the high bits of the address bus and that only the high bits are programmable. This convention also means that the size of any region must be a power of two.

This "partial decoding'' technique has the additional advantage that the software can determine the size of a PCI region by checking the number of nonprogrammable bits in the configuration register. To this end, the PCI standard states that unused bits must always read as 0. By imposing a minimum size of 8 bytes for I/O regions and 16 bytes for memory regions, the standard can fit some extra information into the low bits of the base address registers:

• Bit 0 is the "space'' bit. It is set to 0 if the region maps to the memory address space, and 1 if it maps to the I/O address space.

• Bits 1 and 2 are the "type'' bits: memory regions can be marked as 32-bit regions, 64-bit regions, or "32-bit regions that must be mapped below 1 MB'' (an obsolete x86-specific idea, now unused).

• Bit 3 is the "prefetchable'' bit, used for memory regions.

It's apparent from whence information for the resource flags comes.

  static u32 addresses[] = {     PCI_BASE_ADDRESS_0,     PCI_BASE_ADDRESS_1,     PCI_BASE_ADDRESS_2,     PCI_BASE_ADDRESS_3,     PCI_BASE_ADDRESS_4,     PCI_BASE_ADDRESS_5,     0 };  int pciregions_read_proc(char *buf, char **start, off_t offset,                    int len, int *eof, void *data) {     /* this macro helps in keeping the following lines short */ #define PRINTF(fmt, args...) sprintf(buf+len, fmt, ## args)     len=0;      /* Loop through the devices (code not printed in the book) */          /* Print the address regions of this device */         for (i=0; addresses[i]; i++) {             u32 curr, mask, size;             char *type;              pci_read_config_dword(dev, addresses[i],&curr);             cli();             pci_write_config_dword(dev, addresses[i],~0);             pci_read_config_dword(dev, addresses[i],&mask);             pci_write_config_dword(dev, addresses[i],curr);             sti();              if (!mask) 		continue; /* there may be other regions */  	    /* 	     * apply the I/O or memory mask to current position. 	     * note that I/O is limited to 0xffff, and 64-bit is not 	     * supported by this simple implementation 	     */ 	    if (curr & PCI_BASE_ADDRESS_SPACE_IO) { 		curr &= PCI_BASE_ADDRESS_IO_MASK; 	    } else { 		curr &= PCI_BASE_ADDRESS_MEM_MASK; 	    } 		             len += PRINTF("\tregion %i: mask 0x%08lx, now at 0x%08lx\n",                         i, (unsigned long)mask,                            (unsigned long)curr);             /* extract the type, and the programmable bits */             if (mask & PCI_BASE_ADDRESS_SPACE_IO) {                 type = "I/O"; mask &= PCI_BASE_ADDRESS_IO_MASK; 		size = (~mask + 1) & 0xffff; /* Bleah */             } else {                 type = "mem"; mask &= PCI_BASE_ADDRESS_MEM_MASK; 		size = ~mask + 1;             }             len += PRINTF("\tregion %i: type %s, size %i (%i%s)\n", i,                           type, size, 			  (size & 0xfffff) == 0 ? size >> 20 : 			    (size & 0x3ff) == 0 ? size >> 10 : size, 			  (size & 0xfffff) == 0 ? "MB" : 			    (size & 0x3ff) == 0 ? "KB" : "B"); 	    if (len > PAGE_SIZE / 2) { 		len += PRINTF("... more info skipped ...\n"); 		*eof = 1; return len; 	    }         }     return len; } 

Here, for example, is what /proc/pciregionsreports for our frame grabber:

 Bus 0, device 13, fun  0 (id 8086-1223)         region 0: mask 0xfffff000, now at 0xf1000000         region 0: type mem, size 4096 (4KB) 

It's interesting to note that the memory size reported by the program just listed can be overstated. For instance, /proc/pciregions reported that a video device had 16 MB of memory when it actually had only 1. This lie is acceptable because the size information is used only by the firmware to allocate address ranges; region oversizing is not a problem for the driver writer who knows the internals of the device and can correctly deal with the address range assigned by the firmware. In this case, device RAM could be added later without the need to change the behavior of PCI registers while upgrading the RAM.

PCI Interrupts

If the device doesn't support interrupts, register 61 (PCI_INTERRUPT_PIN) is 0; otherwise, it's nonzero. However, since the driver knows if its device is interrupt driven or not, it doesn't usually need to read PCI_INTERRUPT_PIN.

Thus, PCI-specific code for dealing with interrupts just needs to read the configuration byte to obtain the interrupt number that is saved in a local variable, as shown in the following code. Otherwise, the information in Chapter 9, "Interrupt Handling" applies.

 result = pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &myirq); if (result) { /* deal with error */ } 

The rest of this section provides additional information for the curious reader, but isn't needed for writing drivers.

A PCI connector has four interrupt pins, and peripheral boards can use any or all of them. Each pin is individually routed to the motherboard's interrupt controller, so interrupts can be shared without any electrical problems. The interrupt controller is then responsible for mapping the interrupt wires (pins) to the processor's hardware; this platform-dependent operation is left to the controller in order to achieve platform independence in the bus itself.

The read-only configuration register located at PCI_INTERRUPT_PIN is used to tell the computer which single pin is actually used. It's worth remembering that each device board can host up to eight devices; each device uses a single interrupt pin and reports it in its own configuration register. Different devices on the same device board can use different interrupt pins or share the same one.

The PCI_INTERRUPT_LINE register, on the other hand, is read/write. When the computer is booted, the firmware scans its PCI devices and sets the register for each device according to how the interrupt pin is routed for its PCI slot. The value is assigned by the firmware because only the firmware knows how the motherboard routes the different interrupt pins to the processor. For the device driver, however, the PCI_INTERRUPT_LINE register is read-only. Interestingly, recent versions of the Linux kernel under some circumstances can assign interrupt lines without resorting to the BIOS.

Handling Hot-Pluggable Devices

The basic idea being exploited is that whenever a new device appears during the system's lifetime, all available device drivers must check whether the new device is theirs or not. Therefore, instead of using the classic init and cleanupentry points for the driver, the hot-plug-aware device driver must register an object with the kernel, and the probefunction for the object will be asked to check any device in the system to take hold of it or leave it alone.

This approach has no downside: the usual case of a static device list is handled by scanning the device list once for each device at system boot; modularized drivers will just unload as usual if no device is there, and an external process devoted to monitoring the bus will arrange for them to be loaded if the need arises. This is exactly how the PCMCIA subsystem has always worked, and having it integrated in the kernel proper allows for more coherent handling of similar issues with different hardware environments.

While you may object that hot-pluggable PCI is not common these days, the new driver-object technique proves very useful even for non-hot-plug drivers that must handle a number of alternative devices. The initialization code is simplified and streamlined because it just needs to check the current device against a list of known devices, instead of actively searching the PCI bus by looping once around pci_find_class or looping several times around pci_find_device.

 struct pci_driver hppm_driver = { /* .... */ };  int hppm_init_module(void) {     return pci_module_init(&hppm_driver); }  int hppm_cleanup_module(void) {     pci_unregister_driver(&hppm_driver); }  module_init(hppm); module_exit(hppm); 

That's all. It's incredibly easy. The hidden magic is split between the implementation of pci_module_init and the internals of the driver structure. We'd better follow a top-down path and start by introducing the relevant functions:

The pci_driver structure

The PCI driver object is quite straightforward and a pleasure to use. We think there's little to add to the field enumeration, because normal hardware-handling code fits well in this abstraction without the need to tweak it in any way.

unsigned int vendor, device;

The vendor and device IDs of the device this driver is interested in. The values are matched against registers 0x00 and 0x02 of the PCI configuration space.

unsigned int subvendor, subdevice;

The sub-IDs, matched against registers 0x2C and 0x2E of the PCI configuration space. They are used in matching the device because sometimes a vendor/device ID pair identifies a group of devices and the driver can only work with a few items in the group.

unsigned int class, class_mask;

If the device driver wants to deal with an entire class or a subset thereof, it can set the previous fields to PCI_ANY_ID and use class identifiers instead. The class_mask is present to allow both for drivers that want to deal with a base class and for drivers that are only interested in a subclass. If device selection is performed using vendor/device identifiers, both these fields must be set to 0 (not to PCI_ANY_ID, since the check is performed through a logical AND with the mask field).

unsigned long driver_data;

A field left for use by the device driver. It can, for example, differentiate between the various devices at compilation time, avoiding tedious arrays of conditional tests at runtime.

Hardware Abstractions

The mechanism used to implement hardware abstraction is the usual structure containing methods. It's a powerful technique that adds just the minimal overhead of dereferencing a pointer to the normal overhead of a function call. In the case of PCI management, the only hardware-dependent operations are the ones that read and write configuration registers, because everything else in the PCI world is accomplished by directly reading and writing the I/O and memory address spaces, and those are under direct control of the CPU.

 struct pci_ops {     int (*read_byte)(struct pci_dev *, int where, u8 *val);     int (*read_word)(struct pci_dev *, int where, u16 *val);     int (*read_dword)(struct pci_dev *, int where, u32 *val);     int (*write_byte)(struct pci_dev *, int where, u8 val);     int (*write_word)(struct pci_dev *, int where, u16 val);     int (*write_dword)(struct pci_dev *, int where, u32 val); }; 

The six functions that act on the PCI configuration space have more overhead than dereferencing a pointer, because they use cascading pointers due to the high object-orientedness of the code, but the overhead is not an issue in operations that are performed quite rarely and never in speed-critical paths. The actual implementation of pci_read_config_byte(dev), for instance, expands to:

 dev->bus->ops->read_byte(); 

Despite its great disadvantages, ISA is still used in several unexpected places. For example, the VR41xx series of MIPS processors used in several palmtops features an ISA-compatible expansion bus, strange as it seems. The reason behind these unexpected uses of ISA is the extreme low cost of some legacy hardware, like 8390-based Ethernet cards, so a CPU with ISA electrical signaling can easily exploit the awful but cheap PC devices.

Hardware Resources

Even though the x86 processors support 64 kilobytes of I/O port memory (i.e., the processor asserts 16 address lines), some old PC hardware decodes only the lowest 10 address lines. This limits the usable address space to 1024 ports, because any address in the range 1 KB to 64 KB will be mistaken for a low address by any device that decodes only the low address lines. Some peripherals circumvent this limitation by mapping only one port into the low kilobyte and using the high address lines to select between different device registers. For example, a device mapped at 0x340 can safely use port 0x740, 0xB40, and so on.

If the availability of I/O ports is limited, memory access is still worse. An ISA device can use only the memory range between 640 KB and 1 MB and between 15 MB and 16 MB. The 640-KB to 1-MB range is used by the PC BIOS, by VGA-compatible video boards, and by various other devices, leaving little space available for new devices. Memory at 15 MB, on the other hand, is not directly supported by Linux, and hacking the kernel to support it is a waste of programming time nowadays.

Although the original ISA specification doesn't allow interrupt sharing across devices, most device boards allow it.[60] Interrupt sharing at the software level is described in "Interrupt Sharing", in Chapter 9, "Interrupt Handling".

ISA Programming

The programming techniques shown throughout the first part of this book apply to ISA devices; the driver can probe for I/O ports, and the interrupt line must be autodetected with one of the techniques shown in "Autodetecting the IRQ Number", in Chapter 9, "Interrupt Handling".

The helper functions isa_readb and friends have been briefly introduced in "Using I/O Memory" in Chapter 8, "Hardware Management" and there's nothing more to say about them.

The Plug-and-Play Specification

Interface boards following the PnP specs are complicated at the hardware level. They are much more elaborate than PCI boards and require complex software. It's not unusual to have difficulty installing these devices, and even if the installation goes well, you still face the performance constraints and the limited I/O space of the ISA bus. It's much better in our opinion to install PCI devices whenever possible and enjoy the new technology instead.

Both standards refer to specific form factors for printed circuit boards as well as electrical/mechanical specifications for board interconnections. The practical advantage of these buses is that they allow circuit boards to be stacked vertically using a plug-and-socket kind of connector on one side of the device.

The electrical and logical layout of the two buses is identical to ISA (PC/104) and PCI (PC/104+), so software won't notice any difference between the usual desktop buses and these two.

EISA

Like PCI and MCA, the EISA bus is designed to host jumperless devices, and it has the same features as MCA: 32-bit address and data lines, multimaster DMA, and shared interrupt lines. EISA devices are configured by software, but they don't need any particular operating system support. EISA drivers already exist in the Linux kernel for Ethernet devices and SCSI controllers.

An EISA driver checks the value EISA_bus to determine if the host computer carries an EISA bus. Like MCA_bus, EISA_bus is either a macro or a variable, depending on whether EISA_bus_ _is_a_macro is defined. Both symbols are defined in <asm/processor.h>.

As far as the driver is concerned, there is no special support for EISA in the kernel, and the programmer must deal with ISA extensions by himself. The driver uses standard EISA I/O operations to access the EISA registers. The drivers that are already in the kernel can be used as sample code.

VLB

The VESA bus is much more limited in its capabilities than the EISA, MCA, and PCI buses and is disappearing from the market. No special kernel support exists for VLB. However, both the Lance Ethernet driver and the IDE disk driver in Linux 2.0 can deal with VLB versions of their devices.

SBus is quite an advanced design, although it has been around for a long time. It is meant to be processor independent (even though only SPARC computers use it) and is optimized for I/O peripheral boards. In other words, you can't plug additional RAM into SBus slots (RAM expansion boards have long been forgotten even in the ISA world, and PCI does not support them either). This optimization is meant to simplify the design of both hardware devices and system software, at the expense of some additional complexity in the motherboard.

SBus peripherals use the Forth language in their PROMs to initialize themselves. Forth was chosen because the interpreter is lightweight and therefore can be easily implemented in the firmware of any computer system. In addition, the SBus specification outlines the boot process, so that compliant I/O devices fit easily into the system and are recognized at system boot. This was a great step to support multi-platform devices; it's a completely different world from the PC-centric ISA stuff we were used to. However, it didn't succeed for a variety of commercial reasons.

Although current kernel versions offer quite full-featured support for SBus devices, the bus is so little used nowadays that it's not worth covering in detail here. Interested readers can look at source files in arch/sparc/kernel and arch/sparc/mm.

The file drivers/nubus/nubus.c includes almost everything we know about this bus, and it's interesting reading; it shows how much hard reverse engineering developers had to do.

Conceptually, these buses are neither full-featured interface buses (like PCI is) nor dumb communication channels (like the serial ports are). It's hard to classify the software that is needed to exploit their features, as it's usually split into two levels: the driver for the hardware controller (like drivers for PCI SCSI adaptors or PCI controllers introduced earlier in "The PCI Interface") and the driver for the specific "client'' device (like sd.c handles generic SCSI disks and so-called PCI drivers deal with cards plugged in the bus).

But there's another problem with these new buses. With the exception of USB, their support is either not mature or is somehow in need of a revision (the latter condition applies especially to the SCSI kernel subsystem, which is reported to be far from optimal by several of the best kernel hackers).

USB

The bus is nothing exciting at the technological level, as it's a single-master implementation in which the host computer polls the various devices. Despite this intrinsic limit of the bus, it has interesting features, such as the ability for a device to request a fixed bandwidth for its data transfers in order to reliably support video and audio I/O. Another important feature of USB is that it acts merely as a communication channel between the device and the host, without requiring specific meaning or structure in the data it delivers.[61]

This is unlike SCSI communication and like standard serial media.

These features, together with the inherent hot-plug capability of the design, make USB a handy low-cost mechanism to connect (and disconnect) several devices to the computer without the need to shut the system down, open the cover, and swear over screws and wires. USB is becoming popular in the PC market but remains unsuitable for high-speed devices because its maximum transfer rate is 12 Mb per second.

USB is supported by version 2.2.18 (and later) and 2.4.x of the Linux kernel. The USB controller in any computer belongs to one of two kinds, and both drivers are part of the standard kernel.

Writing a USB Driver

 #include <linux/usb.h>  static struct usb_driver sample_usb_driver = {         name:        "sample",         probe:       sample_probe,         disconnect:  sample_disconnect, };  int init_module(void) {     /* just register it; returns 0 or error code */     return usb_register(&sample_usb_driver); }  void cleanup_module(void) {     usb_deregister(&sample_usb_driver); }  

The probe function declared in the data structure is called by the USB kernel subsystem whenever a new device is connected to the system (or when the driver is loaded if any unclaimed devices are already connected to the bus).

Each device identifies itself by providing the system with vendor, device, and class identifiers, similar to what PCI devices do. The task of sample_probe, therefore, is looking into the information it receives and claiming ownership of the device if suitable.

To claim ownership, the function returns a non-NULL pointer that will be used to identify the device. This will usually be a pointer to the device-specific data structure that is at the core of the device driver as a whole.

To exchange information with the device, you'll then need to tell the USB subsystem how to communicate. This task is performed by filling a struct urb (for USB request block) and by passing it to usb_submit_urb. This step is usually performed by the open method associated with the device special file, or an equivalent function.

Note that not every USB driver needs to implement its own device special files by requesting a major number and so on. Devices that fall within a class for which the kernel offers generalized support won't have their own device files and will report their information through other means.

An example of generalized management is input handling. If your USB device is an input device (such as a graphic tablet), you won't allocate a major number but rather will register your hardware by calling input_register_device. In this case, the open callback of your input device is in charge of establishing communication by calling usb_submit_urb.

A USB input driver, therefore, must rely on several other system blocks, and most of them can be modules as well. The module-stacking architecture for USB input device drivers is shown in Figure 15-3.

You'll find a complete USB device driver in the sample files available on the O'Reilly FTP site. It is a very simplified keyboard and mouse driver that shows how to lay out a complete USB driver. To keep it simple, it doesn't use the input subsystem to report events but rather posts messages about them using printk. You'll need at least a USB keyboard or a USB mouse to test the driver.

Fortunately, dealing with the difference is not a big problem, and if you include sysdep.h you'll be able to use 2.4 semantics even when compiling under 2.0. PCI support for version 2.0 is available in the header pci-compat.h, automatically included by sysdep.h when you compile under 2.0. The header, as distributed, implements the most important functions used to work with the PCI bus.

If you use pci-compat.h to develop drivers that work all the way from 2.0 through 2.4, you must call pci_release_device when you are done with a pci_dev item. This happens because the fake pci_dev structures created by the header are allocated with kmalloc, whereas the real structures of 2.2 and 2.4 are static resources in the kernel proper. The extra function is defined to do nothing by sysdep.h whenever compiling for 2.2 or 2.4, so it does no harm. Feel free to look at pciregions.cor pcidata.c to see portable code in action.