Adding PCMCIA support to the kernel tree -- developers needed.

Hi,

I asked David Hinds to write up an outline of the things that will be needed to get PCMCIA support cleanly and completely integrated into the kernel tree.

David has expressed that he'll not be able to participate in this work. He has his hands full with his day job and his role as maintainer/developer of the pcmcia-cs package.

David, I would appreciate one additional layer of information that is not present in your list. Would add the names of a few representative devices for each of your bullet points? For example, for the last list item, what are the names of the major (non-CardBus) PCI-to-PCMCIA bridges?

Here is David's list:

This list does seem to break out the work into chunks that can be tackled more or less independently.

Anyone willing to sign up for some of this effort?

Miles

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[...]

I'll convert all the network drivers once a design is agreed upon.

Jeff

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

How often is this used?

It's arguable that this is a bug in the SCSI and IDE drivers. Users _do_ just pull cards out. We should deal with it, not oops and die. This is a fundamental part of what hotplugging means, especially to users of consumer devices.

Or specific drivers for the PCI drivers need to be provided. The i82365 driver with all the PCI stuff is a horrible mess. I tried putting back the non-CardBus PCI support at one point. It was ugly, and didn't work. Someone's now working on a driver for the Intel i82092AA bridge, and I think that's the best answer for the other PCI-PCMCIA bridges too, rather than merging it back into the ISA i82365 code.

I'm trying to get some time to work on it, yes.

I was actually coming to the conclusion that I'd prefer just to ditch the whole of the existing PCMCIA support and rewrite it from scratch as a kind of hot-pluggable isapnp, which is basically what it is (when you remember that PCMCIA != CardBus).

dwmw2



_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Would you write up a proposal for this design that we could work from to come to a agreed design? You are probably the best person to start this process.

Thanks!
Miles

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Fairly rarely; there are currently around 15 types of cards that have override files for broken CIS information.

I would probably agree. Dealing with hot eject of a block device is fairly hard, though; beyond having the driver not oops, you also have to potentially deal with mounted filesystems going away.

-- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

So is it reasonable to use the same kind of fixup approach that we do with broken PCI devices? If the core code _really_ has to know about it it does, else the driver fixes it up?

Excuses, excuses :) It all wants fixing. Until you can have half-witted consumers plugging and unplugging PCMCIA devices at will, PCMCIA support on embedded consumer devices in Linux just isn't worth having.

dwmw2



_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

That sounds like two related mechanisms, not one. A "clean shutdown" request to a driver is a different thing than a "device is gone" notification, even if sometimes the end state will be similar.

I pretty much think both are needed ... clean shutdown is pretty similar to what should be done before a power management suspend, right? There are a bunch of other reasons to have a clean shutdown call.

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Would you enumerate these or else explain how we can gather this information ourselves? Is it just a matter of reading driver code or looking in specific configuration files in the pcmcia-cs package?

It seems like we should both:

1. Not OOPS when cards are ejected without warning

2. Have a cardmgr equivalent that schedules a device removal, triggering notices to a user to (for example) unmount partitions before removing a cardbus card.

It seems like there has been general agreement that a cardmgr replacement is needed, but (IIRC) the replacement hasn't been well-defined. Can we start nailing this down, so we can begin work on building it?

Miles

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

FWIW there has been some discussion between kernel developers about redesigning the module load/unload mechanism. Rusty Russell points out that controlling module use counts by exporting the module structure via the owner field does not work when the use count needs to be manipulated from an interrupt. In Rusty's case he is thinking about netfilter, but the same point applies to hot unplugging.

Current thinking is to change modules so they have four required functions, instead of the current two functions.

init: Allocate resources.
register: Make services available.
unregister: Remove services.
exit: Deallocate resources.

Module startup automatically calls init then register. Conditional shutdown checks for zero use count, calls unregister then flushes any other cpus that had just entered the module. If the flush was successful, call exit. If the flush was unsuccessful (somebody just started using the module), call register to make the services available again.

There is also an unconditional shutdown mode. Call unregister and even if the module is still in use, do not call register again. When the use count finally goes to zero, the exit routine is called and the module is removed.

I think this will help hot unplugging. When the device disappears, the driver internally marks its hardware as unusable and schedules an unconditional shutdown of itself, all out of the interrupt handler.

Unconditional shutdown calls unregister which stops any new code entering the module. The driver returns -EIO for all outstanding requests which will eventually result in the outstanding users calling close() or its equivalent and leaving the module. When the use count finally goes to zero, exit releases the resources and the module is removed. For built in code we do almost the same, the only difference is that built in code is not removed from memory.

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

David Woodhouse wrote:

[...]

Well, would care to elaborate on what the PCI mess is, exactly?

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?

[...]

Why do you think the codebase needs to be jettisoned?

Which do you think should happen first: you develop an exploratory implementation or have a general discussion of design issues?

My preference would be, if we decide to start fresh, that Linus participate
in the design process. This worked well during the early design stage for
the /sbin/hotplug design.

Miles

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

/etc/pcmcia/cis/*.dat are the override files; they are referenced from /etc/pcmcia/config.

-- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

See attached patch.

Some, yes. But I'm not sure there's enough there to justify doing so.

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.

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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

So there's enough information in the real CIS to identify the offending device? What problems are fixed by the replacement CIS structures? Missing resources &c? Anything which couldn't be overloaded by a driver in its probe() routine before attempting to activate the card?

dwmw2



_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Flushing ? How ?

Doing so means that there's a time where the device is unregistered illegitimately. Wouldn't it be simpler to take the big kernel lock for the check ? The unregistering would have to take it anyway.

This is definitely needed, but why two calls for that ? It would be easier to provide a callback to be called when the use count reaches zero.

Is that really necessary ? Can't a kernel thread be used ? It is much easier than coding in interrupt.

That is wise.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Er... I seem to have lied about the patch being attached.

Index: i82365.c
=================================RCS file: /net/passion/inst/cvs/linux/drivers/pcmcia/Attic/i82365.c,v retrieving revision 1.1.2.15

diff -u -r1.1.2.15 i82365.c
@@ -142,6 +142,18 @@
 MODULE_PARM(wakeup, "i");
 #endif
 
+#ifdef CONFIG_PCI
+static int pci_irq_list[8] = { 0 };	/* PCI interrupt assignments */
+static int do_pci_probe = 1;		/* Scan for PCI bridges? */
+static int fast_pci = -1;
+static int irq_mode = -1;		/* Override BIOS routing? */
+
+MODULE_PARM(pci_irq_list, "1-8i");
+MODULE_PARM(do_pci_probe, "i");
+MODULE_PARM(fast_pci, "i");
+MODULE_PARM(irq_mode, "i");
+#endif
+
 MODULE_PARM(do_scan, "i");
 MODULE_PARM(poll_interval, "i");
 MODULE_PARM(cycle_time, "i");

@@ -153,11 +165,27 @@
 MODULE_PARM(setup_time, "i");
 MODULE_PARM(cmd_time, "i");
 MODULE_PARM(recov_time, "i");
+#if defined(CONFIG_ISA) && defined(CONFIG_PCI)
+int pci_csc = 1;		/* PCI card status irqs? */
+int pci_int = 1;		/* PCI IO card irqs? */
+MODULE_PARM(pci_csc, "i");
+MODULE_PARM(pci_int, "i");
+#elif defined(CONFIG_ISA) && !defined(CONFIG_PCI)
+#define pci_csc		0
+#define pci_int		0
+#elif !defined(CONFIG_ISA) && defined(CONFIG_PCI)
+#define pci_csc		0
+#define pci_int		1		/* We must use PCI irq's */
+#else
+#error "No bus architectures defined!"
+#endif
 
+
 /*==================================*/
 
 typedef struct cirrus_state_t {
     u_char		misc1, misc2;
+    u_char		ectl1;
     u_char		timer[6];
 } cirrus_state_t;
 

@@ -165,6 +193,17 @@
     u_char		ctl, ema;
 } vg46x_state_t;
 
+typedef struct o2micro_state_t {
+    u_char		mode_a;		/* O2_MODE_A */
+    u_char		mode_b;		/* O2_MODE_B */
+    u_char		mode_c;		/* O2_MODE_C */
+    u_char		mode_d;		/* O2_MODE_D */
+    u_char		mhpg;		/* O2_MHPG_DMA */
+    u_char		fifo;		/* O2_FIFO_ENA */
+    u_char		mode_e;		/* O2_MODE_E */
+} o2micro_state_t;
+
+
 typedef struct socket_info_t {
     u_short		type, flags;
     socket_cap_t	cap;

@@ -176,9 +215,15 @@
 #ifdef CONFIG_PROC_FS
     struct proc_dir_entry *proc;
 #endif
+    u_char		pci_irq_code;
+    u_char		revision;
+#ifdef CONFIG_PCI
+    struct pci_dev	*dev;
+#endif
     union {
 	cirrus_state_t		cirrus;
 	vg46x_state_t		vg46x;
+	o2micro_state_t		o2micro;
     } state;
 } socket_info_t;
 

@@ -216,6 +261,18 @@
     IS_IBM, IS_RF5Cx96, IS_VLSI, IS_VG468, IS_VG469,
     IS_PD6710, IS_PD672X, IS_VT83C469,
 #endif
+#ifdef CONFIG_PCI
+    /*
+     * There are many cards which were supported by the i82365 driver
+     * in the standalone package, but which are not listed here.
+     * This is because they are CardBus-capable and hence now supported
+     * by the Yenta driver.
+     */
+    IS_I82092AA, IS_OM82C092G, 			/* Intel 82092-based */
+    IS_PD6729, IS_PD6730, 			/* Cirrus */
+    IS_OZ6729, IS_OZ6730, 			/* O2Micro  */
+    IS_UNK_PCI
+#endif
 } pcic_id;
 
 /* Flags for classifying groups of controllers */

@@ -251,7 +308,86 @@
     { "Cirrus PD672x", IS_CIRRUS },
     { "VIA VT83C469", IS_CIRRUS|IS_VIA },
 #endif
