Skip to contentSkip to conversation

more CardServices() removals (drivers/net/wireless)

PATCH In review Andres Salomon 6 participants 14 messages Dec 24, 2003 – Dec 26, 2003

Subsystems (3)
Network drivers SCSI Networking drivers (wireless)
lore
Share & tools
lore

Andres Salomon

author
#0 lore raw

PATCH 5/7 more CardServices() removals (drivers/net/wireless)

Part 5 of 7.

Revision: linux--mainline--2.6--patch-18
Archive: [email protected]
Creator: Andres Salomon <[email protected]>
Date: Sun Dec 21 21:08:50 EST 2003
Standard-date: 2003-12-22 02:08:50 GMT
Modified-files: drivers/net/pcmcia/3c574_cs.c
New-patches: [email protected]/linux--mainline--2.6--patch-18
Summary: CardServices() removal, pt. 5
Keywords:

Remove calls to CardServices(), part 5; 3c574_cs.c.

* added files

    {arch}/linux/linux--mainline/linux--mainline--2.6/[email protected]/patch-log/patch-18

* modified files

drivers/net/pcmcia/3c574_cs.c +20 -20
@@ -330,7 +330,7 @@
 	client_reg.event_handler = &tc574_event;
 	client_reg.Version = 0x0210;
 	client_reg.event_callback_args.client_data = link;
-	ret = CardServices(RegisterClient, &link->handle, &client_reg);
+	ret = pcmcia_register_client(&link->handle, &client_reg);
 	if (ret != 0) {
 		cs_error(link->handle, RegisterClient, ret);
 		tc574_detach(link);

@@ -369,7 +369,7 @@
 	}
 
 	if (link->handle)
-		CardServices(DeregisterClient, link->handle);
+		pcmcia_deregister_client(link->handle);
 
 	/* Unlink device structure, free bits */
 	*linkp = link->next;

@@ -387,8 +387,8 @@
 	ethernet device available to the system.
 */
 
