[RFC 2/2] match PCMCIA devcies in kernelspace

[Dominik Brodowski]

Hi Dave,

Many thanks for your reply.

On Fri, Feb 11, 2005 at 05:32:55PM -0800, David Hinds wrote:
> On Fri, Feb 11, 2005 at 08:49:32PM +0100, Dominik Brodowski wrote:
> > 
> > I checked the pcmcia-cs code and found out that the kernel code is not
> > logically equivalent to the pcmcia-cs code. Therefore, it'd be helpful if
> > you could tell me if there are a significant amount of PCMCIA devices where
> > the function ID is "wrong" -- i.e. devices with function ID "3" but not
> > working with the parport driver, ID "4" but not working with "ide_cs", ID
> > "1" and not working with "memory_cs" and -- probably most important --
> > ID "2" and "serial_cs". Note that multiple bindings to one card should work
> > with my code nonetheless -- just a card with ID "2" but needing a different
> > driver than "serial_cs" would fail.
> 
> I'm afraid I'd have a tough time coming up with specific examples of
> incorrect function ID's, but they do happen.  I think the "serial"
> case you mention is indeed the most problematic.  But are there cards
> that identify themselves as "serial" that need a different driver?
> I'm not sure.  How about 16-bit Winmodems (if there are any that have
> Linux drivers)?  If it is not too much work, I think it is safer and
> more "correct" to give function ID matches a lower priority; I don't
> think a card function ID of "serial" makes any guarantees about what
> register-level interface it provides.  It just happens that most are
> 8250-compatible.
> 
> I vaguely also remember inconsistencies between "fixed disk" and
> "SCSI" cards, but don't remember specifics.

While it's quit trivial to do

	"check all loaded modules / built-in drivers for a high-priority match"

	and if this failed, then

	"check all loaded modules / built-in drivers for a low-priority match"

in the pcmcia_match() function.

Difficult problems arise if e.g. "serial_cs" is already loaded, but the
driver which should be used (let's call it "xyz_cs") is not yet loaded. The
hotplug process (or cardmgr in the current way of doing things) needs quite
some time until the module is loaded, and -- IIRC -- the driver isn't even
registered until the pcmcia_match() function returns. Therefore, I'm
tempted to avoid function-ID based matches in kernel space at all. Then we
could do

pcmcia_match():
	"check all loaded modules / built-in drivers for a
		prod_id/manf_id/card_id match"

if it failed, the hotplug (userspace) subsystem -- or, currently, cardmgr -- 
checks if a module is to be loaded because of a prod_id/manf_id/card_id
match. 

And if there is no such match, we'd need a special case in the hotplug{-ng}
subsystem similar to the current cardmgr handling -- trying a func_id match.
Using some sort of userspace<->kernel interface, the kernel is informed to
allow a func_id match in this special case: for cardmgr this is done using
the bind variant of the ioctl, for hotplug{-ng} I'm thinking of sysfs... 

Also, we could ask users to report cards requiring a func_id match, and add
prod_id/manf_id/card_id-based matching for these cards.

Thanks,
	Dominik