+#ifdef CONFIG_PCI
+    { "Intel 82092AA", IS_PCI },
+    { "Omega Micro 82C092G", IS_PCI },
+    { "Cirrus PD6729", IS_CIRRUS|IS_PCI },
+    { "Cirrus PD6730", IS_CIRRUS|IS_PCI },
+    { "O2Micro OZ6729", IS_O2MICRO|IS_PCI|IS_VG_PWR },
+    { "O2Micro OZ6730", IS_O2MICRO|IS_PCI|IS_VG_PWR },
+    { "Unknown", IS_PCI|IS_UNKNOWN },
+#endif
+};
+
+#ifdef CONFIG_PCI
+static struct pci_device_id i82365_pci_ids[] = {
+	{	
+		vendor: PCI_VENDOR_ID_INTEL,
+		device: PCI_DEVICE_ID_INTEL_82092AA_0,
+		subvendor: PCI_ANY_ID,
+		subdevice: PCI_ANY_ID,
+		class: 0, class_mask: 0,
+		driver_data: IS_I82092AA
+	}, {
+		vendor: PCI_VENDOR_ID_OMEGA,
+		device: PCI_DEVICE_ID_OMEGA_82C092G,
+		subvendor: PCI_ANY_ID,
+		subdevice: PCI_ANY_ID,
+		class: 0, class_mask: 0,
+		driver_data: IS_OM82C092G
+	}, {
+		vendor: PCI_VENDOR_ID_CIRRUS,
+		device: PCI_DEVICE_ID_CIRRUS_6729,
+		subvendor: PCI_ANY_ID,
+		subdevice: PCI_ANY_ID,
+		class: 0, class_mask: 0,
+		driver_data: IS_PD6729
+	}, {
+		vendor: PCI_VENDOR_ID_CIRRUS,
+		device: PCI_ANY_ID,
+		subvendor: PCI_ANY_ID,
+		subdevice: PCI_ANY_ID,
+		class: PCI_CLASS_BRIDGE_PCMCIA,
+		class_mask: 0xffff,
+		driver_data: IS_PD6730
+	}, {
+		vendor: PCI_VENDOR_ID_O2,
+		device: PCI_DEVICE_ID_O2_6729,
+		subvendor: PCI_ANY_ID,
+		subdevice: PCI_ANY_ID,
+		class: 0, class_mask: 0,
+		driver_data: IS_OZ6729
+	}, {
+		vendor: PCI_VENDOR_ID_O2,
+		device: PCI_DEVICE_ID_O2_6730,
+		subvendor: PCI_ANY_ID,
+		subdevice: PCI_ANY_ID,
+		class: 0, class_mask: 0,
+		driver_data: IS_OZ6730
+	}, {
+		vendor: PCI_ANY_ID,
+		device: PCI_ANY_ID,
+		subvendor: PCI_ANY_ID,
+		subdevice: PCI_ANY_ID,
+		class: PCI_CLASS_BRIDGE_PCMCIA,
+		class_mask: 0xffff,
+		driver_data: IS_UNK_PCI
+	},
+	{ /* Terminating entry */ }
+};
+
+static int i82365_pci_probe(struct pci_dev *dev, const struct pci_device_id *id);
+static void i82365_pci_remove(struct pci_dev *dev);
+
+static struct pci_driver i82365_pci_drv = {
+	name:		"i82365",
+	id_table:	i82365_pci_ids,
+	probe:		i82365_pci_probe,
+	remove:		i82365_pci_remove,
+	suspend:	NULL,
+	resume:		NULL
 };
+#endif
 
 #define PCIC_COUNT	(sizeof(pcic)/sizeof(pcic_t))
 

@@ -315,6 +451,22 @@
     i365_set(sock, reg+1, data >> 8);
 }
 
+#ifdef CONFIG_PCI
+
+static int __init get_pci_irq(u_short s)
+{
+    socket_info_t *t = &socket[s];
+    u8 irq;
+
+    irq = t->dev->irq;
+    if ((irq = 0) && (pci_csc || pci_int))
+	irq = pci_irq_list[t - socket];
+    if (irq >= NR_IRQS) irq = 0;
+    t->cap.pci_irq = irq;
+    return irq;
+}
+
+#endif
 /*===================================
 
     Code to save and restore global state information for Cirrus

@@ -384,6 +536,23 @@
 	if (p->misc2 & PD67_MC2_FREQ_BYPASS)
 	    strcat(buf, " [freq bypass]");
 	}
+#ifdef CONFIG_PCI
+    } else {
+	p->misc1 &= ~PD67_MC1_MEDIA_ENA;
+	p->misc1 &= ~(PD67_MC1_PULSE_MGMT | PD67_MC1_PULSE_IRQ);
+	p->ectl1 &= ~(PD67_EC1_INV_MGMT_IRQ | PD67_EC1_INV_CARD_IRQ);
+	flip(p->misc2, PD67_MC2_FAST_PCI, fast_pci);
+	if (p->misc2 & PD67_MC2_IRQ15_RI)
+	    mask &= (t->type = IS_PD6730) ? ~0x0400 : ~0x8000;
+	if ((irq_mode = 1) && get_pci_irq(s)) {
+	    /* Configure PD6729 bridge for PCI interrupts */
+	    p->ectl1 |= PD67_EC1_INV_MGMT_IRQ | PD67_EC1_INV_CARD_IRQ;
+	    t->pci_irq_code = 3; /* PCI INTA = "irq 3" */
+	    buf += strlen(buf);
+	    sprintf(buf, " [pci irq %d]", t->cap.pci_irq);
+	    mask = 0;
+	}
+#endif
     }
     if (!(t->flags & IS_VIA)) {
 	if (setup_time >= 0)

@@ -459,7 +628,79 @@
 
 #endif
 
+/*===================================
+
+    Code to save and restore global state information for O2Micro
+    controllers, and to set and report global configuration options.
+    
+===================================*/
+
+#ifdef CONFIG_PCI
+
+static void __init o2micro_get_state(u_short s)
+{
+    o2micro_state_t *p = &socket[s].state.o2micro;
+
+    if (((socket[s].revision & 0xff) = 0x34) || 
+	((socket[s].revision & 0xff) = 0x62)) {
+	p->mode_a = i365_get(s, O2_MODE_A_2);
+	p->mode_b = i365_get(s, O2_MODE_B_2);
+    } else {
+	p->mode_a = i365_get(s, O2_MODE_A);
+	p->mode_b = i365_get(s, O2_MODE_B);
+    }
+    p->mode_c = i365_get(s, O2_MODE_C);
+    p->mode_d = i365_get(s, O2_MODE_D);
+}
+
+static void o2micro_set_state(u_short s)
+{
+    o2micro_state_t *p = &socket[s].state.o2micro;
+
+    if (((socket[s].revision & 0xff) = 0x34) || 
+	((socket[s].revision & 0xff) = 0x62)) {
+	i365_set(s, O2_MODE_A_2, p->mode_a);
+	i365_set(s, O2_MODE_B_2, p->mode_b);
+    } else {
+	i365_set(s, O2_MODE_A, p->mode_a);
+	i365_set(s, O2_MODE_B, p->mode_b);
+    }
+    i365_set(s, O2_MODE_C, p->mode_c);
+    i365_set(s, O2_MODE_D, p->mode_d);
+}
+
+static u_int __init o2micro_set_opts(u_short s, char *buf)
+{
+    o2micro_state_t *p = &socket[s].state.o2micro;
+    u_int mask = 0xffff;
 
+    p->mode_b = (p->mode_b & ~O2_MODE_B_IDENT) | O2_MODE_B_ID_CSTEP;
+    flip(p->mode_b, O2_MODE_B_IRQ15_RI, has_ring);
+    p->mode_c &= ~(O2_MODE_C_ZVIDEO | O2_MODE_C_DREQ_MASK);
+
+    if (p->mode_b & O2_MODE_B_IRQ15_RI) {
+	mask &= ~0x8000;
+	strcat(buf, " [ring]");
+    }
+    if (irq_mode != -1)
+	p->mode_d = irq_mode;
+    if (p->mode_d & O2_MODE_D_ISA_IRQ) {
+	strcat(buf, " [pci+isa]");
+    } else {
+	switch (p->mode_d & O2_MODE_D_IRQ_MODE) {
+	case O2_MODE_D_IRQ_PCPCI:
+	    strcat(buf, " [pc/pci]"); break;
+	case O2_MODE_D_IRQ_PCIWAY:
+	    strcat(buf, " [pci/way]"); break;
+	case O2_MODE_D_IRQ_PCI:
+	    strcat(buf, " [pci only]"); mask = 0; break;
+	}
+    }
+    return mask;
+}
+
+#endif
+
 /*===================================
 
     Generic routines to get and set controller options

@@ -475,6 +716,10 @@
     else if (t->flags & IS_VADEM)
 	vg46x_get_state(s);
 #endif
+#ifdef CONFIG_PCI
+    else if (t->flags & IS_O2MICRO)
+	o2micro_get_state(s);
+#endif
 }
 
 static void set_bridge_state(u_short s)

@@ -491,6 +736,10 @@
     if (t->flags & IS_VADEM)
 	vg46x_set_state(s);
 #endif
+#ifdef CONFIG_PCI
+    if (t->flags & IS_O2MICRO)
+	o2micro_set_state(s);
+#endif
 }
 
 static u_int __init set_bridge_opts(u_short s, u_short ns)

@@ -512,6 +761,10 @@
 	else if (socket[i].flags & IS_VADEM)
 	    m = vg46x_set_opts(i, buf);
 #endif
+#ifdef CONFIG_PCI
+	else if (socket[i].flags & IS_O2MICRO)
+	    m = o2micro_set_opts(s+i, buf);
+#endif
 	set_bridge_state(i);
 	printk(KERN_INFO "    host opts [%d]:%s\n", i,
 	       (*buf) ? buf : " none");

@@ -535,12 +788,15 @@
     DEBUG(2, "-> hit on irq %d\n", irq);
 }
 
-static u_int __init test_irq(u_short sock, int irq)
+static u_int __init test_irq(u_short sock, int irq, int pci)
 {
-    DEBUG(2, "  testing ISA irq %d\n", irq);
+    int csc = (pci) ? 0 : irq;
+
+    DEBUG(2, "  testing %s irq %d\n", pci?"PCI":"ISA", irq);
     if (request_irq(irq, irq_count, 0, "scan", irq_count) != 0)
 	return 1;
-    irq_hits = 0; irq_sock = sock;
+    irq_hits = 0;
+    irq_sock = sock;
     __set_current_state(TASK_UNINTERRUPTIBLE);
     schedule_timeout(HZ/100);
     if (irq_hits) {

@@ -550,7 +806,7 @@
     }
 
     /* Generate one interrupt */
-    i365_set(sock, I365_CSCINT, I365_CSC_DETECT | (irq << 4));
+    i365_set(sock, I365_CSCINT, I365_CSC_DETECT | (csc << 4));
     i365_bset(sock, I365_GENCTL, I365_CTL_SW_IRQ);
     udelay(1000);
 

@@ -560,7 +816,10 @@
     i365_set(sock, I365_CSCINT, 0);
     DEBUG(2, "    hits = %d\n", irq_hits);
     
-    return (irq_hits != 1);
+    if (pci)
+	    return (irq_hits = 0);
+    else
+	    return (irq_hits != 1);
 }
 
 #ifdef CONFIG_ISA

@@ -580,10 +839,10 @@
 	set_bridge_state(sock);
 	i365_set(sock, I365_CSCINT, 0);
 	for (i = 0; i < 16; i++)
-	    if ((mask0 & (1 << i)) && (test_irq(sock, i) = 0))
+	    if ((mask0 & (1 << i)) && (test_irq(sock, i, 0) = 0))
 		mask1 |= (1 << i);
 	for (i = 0; i < 16; i++)
-	    if ((mask1 & (1 << i)) && (test_irq(sock, i) != 0))
+	    if ((mask1 & (1 << i)) && (test_irq(sock, i, 0) != 0))
 		mask1 ^= (1 << i);
     }
     

@@ -611,6 +870,22 @@
 
 #endif /* CONFIG_ISA */
 
+#ifdef CONFIG_PCI
+static int __init pci_scan(u_short sock)
+{
+    socket_info_t *t = &socket[sock];
+
+    /* for PCI-to-PCMCIA bridges, just check for wedged irq */
+    irq_sock = sock; irq_hits = 0;
+    if (request_irq(t->cap.pci_irq, irq_count, 0, "scan", irq_count))
+	    return 1;
+    udelay(50);
+    free_irq(t->cap.pci_irq, irq_count);
+    DEBUG(2,"pci_scan: %d hits on IRQ %d\n", irq_hits, t->cap.pci_irq);
+    return (!irq_hits);
+}
+#endif /* CONFIG_PCI */
+
 /*==================================*/
 
 /* Time conversion functions */

@@ -629,7 +904,7 @@
 
 #ifdef CONFIG_ISA
 
