Very Computer

>    I'm trying to get i82365 to work again, because I need to test
<snip>
> Intel PCIC probe:
>   Vadem VG-469 ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets
>     host opts [0]: none
>     host opts [1]: none
>     ISA irqs (scanned) = 4,5 polling interval = 1000 ms
> ds: no socket drivers loaded!

> P?iv?ys: 2003/03/04 ti AM 09:39:15 GMT+02:00



> Aihe: [PATCH] pcmcia: get initialization ordering right [Was: [PATCH 2.5] : i82365 & platform_bus_type]

> Hi,

> >       Hi,

> >       I'm trying to get i82365 to work again, because I need to test
> <snip>
> > Intel PCIC probe:
> >   Vadem VG-469 ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets
> >     host opts [0]: none
> >     host opts [1]: none
> >     ISA irqs (scanned) = 4,5 polling interval = 1000 ms
> > ds: no socket drivers loaded!

> Sorry about that -- I mixed up the ordering of initializing the class data
> and registering the platform device. Here's a bugfix for the three pcmcia
> socket drivers that are platform devices.

> Please apply,
>    Dominik

> diff -ruN linux-original/drivers/pcmcia/hd64465_ss.c linux/drivers/pcmcia/hd64465_ss.c
> --- linux-original/drivers/pcmcia/hd64465_ss.c     2003-03-04 08:27:06.000000000 +0100
> +++ linux/drivers/pcmcia/hd64465_ss.c      2003-03-04 08:30:37.000000000 +0100

>    }

>  /*        hd64465_io_debug = 0; */
> -  platform_device_register(&hd64465_device);
>    hd64465_device.dev.class_data = &hd64465_data;
> +  platform_device_register(&hd64465_device);

>    return 0;
>  }
> diff -ruN linux-original/drivers/pcmcia/i82365.c linux/drivers/pcmcia/i82365.c
> --- linux-original/drivers/pcmcia/i82365.c 2003-03-04 08:27:06.000000000 +0100
> +++ linux/drivers/pcmcia/i82365.c  2003-03-04 08:28:28.000000000 +0100

>    request_irq(cs_irq, pcic_interrupt, 0, "i82365", pcic_interrupt);
>  #endif

> -    platform_device_register(&i82365_device);
> -
>      i82365_data.nsock = sockets;
>      i82365_device.dev.class_data = &i82365_data;

> +    platform_device_register(&i82365_device);
> +
>      /* Finally, schedule a polling interrupt */
>      if (poll_interval != 0) {
>    poll_timer.function = pcic_interrupt_wrapper;
> diff -ruN linux-original/drivers/pcmcia/tcic.c linux/drivers/pcmcia/tcic.c
> --- linux-original/drivers/pcmcia/tcic.c   2003-03-04 08:27:06.000000000 +0100
> +++ linux/drivers/pcmcia/tcic.c    2003-03-04 08:30:03.000000000 +0100

>    sockets++;
>      }

> -    platform_device_register(&tcic_device);
> -
>      switch (socket_table[0].id) {
>      case TCIC_ID_DB86082:
>    printk("DB86082"); break;

>      tcic_data.nsock = sockets;
>      tcic_device.dev.class_data = &tcic_data;

> +    platform_device_register(&tcic_device);
> +
>      return 0;

>  } /* init_tcic */
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

> static int platform_match(struct device * dev, struct device_driver * drv)
> {
>    return 0;
> }

> which effectively makes driver binding impossible, pcmcia_socket_class->add_device isn't called.

> --Mika

> > P?iv?ys: 2003/03/04 ti AM 09:39:15 GMT+02:00



> > Aihe: [PATCH] pcmcia: get initialization ordering right [Was: [PATCH 2.5] : i82365 & platform_bus_type]

> > Hi,

> > >  Hi,

> > >  I'm trying to get i82365 to work again, because I need to test
> > <snip>
> > > Intel PCIC probe:
> > >   Vadem VG-469 ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets
> > >     host opts [0]: none
> > >     host opts [1]: none
> > >     ISA irqs (scanned) = 4,5 polling interval = 1000 ms
> > > ds: no socket drivers loaded!

