From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse Date: Sun, 04 Feb 2001 09:55:59 +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 On Sat, 3 Feb 2001, Miles Lane wrote: > Well, would care to elaborate on what the PCI mess is, exactly? See attached patch. > I like the idea of not overloading drivers, if overloading leads to > horribly complex or unmaintainable code. Is there any generic code in > the > i82365 driver that you think should be split out and included in drivers > for the various bridge drivers? Some, yes. But I'm not sure there's enough there to justify doing so. > Why do you think the codebase needs to be jettisoned? It appears to be based on the PCMCIA spec. It allows for silly legacy drivers which work with only certain IRQs and IO addresses - sort of ioremap(MAP_FIXED) stuff. It's complex, racy, overdesigned, the layering is wrong... oh and it uses sleep_on() :) I don't want that to come across as a criticism of David Hinds; there are reasons why some of it was specified like that, and maybe the code for other operating systems actually requires some of the stuff which appears in Linux to be superfluous. In another conversation, Linus has agreed with my assessment. > Which do you think should happen first: you develop an exploratory > implementation or have a general discussion of design issues? I'm in the middle of writing JFFS2 at the moment. An exploratory implementation isn't going to happen for a while. I think a discussion of design issues is worth having. Bearing in mind that it's first thing on a Sunday morning and I haven't really fleshed this out very much yet (i.e. be kind), here's my basic idea. Remove cardmgr completely. It doesn't do anything that can't be done from an improved /sbin/hotplug usermodehelper. We use the 'hotplug isapnp' concept. Pick fields which can be used in place of manufacturer and device ID to identify devices and match them with drivers. PCMCIA devices actually have mfr and device IDs - I'm not sure how reliable they are. They can also have a text string. As with PCI, drivers register with the core PCMCIA code a pcmcia_device_id table which identifies a superset of the devices they want to drive. Further elimination is done by the driver's probe() routine, which can check the CIS if it needs to, or check for the existing of the letters 'modem' in the text string, etc. Upon arrival of a card, the CIS is parsed by the core code and turned into a set of resource structs in the pcmcia_dev_t, just like PCI. If necessary, a driver can fix these up before calling pcmcia_enable_device(). We probably want a way for resources to be enabled individually, rather than in one go with pcmcia_enable_device. Especially because some of them (attribute memory space/normal memory space) are mutually exclusive. The 'bus' abstraction is useful - see include/pcmcia/bus_ops.h. But also 'grep --context=2 doesn include/linux/mtd/map.h' :) But now might not be the time to push that, as apparently Linus doesn't like it. I don't want that argument to get in the way. Core PCMCIA code has functions for parsing a CIS, doing the necessary resets and delays when cards are inserted, etc. Nothing on top of the socket drivers like ds.o at the moment. Expose the CIS to userspace via /proc/bus/pcmcia as a whole. We don't care if we have to duplicate the CIS parsing code in userspace and it's already in the kernel. Some way for userspace to override which driver gets to 'bind' to a particular card? Maybe, but not with the ugly 'bind' stuff we already have, and not by requiring userspace to get involved every time. Maybe just 'echo drivername > /proc/bus/pcmcia/00/driver' and use 'drivername' as an extra field to match in the core code when seeking a driver to go with any particular card? -- dwmw2 _______________________________________________ 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