-static int __init identify(u_short port, u_short sock)
+static int __init isa_identify(u_short port, u_short sock)
 {
     u_char val;
     int type = -1;

@@ -741,8 +1016,17 @@
     
     if (base = 0) printk("\n");
     printk(KERN_INFO "  %s", pcic[type].name);
-    printk(" ISA-to-PCMCIA at port %#x ofs 0x%02x",
-	       t->ioaddr, t->psock*0x40);
+#ifdef CONFIG_PCI
+    if (t->flags & IS_UNKNOWN)
+	    printk(" [%04x %04x]", t->dev->vendor, t->dev->device);
+    printk(" rev %02x", t->revision);
+    if (t->flags & IS_PCI)
+	    printk(" PCI-to-PCMCIA at slot %02x:%02x, port %#x",
+		   t->dev->bus->number, PCI_SLOT(t->dev->devfn), t->ioaddr);
+    else
+#endif
+	    printk(" ISA-to-PCMCIA at port %#x ofs 0x%02x",
+		   t->ioaddr, t->psock*0x40);
     printk(", %d socket%s\n", ns, ((ns > 1) ? "s" : ""));
 
 #ifdef CONFIG_ISA

@@ -754,13 +1038,27 @@
 	    mask |= (1<<irq_list[i]);
 #endif
     mask &= I365_MASK & set_bridge_opts(base, ns);
+#ifdef CONFIG_PCI
+    /* Can we use PCI interrupts for card status changes? */
+    if (pci_csc || pci_int) {
+	for (i = base; i < base + ns; i++)
+		if (!socket[i].cap.pci_irq || test_irq(i, socket[i].cap.pci_irq, 1)) break;
+	use_pci = (i=ns);
+    }
+#endif
 #ifdef CONFIG_ISA
     /* Scan for ISA interrupts */
     mask = isa_scan(base, mask);
-#else
-    printk(KERN_INFO "    PCI card interrupts,");
+#endif
+
+#ifdef CONFIG_PCI
+    if (!mask)
+	printk(KERN_INFO "    %s card interrupts,",
+	       (use_pci && pci_int) ? "PCI" : "*NO*");
+    if (use_pci && pci_csc)
+	printk(" PCI status changes\n");
 #endif
-        
+  
 #ifdef CONFIG_ISA
     /* Poll if only two interrupts available */
     if (!use_pci && !poll_interval) {

@@ -770,7 +1068,8 @@
 	    poll_interval = HZ;
     }
     /* Only try an ISA cs_irq if this is the first controller */
-    if (!use_pci && !grab_irq && (cs_irq || !poll_interval)) {
+    if (!(use_pci && pci_csc) && !grab_irq &&
+	(cs_irq || !poll_interval)) {
 	/* Avoid irq 12 unless it is explicitly requested */
 	u_int cs_mask = mask & ((cs_irq) ? (1<<cs_irq) : ~(1<<12));
 	for (cs_irq = 15; cs_irq > 0; cs_irq--)

@@ -785,7 +1084,7 @@
     }
 #endif
     
-    if (!use_pci && !isa_irq) {
+    if (!(use_pci && pci_csc) && !isa_irq) {
 	if (poll_interval = 0)
 	    poll_interval = HZ;
 	printk(" polling interval = %d ms\n",

@@ -798,6 +1097,8 @@
 	t[i].cap.features |= SS_CAP_PCCARD;
 	t[i].cap.map_size = 0x1000;
 	t[i].cap.irq_mask = mask;
+	if (!use_pci)
+	    t[i].cap.pci_irq = 0;
 	t[i].cs_irq = isa_irq;
     }
 

@@ -819,13 +1120,13 @@
 	return;
     }
 
-    id = identify(i365_base, 0);
-    if ((id = IS_I82365DF) && (identify(i365_base, 1) != id)) {
+    id = isa_identify(i365_base, 0);
+    if ((id = IS_I82365DF) && (isa_identify(i365_base, 1) != id)) {
 	for (i = 0; i < 4; i++) {
 	    if (i = ignore) continue;
 	    port = i365_base + ((i & 1) << 2) + ((i & 2) << 1);
 	    sock = (i & 1) << 1;
-	    if (identify(port, sock) = IS_I82365DF) {
+	    if (isa_identify(port, sock) = IS_I82365DF) {
 		add_socket(port, sock, IS_VLSI);
 		add_pcic(1, IS_VLSI);
 	    }

@@ -834,12 +1135,12 @@
 	for (i = 0; i < (extra_sockets ? 8 : 4); i += 2) {
 	    port = i365_base + 2*(i>>2);
 	    sock = (i & 3);
-	    id = identify(port, sock);
+	    id = isa_identify(port, sock);
 	    if (id < 0) continue;
 
 	    for (j = ns = 0; j < 2; j++) {
 		/* Does the socket exist? */
-		if ((ignore = i+j) || (identify(port, sock+j) < 0))
+		if ((ignore = i+j) || (isa_identify(port, sock+j) < 0))
 		    continue;
 		/* Check for bad socket decode */
 		for (k = 0; k <= sockets; k++)

@@ -857,6 +1158,47 @@
 
 #endif
 
+#ifdef CONFIG_PCI
+static void pcic_interrupt(int irq, void *dev,
+			   struct pt_regs *regs);
+
+static int i82365_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
+{
+    socket_info_t *s = &socket[sockets];
+    int type = id->driver_data;
+    unsigned long addr;
+    int ns;
+ 
+    dev->driver_data = (void *)sockets;
+    printk("i82365_pci_probe\n");
+
+    if (pci_enable_device(dev))
+	return -EIO;
+    
+    addr = dev->resource[0].start & ~1;
+    for (ns=0; ns < ((type = IS_I82092AA) ? 4 : 2); ns++) {
+	s[ns].dev = dev;
+	s[ns].cap.pci_irq = dev->irq;
+	pci_read_config_byte(dev, PCI_REVISION_ID, &s[ns].revision);
+	add_socket(addr, ns, type);
+    }
+
+    add_pcic(ns, type);
+    if (pci_csc && s[0].cap.pci_irq)
+	request_irq(dev->irq, pcic_interrupt, SA_SHIRQ, "i82365", pcic_interrupt);
+    return 0;
+
+}
+static void i82365_pci_remove(struct pci_dev *dev)
+{
+    u_short s = (u_short)dev->driver_data;
+    
+    if (pci_csc && socket[s].cap.pci_irq)
+	free_irq(dev->irq, pcic_interrupt);
+}
+
+#endif
+
 /*==================================*/
 
 static u_int pending_events[8];

@@ -980,6 +1322,20 @@
     *value |= (status & I365_CS_READY) ? SS_READY : 0;
     *value |= (status & I365_CS_POWERON) ? SS_POWERON : 0;
 
+#ifdef CONFIG_PCI
+    if (socket[sock].flags & IS_O2MICRO) {
+	status = i365_get(sock, O2_MODE_B);
+	*value |= (status & O2_MODE_B_VS1) ? 0 : SS_3VCARD;
+	*value |= (status & O2_MODE_B_VS2) ? 0 : SS_XVCARD;
+    } else if (socket[sock].type = IS_PD6729) {
+	status = pd67_ext_get(sock + (1-socket[sock].psock), PD67_EXTERN_DATA);
+	*value |= (status & PD67_EXD_VS1(socket[sock].psock)) ? 0 : SS_3VCARD;
+	*value |= (status & PD67_EXD_VS2(socket[sock].psock)) ? 0 : SS_XVCARD;
+    }
+    /* For now, ignore cards with unsupported voltage keys */
+    if (*value & SS_XVCARD)
+	*value &= ~(SS_DETECT|SS_3VCARD|SS_XVCARD);
+#endif
 #ifdef CONFIG_ISA
     if (socket[sock].type = IS_VG469) {
 	status = i365_get(sock, VG469_VSENSE);

@@ -1044,7 +1400,13 @@
     reg = i365_get(sock, I365_INTCTL);
     state->flags |= (reg & I365_PC_RESET) ? 0 : SS_RESET;
     if (reg & I365_PC_IOCARD) state->flags |= SS_IOCARD;
-    state->io_irq = reg & I365_IRQ_MASK;
+
+#ifdef CONFIG_PCI
+    if (socket[sock].cap.pci_irq)
+	    state->io_irq = socket[sock].cap.pci_irq;
+    else
+#endif
+	    state->io_irq = reg & I365_IRQ_MASK;
     
     /* speaker control */
     if (t->flags & IS_CIRRUS) {

@@ -1084,8 +1446,8 @@
     set_bridge_state(sock);
     
     /* IO card, RESET flag, IO interrupt */
-    reg = t->intr;
-    if (state->io_irq != t->cap.pci_irq) reg |= state->io_irq;
+    reg = t->intr | ((state->io_irq = t->cap.pci_irq) ?
+		     t->pci_irq_code : state->io_irq);
     reg |= (state->flags & SS_RESET) ? 0 : I365_PC_RESET;
     reg |= (state->flags & SS_IOCARD) ? I365_PC_IOCARD : 0;
     i365_set(sock, I365_INTCTL, reg);

@@ -1164,7 +1526,7 @@
     }
     
     /* Card status change interrupt mask */
-    reg = t->cs_irq << 4;
+    reg =  (t->cap.pci_irq ? t->pci_irq_code : t->cs_irq) << 4;
     if (state->csc_mask & SS_DETECT) reg |= I365_CSC_DETECT;
     if (state->flags & SS_IOCARD) {
 	if (state->csc_mask & SS_STSCHG) reg |= I365_CSC_STSCHG;

@@ -1261,6 +1623,13 @@
     mem->card_start = ((u_int)(i & 0x3fff) << 12) + mem->sys_start;
     mem->card_start &= 0x3ffffff;
     
+#ifdef CONFIG_PCI
+    /* Take care of high byte, for PCI controllers */
+    if (socket[sock].type = IS_PD6729) {
+	i365_set(sock, PD67_EXT_INDEX, PD67_MEM_PAGE(map));
+	addr = i365_get(sock, PD67_EXT_DATA) << 24;
+    }
+#endif
     DEBUG(1, "i82365: GetMemMap(%d, %d) = %#2.2x, %d ns, %#5.5lx-%#5."
 	  "5lx, %#5.5x\n", sock, mem->map, mem->flags, mem->speed,
 	  mem->sys_start, mem->sys_stop, mem->card_start);

@@ -1290,6 +1659,13 @@
     if (i365_get(sock, I365_ADDRWIN) & I365_ENA_MEM(map))
 	i365_bclr(sock, I365_ADDRWIN, I365_ENA_MEM(map));
     
+#ifdef CONFIG_PCI
+    /* Take care of high byte, for PCI controllers */
+    if (socket[sock].type = IS_PD6729) {
+	i365_set(sock, PD67_EXT_INDEX, PD67_MEM_PAGE(map));
+	i365_set(sock, PD67_EXT_DATA, (mem->sys_start >> 24));
+    }
+#endif
     base = I365_MEM(map);
     i = (mem->sys_start >> 12) & 0x0fff;
     if (mem->flags & MAP_16BIT) i |= I365_MEM_16BIT;

@@ -1332,6 +1708,12 @@
     char *p = buf;
     p += sprintf(p, "type:     %s\npsock:    %d\n",
 		 pcic[s->type].name, s->psock);
+#ifdef CONFIG_PCI
+    if (s->flags & (IS_PCI))
+	p += sprintf(p, "bus:      %02x\ndevfn:    %02x.%1x\n",
+		     s->dev->bus->number, PCI_SLOT(s->dev->devfn),
+		     PCI_FUNC(s->dev->devfn));
+#endif
     return (p - buf);
 }
 

@@ -1361,6 +1743,26 @@
     return (p - buf);
 }
 
+#ifdef CONFIG_PCI
+static int proc_read_pci(char *buf, char **start, off_t pos,
+			  int count, int *eof, void *data)
+{
+    struct pci_dev *dev = ((socket_info_t *)data)->dev;
+    char *p = buf;
+    u_int a, b, c, d;
+    int i;
+    
+    for (i = 0; i < 0xc0; i += 0x10) {
+	pci_read_config_dword(dev, i, &a);
+	pci_read_config_dword(dev, i+4, &b);
+	pci_read_config_dword(dev, i+8, &c);
+	pci_read_config_dword(dev, i+12, &d);
+	p += sprintf(p, "%08x %08x %08x %08x\n", a, b, c, d);
+    }
+    return (p - buf);
+}
+#endif
+
 static void pcic_proc_setup(unsigned int sock, struct proc_dir_entry *base)
 {
     socket_info_t *s = &socket[sock];

@@ -1370,15 +1772,26 @@
 
     create_proc_read_entry("info", 0, base, proc_read_info, s);
     create_proc_read_entry("exca", 0, base, proc_read_exca, s);
+#ifdef CONFIG_PCI
+    if (s->flags & IS_PCI)
+	create_proc_read_entry("pci", 0, base, proc_read_pci, s);
+#endif
     s->proc = base;
 }
 
 static void pcic_proc_remove(u_short sock)
 {
     struct proc_dir_entry *base = socket[sock].proc;
-    if (base = NULL) return;
+
+    if (base = NULL) 
+	return;
+
     remove_proc_entry("info", base);
     remove_proc_entry("exca", base);
+#ifdef CONFIG_PCI
+    if (socket[sock].flags & IS_PCI)
+	remove_proc_entry("pci", base);
+#endif
 }
 
 #else

@@ -1523,12 +1936,19 @@
     printk(KERN_INFO "Intel PCIC probe: ");
     sockets = 0;
 
+#ifdef CONFIG_PCI
+    if (do_pci_probe)
+	pci_register_driver (&i82365_pci_drv);
+#endif
 #ifdef CONFIG_ISA
     isa_probe();
 #endif
-
     if (sockets = 0) {
 	printk("not found.\n");
+#ifdef CONFIG_PCI
+	if (do_pci_probe)
+	    pci_unregister_driver (&i82365_pci_drv);
+#endif
 	return -ENODEV;
     }
 

@@ -1537,7 +1957,7 @@
     if (grab_irq != 0)
 	request_irq(cs_irq, pcic_interrupt, 0, "i82365", pcic_interrupt);
 #endif
-    
+
     if (register_ss_entry(sockets, &pcic_operations) != 0)
 	printk(KERN_NOTICE "i82365: register_ss_entry() failed\n");
 

@@ -1567,6 +1987,11 @@
     if (grab_irq != 0)
 	free_irq(cs_irq, pcic_interrupt);
 #endif
+#ifdef CONFIG_PCI
+    if (do_pci_probe)
+	pci_unregister_driver (&i82365_pci_drv);
+#endif
+
     for (i = 0; i < sockets; i++) {
 	/* Turn off all interrupt sources! */
 	i365_set(i, I365_CSCINT, 0);

Index: i82365.h
=================================RCS file: /net/passion/inst/cvs/linux/drivers/pcmcia/Attic/i82365.h,v retrieving revision 1.1.2.2

diff -u -r1.1.2.2 i82365.h
@@ -132,4 +132,9 @@
 
 #define I365_REG(slot, reg)	(((slot) << 6) + reg)
 
+#define  O2_MODE_D_IRQ_MODE     0x03
+#define  O2_MODE_D_IRQ_PCPCI    0x00
+#define  O2_MODE_D_IRQ_PCIWAY   0x02
+#define  O2_MODE_D_IRQ_PCI      0x03
+
 #endif /* _LINUX_I82365_H */

dwmw2



_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Upon further reflection (and OK, maybe a cup of tea or two), I think I am going to try to abstract the bus access functions.

Rather than making pcmcia_enable_{device,resource} visible to the core code and card drivers to enable mapping of certain resources to the host, this should probably be handled internally to the socket driver.

Not everything nowadays is an i82365, the bridge chip the PCMCIA spec appears to have been written for. Many of the interesting toys I've encountered recently don't have to muck about with remapping address ranges - the SH3 expects you to map Area 5 and 6 to PCMCIA sockets and the IO/attribute lines are taken from the higher bits of the address.

So the socket drivers should provide access functions for the socket's address ranges - {attr,mem,io}_{read,write}{8,16,32} and {attr,mem,io}_copy{to,from}. Mostly, they'll be a simple case of adding an offset to the requested address and doing the requested operation.

For the now degenerate case where the bridge has to be configured to map certain addresses, that can be handled internally to the socket driver reasonably efficiently. The common case will be that the functions will check, find that there's a window currently pointing at the right place, and will use it. Sometimes they'll need to change one of the windows to point at the requested address - but not often.

I spent a long time trying to avoid this abstraction in the MTD code, before someone eventually convinced me that unconditional branches really aren't that difficult for modern CPUs to predict, and the increased simplicity of the 'map' abstraction was better.

dwmw2




_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Problems like cards that say they are parallel port devices when they are serial cards, cards that say they are serial devices when they are multifunction ethernet/modem cards, and cards that have malformed data structures that can't be interpreted at all.

Nothing that can't be overloaded in a driver. But things that were sufficiently ugly that I did not want to write special case code with lots of hard-wired information.

I think it may also be more space-efficient to code this information in CIS structures than to write special case code to handle all the bugs.

-- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Here's an overview of where we are now.

(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?)

Yes. This seems straightforward.

(Discussion has started on linux-hotplug-devel)

===============

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)

--------------

(Rusty Russell and other kernel developers are looking into related improvements. Also, discussion has started on linux-hotplug-devel)

--------------

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?

===============

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).

---------------

(David Woodhouse will explore fixing this problem) (Discussion has started on linux-hotplug-devel)

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Flushing ? How ?

Doing so means that there's a time where the device is unregistered illegitimately. Wouldn't it be simpler to take the big kernel lock for the check ? The unregistering would have to take it anyway.

This is definitely needed, but why two calls for that ? It would be easier to provide a callback to be called when the use count reaches zero.

Is that really necessary ? Can't a kernel thread be used ? It is much easier than coding in interrupt.

That is wise.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Hi David (H),

I am wondering how you managed to get adequate test coverage for pcmcia-cs. Did any manufactures donate or loan equipment to you for testing? If not, did you determine some subset of hardware that you could use to exercise the majority of your drivers' functionality? If so, could you send me a list of the devices you test with?

The point is that I'd like to volunteer to do a large chunk of the testing for the in-kernel PCMCIA support. How would you suggest I go about this? If you can give me a list of hardware that is most widely used in the pcmcia-cs user community, I could go out and build a collection of those devices.

Lastly, if you know pcmcia-cs users who might be willing to climb out onto the bleeding edge, would you ask them if they would be willing to help?

Many thanks!

Miles

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I'm going to finish my current projects first :)

Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I'm not sure I'd want module "use" count to be affected by plugging and unplugging, but I'd like to have that kind of way to track the number of devices associated with a module! Normal users won't expect to see devices become unusable (by driver removal) except by disconnecting, for all that developers should still be able to hotswap the drivers that aren't actively using the device.

I'll have to think on this a bit ... seems initially plausible, but it'll need to fit neatly with suspend/resume and probe/disconnect processing and I'll want to think about that. All of those involve managing some sort of resource or service. I can't think of many resources/services that really ought to be managed at the _module_ level rather than at the granularity of individual devices ... except for modules that don't hold device drivers, maybe!

Maybe it won't be detected in_irq() though. For example, USB device drivers typically have their disconnect() routines called by real threads. ("khubd", except for root hubs.)

Also, there's the issue that modules can manage multiple devices. Just because someone unplugged one <foo> adapter doesn't mean the others should get brought down and the driver removed!!

Then clearly it should not be used with hot-unplug, since driver modules are typically expected to handle multiple similar devices. Unplug of one mustn't affect the others.

Until that last "module is removed", it sounded like a reasonable description of what a usb or pci disconnect() routine has to cause when it's told that a device has gone away.

I'd like to see that be "built-in modules or ones still coupled to some connected device" ... so that when the last device owned by the module goes away, it becomes eligible for removal.

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

As we look into developing PCMCIA support in the 2.4/2.5 kernel trees, in addition to reading the pcmcia-cs code to learn about problems with specific devices that need to be handled, David Hinds also a reference page that lists some a bunch of issues that are in varying degrees of resolution:

http://pcmcia-cs.sourceforge.net/ftp/BUGS

This may be a useful resource. I'll see whether David has time to update this page with a bit more detailed explanations of the problems. Some of the items are pretty vague. For example,

the Asix AX88190 chipset, which has several serious bugs and incompatibilities that render the regular pcnet_cs driver unusable

It would be nice to know exactly what those bugs and incompatibilities are. :-)

Anyhow, I hope this helps,

Miles

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[...]

David, as you work on this design, would you include a plan for supporting detection of devices that are already plugged in at boot time? This is something that David Brownell is already working on for PCI/Cardbus and USB. The solutions that DavidB is exploring leverage the usbmodules and pcimodules tools. We may need some corresponding tool to interact with the kernel PCMCIA stuff you are designing.

Please refer to David Brownell's message to linux-hotplug-devel (2-4-2001 @ 7:02PM).

BTW: I'll be exploring your design over the next few days and hope to at least have a bit of constructive feedback for you. BTW: It would be really great if you could talk the folks you are working with on LKML into joining the linux-hotplug-devel list.

Thanks for your hard work!

Miles

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Black magic :-). See synchronize_kernel() in Rusty's recent patch for hotswap cpus.

Yes, this small race is inherent in the quiesce model for module services. Worst case is a few open() calls get -ENODEV, but that can occur now during module unload and reload.

Only if the code that calls the module is also under BKL. That has not been true since 2.2, which is why module unloading has been such a problem since then.

If you leave the services registered, other code can reenter the module. To whole point of unregistering services is to prevent any new uses of the module while we wait for the remnant use count to drop to zero.

Something has to mark the hardware as unusable, say a flag which can be set from the interrupt. When I said "schedules an unconditional shutdown of itself" I meant schedule the shutdown from the interrupt but run the shutdown via a kernel thread. The shutdown code could sleep so it cannot be called directly from the interrupt.

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I was thinking of the model of one device, one module. But we have another model as well, one module handling multiple devices. All the state is internal to the module and not visible to the rest of the kernel. I wonder if we need per-device register and unregister calls as well as per-module.

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Have we considered the possibility that the kernel thread spawned by exec_usermodehelper could sleep on a wait queue if invoked too early in the boot sequence, and the kernel could call wake_up() on that wait queue after the root filesystem is mounted? That way, we can just forget about this special case.

Or is that still too early in the boot sequence? Do we need to wait for other filesystems to be mounted?

Thanks.

Now the listserver has finally seen fit to spit my ramblings back at me, I'm not really sure whether the bus->read/write functions are a good idea.

It depends how many existing drivers would need to be modified. For drivers which are only PCMCIA, it's OK; but introducing that extra overhead (little though it is) for existing drivers which handle devices on multiple busses is less clearly the right thing to do. (Note that we wouldn't do this for CardBus - only PCMCIA). Maybe we should go down the pcmcia_enable_resource() route after all.

But then again... are we going to need this anyway for dealing with multiple PCI(/other) busses?

dwmw2




_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

In particular, do you know of any way of getting hold of real PCMCIA flash devices (i.e. not CompactFlash)? Is anyone still making them?

dwmw2



_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Most certainly yes. You need proc and usbdevfs. usr or devfs are conceivable, too. Even var might be needed.

If you wish to wait, why not wait for activation by sysctl ?

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Hi David,

I have added Werner Heuser to the TO: since he
seems to be pretty knowledgeable about FlashCard
and SmartCard support. Check out his webpage on
the subject, here:

http://mobilix.org/smart_linux.html

Cheers,
Miles

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Oliver responding to David W:

I think that got batted around (I certainly thought about it) but it doesn't offer a way to guarantee some behaviors that I think are important. (Ones that the test12 patch, turning everything async, removed ... though the comments in 'usb.c' aren't updated.) Serializing the order for event reports is a concern: don't report unplugs before you report the plug-in of that device, keep the device identifiers stable.

For example, I know that some folk have been using hotplugging in setting security policies for the /proc/bus/usb/MMM/NNN device files (used in user mode driver APIs). To do that reliably, you must know that the name passed through /sbin/hotplug (DEVICE variable in the environment) is still going to point to the right device when the per-device setup scripts run ... rather than pointing to some different device. "usbdevfs" is optional so that issue doesn't show up in Linus' default kernel configuration, but that type of problem should have a good solution.

Design goal of USB hotplugging: don't _require_ usbdevfs in for most current devices. It doesn't, but "usbmodules" does. Maybe the next iteration of hotplug should do differently.

Of course, "hot" plugging is not the same thing as being present at boot time ... I think of these two as separate technical problems, which happen to need a common subroutine ("/sbin/hotplug usb" being the current implementation).

Right now the /etc/init.d/hotplug script runs as part of the normal setup sequence, with all those accessible.

The "boot time events" are all lost unless they can be inferred from "usbdevfs" or (for PCI) "procfs".

That is, sysctl to set the kernel "hotplug" string? Would that then invoke "/sbin/hotplug start", or would something else need to make sure all the relevant subsystems are well enough initialized?

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I suspect the way this "ought" to be done will involve some chitchat between the bus driver (USB, PCI, ...) and the module subsystem, and not be visible to most device drivers.

It might be as simple as the module use count is today, but tracking devices not opens. Developers would have a way to tell "rmmod" to ignore device count ... maybe "module device count goes to zero" could enable autoclean, not "module open count goes zero" as it stands today. (Just thinking out loud about the details, I'm not sure how that new model you sketched applies to use/open counts.)

- Dave

----- Original Message -----
From: "Keith Owens" <[email protected]>
To: <[email protected]>
Sent: Monday, February 05, 2001 2:13 AM
Subject: Re: Adding PCMCIA support to the kernel tree -- developers needed.

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Not sure if this might be of any interest to you:

http://www.everythinglinux.com.au/item.php3?id=MG6469&start=0&max=8&invcata@&invcatb=7&back=%2Fcategory.php3%3Fprodtype%3Dnormal%26invcata%3D40%26invcatb%3D7%26back%3D%252Fcat.php3%253Ftt%253D981442005%2526invcata%253D40%2526invcataname%253DHardware%2526invcatadesc%253DHardware%252Bthat%252Bworks%252Bwith%252BLinux%26tt%3D981442031

Miles

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Er... we can wait for arbitrary lengths of time in execve(). So events aren't serialised anyway, and cannot be if you report them by running a userspace helper like this. You'd have to have a queue which is read by a single userspace process (which could perhaps be spawned when the queue becomes non-empty).

Should be entirely feasible for a PCMCIA script to determine the devices present during boot too, rather than queuing the actual events, then.

I assumed this meant the threads would be spawned and wait, as I suggested, but instead of waiting till the rootfs is mounted, they'd wait for an explicit trigger from userspace, whether that's setting the 'hotplug' string or a new 'hotplug_trigger' sysctl. But that means we have kernel threads collecting waiting for userspace to trigger them, and I'm not sure that's a good idea.

dwmw2




_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I never got around to fully implementing it, because there are really quite few situations where it is needed. There is a PCMCIA card reader that connects to a parallel port, where every card access has to be virtualized. But it is overkill for bridges with different sorts of memory windowing. There are already Linux socket drivers for Motorola mpc8xx, Hitachi SuperH, and StrongARM processors that look nothing like an i82365.

-- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

The spec is actually quite general; the virtualized IO and memory access scheme is pretty much straight out of the spec.

Be sure that you need it. I originally liked the idea (otherwise I would not have implemented it), but it has not worked out to be useful so far.

-- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

What ones do you have? Are you using 16-bit cards or only CardBus cards?

The PCMCIA-HOWTO has a list. Some adapters do not power up in the correct interrupt delivery mode and the yenta driver doesn't have a way to tell it that a bridge must be put in PCI interrupt mode.

-- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

There's no need to wait until after spawning the threads. Check for activation before you spawn. If that check fails, write the request to a buffer. If the trigger is recieved, replay the buffer.

HTH
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I don't really understand why the /sbin/hotplug callout exists at all. If instead the kernel were to spit the event strings out of some FIFO device (character special or whatever) then hotplugd can perform all its actions nice and serially.

Plus we can buffer all the "insertion events" which occur from boot-time scanning so they're available when hotplugd starts up.

Confused.

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I had been thinking the same thing. I think Linus originally said "do it with /sbin/hotplug" and that's the way it went.

My suggestion would be a ring buffer that includes a jiffy (or other) timestamp before each event. That way it would be trivial for a hotplugd to replay whatever events it missed...

Jeff

Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Could we use netlink? Or does that not have the desired behaviour when the listener isn't yet present? We want it to queue the packets, not just drop them.

--
dwmw2

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I have thought more about it.
You cannot simply wait. In fact you need to cancel those requests to user space. If you simply replay the sequence of events you have scripts acting on device nodes that have already been reused. Simple waiting is even worse. You'd loose the defined order of events. The result wouldn't even be deterministic.

On the activation of user space hotplugging support plugging events must be faked and must reflect current hardware. Probably user space should be notified of the fact that these devices may already be in use.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

There is no defined order of events in the current scheme. Do not make the mistake of thinking that there is, just because it happens to look that way most of the time.

--
dwmw2

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

That is unfortunately true. And it _is_ a bug.
The original design had definite order. That was not a nice addition, it was a necessity. You cannot get stable behaviour unless you guarantee that the scripts don't race with each other.
The approach with a user space demon solves a part of this problem, but not all parts.
User space needs to acknowledge that it is finished dealing with one event _before_ the next event is pumped to user space _and_ before the device the event refers to is accessable from user space. That's the only way to get security if device nodes can be reused.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Not sure, don't know netlink that well. Interesting idea though... Queue skbs containing hotplug data onto a virtual network device.

Jeff

Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

From Oliver:

When I thought about this last year, my conclusion was that it SHOULD be OK to have multiple event orderings so long as all were correctly serialized with respect to essential criteria. Just as if they were database transactions that didn't interfere with each other. The configuration of a GNU/Linux operating environment is a transactable problem, and users have no business caring which hotplug action is handled first ... so long as each one is handled correctly.

I suspect there are solutions that don't involve faking, but there'd be a price in extra complexity. Userspace SHOULD be able to see if the device has a driver bound to it ... I'm not quite so sure about "in use", which I usually think of as meaning "opened".

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

One reason was to get rid of the added system costs of creating such a FIFO, creating a "hotplugd", then operating both of them (tying down system resources). After all, the kernel already has parsed event data in hand, and it's always going to be cheaper to allocate the hotplug agent resources for short periods than to keep them allocated at all times (order of 100 KBytes).

The first implementation was a way to get _away_ from yet another user mode daemon, and its costs. The tradeoff was some simple kernel code (less than 512 bytes) against some complex kernel code to create/manage such a FIFO, and even more code to decode the FIFO data and call the same user mode agent the kernel could call directly.

I don't recall Linus doing more than acknowledging that such boot-time solutions were proven ("kudzu" on RedHat) and could easily just call the same /sbin/hotplug "subroutine" used when hotplugging.

He did come up with the name "/sbin/hotplug" as a generic name that all kernel subsystems (not just USB :-) could use to deliver hotplug notifications ... with specific reference to 2.4 supporting USB, PCI, and network hotplugging.

Didn't "devfsd" rely on such a thing? But it only knows about
device files, not /proc/bus/* or network interfaces. Not relying on "devfs" was another requirement for the original hotplug work, but maybe that can be rethought for the 2.5 series.

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Originally they _were_ serialized, because the usermode helpers were called synchronously by threads that only reported the events in the appropriate sequence. That is, serialization between subsystems wasn't provided (shouldn't be, IMO), only within the subsystem (say USB or PCI, which provided the thread).

My short version of "why did that change" was that the addition of network hotplugging turned up some races (the network driver API wasn't designed for hotplugging, unlike USB or PCI, and some locks were held so usermode "ifconfig" could deadlock) and changing all that was the expedient way out. Andrew Morton can elaborate; from test5 through test11, hotplugging was synchronous, without any reported problems when used with USB.

By itself, a queue won't solve the problems. Entry #1: new device /proc/bus/usb/001/004 ... Entry #N: removes it ... Entry #M, new device reusing the /proc/bus/usb/001/004 name. Synchronization of some kind is needed. ("devfsd" dealt with some of these issues, not that I use it; there may be ideas woth stealing from it.)

This subproblem might get simpler if the hotplug notifications can't do more than identify a device type, and they can't access devices (for stuff like serial numbers, alternative configurations, and other such "extended type info") ... but that surely rules out some kinds of necessary response to hotplug notifications.

Modulo races between usermode code accessing devices using those names, and the kernel invalidating and reusing them, yes. "usbdevfs" lets those issues be solved by keeping device nodes in that namespace until the last open FD is gone, but there's a role for non-kernel code to play too (talk to the FS safely, which can't quite be done with the hotplug agent getting called asynchronously).

Not to overstate things: typical usage scenarios today (only a few devices, usage patterns still evolving) probably won't suffer too much from these problems. Yet.

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I don't understand the need to queue hot plug events that
occur before user level facilities are ready to handle them. For all devices that I am aware of, it is simple enough to scan the bus after initializing the hot plugging support and deal with the devices that are already plugged in at that point.

Perhaps someone could provide an example.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
[email protected]     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America

fax +1 408 261-6631 "Free Software For The Rest Of Us."

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Well, I'm glad I wasn't missing something :)

Yes, timestamps would probably be helpful.

Using netlink would tie hotplug to the presence of CONFIG_NET, which isn't really bad, but isn't really good, either.

Heck, you could just use printk:

tail -f /var/log/messages | hotplugd &

(joke).

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Well, you need to have your devices working earlier to eg boot from PCMCIA. Thus you need a way to safely switch from operation without user space support to operation with user space support.
You need to lock the bus so that you don't configure devices that have been replaced and after that unlock the bus.
You need at least a few sysctls to do that.

HTH
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

It was a deadlock, not a race. We were calling /sbin/hotplug net' from within register_netdevice, with rtnl_lock held. /sbin/hotplug then called ifconfig up', which wanted to claim rtnl_lock.

My third (and as yet unapplied) call_usermodehelper patch rearranges the calls to '/sbin/hotplug net' so they happen outside the rtnl_lock, so I think we could use synchronous-exec mode there. (We don't have synchronous exec mode at present - that was the other part of the patch).

Look. If we really think we need call_usermodehelper to be synchronous then let's make a swift and solid decision, present a good case to the boss.

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Device naming worries me.

Suppose we were able to make an entire "hotplug" transaction synchronous and correctly serialised. So when I "insert" my 3c501, the driver load and the open all happen safely and serially.

Well, I still want to provide a consistent and predictable ordering of this wrt the "hotplug" of my Acenic card.

Why? Because I don't want them to be randomly assigned "eth0" or "eth1" depending on which way the wind is blowing.

This means, I think, that we want *global* serialisation of all hotplug activity. *never* do more than one thing at a time. So all driver loads and opens will happen strictly, synchronously in scan order.

Nice, simple, and can't be done.

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

You're right, it _can_ be done by synthesizing hotpluf events from the initscripts. In fact, that's how it must be done.

It simply seems nicer to have just one way of doing things, IMO.

But you still will need to special-case things which are required to get a successful boot. I confess I haven't thought about this too hard.

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Stop. Step back and think.

Why don't you want the name to change?

Surely what you actually mean to say is that you don't want stuff to break because the name has changed. Be that because the name didn't actually change, or be that just because stuff didn't break - we just want it not to break.

Identifying devices by something more constant than the name which the kernel happens to have assigned to them today is not difficult.

dwmw2




_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

No undue haste please. Let's do it right the first time.

We do agree that device addition must be processed fully, before device removal is processed, don't we ?

Then we have the problem of device node reuse. It means that
a user space script for addition of a new device must not be run before all removal handlers are completed.
At least I see no alternative.

But I am not sure that synchronous operation is free of deadlocks. What happens if a CardBus USB Controller with devices attached is plugged in ?

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I am afraid it cannot be simply done from the init scripts. Simply parsing proc has an unavoidable race condition. You need to lock it.

HTH
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Oh that's very true. The current scheme of assigning names by scan order sucks seriously - if you swap your NICs around, *everything* breaks.

Andi has a little app which renames interfaces based on their MAC address, using SIOCSIFNAME, which is a perfectly sensible thing to do, IMO.

But:

- We don't want to have anything which is *worse* than what we currently have and

- I'm only talking about netdevices. What happens with other types of device if the discovery order is randomised? I dunno.

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Usually a smart thing to do when designing anything, even if you're not in marketing! :-)

The word I use for that characteristic is a "stable" name. As in, "Device names visible outside the kernel should be stable, so you can label devices and use those names in shell scripts and sysadmin forms."

Names based on physical connectivity (PCI slot, port on USB hub, etc) are stable almost by definition; they change only when you connect things differently. Some names are more stable than that ... unique serial numbers (like Ethernet addresses) can help.

Names like "eth0" aren't stable, nor are /proc/bus/usb names, but /proc/bus/pci names are. If "acenic" used "pdev->slot_name" not "eth%d" for its interface names, that driver would have stable naming right now.

I read recently that "stable" names were a goal of "devfs", so I wonder if that "stable" is my "stable".

No -- using "stable" names would solve that! Serialization between subsystems would be a bug in need of fixing. Serialization within individual subsystems is likely though.

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Andrew Morton wrote:

[...]

It appears that we currently only have representation of USB, PCI, PCMCIA and Network driver/bus developers in this discussion. Is that as it should be? It seems to me that the topic of device detection and configuration is quite important to get right for all hotpluggable busses. Should we be extending invitations to others?

It's clear that there are major usability problems that arise from the lack of a MAC address equivalent for all hardware devices.

As David Brownell mentioned, the typical usage pattern (at least for USB) seems to be that just a few devices are connected and usually not more than one device of a given type. The confusion sets in when there are multiple USB mice, keyboards, videocams, etc. If XFree86 ever gets support for multi-headed consoles with support for dedicated mice and keyboards per console, getting the mapping from physical device to logical device (for example, /dev/input/mouse[1-4]) to stay consistent would be really helpful. I believe that this feature is actively being developed for XFree86, BTW.

Probably the most that can be hoped for is that we develop a method of locking down the mapping between logical device interfaces for those devices that have unique identifiers.
Miles

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I said, "scan the bus *after* initializing the hot plugging
support and deal with devices that are already plugged in [...]" You may process a device twice this way, but user level software can detect this and synchronize when this is really necessary. In most cases, you just want to modprobe a module, which can safely be done multiple times, so it is not necessary to bother checking.

Also, since the races are done once the init script completes
(before any user logs in), you can safely do things like load the saved device settings without worrying about clobbering any work done before.

In cases where you really need to avoid doing something twice
(such as spawning a dhcp client on an ethernet port), you can do your synchronization at user level, by something like:

# "insert" script
netif=$1 # For example "eth0"
# /var/run was previous cleared earlier in the boot process, so # we know that if this directory exists, we have been called # twice.
if mkdir /var/run/$netif ; then
dhclient -pf /var/run/$netif/pid $netif &
fi

# "remove" script
netif=$1 # For example "eth0"
kill $(cat /var/run/netif/$netif/pid)
rm -rf /var/run/$netif

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
[email protected]     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America

fax +1 408 261-6631 "Free Software For The Rest Of Us."

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

The problem is that may try to configure a device that's no longer there, or worse a device that is being replaced this way. You need to tell the kernel that it must cease processing events on a bus that you are scanning.

That's the problem. You compute $1 and then you configure it without a guarantee that $1 is still the interface you thought it to be. It is a very small window, but I feel that we shouldn't design something which works only in most cases.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I think it'd be sensible to let the hotplug daemon not rename, but _assign a name/number_ to not only netdevices but every device it's notified about being created.

The daemon can do the decision - it has all the necessary information.

Vojtech Pavlik
SuSE Labs

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

That can always happen; synchronous or not. User waits till the hotplug script/daemon is just about to configure the device and viciously removes it.

You mean ignoring the 'device removed' interrupt and allowing the user to configure the absent device just because we told them it was there? I'm not utterly convinced by that.

How about assigning a unique ID to each _instance_ of each device (i.e. each time it's inserted it gets a new ID. We create a device with a name like eth-hotplug-3452 and then tell the usermodehelper about it. The usermodehelper can do whatever it needs to do to find out which socket it's plugged into, what its MAC address is, or whatever else it needs to decide whether it should be eth0 or eth1, and then renames it.

And if the device goes away in the meantime, that's trivially handled.

--
dwmw2

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

These are not enough. You must ensure that "remove" has finished before you start anything that reuses the device node.

Eg.: Printer 1 added -> printcap edited

      Printer 1 removed -> printcap edited
      Printer 2 added -> printcap edited

You see, changing the order of events 2 and 3 is wrong. You'd have the wrong interfaces in printcap.

At some level the function of devices enters the game.
The hotplugging events must be generated on the physical busses to allow module autoloading, yet they come into contact by the device nodes.

Both a disk on FC-AL in the next building and a PCMCIA SCSI controller share the same device node space.

The amount of locking needed to be provided by shell scripts worries me.

Then you'd need to have a stable name provided to the hotplug script. This is difficult, for several reasons.
a) You need devfs (which is not PC)
b) You know that name only after the driver is loaded. (You don't even know the number of names, multifunction devices and bridges)
c) You'd need to call after drivers have bound to interfaces.
d) There might be devices which have difficulties providing a stable name.

These are conflicting requirements. In fact you'd need _two_ scripts. One to load the driver, a second to configure the device the driver has bound to.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Well, in my opinion we should also consider non-hotpluggable busses, because even there it would make sense to use the same module loading mechanism. It's more flexible than the current modules.conf way.

Many devices do have serial numbers, that's OK. Other devices do at least have bus topology placement, ie. slot number on PCI, hub port on USB, etc.

If the devices can't be identified by a unique number, then bus topology is the only way how to describe which device is which, and thus is the right one.

Yes, it is. And yes, we need this. And bus topology (head #1 uses port #1 on the USB card, head #2 uses port #2, etc.) is the way how to find out which mouse is which.

I imagine it this way:

0) PCI layer finds a new device, registers it, calls the hotplug daemon passing the PCI IDs/class/prog-if and topology (/pci00.07.4)
1) Hotplug daemon checks the class/prog-if and loads usb-ohci module.
2) usb-ohci module senses a new device, registers it w/ USB layer.
3) USB layer calls hotplug daemon, telling it the USB IDs/descriptors and bus topology position (/pci00.07.4/usb0).
4) Hoptlug module sees it's a hub and thus it's handled by a built-in USB hub driver.
5) The hub driver enables the ports on the hub, usb-ohci sees a new device, registers it w/ USB layer.
6) USB layer calls hotplug daemon, telling it the USB IDs/descriptors and bus topology position (/pci00.07.4/usb0/usb3).
7) Hotplug daemon checks the descriptors and decides it's a HID device and loads hid module.
8) The hid module registers a new device on the Input virtual bus.
9) Input layer calls hotplug daemon, telling it the Input IDs/bitmaps and bus topology position (/pci00.07.4/usb0.3/input0).
10) Hotplug daemon checks the bitmaps and decides it's a mouse and loads mousedev.o and evdev.o.
11) Mousedev.o registers a new chardevice minor, so does evdev.o.

I'm not completely sure where to fit the device naming in, I'm thinking about two variants:

A) After step 11, Hotplug daemon is called by the char/block/scsi/net-device layer and the hotplug daemon decides about the minor number/name (based on IDs and topology path - /pci00.07.4/usb0.3/input0/mousedev0).

B) At every time the hotplug daemon is loading a module, it passes a name/number it wishes the new device that caused the load to be registered under. Example: Loading hid.o, register as 'input4'.

I think A is simpler and easier to do. It also will be fairly easy to configure.

B gives complete control of device numbering, even for devices on virtual busses. In the B case, only the last part of the topology would need to be passed. What do you think?

Vojtech Pavlik
SuSE Labs

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Removal can happen, replacement cannot happen in the synchronous mode. Removal can be dealt with by returning EIO.

Again removal is not the problem, replacement is.
And yes, while a configuration script is running the kernel should queue device addition events.
And to be absolutely correct you need to check the queue for obsolete events before you play it to user space.

Workable approach for net devices, but why bother with a name at all ? Let's add an ioctl to name by MAC. OK a temporary name might be a good idea.

That works for net devices, but what about everything else ?

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

IMO it needs not to be a true queue, but rather than a list of present devices which is then checked against a list that the daemon knows about already and the events would be then made to synchronize them.

Vojtech Pavlik
SuSE Labs

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Eeek! Keeping a 'this is what we think userland thinks' state scares me. It can and will get out of sync.

This is where the interface between PCMCIA socket drivers and the core code got it right, IMO. You make the current state available, and occasionally give hints like 'This bit may have changed. You might want to take a look."

Thinks.... a list of hotplug devices in a /proc file, listing some unique per-instance ID against the type, topological information and current name of the device. You don't send explicit add/remove events to userspace, just an "Oi. Look again".

?

--
dwmw2

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I am afraid that order is important unless the scripts are given a stable name.

printer 1 addition -> edit printcap printer 2 addition -> edit printcap printer 1 removal -> edit printcap

will leave you with lp1 as your printer name
If you reverse steps 2 and 3 you get lp0 as printer name.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

That doesn't have to be a problem. If your script is editing printcap and inserting the device name it's given in the entry for the new printer, with whatever queue name(s) are configured elsewhere, why does it matter?

--
dwmw2

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

If you were given that name. For USB at least you get an usbdevfs name at best.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Firstly, that would also happen if you queue the hot plugging
events. Secondly, this situation is detectable by the user level initialization script failing (in the dhcp example, dhclient would get an error). It is easy enough to have the initialization script release the locking resource when that happens (in my example, by doing an "rm -rf /var/run/$netif").

Even for the more elaborate case, where, say, a user quickly
inserts an ethernet card, removes it and then inserts a wireless ethernet card which might need a different initialization, my scheme would get it right because it does not look for existing devices until it has already initialized the hot plug event handling, since the only way that the first card could be detected is if the hot plugging facilties were in place in time to see its later removal and the insertion of the new card.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
[email protected]     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America

fax +1 408 261-6631 "Free Software For The Rest Of Us."

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Exactly that's the problem. What do you wish to do when the replacement has happened after you have decided to do something to the interface, but before you've started your action.

Let me make a diagramm

enable hotplugging
start scanning bus
decide to assign IP to eth0
eth0 goes away (eg leaving 802.11 zone) a PCMCIA ethernet card is plugged in
assign IP to eth0

The window is very small and in this case of little consequence, but for a design it is still unacceptable.

You need to prevent any changes to the bus while you do the scanning. Running hotplug support is not enough. You need further kernel support to do racefree scanning. It gets worse if you take into account interference with non hotpluggable busses (SCSI).
Therefore I suggest scanning in kernel space.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

See comments at end of message.

Hi,

I am leaving this message intact, because I think it's a good snapshot of
several important issues.

So, the process looks something like this:

Device detection
Module loads
Device nodes enabled
Usermode scripts (or daemon) run to
do things like launch programs to
upload data to a device via one of
its device nodes.

Now, we need to figure out a robust way to recover from devices being unplugged and new devices being inserted that reuse device nodes. Obviously, any usermode configuration scripts that fired off for the previous device will still be running and we'd then have two instances of that configuration script running and trying to access devices on the same device nodes. Not good.

So, it seems that we need a way of telling all usermode scripts (or daemons) to back out any work done that depends on a given device node when we discover that the associated device has been unplugged. We then need a method of having any new usermode scripts that will be accessing the same device nodes to wait until the previous script (or daemon) has completed the back out process.

Then there's the question of what to do when a user application has already been launched which will be expecting access to the first device. For example, I plug in a videocam and then unplug it, but my video viewing program has already been launched. Perhaps this isn't a huge problem. If I then connect a different videocam, it would reuse the video0 device node. Hmm.

Yes, this seems like a really messy situation.

Miles

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Yes. Relying on detection order for device naming in a hotplugging system is a nightmare, anyway.

So you have to give them some other names, not based on addition/removal order. Userspace (printcap in this case) will never be happy with names changing no matter how much we serialize.

Vojtech Pavlik
SuSE Labs

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I was assuming something that I suspect we should be considering as a goal (an "architectural" one?): names passed by hotplug agents must be stable.

Right now, PCI meets that requirement (PCI_SLOT).
USB does not, networking does not.

Before 2.4.0 went "final", USB changed its address assignment so its names (busnum/devnum) were less unstable: devnum is assigned round-robin. There's a patch I put together a while back to give USB devices stable names, but it's not integrated.

I'll have to think more about Vojtech's comments. I think I will likely want the kernel to guarantee some stable name (is that a place where devfs could really help?) and let all the mappings to "virtual" names (like "eth0") be managed separately.

Couldn't matter if the agent were passing the right stable names though, right?

Compiled code (C, Java, etc) accessing kernel configuration APIs can kick in at any time it's really needed, don't worry about that one!

Yes ...

"devfsd" is not PC for me, but I'm less clear why a "/devfs" wouldn't be fine. Anyone care to start a separate thread on such topics?

Device drivers can be viewed as adapters between namespaces:
loading a device driver may cause entries in other namespaces.

USB device "/proc/bus/usb/002/031" may be network interface "usb0". The lower level name (USB) is known before "usbnet" is loaded, but "usb0" isn't known till afterwards ... but then, USB hotplugging sees the USB name, and network hotplugging is what sees "usb0".

USB hotplug is called after the kernel gives drivers a chance to bind to interfaces.

For network devices, hotplug is called after the driver created and registered/named a new interface.

Then let them deal with it. If the busses provide stable names, then we can federate them in some namespace that can be used by layers above the busses. "pci-02:7.3" can be a PCI device, and any driver that has a hard time turning one stable name into another likely has other problems!

You mean like the difference between /etc/hotplug/*.agent (load driver FOO) and /etc/hotplug/*/FOO (configure each new device)? :-)

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Interesting notion, but I think there's still a need for a stable namespace, which no user mode program can invalidate by renaming.

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Right now there's no printer hotplugging support ... nothing calls out to userland "/dev/usb/lp0 was just born, have a cigar!".

In fact I'm unclear how much the different sorts of printer (USB, parallel, network, ...) all get autoconfigured. Is there anyone working on putting together all those answers?

- Dave

----- Original Message -----
From: "Oliver Neukum" <[email protected]>
To: "David Woodhouse" <[email protected]>
Cc: "Vojtech Pavlik" <[email protected]>; "Adam J. Richter" <[email protected]>; <[email protected]>
Sent: Wednesday, February 07, 2001 6:45 AM
Subject: Re: Adding PCMCIA support to the kernel tree -- developers needed.

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

It's hardcoded into many subsystems.

There's the little issue of a very limited device node space. That doesn't mean that I don't agree with the diagnosis. I just don't see a way to implement the remedy cleanly.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Oliver,

Since I think the device naming needs work (PCI/USB/... bus level, then levels above like "eth0", /dev/lp0, and so on) I'll just say that the interference issues should be globally removed by providing and using stable names (in the right ways :-).

That gets interesting. How would a usermode program request that, say, the PCI or USB devices now present all get "hotplug" events? I agree that it's likely easier to solve the locking issues "well" there, but wonder how those dots would get connected.

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

You don't necessarily have to expand it, you just need to use it with care.

Well, I think letting the hotplug program decide what the device will appear as (the name or possibly also major/minor numbers) could work?

Vojtech Pavlik
SuSE Labs

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Here are a couple of resources where we might be able to find people to connect up with regarding how to get printing working well in a hotplug environment:

http://sourceforge.net/foundry/printing
http://www.linuxprinting.org/summit.html

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Good idea.

For SCSI devfs does that. About other subsystems I don't know enough.

But stable names don't save you from a need to serialise due to reuse. In fact a stable name implies reuse, as it depends on bus location. Either you get unique or you get stable names.

Right, except for true reuse. See above.

This is the most theoretical way I have ever heard device drivers described :-)

True, but there's no equivalent for network hotplugging for other subsystems.

That's not enough.
The mapping between devices and nodes isn't 1:1 but 1:0-n
You need an agent run for every node and an agent for the device (to load the driver)

I am not sure. I think you need to call them independently.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I also said (different word, true) that the names don't invalidate (hence don't get reused!) while the agents operate. There were two constraints I put in that "minimal" set; you' ve focussed on the first one!

Yet. The stack we're looking at today has two layers: bus (USB, PCI), and "next" (network). Printers and disks will be layered above busses; PCMCIA is another bus.

I think I allowed for that already in that comment of mine you had
described as "theoretical"! (I was trying to describe the practice
of things in a general way ... surely that's one kind of theory. :-)

By "node" presumably you mean "filesystem node"? Because I can't see the sense of a device that doesn't show up in _any_ namespace (filesystem, netdev, etc). No software could access it, right?

Have a look at how the USB hotplug agent works; they're called independently, in that the per-device setup can get called even if the driver hasn't been loaded.

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

OK. I had overlooked that.

I see. However as soon as you take PCI into the picture, that's all devices. It begins to look like recreating devfs.

Yes, I was refering to those things living in /dev ;-) A device invisible to user space isn't useless.
A SCSI controller without devices attached is exactly that, yet it has its uses later.

I may be dense today. All I can see is usb.c::usb_new_device()

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I have a "3Com PCI 3CCFE575BT Cyclone CardBus" (lspci lists this device as a "3Com Corporation 3c575 [Megahertz] 10/100 LAN CardBus [rev 01]") and a "Belkin BusPort Mobile" (lspci gives "OPTi Inc. 82C861 [rev 10] [prog-if 10 [OHCI]]" for this device).

The full lspci output for them is:

01:00.0 Ethernet controller: 3Com Corporation 3c575 [Megahertz] 10/100 LAN CardBus (rev 01)
Subsystem: 3Com Corporation: Unknown device 5b57
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 10 min, 5 max, 64 set
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 1000 [size8]
Region 1: Memory at 10800000 (32-bit, non-prefetchable)
[size8]
Region 2: Memory at 10800080 (32-bit, non-prefetchable)
[size8]
Expansion ROM at 10400000 [size8K]
Capabilities: [50] Power Management version 1
Flags: PMEClk- AuxPwr- DSI- D1+ D2+ PME-
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: b7 10 57 51 07 00 10 02 01 00 00 02 00 40 00 00 10: 01 10 00 00 00 00 80 10 80 00 80 10 00 00 00 00 20: 00 00 00 00 00 00 00 00 90 00 00 00 b7 10 57 5b 30: 01 00 40 10 50 00 00 00 00 00 00 00 0b 01 0a 05 40: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 50: 01 00 01 76 00 00 00 00 00 00 00 00 00 00 00 00 60: 10 00 7c 4b 9d 9d 57 51 c9 c4 36 00 4e 56 50 6d 70: 00 30 09 00 10 00 7c 4b 9d 9d 10 20 00 00 06 00 80: a6 32 70 15 00 00 60 00 07 00 00 00 00 00 81 00 90: 13 03 43 49 53 20 04 01 01 57 51 04 06 03 01 00
a0: 00 00 00 05 0c 41 9a 01 b5 1e 01 55 02 30 ff ff
b0: 01 07 06 11 00 40 00 00 00 15 34 05 00 33 43 6f
c0: 6d 20 43 6f 72 70 6f 72 61 74 69 6f 6e 00 33 43
d0: 43 46 45 35 37 35 42 54 00 4c 41 4e 20 43 61 72
e0: 64 62 75 73 20 43 61 72 64 00 30 30 31 00 ff 21
f0: 02 06 01 05 06 00 80 80 80 80 19 ff ff ff ff ff

and

05:00.0 USB Controller: OPTi Inc. 82C861 (rev 10)
(prog-if 10 [OHCI])
Subsystem: OPTi Inc.: Unknown device c861
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 11000000 (32-bit, non-prefetchable)
[size=4K]
00: 45 10 61 c8 02 00 80 02 10 10 03 0c 00 00 00 00 10: 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 45 10 61 c8 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 00 00 40: 00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 01 26 00 30 33 33 33 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Now, I do have a couple of bugs I am currently documenting. One where, if I insert a card into a slot that was empty at boot time, an OOPS occurs and the PCMCIA/Cardbus slots become unusable. The other has to do with using these two cardbus cards simultaneously. Linus thinks this is related to my latency_timer settings, but I haven't been able to confirm this, yet.

I should note that for at least the 3c575, I have been using this card for about half a year with the yenta driver and it's worked great. The problems I mention only started showing up in the later kernels from the 2.4.0-test series.

Anyhow, I have used both of these cards without other trouble. If I have one of these cards inserted at boot time, I can load either 3c59x or usb-ohci and use the corresponding card.

Thanks. We'll refer to it.

Miles

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[...]

You cannot lock physical reality.

In any case, the doubt that I originally expressed was about
the need to queue hotplug events _before_ the hot plug system was initialized. In your example, the events occur after the hot plug system is initialized.

However, now that you mention it, let's talk about handling
events that occur after initialization. I think we can avoid the need to queue those events too.

First of all, we should recognize that for most hardware,
the events caused by unplugging are handled directly by the kernel, not by the user level hot plugging code. For example, with a DHCP configured ethernet, removal of the ethernet interface card should cause the socket that dhcp has open on the ethernet interface to return an IO exception condition, and dhclient should get -EIO and abort when it tries to execute the ioctl to check the status.

Secondly, there is a way to get this processing right
where necessary without the need to queue events (which can overflow, and involve maintiaining arbitrary large dynamic data strucutres). All you need is a "new" flag that the kernel would set when on a device when it is inserted. The hot plug code would be called by the kernel with an argument indicating what device to check, without necessarily even indicating whether it was a hot plug or a remove event.

	userland_hotplug_handler(dev)
	{
		// was_plugged_in[dev] is persistent data, perhaps
		// stored in a file.

		acquire_lock(dev);   // Flock some file; could just have
				     // one global lock.  Whatever.
		if (was_plugged_in[dev]
		    && (new[dev] || !is_plugged_in[dev])) {
			was_plugged_in[dev] = 0;
			handle_remove_event(dev);
		}
		if (new[dev]) {
			new[dev] = 0;
			if (is_plugged_in[dev]) {
				was_plugged_in[dev] = 1;
				handle_insert_event(device);
			}
		}
		old_status[dev] = new_status;
		release_lock(dev);
	}

	Under this scheme, if multiple events occur on a particular

device slot, they will basically end up being coallesced together, and the first call to /sbin/hotplug for this device will update the situation to reflect the present status of the device (generating possibly both an remove event and then an insert event), and the subsequent calls to /sbin/hotplug that were queued for that device will take no action.

This scheme is inspired by the way similar status changes are
accumulated by USB hubs, but it should be able to work for all of the hot plugging facilities if necessary.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
[email protected]     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America

fax +1 408 261-6631 "Free Software For The Rest Of Us."

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

To a certain extent you can. You cannot hide removal, but you can hide addition. That's enough.

No, it occurs while you are initialising the hotplug system. You cannot scan a bus without locking it.
While you lock the bus what do you do with the events ?

You could indeed do without queueing initial events, if you did scan the bus under lock.
Provided that you give stable names (David's definition) to the agents in order to be able to loose information about ordering of events.

I am afraid I have to disagree. Most hardware is associated with device nodes in /dev which retain their permission bits. You have to reset them on removal.

^ race condition, the condition you check for might change

and you may forget a removal event this way, which is bad

The problem is is_plugged_in[]. It has to come from the kernel in last consequence. To avoid the race condition in the code above, acquire_lock has to lock is_plugged_in[], too. That means it has a need for kernel support. Then what is the kernel supposed to do about events arriving while the lock is held ? Dropping them causes a race which can lead to events being lost. You have to queue them (or at least set a flag, if you use stable names).

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Do you have a ksymoops trace for that?

Well, we played with that and it didn't help.

You're getting a PCI target abort (or was it a master abort?). The Cardbus bridge is unhappy. I think we decided the NIC was generating the abort, and we don't know why. It's a messy one.

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

If you want stable names based on bus position then you absolutely need to expand it. For USB at least you have no other way to get a stable name.

I believe it could work, but at the same time I think it is a very bad idea.

a) How do you operate during system start ?
b) How do you do the transition ?
c) How do you handle locking ? You need total mutual exclusion.
d) How do you handle an error in the hotplug agent ?
e) What other algorithmus that couldn't be trivially implemented in kernel do you want to use ?

