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

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

[Andres Salomon]

[-- Attachment #1.1: Type: text/plain, Size: 14 bytes --]

Part 5 of 7.

[-- Attachment #1.2: 005-cs_remove.patch --]
[-- Type: text/x-patch, Size: 4925 bytes --]

Revision: linux--mainline--2.6--patch-18
Archive: dilinger@voxel.net--2003-spiral
Creator: Andres Salomon <dilinger@voxel.net>
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: dilinger@voxel.net--2003-spiral/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/dilinger@voxel.net--2003-spiral/patch-log/patch-18

* modified files

--- orig/drivers/net/pcmcia/3c574_cs.c
+++ mod/drivers/net/pcmcia/3c574_cs.c
@@ -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);




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 5/7] more CardServices() removals (drivers/net/wireless)

[Andrew Morton]

Andres Salomon <dilinger@voxel.net> wrote:
>
> Part 5 of 7.
> 
> 
> [005-cs_remove.patch  text/x-patch (6824 bytes)]
>  Revision: linux--mainline--2.6--patch-18
>  Archive: dilinger@voxel.net--2003-spiral
>  Creator: Andres Salomon <dilinger@voxel.net>
>  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.

Re: [PATCH 5/7] more CardServices() removals (drivers/net/wireless)

[Andres Salomon]

[-- Attachment #1.1: Type: text/plain, Size: 1011 bytes --]

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.




On Tue, 2003-12-23 at 21:28, Andrew Morton wrote:
> Andres Salomon <dilinger@voxel.net> wrote:
> >
> > Part 5 of 7.
> > 
> > 
> > [005-cs_remove.patch  text/x-patch (6824 bytes)]
> >  Revision: linux--mainline--2.6--patch-18
> >  Archive: dilinger@voxel.net--2003-spiral
> >  Creator: Andres Salomon <dilinger@voxel.net>
> >  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.
> 

[-- Attachment #1.2: 105-cs_remove.patch --]
[-- Type: text/x-patch, Size: 6026 bytes --]

Revision: linux--mainline--2.6--patch-34
Archive: dilinger@voxel.net--2003-spiral
Creator: Andres Salomon <dilinger@voxel.net>
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: dilinger@voxel.net--2003-spiral/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/dilinger@voxel.net--2003-spiral/patch-log/patch-34

* modified files

--- orig/drivers/net/wireless/wavelan_cs.c
+++ mod/drivers/net/wireless/wavelan_cs.c
@@ -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);




[-- Attachment #1.3: 107-cs_remove.patch --]
[-- Type: text/x-patch, Size: 5466 bytes --]

Revision: linux--mainline--2.6--patch-36
Archive: dilinger@voxel.net--2003-spiral
Creator: Andres Salomon <dilinger@voxel.net>
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: dilinger@voxel.net--2003-spiral/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/dilinger@voxel.net--2003-spiral/patch-log/patch-36

* modified files

--- orig/drivers/net/wireless/ray_cs.c
+++ mod/drivers/net/wireless/ray_cs.c
@@ -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);




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 5/7] more CardServices() removals (drivers/net/wireless)

[Jeff Garzik]

Andrew Morton wrote:
> Andres Salomon <dilinger@voxel.net> wrote:
> 
>>Part 5 of 7.
>>
>>
>>[005-cs_remove.patch  text/x-patch (6824 bytes)]
>> Revision: linux--mainline--2.6--patch-18
>> Archive: dilinger@voxel.net--2003-spiral
>> Creator: Andres Salomon <dilinger@voxel.net>
>> 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.


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

Re: [PATCH 5/7] more CardServices() removals (drivers/net/wireless)

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> 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.

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

Re: [PATCH 5/7] more CardServices() removals (drivers/net/wireless)

[Jeff Garzik]

Andrew Morton wrote:
>> 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

Re: [PATCH 5/7] more CardServices() removals (drivers/net/wireless)

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> 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 ;)

Re: [PATCH 5/7] more CardServices() removals (drivers/net/wireless)

[Matt Mackall]

On Tue, Dec 23, 2003 at 08:23:05PM -0800, Andrew Morton wrote:
> Jeff Garzik <jgarzik@pobox.com> wrote:
> >
> > 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?

Yep, I'm working on it this very moment for my -tiny tree on top of
Jeff's latest. Should have another cut soon.
 
> 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.

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting

[PATCH] final CardServices() removal patches

[Andres Salomon]

[-- Attachment #1.1: Type: text/plain, Size: 1772 bytes --]

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


[-- Attachment #1.2: cs_remove3.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 12097 bytes --]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 5/7] more CardServices() removals (drivers/net/wireless)

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]


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



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 5/7] more CardServices() removals (drivers/net/wireless)

[George Anzinger]

Matt Mackall wrote:
> On Tue, Dec 23, 2003 at 08:23:05PM -0800, Andrew Morton wrote:
> 
>>Jeff Garzik <jgarzik@pobox.com> wrote:
>>
>>>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?
> 
> 
> Yep, I'm working on it this very moment for my -tiny tree on top of
> Jeff's latest. Should have another cut soon.
>  
> 
>>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.
> 
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.


-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: [PATCH 5/7] more CardServices() removals (drivers/net/wireless)

[Andrew Morton]

George Anzinger <george@mvista.com> wrote:
>
> >>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.
>  > 
>  I got side tracked by a customer with money :)

A what?

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

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

Re: [PATCH 5/7] more CardServices() removals (drivers/net/wireless)

[Matt Mackall]

On Thu, Dec 25, 2003 at 01:45:58AM -0800, George Anzinger wrote:
> 
> 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.

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting

Re: [PATCH 5/7] more CardServices() removals (drivers/net/wireless)

[George Anzinger]

Matt Mackall wrote:
> On Thu, Dec 25, 2003 at 01:45:58AM -0800, George Anzinger wrote:
> 
>>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.

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml