lkml.org 
[lkml]   [2006]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Driver model ISA bus
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 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: 2006-07-30 15:13    [W:0.097 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site