lkml.org 
[lkml]   [2003]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Displaying/modifying PCI device id tables via sysfs
On 3 Mar 2003, Matt Domsch wrote:

> /sys
> `-- bus
> `-- pci
> `-- drivers
> `-- 3c59x
> |-- dynamic_id_0 (these are simple DRIVER_ATTRs)
> |-- dynamic_id_1
> |-- dynamic_id_2
> `-- new_id
>
> Where dynamic_id_[012] are new dynamic entries, created by writing
> values into new_id. Both file types would be of the format (analogous
> to pci_show_resources):
> echo "0x0000 0x0000 0x0000 0x0000 0x0000 0x0000" > new_id
> with fields being vendor, device, subvendor, subdevice, class,
> class_mask.

I dont' think what you actually want is changing the id table - after all,
it's only walked when registering the driver (+ hotplug).

What you really want is a way to call the drivers' probe routine for a
device which isn't in its tables.

So why not simply

echo "0x0000 0x0000 0x0000 0x0000 0x0000 0x0000" > .../3c59x/probe
It shares one caveat with the approach above, i.e. struct pci_device_id
has a field called "unsigned long driver_data", and as such is really hard
to fill from userspace. I think in the common case it's not used and can
be just set to zero, but if the driver e.g. expects it to point to a
driver-private structure describing the device, you lose.

And you need one more thing, i.e. the ability to load a driver without
hardware being present. E.g. pci_module_init() is supposed to return
-ENODEV when modular and no hardware is found. Actually, it doesn't
anymore, since someone (I think you, Pat ;) broke it.

--Kai




-
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/

\
 
 \ /
  Last update: 2005-03-22 13:33    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site