From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miles Lane Date: Sun, 04 Feb 2001 18:02:36 +0000 Subject: Re: Adding PCMCIA support to the kernel tree -- developers needed. Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Here's an overview of where we are now. David Hinds wrote: > On Wed, Jan 31, 2001 at 08:19:56PM -0800, Miles Lane wrote: > >> Would you be willing to outline all the major things that >> need to addressed to get full PCMCIA support in 2.5? > > > Here is a short list: > > To include 16-bit PCMCIA cards in the hot plug framework would require > few driver changes; the only mandatory changes would be in how drivers > register themselves and are hooked up with appropriate devices: > > -- Make up pcmcia_device_id and pcmcia_driver types, and write new > register/unregister calls to parallel PCI and USB drivers. This > would eventually take over for the "ds" module and cardmgr. (Jeff Garzik has volunteered to make required changes to the PCMCIA network device drivers. Perhaps he could make these pcmcia_device_id and pcmcia_driver changes to the network drivers, thus creating a reference implementation that could then migrate rapidly to the other driver families?) > -- Rewrite all PCMCIA client drivers to have MODULE_DEVICE_TABLE > entries and use the new driver services. This can all be done > incrementally, with ds/cardmgr handling old-style drivers. Yes. This seems straightforward. > -- The CIS override functionality in the PCMCIA package is unpleasant > to support in a completely in-kernel framework. (Discussion has started on linux-hotplug-devel) =============== > Missing functionality in the hotplug framework: > 1. Only new network devices generate /sbin/hotplug events now. Modify > all other device types to also do so: the ones currently handled by > PCMCIA include serial, parallel, SCSI (all types), and IDE. Is it true that doing this is fairly straightforward and is it something that one person could do? (No discussion or volunteers for this, yet) -------------- > 2. There is no mechanism to request a card eject in the new framework. > This is required for clean shutdown of SCSI and IDE adapters. (Rusty Russell and other kernel developers are looking into related improvements. Also, discussion has started on linux-hotplug-devel) -------------- > 3. The PCMCIA device configuration scripts have a lot of capabilities > that the hotplug scripts do not have yet. At the moment, the > extent of device-specific hotplug configuration is running "ifup". Well, solving this problem for PCMCIA devices alone might be the wrong way to go. Don't want to meet the need for flexible configuration for the general case of all drivers for all devices on all hotpluggable busses, if possible? If so, then the interesting question is whether any configuration needs are unique to PCMCIA configuration. Perhaps we need two things: a good outline of the configuration functionality in pcmcia-cs and a list of the types of configuration handling we need for the general hotplug system. I'm afraid I don't have a very good handle on how this should all work. Suggestions? =============== > Missing functionality in the 2.4 PCMCIA drivers: > 1. The yenta driver can't handle CardBus adapter cards for desktop > systems. Many require explicit overrides for the default interrupt > delivery settings, and a few require other special bridge settings. Huh? You mean that the driver can't handle _some_ Cardbus adapter cards, right? Mine work fine. As for the issue of many drivers requiring overrides and special settings, could you please give us a few examples? Also, if you would elaborate on why this is a flaw in yenta, that would be really helpful. I'd also like to know if you have any thoughts regarding how this flaw might be fixed (vague handwaving would be okay, if others could extrapolate from it). --------------- > 2. The i82365 driver can't handle (non-CardBus) PCI-to-PCMCIA bridges > any more. Some of the PCI code in the old i82365 driver needs to > be put back. (David Woodhouse will explore fixing this problem) (Discussion has started on linux-hotplug-devel) _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel