the bulk of the probe code can stay in the library.
Maybe something like this in a personality module:
static struct pci_driver drm_driver = {
.name = DRIVER_NAME,
.id_table = DRM(pciidlist),
.probe = my_probe,
.remove=
Okay at
http://www.skynet.ie/~airlied/patches/dri/drm_fn_tbl.diff
is my first attempt at swatting the low hanging fruit in the DRM,
this moves the driver macros into a function table which the driver can
work off.. i've only done the radeon on Linux (no point going too far
without making sure
Dave Airlie wrote:
Okay at
http://www.skynet.ie/~airlied/patches/dri/drm_fn_tbl.diff
is my first attempt at swatting the low hanging fruit in the DRM,
this moves the driver macros into a function table which the driver can
work off.. i've only done the radeon on Linux (no point going too far
This will give us a chance to make sure they return errors and the
errors get checked. But if this code is going to go into a library, the
PCI match will need to be triggered from the personality modules. Does
this change the way we want to structure the code?
--- Keith Whitwell [EMAIL PROTECTED]
This will give us a chance to make sure they return errors and the
errors get checked. But if this code is going to go into a library, the
PCI match will need to be triggered from the personality modules. Does
this change the way we want to structure the code?
As Ian said we should take this
the bulk of the probe code can stay in the library.
Maybe something like this in a personality module:
static struct pci_driver drm_driver = {
.name = DRIVER_NAME,
.id_table = DRM(pciidlist),
.probe = my_probe,
.remove=
