[PATCHES 2.5.67] PCMCIA hotplugging, in-kernel-matching and depmod support

[PATCHES 2.5.67] PCMCIA hotplugging, in-kernel-matching and depmod support

[Dominik Brodowski]

... and the deprecation of "cardmgr" and "cardctl"

Dear kernel developers and testers,

Updated and re-diffed revisions of my pcmcia-related patches are 
available at http://www.brodo.de/pcmcia/

These patches update the PCMCIA subsystem (16-bit) to use the driver
model matching and hotplug utilities. The "cardmgr" will not be 
needed any longer - in fact, it won't even work any longer.

They are based on kernel 2.5.67

Many thanks to David Hinds for the great PCMCIA package to build this
work onto, to David Woodhouse for parts of the code and many ideas,
to Russell King, Greg Kroah-Hartman for their insight, and to Patrick
Mochel for the great linux driver model which made implementing this
so much easier.

A descritption of each patch, and more information can be found at the said
website, http://www.brodo.de/pcmcia/index.html

	Dominik

Re: [PATCHES 2.5.67] PCMCIA hotplugging, in-kernel-matching and depmod support

[Jeff Garzik]

On Tue, Apr 08, 2003 at 10:56:23PM +0200, Dominik Brodowski wrote:
> ... and the deprecation of "cardmgr" and "cardctl"
> 
> Dear kernel developers and testers,
> 
> Updated and re-diffed revisions of my pcmcia-related patches are 
> available at http://www.brodo.de/pcmcia/
> 
> These patches update the PCMCIA subsystem (16-bit) to use the driver
> model matching and hotplug utilities. The "cardmgr" will not be 
> needed any longer - in fact, it won't even work any longer.
> 
> They are based on kernel 2.5.67

Will we see pcmcia id lists making their way into low-level drivers?

That was a big stumbling block when I last looked at the "big picture"
for pcmcia -- in-kernel drivers still required probe assistance from
userspace via the /etc/pcmcia/* bindings.

	Jeff

Re: [PATCHES 2.5.67] PCMCIA hotplugging, in-kernel-matching and depmod support

[Dominik Brodowski]

On Tue, Apr 08, 2003 at 05:20:59PM -0400, Jeff Garzik wrote:
> On Tue, Apr 08, 2003 at 10:56:23PM +0200, Dominik Brodowski wrote:
> > ... and the deprecation of "cardmgr" and "cardctl"
> > 
> > Dear kernel developers and testers,
> > 
> > Updated and re-diffed revisions of my pcmcia-related patches are 
> > available at http://www.brodo.de/pcmcia/
> > 
> > These patches update the PCMCIA subsystem (16-bit) to use the driver
> > model matching and hotplug utilities. The "cardmgr" will not be 
> > needed any longer - in fact, it won't even work any longer.
> > 
> > They are based on kernel 2.5.67
> 
> Will we see pcmcia id lists making their way into low-level drivers?
> 
> That was a big stumbling block when I last looked at the "big picture"
> for pcmcia -- in-kernel drivers still required probe assistance from
> userspace via the /etc/pcmcia/* bindings.

In the drivers I converted (~20 or so...) this is done already. You can 
find them at http://www.brodo.de/pcmcia/ , for example the network drivers
(all of them should be converted) at
http://www.brodo.de/pcmcia/pcmcia-2.5.67-drivers_network .

For example, a part of pcnet_cs.c looks like this now:

static struct pcmcia_device_id pcnet_ids[] = {
	{ PCMCIA_DEVICE_VERS1("2412LAN", 0x67f236ab) },
	{ PCMCIA_DEVICE_VERS12("ACCTON", "EN2212", 0xdfc6b5b2, 0xcb112a11) },
	...
	{ PCMCIA_MFC_DEVICE_MANF_CARD(0, 0x0105, 0xea15) },
	{ },
};
MODULE_DEVICE_TABLE(pcmcia, pcnet_ids);

As strings can't be passed to userspace in file2alias.c, I've chosen the
crc32 value of the string as the matching identifier for the userspace
hotplug script. In-kernel matching uses the full string then. And _MFC_
stands for multi-function-card , function 0 of the card in the example above
will be bound to this driver. Oh, and I didn't do this parsing by hand --
wrote an ugly /etc/pcmcia/config --> pcmcia_device_id_table parser (which
works) and I'm willing to convert any entries still left over.

	Dominik

Re: [PATCHES 2.5.67] PCMCIA hotplugging, in-kernel-matching and depmod support

[Jeff Garzik]

Dominik Brodowski wrote:
> On Tue, Apr 08, 2003 at 05:20:59PM -0400, Jeff Garzik wrote:
>>Will we see pcmcia id lists making their way into low-level drivers?

> In the drivers I converted (~20 or so...) this is done already. You can 
> find them at http://www.brodo.de/pcmcia/ , for example the network drivers
> (all of them should be converted) at
> http://www.brodo.de/pcmcia/pcmcia-2.5.67-drivers_network .
> 
> For example, a part of pcnet_cs.c looks like this now:
> 
> static struct pcmcia_device_id pcnet_ids[] = {
> 	{ PCMCIA_DEVICE_VERS1("2412LAN", 0x67f236ab) },
> 	{ PCMCIA_DEVICE_VERS12("ACCTON", "EN2212", 0xdfc6b5b2, 0xcb112a11) },
> 	...
> 	{ PCMCIA_MFC_DEVICE_MANF_CARD(0, 0x0105, 0xea15) },
> 	{ },
> };
> MODULE_DEVICE_TABLE(pcmcia, pcnet_ids);

Very cool...


> As strings can't be passed to userspace in file2alias.c, I've chosen the
> crc32 value of the string as the matching identifier for the userspace
> hotplug script.

This sounds like a problem to be solved, not worked around...  the 
source should have the strings presented directly, and I'm sure a 
creative and smart person such as yourself can conceive of at least 
one... ;-)

	Jeff

Re: [PATCHES 2.5.67] PCMCIA hotplugging, in-kernel-matching and depmod support

[Dominik Brodowski]

On Tue, Apr 08, 2003 at 07:01:39PM -0400, Jeff Garzik wrote:
> >As strings can't be passed to userspace in file2alias.c, I've chosen the
> >crc32 value of the string as the matching identifier for the userspace
> >hotplug script.
> 
> This sounds like a problem to be solved, not worked around...  the 
> source should have the strings presented directly, and I'm sure a 
> creative and smart person such as yourself can conceive of at least 
> one... ;-)

OK, there might be a way to do this (and yes, I can think of one...).
However, I doubt it makes sense: using strings in depmod.c and in the
hotplug utilities is even worse than in file2alias.c. For example, 
whitespace is used as delimitier for the values being parsed in hotplug
scripts. So I think the better (as simpler and thus more difficult to break)
approach is using crc32.

	Dominik

Re: [PATCHES 2.5.67] PCMCIA hotplugging, in-kernel-matching and depmod support

[Jean Tourrilhes]

Jeff Garzik wrote :
> On Tue, Apr 08, 2003 at 10:56:23PM +0200, Dominik Brodowski wrote:
> > ... and the deprecation of "cardmgr" and "cardctl"
> > 
> > Dear kernel developers and testers,
> > 
> > Updated and re-diffed revisions of my pcmcia-related patches are 
> > available at http://www.brodo.de/pcmcia/
> > 
> > These patches update the PCMCIA subsystem (16-bit) to use the driver
> > model matching and hotplug utilities. The "cardmgr" will not be 
> > needed any longer - in fact, it won't even work any longer.
> > 
> > They are based on kernel 2.5.67
> 
> Will we see pcmcia id lists making their way into low-level drivers?
> 
> That was a big stumbling block when I last looked at the "big picture"
> for pcmcia -- in-kernel drivers still required probe assistance from
> userspace via the /etc/pcmcia/* bindings.

	No ! Please don't do that, it will only bring madness.

	Example :
	Lucent/Agere Orinoco wireless card :
		manfid 0x0156,0x0002
		possible drivers : wlan_cs ; orinoco_cs
	Intersil PrismII and clones (Linksys, ...) :
		manfid 0x0156,0x0002
		possible drivers : prism2_cs ; hostap_cs

	Please explain me in details how your stuff will cope with the
above, and how to make sure the right driver is loaded in every case
and how user can control this.
	If your scheme can't cope with the simple real life example
above (I've got those cards on my desk, and those drivers on my disk),
then it's no good to me.

	Good luck...

	Jean

Re: [PATCHES 2.5.67] PCMCIA hotplugging, in-kernel-matching and depmod support

[Jeff Garzik]

Jean Tourrilhes wrote:
> Jeff Garzik wrote :
>>That was a big stumbling block when I last looked at the "big picture"
>>for pcmcia -- in-kernel drivers still required probe assistance from
>>userspace via the /etc/pcmcia/* bindings.
> 
> 
> 	No ! Please don't do that, it will only bring madness.

Nope.  It's already a solved problem :)  More below...


> 	Example :
> 	Lucent/Agere Orinoco wireless card :
> 		manfid 0x0156,0x0002
> 		possible drivers : wlan_cs ; orinoco_cs
> 	Intersil PrismII and clones (Linksys, ...) :
> 		manfid 0x0156,0x0002
> 		possible drivers : prism2_cs ; hostap_cs
> 
> 	Please explain me in details how your stuff will cope with the
> above, and how to make sure the right driver is loaded in every case
> and how user can control this.
> 	If your scheme can't cope with the simple real life example
> above (I've got those cards on my desk, and those drivers on my disk),
> then it's no good to me.

These cases already exist for PCI, so pcmcia behavior should follow what 
the kernel does when the PCI core sees such.

	Jeff

Re: [PATCHES 2.5.67] PCMCIA hotplugging, in-kernel-matching and depmod support

[Jean Tourrilhes]

On Tue, Apr 08, 2003 at 06:56:12PM -0400, Jeff Garzik wrote:
> 
> >	Example :
> >	Lucent/Agere Orinoco wireless card :
> >		manfid 0x0156,0x0002
> >		possible drivers : wlan_cs ; orinoco_cs
> >	Intersil PrismII and clones (Linksys, ...) :
> >		manfid 0x0156,0x0002
> >		possible drivers : prism2_cs ; hostap_cs
> >
> >	Please explain me in details how your stuff will cope with the
> >above, and how to make sure the right driver is loaded in every case
> >and how user can control this.
> >	If your scheme can't cope with the simple real life example
> >above (I've got those cards on my desk, and those drivers on my disk),
> >then it's no good to me.
> 
> These cases already exist for PCI, so pcmcia behavior should follow what 
> the kernel does when the PCI core sees such.
> 
> 	Jeff

	I've never heard of a case of PCI-ID collision between two
different manufacturer, so I need to update myself ;-)
	I was already burnt by this mess, as many IrDA users get
confused when ir-usb loads instead of irda-usb, so my experience so
far in handling those case has not been very positive.
	But, I trust you now have things under control ;-)

	Have fun...

	Jean

Re: [PATCHES 2.5.67] PCMCIA hotplugging, in-kernel-matching and depmod support

[Dominik Brodowski]

On Tue, Apr 08, 2003 at 05:05:53PM -0700, Jean Tourrilhes wrote:
> On Tue, Apr 08, 2003 at 06:56:12PM -0400, Jeff Garzik wrote:
> > 
> > >	Example :
> > >	Lucent/Agere Orinoco wireless card :
> > >		manfid 0x0156,0x0002
> > >		possible drivers : wlan_cs ; orinoco_cs
> > >	Intersil PrismII and clones (Linksys, ...) :
> > >		manfid 0x0156,0x0002
> > >		possible drivers : prism2_cs ; hostap_cs
> > >
> > >	Please explain me in details how your stuff will cope with the
> > >above, and how to make sure the right driver is loaded in every case
> > >and how user can control this.

Actually, I was unaware of this problem: etc/* of pcmcia-cs-3.2.3 only tells
me about the orinoco_cs driver. And that's the only one I can find in kernel
2.5.67 as well.... However, for such cases there is already an override
option in my patches:
echo -n "driver_the_next_device_needs" > /sys/bus/pcmcia/settings/force_match

> > >	If your scheme can't cope with the simple real life example
> > >above (I've got those cards on my desk, and those drivers on my disk),
> > >then it's no good to me.
> > 
> > These cases already exist for PCI, so pcmcia behavior should follow what 
> > the kernel does when the PCI core sees such.

i.e. a ->probe() callback?


	Dominik