Either you use stable names, or you let the kernel decide the name and give it to the hotplug agent.
The first approach isn't all that good because it ruins things like /dev/videoX or /dev/audioX.
The second requires hotplug notification on device registration.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Seems sensible to me. It's a bit racy, but the read could be made atomic if desired. (Thinks: devfs).

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

You throw away information the kernel has for free.
You need to build a map of devices in user space, which is a single point of failure. You are required to serialise the agents. You are unable to handle errors.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I'm glad you like the scheme I described. I don't care about the naming much, as long as it works.

Depends on what you define as logical and physical. Yes, the "input bus" is a purely virtual bus which has no physical representation. Still it may behave like any other hotplugging bus, with input devices appearing and disappearing, as lower-level modules register/unregister them.

The topology paths I've given above are just an example, and just one I made up on the fly. However, I think they'd work:

/ is the host virtual bus
pci00.07.4 is subdevice 4 of device 7 on PCI bus 0.
usb0.3 is device in the fourth port (#3) on a hub attached
to the first port on the USB card
input0 is the first input device on the input bus

And I probably made a mistake calling the last 'mousedev0', it should have been

char13.32 which would be the mousedev device - a chardevice on

			major 13, minor 32.

In 'B' we wouldn't need to pass the whole 'topology path', instead passing just the last part of the path would be enough.

Vojtech Pavlik
SuSE Labs

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

But also a very exact one. Current namespaces (buses) include usb pci isapnp input serio gameport char block scsi net and others ...

There are many types of these 'adapters', for example a PCI gameport driver for the Live! soundcard is pci->gameport, the mousedev module is input->char, then there is for example the ohci driver which is pci->usb, or the a3d is gameport->input+gameport.

Vojtech Pavlik
SuSE Labs

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Actually I think that we need more than just devfs. Devfs stopped too early and focuses only on the userland interface (/dev/*). If we manage to get us stable names, we'll need more than devfs and I think that we'll also make devfs obsolete.

Vojtech Pavlik
SuSE Labs

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

True, if you don't want what's described below. But anyway, something like that is needed for user friendliness, noone will want to type the whole topology path each time he wants to access a device.

Either assign the numbers by detection order or not at all and assume the hotplug agent is started early from the root partition - then when it starts, it'll see the unhandled (new) devices.. Can't do much else anyway.

See above. There will be undetected devices, those will be handled by the hotplug agent. For those already assigned at kernel boot, either leave them as they are or rename them via some system call.

Uh, mutual exclusion of what? I can't handle a device in the bus path that's and one below/above it simultaneously. I can handle devices on different branches simultaneously. It's possible that the hotplug agent will want the same minor number for two different devices, one of these calls will fail and will have to be retried with a different number by the hotplug agent.

Any other problems?

By falling back to assign-first-available default behavior.

I want a config file, where the user can specify that:

a) The ethercard with MAC 00:06:08:fa:9c:dd is to be registered always as eth0

b) Any USB mouse that's connected to a hub connected to the first port of the USB card in first PCI slot is to be /dev/input/mouse2

c) Any IDE drive with serial number 8937298A is to be /dev/hdf

d) et similar.

You can't do this sanely in the kernel.

I think the hotplug agent should decide about the name.

Vojtech Pavlik
SuSE Labs

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

By detection order, else good bye to booting from PCMCIA, firewire, FC-AL, ...

You can retry, you are right. I failed to see that. But you seem to suffer from the name reuse race.

reality task A task B
plug in dev A
bind dev A to name 0
unplug dev A
unbind name 0
plug in dev B
bind dev B to name 0
do something arbitrary
to the dev associated
with name 0

If the kernel would select name 0, it could lock on name 0. With your scheme this is hard to do.

Nor do you absolutely need to.
You can already rename network devices by ioctl.
For everything else a humble symlink should do the job, shouldn't it ?

Else you introduce complexity without much gain.
And you need renaming in any case, as device names may have been assigned during boot.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Ok.

Unbind on name 0 should block until task A finishes the arbitrary stuff. Is there any problem with that? We could even have a 'setup finished' ioctl for this, though I think I'd prefer just having one task per action.

Yes, but with humble symlinks you will run out of minor/major numbers soon.

Yes. Symlinks would help here, however, you'd probably need devfs in that case.

Vojtech Pavlik
SuSE Labs

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

This would work provided that the lock is taken atomically with binding to the name.

Why is that ? Even if you assign numbers by the agent you would take them out of a pool of numbers the kernel could also use.
In both cases it would seem that devices use the same amount of numbers.

I can see devfs helping tremendously with providing stable names, but why is it necessary ?

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Could you elaborate on "more than devfs"?

I know some criticisms of devfs: it didn't get drivers out of the business of preallocating major/minor device numbers. (Why should there be so few /dev/input device nodes available?) And the "let a million symlinks bloom" role of devfsd isn't necessarily desired. "devfs" doesn't know about /proc/bus/... physical names (maybe shouldn't); it doesn't know about network interface names (maybe shouldn't).

One thing I think I see missing is a way to relate the "logical" names (like /dev/input/* or /dev/audio*) to physical ones (based on topology, like /proc/bus/*). That's something "cardmgr" does inside itself ("eth0" is pcmia slot 1) as I recall. It should be possible to set up a topology-based naming policy so that we never see "mouse999" style names, but only ".../kiosk42/mouse" style ones ... at least after the system has fully booted.

But I don't yet see all that adding up to something I could wrap my head around and use or implement ... needs more discussion! :-)

- Dave

----- Original Message -----
From: "Vojtech Pavlik" <[email protected]>
To: "Oliver Neukum" <[email protected]>
Cc: "David Brownell" <[email protected]>; <[email protected]>
Sent: Thursday, February 08, 2001 7:13 AM
Subject: Re: Adding PCMCIA support to the kernel tree -- developers needed.

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Yep, that's what I intended.

Actually, you're right. For some reason I was assuming the symlinks would have to point to stable names - unique at least for each topology path. This is not completely necessary, though.

It isn't needed - I was assuming the symlinks would have to point to stable names.

Vojtech Pavlik
SuSE Labs

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[ based on David Hinds' list ]

Exactly what is meant by "eject" though? "eject pcmcia-slot-1" can't exactly eject the drive, as it would for a CD or ZIP disc. And I think it might be good to avoid requiring each type of hotplug bus to have its own "eject" tool.

I think what's meant is "disconnect the drivers and do electrical shutdown". USB needs corresponding functionality. I did a patch a while back, which I'll submit soonish; it turns out to be helpful for a variety of user-mode tools. It's an ioctl on the /proc/bus/usb device files ... perhaps that approach should be incorporated into the /proc/bus/pci device file support.

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

For Compact PCI, what you describe below ("disconnect the drivers and do electrical shutdown") is called "quiescing" the device. It's essentially the same thing as opening the ejection handle on a board. The blue "safe to remove" LED on the board should be lit so the operator can see which board it is that can now be removed.

Overall, this seems to me like a reasonable interpretation of "eject" in cPCI-land.

Chris

-----Original Message-----
Date: Mon, 26 Feb 2001 09:47:49 -0800
From: David Brownell <[email protected]>
Subject: Re: Adding PCMCIA support to the kernel tree -- developers needed.
To: Miles Lane <[email protected]>,
Linux Hotplug <[email protected]>

[ based on David Hinds' list ]

Exactly what is meant by "eject" though? "eject pcmcia-slot-1" can't exactly eject the drive, as it would for a CD or ZIP disc. And I think it might be good to avoid requiring each type of hotplug bus to have its own "eject" tool.

I think what's meant is "disconnect the drivers and do electrical shutdown". USB needs corresponding functionality. I did a patch a while back, which I'll submit soonish; it turns out to be helpful for a variety of user-mode tools. It's an ioctl on the /proc/bus/usb device files ... perhaps that approach should be incorporated into the /proc/bus/pci device file support.

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Actually some PCMCIA sockets do have eject mechanisms. Powerbooks for example.

This was mostly what I had in mind.

-- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Does "cardctl eject 1" physically eject on those platforms?

Good. Seems like for PCI, we'll need to pay attention to the user feedback mechanisms, since this is important for the high availability hotplugging mechanisms (cPCI, Compaq "Hotplug PCI") that use indicator LEDs to help protect that mission-critical data, while we recently learned that some folk really like beeps on PC-Card form factor devices.

Without having looked at this, I'd like to think that the "quiesce the driver and hardware" functionality should be one code path, and the "give the right domain-specific feedback" paths might need to be different ... though I'd hope not. I think some of the patches Compaq put up on their hotplug site related to this stuff.

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

There is a patch to do it but I haven't included it in the regular driver distribution yet.

-- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel