Device types

A driver's udiprops.txt file must include one or more device declarations, describing the devices supported by the driver. The sample udi_cmos and pseudod drivers define these devices:

cmos_udi.c sample driver udiprops.txt (cont.)
# Since this is a "System"-bus device, which is not self-identifying, # we have to specify a default I/O address range with "config_choices". # For PCI devices, there'd be no "config_choices" and the "device" # declaration would include attributes like "pci_vendor_id". # This device line is an example of what a real PCI device line # would look like. Currently the CMOS device is being supplied # as a fake PCI entry. See comments above. device 10 2 bus_type string pci pci_vendor_id ubit32 0x434d \ pci_device_id ubit32 0x4f44 #device 10 2 bus_type string system message 10 Motherboard CMOS RAM #config_choices 10 ioaddr1 ubit32 0x70 any iolen1 ubit32 2 only
pseudod.c sample driver udiprops.txt (cont.)
# This is a pseudo driver but to easily instantiate the device using the bus # bridge enumeration mechanism, we fake ourselves to be recognised from some # common PCI bridge and/or video controller IDs. # This list can be changed to add or remove other controller IDs depending # on the system being used. # # NOTE: At the moment only the first device line is referenced for matching # against the enumerated PCI devices. This means the order has to be # changed to match what PCI devices are physically present in the PC. # This will work properly when multiple device lines are handled by the # udi_MA code # Toshiba Vendor ID = 0x1179 (These are probably pcmcia masters) device 4 2 \ bus_type string pci \ pci_vendor_id ubit32 0x1179 \ pci_device_id ubit32 0x0701 device 4 2 \ bus_type string pci \ pci_vendor_id ubit32 0x1179 \ pci_device_id ubit32 0x0406 # Intel vendor ID = 0x8086 # Common Intel motherboard PCI masters device 4 2 \ bus_type string pci \ pci_vendor_id ubit32 0x8086 \ pci_device_id ubit32 0x7180 device 4 2 \ bus_type string pci \ pci_vendor_id ubit32 0x8086 \ pci_device_id ubit32 0x7181 device 4 2 \ bus_type string pci \ pci_vendor_id ubit32 0x8086 \ pci_device_id ubit32 0x7111 device 4 2 \ bus_type string pci \ pci_vendor_id ubit32 0x8086 \ pci_device_id ubit32 0x7113 # Motorola Vendor ID = 0x1057 # Devices: # Motorola MPC 105 (Eagle) = 0x0001 # Motorola MPC 106 (Grackle) = 0x0002 # Both of these PCI bridges can be found in Old World Apple PowerMacs device 4 2 \ bus_type string pci \ pci_vendor_id ubit32 0x1057 \ pci_device_id ubit32 0x0001 device 4 2 \ bus_type string pci \ pci_vendor_id ubit32 0x1057 \ pci_device_id ubit32 0x0002 # Apple Vendor ID = 0x106B # Devices: # PowerMac G4 sawtooth (New World/AGP) host bridge: 0x0020 device 4 2 \ bus_type string pci \ pci_vendor_id ubit32 0x106B \ pci_device_id ubit32 0x0020 # # Initialization, shutdown messages # message 1100 pseudod: devmgmt_req %d message 1500 pseudod: final_cleanup_req

In general, a driver includes one device declaration for each device model supported by the driver:

   device msgnum meta_idx { attr_name attr_type attr_value }...

The msgnum supplied must refer to a message declaration elsewhere in the file. These are meant to be human-readable descriptions of the device model.

The meta_idx must refer to a meta metalanguage declaration, as well as to the meta_idx used in a parent_bind_ops declaration, found elsewhere in the file.

The attribute name, type, and value triplets that follow must be valid enumeration attribute names, types, and values for the metalanguage specified by meta_idx. These are found in the specification for the metalanguage.

Both the above drivers specify the PCI Bus Bridge Metalanguage for the devices they define. The enumeration attributes used are explained under Instance Attribute Bindings in the PCI Bus Binding Specification. This specification defines the implementation of Physical I/O on the PCI Bus.

For the set of allowable attr_type values, see the detailed explanation of the Device Declaration in the UDI Core Specification.