linux-kernel - Re: Driver model ISA bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <44CCB087.8030804@keyaccess.nl>
Date:	Sun, 30 Jul 2006 15:13:43 +0200
From:	Rene Herman <rene.herman@...access.nl>
To:	Simon White <s_a_white@...il.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/