Simon White wrote:
No, the name is just an identifier under which the driver (and
devices) show up in sysfs and ndev the number of devices we want to
the driver code to call our methods with -- given that ISA devices
do not announce themselves we have to tell the driver core this.
If I understood correctly, it is the maximum number of devices our
driver will support.
Yes.
I got confused with an earlier version of this whereby devices were
to be registered with the isa bus on finding them.
One further thing I'd like to check. In my case there can only be a
maximum of 4 cards, limited by the possible hardware addresses
manually selectable. Will the probe calls just happen or do they
require some userspace activity to occur (referring to that echo bind
in the example).
If you provide a match() method as part of the isa_driver struct the
calls to that method will just happen and if it returns non-zero,
indicating a match between this driver and the device, the calls to the
probe method will just happen. On a non-match (0), the device is
unregistered again.
The driver model ISA bus is meant to provide a framework for ISA drivers
close to the model from saner busses such as PCI. PCI drivers load
always (even without their PCI ID present) since the user could do
things such as supply a new PCI ID to the driver after it's loaded
through sysfs (the new_id file).
As the example says, the match() method is intended only for things
which should make the device fail to register since it could never be
useful anymore -- in the example, if a port value hasn't been passed in
we can't do anything so fail the device registration. Due to the fact
that most other problems could be fixed later while the driver is loaded
(such as by unloading a different driver which was keeping our ports
busy) things such as that are also really the only things you should
check in the match method, and do everything else from the probe method.
On the other hand, if you are really dead set against loading when you
can't immediately drive something that's up to you as well -- you decide
when to fail the match().
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