> > Sorry about that -- I mixed up the ordering of initializing the class data
> > and registering the platform device. Here's a bugfix for the three pcmcia
> > socket drivers that are platform devices.

> > Please apply,
> >       Dominik

> > diff -ruN linux-original/drivers/pcmcia/hd64465_ss.c linux/drivers/pcmcia/hd64465_ss.c
> > --- linux-original/drivers/pcmcia/hd64465_ss.c        2003-03-04 08:27:06.000000000 +0100
> > +++ linux/drivers/pcmcia/hd64465_ss.c 2003-03-04 08:30:37.000000000 +0100

> >       }

> >  /*   hd64465_io_debug = 0; */
> > -     platform_device_register(&hd64465_device);
> >       hd64465_device.dev.class_data = &hd64465_data;
> > +     platform_device_register(&hd64465_device);

> >       return 0;
> >  }
> > diff -ruN linux-original/drivers/pcmcia/i82365.c linux/drivers/pcmcia/i82365.c
> > --- linux-original/drivers/pcmcia/i82365.c    2003-03-04 08:27:06.000000000 +0100
> > +++ linux/drivers/pcmcia/i82365.c     2003-03-04 08:28:28.000000000 +0100

> >       request_irq(cs_irq, pcic_interrupt, 0, "i82365", pcic_interrupt);
> >  #endif

> > -    platform_device_register(&i82365_device);
> > -
> >      i82365_data.nsock = sockets;
> >      i82365_device.dev.class_data = &i82365_data;

> > +    platform_device_register(&i82365_device);
> > +
> >      /* Finally, schedule a polling interrupt */
> >      if (poll_interval != 0) {
> >       poll_timer.function = pcic_interrupt_wrapper;
> > diff -ruN linux-original/drivers/pcmcia/tcic.c linux/drivers/pcmcia/tcic.c
> > --- linux-original/drivers/pcmcia/tcic.c      2003-03-04 08:27:06.000000000 +0100
> > +++ linux/drivers/pcmcia/tcic.c       2003-03-04 08:30:03.000000000 +0100

> >       sockets++;
> >      }

> > -    platform_device_register(&tcic_device);
> > -
> >      switch (socket_table[0].id) {
> >      case TCIC_ID_DB86082:
> >       printk("DB86082"); break;

> >      tcic_data.nsock = sockets;
> >      tcic_device.dev.class_data = &tcic_data;

> > +    platform_device_register(&tcic_device);
> > +
> >      return 0;

> >  } /* init_tcic */
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/

> How is it supposed to work then? I thought adding a platform_device and
> platform_driver with the same name and bus_id causes the platform_driver to
> be bound to the platform_device?

> This patch is completley untested, but it should work.

> > This patch is completley untested, but it should work.

>    I think you are hitting the nail on the head, various people
> are doing many "obvious" changes all over the place without bothering
> to check them, resulting in non functional code.
>    That's not the way I want to work, and that's why I won't
> commit the new Wireless Extensions stuff until I can really test it.

> Surely you're sore that your code has required some modifications since
> Dominik has started working on PCMCIA, and I'm sure that no harm was
> intended. It's had some bumps, but IMO, he's done a great job, and the
> result is a vast improvement. The least you could is give the guy some
> slack, instead of whining about your own inconveniences.

> > Surely you're sore that your code has required some modifications since
> > Dominik has started working on PCMCIA, and I'm sure that no harm was
> > intended. It's had some bumps, but IMO, he's done a great job, and the
> > result is a vast improvement. The least you could is give the guy some
> > slack, instead of whining about your own inconveniences.

>    I don't mind the changes, changes are usually good. In 2.5.X,
> I had to change my code to accomodate the new PCI interface, the
> removal of global IRQ, the new module interface, the various USB API
> changes and other changes. And actually, your work currently hasn't
> had any impact on the source code I follow (yet).
>    What I mind is the lack of basic testing. From your patch, the
> initialisation order mixup and the other obvious bug fix I sent you,
> this code had zero chances of working at all and it's obvious that
> nobody bothered to check if it could work or not for at least two
> kernel releases.