Displaying/modifying PCI device id tables via sysfs

From: Matt Domsch (Matt_Domsch@Dell.com)
Date: Mon Mar 03 2003 - 12:57:05 EST


A lot of PCI drivers today use the pci_device_id table model to specify
what IDs the driver supports. I'd like to be able to do 2 things with
this information:
1) display it in sysfs
2) Add new IDs at runtime and have the drivers probe for the new IDs.

To this end, I've started thinking about how to properly display the table
via sysfs. So far I've got:

/sys
|-- bus
| |-- pci
| | `-- drivers
| | |-- 3c59x
| | | `-- id_table
| | |-- PIIX IDE
| | | `-- id_table
| | |-- RZ1000 IDE
| | | `-- id_table
| | |-- aic7xxx
| | | `-- id_table
| | |-- e100
| | | `-- id_table
| | |-- e1000
| | | `-- id_table
| | |-- eepro100
| | | `-- id_table
| | `-- serial
| | `-- id_table

where id_table is a file that looks like:

  vendor, device, subvendor, subdevice, class, class_mask
00009004, ffffffff, ffffffff, ffffffff, 00010000, 00ffff00
00009005, ffffffff, ffffffff, ffffffff, 00010000, 00ffff00

Now, this isn't ideal.
a) It violates sysfs rule of one value per file
b) for drivers with lots of IDs (like 3c59x), it could be longer than
PAGE_SIZE.

So, I've thought about a directory model:

/sys
`-- bus
    `-- pci
        `-- drivers
            `-- 3c59x
                |-- dynamic_id_table
                | |-- 0
                | | |-- class
                | | |-- class_mask
                | | |-- device
                | | |-- subdevice
                | | |-- subvendor
                | | `-- vendor
                | `-- new_id
                `-- static_id_table
                    |-- 0
                    | |-- class
                    | |-- class_mask
                    | |-- device
                    | |-- subdevice
                    | |-- subvendor
                    | `-- vendor

The new_id file in the dynamic_id_table would be writable, used for
adding new IDs.

This solves a and b both, at the expense of adding two additional
directories to the hierarchy.

The current sysfs implementation doesn't cleanly handle this type of
data display however. sysfs_create_dir() takes a kobject*, but I
don't think we want to instantiate kobjects which are simply
groupings for attribute entries in a table, do we?

I've started down this road, but before I go too far want validation that
I'm on the right track instantiating kobjects for these table entries.
Something doesn't feel quite right about it.

I've so far had to:
a) add a struct kobject and a struct list_head (for the dynamic list) to
pci_device_id.
b) add 2 struct kobjects and 1 struct list_head to struct pci_driver
c) create them all in drivers/pci/pci-sysfs.c.

I also think I need some type of ATTR_ATTR macro, as I don't have whole
devices for these, just kobjects. That's where it starts getting really
weird.

Feedback requested.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer, Architect
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Mar 07 2003 - 22:00:22 EST