-#define CS_CHECK(fn, args...) \
-while ((last_ret=CardServices(last_fn=(fn), args))!=0) goto cs_failed
+#define CS_CHECK(fn, ret) \
+  do { last_fn = (fn); if ((last_ret = (ret)) != 0) goto cs_failed; } while (0)
 
 static void tc574_config(dev_link_t *link)
 {

@@ -409,12 +409,12 @@
 
 	tuple.Attributes = 0;
 	tuple.DesiredTuple = CISTPL_CONFIG;
-	CS_CHECK(GetFirstTuple, handle, &tuple);
+	CS_CHECK(GetFirstTuple, pcmcia_get_first_tuple(handle, &tuple));
 	tuple.TupleData = (cisdata_t *)buf;
 	tuple.TupleDataMax = 64;
 	tuple.TupleOffset = 0;
-	CS_CHECK(GetTupleData, handle, &tuple);
-	CS_CHECK(ParseTuple, handle, &tuple, &parse);
+	CS_CHECK(GetTupleData, pcmcia_get_tuple_data(handle, &tuple));
+	CS_CHECK(ParseTuple, pcmcia_parse_tuple(handle, &tuple, &parse));
 	link->conf.ConfigBase = parse.config.base;
 	link->conf.Present = parse.config.rmask[0];
 

@@ -424,15 +424,15 @@
 	link->io.IOAddrLines = 16;
 	for (i = j = 0; j < 0x400; j += 0x20) {
 		link->io.BasePort1 = j ^ 0x300;
-		i = CardServices(RequestIO, link->handle, &link->io);
+		i = pcmcia_request_io(link->handle, &link->io);
 		if (i == CS_SUCCESS) break;
 	}
 	if (i != CS_SUCCESS) {
 		cs_error(link->handle, RequestIO, i);
 		goto failed;
 	}
-	CS_CHECK(RequestIRQ, link->handle, &link->irq);
-	CS_CHECK(RequestConfiguration, link->handle, &link->conf);
+	CS_CHECK(RequestIRQ, pcmcia_request_irq(link->handle, &link->irq));
+	CS_CHECK(RequestConfiguration, pcmcia_request_configuration(link->handle, &link->conf));
 
 	dev->irq = link->irq.AssignedIRQ;
 	dev->base_addr = link->io.BasePort1;

@@ -451,8 +451,8 @@
 	   the hardware address.  The future products may include a modem chip
 	   and put the address in the CIS. */
 	tuple.DesiredTuple = 0x88;
-	if (CardServices(GetFirstTuple, handle, &tuple) == CS_SUCCESS) {
-		CardServices(GetTupleData, handle, &tuple);
+	if (pcmcia_get_first_tuple(handle, &tuple) == CS_SUCCESS) {
+		pcmcia_get_tuple_data(handle, &tuple);
 		for (i = 0; i < 3; i++)
 			phys_addr[i] = htons(buf[i]);
 	} else {

@@ -466,9 +466,9 @@
 		}
 	}
 	tuple.DesiredTuple = CISTPL_VERS_1;
-	if (CardServices(GetFirstTuple, handle, &tuple) == CS_SUCCESS &&
-		CardServices(GetTupleData, handle, &tuple) == CS_SUCCESS &&
-		CardServices(ParseTuple, handle, &tuple, &parse) == CS_SUCCESS) {
+	if (pcmcia_get_first_tuple(handle, &tuple) == CS_SUCCESS &&
+		pcmcia_get_tuple_data(handle, &tuple) == CS_SUCCESS &&
+		pcmcia_parse_tuple(handle, &tuple, &parse) == CS_SUCCESS) {
 		cardname = parse.version_1.str + parse.version_1.ofs[1];
 	} else
 		cardname = "3Com 3c574";

@@ -564,9 +564,9 @@
 		return;
 	}
 
-	CardServices(ReleaseConfiguration, link->handle);
-	CardServices(ReleaseIO, link->handle, &link->io);
-	CardServices(ReleaseIRQ, link->handle, &link->irq);
+	pcmcia_release_configuration(link->handle);
+	pcmcia_release_io(link->handle, &link->io);
+	pcmcia_release_irq(link->handle, &link->irq);
 
 	link->state &= ~DEV_CONFIG;
 

@@ -608,7 +608,7 @@
 		if (link->state & DEV_CONFIG) {
 			if (link->open)
 				netif_device_detach(dev);
-			CardServices(ReleaseConfiguration, link->handle);
+			pcmcia_release_configuration(link->handle);
 		}
 		break;
 	case CS_EVENT_PM_RESUME:

@@ -616,7 +616,7 @@
 		/* Fall through... */
 	case CS_EVENT_CARD_RESET:
 		if (link->state & DEV_CONFIG) {
-			CardServices(RequestConfiguration, link->handle, &link->conf);
+			pcmcia_request_configuration(link->handle, &link->conf);
 			if (link->open) {
 				tc574_reset(dev);
 				netif_device_attach(dev);
#1 lore raw
Quoted 11 lines · Andres Salomon

Part 5 of 7.

[005-cs_remove.patch text/x-patch (6824 bytes)]
Revision: linux--mainline--2.6--patch-18
Archive: [email protected]
Creator: Andres Salomon <[email protected]>
Date: Sun Dec 21 21:08:50 EST 2003
Standard-date: 2003-12-22 02:08:50 GMT
Modified-files: drivers/net/pcmcia/3c574_cs.c

hmm, 3c574_cs was done in the other patch series.

I didn't receive patch 7/7. Was there one?

Could you please aggregate these a bit? One single patch for each driver subdir, say.

Thanks.

author
#2 lore raw

Sorry, I'm having issues w/ my dialup (and 5 was definitely the wrong patch). I've attached 5 and 7 (I'm not sure if 7 ever made it through). I broke the patches up so that I could CC separate maintainers, but my ISP's not making this easy for me. My apologies if anyone's getting these emails twice.

Quoted 13 lines · Andrew Morton
Quoted 11 lines · Andres Salomon

Part 5 of 7.

[005-cs_remove.patch text/x-patch (6824 bytes)]
Revision: linux--mainline--2.6--patch-18
Archive: [email protected]
Creator: Andres Salomon <[email protected]>
Date: Sun Dec 21 21:08:50 EST 2003
Standard-date: 2003-12-22 02:08:50 GMT
Modified-files: drivers/net/pcmcia/3c574_cs.c

Quoted 9 lines

hmm, 3c574_cs was done in the other patch series.

I didn't receive patch 7/7. Was there one?

Could you please aggregate these a bit? One single patch for each driver subdir, say.

Thanks.

Revision: linux--mainline--2.6--patch-34
Archive: [email protected]
Creator: Andres Salomon <[email protected]>
Date: Tue Dec 23 19:04:02 EST 2003
Standard-date: 2003-12-24 00:04:02 GMT
Modified-files: drivers/net/wireless/wavelan_cs.c
New-patches: [email protected]/linux--mainline--2.6--patch-34
Summary: CardServices() removal, act 2, pt. 5.
Keywords:

Remove calls to CardServices(), act 2, part 5; wavelan_cs.c.

* added files

    {arch}/linux/linux--mainline/linux--mainline--2.6/[email protected]/patch-log/patch-34

* modified files

drivers/net/wireless/wavelan_cs.c +20 -21
@@ -3802,7 +3802,7 @@
   printk(KERN_DEBUG "%s: ->wv_pcmcia_reset()\n", dev->name);
 #endif
 
-  i = CardServices(AccessConfigurationRegister, link->handle, &reg);
+  i = pcmcia_access_configuration_register(link->handle, &reg);
   if(i != CS_SUCCESS)
     {
       cs_error(link->handle, AccessConfigurationRegister, i);

@@ -3816,7 +3816,7 @@
 
   reg.Action = CS_WRITE;
   reg.Value = reg.Value | COR_SW_RESET;
-  i = CardServices(AccessConfigurationRegister, link->handle, &reg);
+  i = pcmcia_access_configuration_register(link->handle, &reg);
   if(i != CS_SUCCESS)
     {
       cs_error(link->handle, AccessConfigurationRegister, i);

@@ -3825,7 +3825,7 @@
       
   reg.Action = CS_WRITE;
   reg.Value = COR_LEVEL_IRQ | COR_CONFIG;
-  i = CardServices(AccessConfigurationRegister, link->handle, &reg);
+  i = pcmcia_access_configuration_register(link->handle, &reg);
   if(i != CS_SUCCESS)
     {
       cs_error(link->handle, AccessConfigurationRegister, i);

@@ -4018,16 +4018,16 @@
     {
       tuple.Attributes = 0;
       tuple.DesiredTuple = CISTPL_CONFIG;
-      i = CardServices(GetFirstTuple, handle, &tuple);
+      i = pcmcia_get_first_tuple(handle, &tuple);
       if(i != CS_SUCCESS)
 	break;
       tuple.TupleData = (cisdata_t *)buf;
       tuple.TupleDataMax = 64;
       tuple.TupleOffset = 0;
-      i = CardServices(GetTupleData, handle, &tuple);
+      i = pcmcia_get_tuple_data(handle, &tuple);
       if(i != CS_SUCCESS)
 	break;
-      i = CardServices(ParseTuple, handle, &tuple, &parse);
+      i = pcmcia_parse_tuple(handle, &tuple, &parse);
       if(i != CS_SUCCESS)
 	break;
       link->conf.ConfigBase = parse.config.base;

@@ -4045,7 +4045,7 @@
   link->state |= DEV_CONFIG;
   do
     {
-      i = CardServices(RequestIO, link->handle, &link->io);
+      i = pcmcia_request_io(link->handle, &link->io);
       if(i != CS_SUCCESS)
 	{
 	  cs_error(link->handle, RequestIO, i);

@@ -4056,7 +4056,7 @@
        * Now allocate an interrupt line.  Note that this does not
        * actually assign a handler to the interrupt.
        */
-      i = CardServices(RequestIRQ, link->handle, &link->irq);
+      i = pcmcia_request_irq(link->handle, &link->irq);
       if(i != CS_SUCCESS)
 	{
 	  cs_error(link->handle, RequestIRQ, i);

@@ -4068,7 +4068,7 @@
        * the I/O windows and the interrupt mapping.
        */
       link->conf.ConfigIndex = 1;
-      i = CardServices(RequestConfiguration, link->handle, &link->conf);
+      i = pcmcia_request_configuration(link->handle, &link->conf);
       if(i != CS_SUCCESS)
 	{
 	  cs_error(link->handle, RequestConfiguration, i);

@@ -4084,8 +4084,7 @@
       req.Attributes = WIN_DATA_WIDTH_8|WIN_MEMORY_TYPE_AM|WIN_ENABLE;
       req.Base = req.Size = 0;
       req.AccessSpeed = mem_speed;
-      link->win = (window_handle_t)link->handle;
-      i = CardServices(RequestWindow, &link->win, &req);
+      i = pcmcia_request_window(&link->handle, &req, &link->win);
       if(i != CS_SUCCESS)
 	{
 	  cs_error(link->handle, RequestWindow, i);

@@ -4096,7 +4095,7 @@
       dev->mem_end = dev->mem_start + req.Size;
 
       mem.CardOffset = 0; mem.Page = 0;
-      i = CardServices(MapMemPage, link->win, &mem);
+      i = pcmcia_map_mem_page(link->win, &mem);
       if(i != CS_SUCCESS)
 	{
 	  cs_error(link->handle, MapMemPage, i);

@@ -4170,10 +4169,10 @@
 
   /* Don't bother checking to see if these succeed or not */
   iounmap((u_char *)dev->mem_start);
-  CardServices(ReleaseWindow, link->win);
-  CardServices(ReleaseConfiguration, link->handle);
-  CardServices(ReleaseIO, link->handle, &link->io);
-  CardServices(ReleaseIRQ, link->handle, &link->irq);
+  pcmcia_release_window(link->win);
+  pcmcia_release_configuration(link->handle);
+  pcmcia_release_io(link->handle, &link->io);
+  pcmcia_release_irq(link->handle, &link->irq);
 
   link->state &= ~DEV_CONFIG;
 

@@ -4772,10 +4771,10 @@
   client_reg.event_callback_args.client_data = link;
 
 #ifdef DEBUG_CONFIG_INFO
-  printk(KERN_DEBUG "wavelan_attach(): almost done, calling CardServices\n");
+  printk(KERN_DEBUG "wavelan_attach(): almost done, calling pcmcia_register_client\n");
 #endif
 
-  ret = CardServices(RegisterClient, &link->handle, &client_reg);
+  ret = pcmcia_register_client(&link->handle, &client_reg);
   if(ret != 0)
     {
       cs_error(link->handle, RegisterClient, ret);

@@ -4826,7 +4825,7 @@
 
   /* Break the link with Card Services */
   if(link->handle)
-    CardServices(DeregisterClient, link->handle);
+    pcmcia_deregister_client(link->handle);
     
   /* Remove the interface data from the linked list */
   if(dev_list == link)

@@ -4955,7 +4954,7 @@
 	  {
       	    if(link->open)
 	      netif_device_detach(dev);
-      	    CardServices(ReleaseConfiguration, link->handle);
+      	    pcmcia_release_configuration(link->handle);
 	  }
 	break;
 

@@ -4965,7 +4964,7 @@
       case CS_EVENT_CARD_RESET:
 	if(link->state & DEV_CONFIG)
 	  {
-      	    CardServices(RequestConfiguration, link->handle, &link->conf);
+      	    pcmcia_request_configuration(link->handle, &link->conf);
       	    if(link->open)	/* If RESET -> True, If RESUME -> False ? */
 	      {
 		wv_hw_reset(dev);

Revision: linux--mainline--2.6--patch-36
Archive: [email protected]
Creator: Andres Salomon <[email protected]>
Date: Tue Dec 23 19:17:46 EST 2003
Standard-date: 2003-12-24 00:17:46 GMT
Modified-files: drivers/net/wireless/ray_cs.c
New-patches: [email protected]/linux--mainline--2.6--patch-36
Summary: CardServices() removal, act 2, pt. 7.
Keywords:

Ok, this isn't really a CardServices() removal patch; it looks like someone already took care of this file. However, the modified CS_CHECK() macro doesn't fill in 'last_fn'. This patch fixes that.

* added files

    {arch}/linux/linux--mainline/linux--mainline--2.6/[email protected]/patch-log/patch-36

* modified files

drivers/net/wireless/ray_cs.c +16 -16
@@ -420,7 +420,7 @@
     client_reg.Version = 0x0210;
     client_reg.event_callback_args.client_data = link;
 
-    DEBUG(2,"ray_cs ray_attach calling CardServices(RegisterClient...)\n");
+    DEBUG(2,"ray_cs ray_attach calling pcmcia_register_client(...)\n");
 
     init_timer(&local->timer);
 

@@ -490,8 +490,8 @@
     is received, to configure the PCMCIA socket, and to make the
     ethernet device available to the system.
 =============================================================================*/
-#define CS_CHECK(fn, args...) \
-while ((last_ret=fn(args))!=0) goto cs_failed
+#define CS_CHECK(fn, ret) \
+do { last_fn = (fn); if ((last_ret = (ret)) != 0) goto cs_failed; } while (0)
 #define MAX_TUPLE_SIZE 128
 static void ray_config(dev_link_t *link)
 {

@@ -510,23 +510,23 @@
 
     /* This reads the card's CONFIG tuple to find its configuration regs */
     tuple.DesiredTuple = CISTPL_CONFIG;
-    CS_CHECK(pcmcia_get_first_tuple, handle, &tuple);
+    CS_CHECK(GetFirstTuple, pcmcia_get_first_tuple(handle, &tuple));
     tuple.TupleData = buf;
     tuple.TupleDataMax = MAX_TUPLE_SIZE;
     tuple.TupleOffset = 0;
-    CS_CHECK(pcmcia_get_tuple_data, handle, &tuple);
-    CS_CHECK(pcmcia_parse_tuple, handle, &tuple, &parse);
+    CS_CHECK(GetTupleData, pcmcia_get_tuple_data(handle, &tuple));
+    CS_CHECK(ParseTuple, pcmcia_parse_tuple(handle, &tuple, &parse));
     link->conf.ConfigBase = parse.config.base;
     link->conf.Present = parse.config.rmask[0];
 
     /* Determine card type and firmware version */
     buf[0] = buf[MAX_TUPLE_SIZE - 1] = 0;
     tuple.DesiredTuple = CISTPL_VERS_1;
-    CS_CHECK(pcmcia_get_first_tuple, handle, &tuple);
+    CS_CHECK(GetFirstTuple, pcmcia_get_first_tuple(handle, &tuple));
     tuple.TupleData = buf;
     tuple.TupleDataMax = MAX_TUPLE_SIZE;
     tuple.TupleOffset = 2;
-    CS_CHECK(pcmcia_get_tuple_data, handle, &tuple);
+    CS_CHECK(GetTupleData, pcmcia_get_tuple_data(handle, &tuple));
 
     for (i=0; i<tuple.TupleDataLen - 4; i++) 
         if (buf[i] == 0) buf[i] = ' ';

@@ -538,22 +538,22 @@
     /* Now allocate an interrupt line.  Note that this does not
        actually assign a handler to the interrupt.
     */
-    CS_CHECK(pcmcia_request_irq, link->handle, &link->irq);
+    CS_CHECK(RequestIRQ, pcmcia_request_irq(link->handle, &link->irq));
     dev->irq = link->irq.AssignedIRQ;
     
     /* This actually configures the PCMCIA socket -- setting up
        the I/O windows and the interrupt mapping.
     */
-    CS_CHECK(pcmcia_request_configuration, link->handle, &link->conf);
+    CS_CHECK(RequestConfiguration, pcmcia_request_configuration(link->handle, &link->conf));
 
 /*** Set up 32k window for shared memory (transmit and control) ************/
     req.Attributes = WIN_DATA_WIDTH_8 | WIN_MEMORY_TYPE_CM | WIN_ENABLE | WIN_USE_WAIT;
     req.Base = 0;
     req.Size = 0x8000;
     req.AccessSpeed = ray_mem_speed;
-    CS_CHECK(pcmcia_request_window, &link->handle, &req, &link->win);
+    CS_CHECK(RequestWindow, pcmcia_request_window(&link->handle, &req, &link->win));
     mem.CardOffset = 0x0000; mem.Page = 0;
-    CS_CHECK(pcmcia_map_mem_page, link->win, &mem);
+    CS_CHECK(MapMemPage, pcmcia_map_mem_page(link->win, &mem));
     local->sram = (UCHAR *)(ioremap(req.Base,req.Size));
 
 /*** Set up 16k window for shared memory (receive buffer) ***************/

@@ -561,9 +561,9 @@
     req.Base = 0;
     req.Size = 0x4000;
     req.AccessSpeed = ray_mem_speed;
-    CS_CHECK(pcmcia_request_window, &link->handle, &req, &local->rmem_handle);
+    CS_CHECK(RequestWindow, pcmcia_request_window(&link->handle, &req, &local->rmem_handle));
     mem.CardOffset = 0x8000; mem.Page = 0;
-    CS_CHECK(pcmcia_map_mem_page, local->rmem_handle, &mem);
+    CS_CHECK(MapMemPage, pcmcia_map_mem_page(local->rmem_handle, &mem));
     local->rmem = (UCHAR *)(ioremap(req.Base,req.Size));
 
 /*** Set up window for attribute memory ***********************************/

@@ -571,9 +571,9 @@
     req.Base = 0;
     req.Size = 0x1000;
     req.AccessSpeed = ray_mem_speed;
-    CS_CHECK(pcmcia_request_window, &link->handle, &req, &local->amem_handle);
+    CS_CHECK(RequestWindow, pcmcia_request_window(&link->handle, &req, &local->amem_handle));
     mem.CardOffset = 0x0000; mem.Page = 0;
-    CS_CHECK(pcmcia_map_mem_page, local->amem_handle, &mem);
+    CS_CHECK(MapMemPage, pcmcia_map_mem_page(local->amem_handle, &mem));
     local->amem = (UCHAR *)(ioremap(req.Base,req.Size));
 
     DEBUG(3,"ray_config sram=%p\n",local->sram);
#3 lore raw
In reply to Andrew Morton
Quoted 14 lines · Andrew Morton
Quoted 10 lines · Andres Salomon

Part 5 of 7.

[005-cs_remove.patch text/x-patch (6824 bytes)]
Revision: linux--mainline--2.6--patch-18
Archive: [email protected]
Creator: Andres Salomon <[email protected]>
Date: Sun Dec 21 21:08:50 EST 2003
Standard-date: 2003-12-22 02:08:50 GMT
Modified-files: drivers/net/pcmcia/3c574_cs.c

Quoted 6 lines

hmm, 3c574_cs was done in the other patch series.

I didn't receive patch 7/7. Was there one?

Could you please aggregate these a bit? One single patch for each driver subdir, say.

Ummm... there are many changes to the pcmcia net drivers in my net-drivers-2.5-exp queue. All can be classified as fixes, to a greater or lesser degree, and I would put those at a higher priority than API cleanups and such. Mainly patches from Russell King and Al Viro, but also some random fixes from lkml.

For the net drivers, please coordinate with me (and perhaps Russell King), otherwise it will turn into an even bigger mess.

My latest patchkits are always posted at
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/

Jeff

#4 lore raw
Quoted 3 lines · Jeff Garzik

Ummm... there are many changes to the pcmcia net drivers in my
net-drivers-2.5-exp queue.

That's OK; I just want to get all these ducks lined up in one place at this time. As we've decided to implement this API switchover we do need to make sure we got everything. Or at least understand which bits are missing and why.

Quoted 2 lines

My latest patchkits are always posted at
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/

Nothing there for 2.6.0?

#5 lore raw
Quoted 5 lines · Andrew Morton
Quoted 2 lines

My latest patchkits are always posted at
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/

Nothing there for 2.6.0?

A simple no-conflicts rediff, but ask and ye shall receive...

Patch:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-netdrvr-exp1.patch.bz2

Changelog:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-netdrvr-exp1.log

BK repo:
http://gkernel.bkbits.net/net-drivers-2.5-exp

#6 lore raw
Quoted 3 lines · Jeff Garzik

Patch:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-netdrvr-exp1.patch.bz2

Thanks, I mmified that. It let me drop a shower of other stuff, which is always welcome. Please send in new versions as-and-when needed.

I dropped all of kgdboe:

kgdb-over-ethernet.patch
kgdb-over-ethernet-fixes.patch
kgdb-CONFIG_NET_POLL_CONTROLLER.patch
kgdb-handle-stopped-NICs.patch
eepro100-poll-controller.patch
tlan-poll_controller.patch
tulip-poll_controller.patch
tg3-poll_controller.patch
8139too-poll_controller.patch
kgdb-eth-smp-fix.patch
kgdb-eth-reattach.patch
kgdb-skb_reserve-fix.patch

Matt, would you be able to take a look at resurrecting kgdboe based on the netpoll infrastructure sometime please?

George, I'm sorely tempted to fold all of these:

	kgdb-buff-too-big.patch
	kgdb-warning-fix.patch
	kgdb-build-fix.patch
	kgdb-spinlock-fix.patch
	kgdb-fix-debug-info.patch
	kgdb-cpumask_t.patch
	kgdb-x86_64-fixes.patch

into the base kgdb patch. Beware ;)

#7 lore raw
Quoted 23 lines · Andrew Morton
Quoted 3 lines · Jeff Garzik

Patch:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-netdrvr-exp1.patch.bz2

Thanks, I mmified that. It let me drop a shower of other stuff, which is always welcome. Please send in new versions as-and-when needed.

I dropped all of kgdboe:

kgdb-over-ethernet.patch
kgdb-over-ethernet-fixes.patch
kgdb-CONFIG_NET_POLL_CONTROLLER.patch
kgdb-handle-stopped-NICs.patch
eepro100-poll-controller.patch
tlan-poll_controller.patch
tulip-poll_controller.patch
tg3-poll_controller.patch
8139too-poll_controller.patch
kgdb-eth-smp-fix.patch
kgdb-eth-reattach.patch
kgdb-skb_reserve-fix.patch

Quoted 2 lines

Matt, would you be able to take a look at resurrecting kgdboe based on the netpoll infrastructure sometime please?

Yep, I'm working on it this very moment for my -tiny tree on top of Jeff's latest. Should have another cut soon.

Quoted 11 lines

George, I'm sorely tempted to fold all of these:

	kgdb-buff-too-big.patch
	kgdb-warning-fix.patch
	kgdb-build-fix.patch
	kgdb-spinlock-fix.patch
	kgdb-fix-debug-info.patch
	kgdb-cpumask_t.patch
	kgdb-x86_64-fixes.patch

into the base kgdb patch. Beware ;)

I did that here too, and I believe mbligh has as well.

Signature · 1 line
Matt Mackall : http://www.selenic.com : Linux development and consulting
#8 lore raw
Quoted 43 lines · Matt Mackall
Quoted 23 lines · Andrew Morton
Quoted 2 lines · Jeff Garzik

Patch:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-netdrvr-exp1.patch.bz2

Thanks, I mmified that. It let me drop a shower of other stuff, which is always welcome. Please send in new versions as-and-when needed.

I dropped all of kgdboe:

kgdb-over-ethernet.patch
kgdb-over-ethernet-fixes.patch
kgdb-CONFIG_NET_POLL_CONTROLLER.patch
kgdb-handle-stopped-NICs.patch
eepro100-poll-controller.patch
tlan-poll_controller.patch
tulip-poll_controller.patch
tg3-poll_controller.patch
8139too-poll_controller.patch
kgdb-eth-smp-fix.patch
kgdb-eth-reattach.patch
kgdb-skb_reserve-fix.patch

Quoted 2 lines

Matt, would you be able to take a look at resurrecting kgdboe based on the netpoll infrastructure sometime please?

Yep, I'm working on it this very moment for my -tiny tree on top of Jeff's latest. Should have another cut soon.

Quoted 10 lines

George, I'm sorely tempted to fold all of these:

	kgdb-buff-too-big.patch
	kgdb-warning-fix.patch
	kgdb-build-fix.patch
	kgdb-spinlock-fix.patch
	kgdb-fix-debug-info.patch
	kgdb-cpumask_t.patch
	kgdb-x86_64-fixes.patch
Quoted 5 lines
Quoted 1 line

into the base kgdb patch. Beware ;)

I did that here too, and I believe mbligh has as well.

I got side tracked by a customer with money :) The fold is fine with me, but I would like to know what went in.

By the way, in my looking at the network link stuff, I started wondering if it could not be done without modifying the card stuff. Here is what I see:

The poll routine just calls the interrupt handler. We only need the address of that routine and a generic poll function to do the indirect call. That address, once the link is up, can be found in the interrupt tables using the irq.

I haven't looked in detail at where we might find the address earlier, but I suspect it may be possible.

There is an issue around when we can start talking to gdb. I am not sure when the net cards are initialized, but it is after memory is available from the slab manager. I am not sure what else needs to be up, need help here. I keep finding myself wondering about a small memory manager to allow the network card to come up a bit sooner (like first C code).

We would also need to arrange to have the needed network parameters at that time, but we can do this using the CONFIG stuff, then override with command line if that is desired.

Thoughts and hints are welcome.

Signature · 3 lines
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
#9 lore raw
Quoted 11 lines · George Anzinger
Quoted 11 lines
Quoted 11 lines

George, I'm sorely tempted to fold all of these:

	kgdb-buff-too-big.patch
	kgdb-warning-fix.patch
	kgdb-build-fix.patch
	kgdb-spinlock-fix.patch
	kgdb-fix-debug-info.patch
	kgdb-cpumask_t.patch
	kgdb-x86_64-fixes.patch
Quoted 6 lines
Quoted 5 lines
Quoted 1 line

into the base kgdb patch. Beware ;)

I did that here too, and I believe mbligh has as well.

I got side tracked by a customer with money :)

A what?

Quoted 1 line

The fold is fine with me, but I would like to know what went in.

I'll send you the diffs when I do it.

Quoted 3 lines

By the way, in my looking at the network link stuff,

That's all changing. It will be based on the netpoll infrstructure, which is also used by netconsole. Matt has a little documentation file and for kgdb and I assume the netpoll code includes documentation of the kernel parameter format to supply IP addresses and such.

#10 lore raw
In reply to George Anzinger
Quoted 8 lines · George Anzinger

By the way, in my looking at the network link stuff, I started wondering if it could not be done without modifying the card stuff. Here is what I see:

The poll routine just calls the interrupt handler. We only need the address of that routine and a generic poll function to do the indirect call. That address, once the link is up, can be found in the interrupt tables using the irq.

Netpoll did exactly this in an earlier incarnation, but Jeff eventually convinced me it was problematic.

Signature · 1 line
Matt Mackall : http://www.selenic.com : Linux development and consulting
#11 lore raw
Quoted 10 lines · Matt Mackall
Quoted 3 lines · George Anzinger

By the way, in my looking at the network link stuff, I started wondering if it could not be done without modifying the card stuff. Here is what I see:

The poll routine just calls the interrupt handler. We only need the address of that routine and a generic poll function to do the indirect call. That address, once the link is up, can be found in the interrupt tables using the irq.

Netpoll did exactly this in an earlier incarnation, but Jeff eventually convinced me it was problematic.

I suppose :( But it would make driver modification go away.

Signature · 3 lines
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
author
#12 lore raw

PATCH 1/1 final CardServices() removal patches

In reply to Jeff Garzik

Remove calls to CardServices(); final.

This removes the CardServices() calls the rest of the tree, as well as CardServices itself from cs.c and cs.h. My previous patches, along w/ Arjan's patch for ide-cs.c and Russell's patch for serial_cs.c should remove all traces of it. I've attached a gzipped tarball to hopefully make things easier.

Files touched:

                                                                            201-cs_remove.patch:+++ mod/sound/pcmcia/vx/vx_entry.c

202-cs_remove.patch:+++ mod/drivers/bluetooth/bluecard_cs.c 202-cs_remove.patch:+++ mod/drivers/bluetooth/bt3c_cs.c 202-cs_remove.patch:+++ mod/drivers/bluetooth/btuart_cs.c 202-cs_remove.patch:+++ mod/drivers/bluetooth/dtl1_cs.c 203-cs_remove.patch:+++ mod/drivers/isdn/hardware/avm/avm_cs.c 203-cs_remove.patch:+++ mod/drivers/isdn/hisax/avma1_cs.c 203-cs_remove.patch:+++ mod/drivers/isdn/hisax/elsa_cs.c 203-cs_remove.patch:+++ mod/drivers/isdn/hisax/sedlbauer_cs.c 204-cs_remove.patch:+++ mod/drivers/parport/parport_cs.c 205-cs_remove.patch:+++ mod/drivers/telephony/ixj_pcmcia.c 206-cs_remove.patch:+++ mod/drivers/mtd/maps/pcmciamtd.c 207-cs_remove.patch:+++ mod/drivers/scsi/pcmcia/aha152x_stub.c 207-cs_remove.patch:+++ mod/drivers/scsi/pcmcia/fdomain_stub.c 207-cs_remove.patch:+++ mod/drivers/scsi/pcmcia/nsp_cs.c 207-cs_remove.patch:+++ mod/drivers/scsi/pcmcia/nsp_cs.h 207-cs_remove.patch:+++ mod/drivers/scsi/pcmcia/qlogic_stub.c 208-cs_remove.patch:+++ mod/drivers/char/pcmcia/synclink_cs.c 209-cs_remove.patch:+++ mod/drivers/pcmcia/cs.c 209-cs_remove.patch:+++ mod/include/pcmcia/cs.h

(Andrew, if you have problems w/ mime encoding or anything, you can also grab patches from http://sloth.voxel.net/~dilinger/kernel/cs_removal/)

#13 lore raw
In reply to Jeff Garzik
Quoted 5 lines

Ummm... there are many changes to the pcmcia net drivers in my net-drivers-2.5-exp queue. All can be classified as fixes, to a greater or lesser degree, and I would put those at a higher priority than API cleanups and such.

This set is not so much about API cleanup as about fixing a REAL bug:
CardServices() has a very broken prototype that miscompiles on amd64 on possibly others (even x86 with the right gcc flags).

Basically the function is implemented like this:

int CardServices(int func, void *a1, void *a2, void *a3) {
...
}

however the prototype that drivers see is using varargs like this:

extern int CardServices(int func, ...);

varargs functions on amd64 have a different calling convention than "normal" functions so this mismatches the actual implementation's calling convention and goes west quite spectacular. The same might be true for other architectures, and is true for x86 when you use -mregparm.

You could argue we should just fix CardServices() instead, but well once you do that you might as well kill it; even in 2.4 it's an optional API which abstracts the real API.