2.4.0 Patch for 3c575

Quoted 1 line · Miles Lane

There are at least two things that need to happen.

....

I think you're not clear on what PCMCIA support is in the 2.4 kernel tree. The pcnet_cs driver has been in the kernel tree as long as anything else. Most PCMCIA drivers are already in the kernel tree; the ones that are not are: the memory card drivers (rarely used now), parport_cs, and wvlan_cs. The hot plug PCI drivers (3c59x, tulip, epic100) subsume the 3c575_cb, tulip_cb, and epic_cb drivers completely.

Quoted 6 lines

For the case where drivers don't exist yet, the /etc/pcmcia/config* files could be migrated into the kernel tree, so that when a kernel is installed that is configured to use the kernel drivers instead of pcmcia-cs drivers, then install the modified /etc/pcmcia/config* files.

I don't like this idea one bit; multiple sets of config files for different kernel versions is not workable. People want to be able to boot different kernel releases. I want a way for cardmgr to figure out on the fly, based on some feedback from the PCMCIA modules, what the right thing to do is.

Quoted 4 lines

This seems kind of heinous. But, these configuration files sometimes get tweaked for a particular machine's hardware configuration, so it's important not to lose them.

/etc/pcmcia/config should never be tweaked for anything. That's what the config.opts file is for.

Quoted 4 lines

I should note that I once before I modified my /etc/pcmcia/config file so that cardmgr loaded 3c59x for my 3c575 card. I got some errors during the card detection phase and I never got "ifup eth0" to run automatically when I inserted the card.

Getting "ifup eth0" to run when you insert a CardBus card in the new 2.4 scheme is going to be an issue with the /sbin/hotplug script, and out of the PCMCIA subsystem's control.

I am going to go through pcmcia-cs and work with you to get a comprehensive mapping of device support to the kernel drivers. Then, we'll identify all the yet-to-be-ported drivers and put together some sort of porting strategy.

Alright. Can you please work with the folks on [email protected] to come up with an acceptable method? Let's open a discussion there on what some possible "generic" methods might be. It would make a lot of sense to design something that would have value across all sorts of drivers, beyond the scope of PCMCIA/Cardbus. Ideally, this would allow straightforward solutions to the kind of problem we have now for all driver modules.

I was thinking of just having a new keyword in /etc/pcmcia/config to say that certain drivers are "hotplug", which would mean to ignore those config entries under a 2.4 kernel with hotplug support.

-- Dave

Quoted 3 lines

I was thinking of just having a new keyword in /etc/pcmcia/config to say that certain drivers are "hotplug", which would mean to ignore those config entries under a 2.4 kernel with hotplug support.

That's probably a workable solution. Though I suspect the pcmcia_cs package will want a way to detect that hotplug PCI is running, so it will do the right thing with such cardbus drivers in atypical setups.

Have you looked at the (PCI-less) /etc/hotplug stuff I sent around? We could arrange that the next iteration of that use some sort of config file in /etc/hotplug to expose such information; I can toss in the PCI/Cardbus support, but it'll be short of testing. The same stuff could let the /sbin/hotplug command itself show status info.