From: Rene Herman <rene.herman@keyaccess.nl>
To: Simon White <s_a_white@email.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Driver model ISA bus
Date: Sun, 30 Jul 2006 15:13:43 +0200 [thread overview]
Message-ID: <44CCB087.8030804@keyaccess.nl> (raw)
In-Reply-To: <20060730122415.A17D31CE304@ws1-6.us4.outblaze.com>
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.
next prev parent reply other threads:[~2006-07-30 13:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-30 12:24 Driver model ISA bus Simon White
2006-07-30 13:13 ` Rene Herman [this message]
2006-07-30 13:21 ` Rene Herman
-- strict thread matches above, loose matches on Subject: below --
2006-07-30 8:18 Simon White
2006-07-30 9:55 ` Rene Herman
2006-06-06 21:54 Rene Herman
2006-06-16 23:42 ` Greg KH
2006-06-18 18:51 ` Rene Herman
2006-05-04 22:07 Rene Herman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44CCB087.8030804@keyaccess.nl \
--to=rene.herman@keyaccess.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=s_a_white@email.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox