Re: Heads up for distro folks: PCMCIA hotplug differences (Re: -rc4: arm broken?)

• Previous message: Pavel Machek: "Re: Heads up for distro folks: PCMCIA hotplug differences (Re: -rc4: arm broken?)"
• In reply to: Pavel Machek: "Re: Heads up for distro folks: PCMCIA hotplug differences (Re: -rc4: arm broken?)"
• Next in thread: Grant Coady: "Re: Heads up for distro folks: PCMCIA hotplug differences (Re: -rc4: arm broken?)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date:	Sun, 31 Jul 2005 00:43:52 +0200
To: Pavel Machek <pavel@ucw.cz>

Hi,

On Sun, Jul 31, 2005 at 12:30:30AM +0200, Pavel Machek wrote:
> > > > Let me qualify that, because it's not 100% fine due to the changes in
> > > > PCMCIA land.
> > > >
> > > > Since PCMCIA cards are detected and drivers bound at boot time, we no
> > > > longer get hotplug events to setup networking for PCMCIA network cards
> > > > already inserted. Consequently, if you are relying on /sbin/hotplug to
> > > > setup your PCMCIA network card at boot time, triggered by the cardmgr
> > > > startup binding the driver, it won't happen.
> > >
> > > Does that mean that if CF is inserted during bootup, it will simply
> > > appear as /dev/hda after bootup, without need to run cardmgr?
> >
> > Yes, which is almost a plus side. Whether you can use it to boot
>
> That's certainly a plus side, because I should be able to use pcmcia
> cards without setting much userland.

Let me clarify this a bit, and point all interested parties to
http://kernel.org/pub/linux/utils/kernel/pcmcia/howto.html

PCMCIA can work without userspace on 2.6.13 if you compile all necessary
things into the kernel and:

a) the socket is smart enough.This is the case for
        - all sockets which statically map resources
          (hd64465, Au1x00, SA1100, SA1111, PXA2xx, M32R_PCC, M32R_CFC,
           VRC4171, VRC4173)
        - yenta-socket, pd6729 or i82092 if it
                1) resides behind a PCI-PCI bridge [oh, I need to update
                        the howto regarding this point...] or
                2) resides behind some other bridge limiting the resource
                        space (PPC, PPC64)

and

b) a Manufactor/Device or Product ID match is known for the device. Matching
for "Function ID" (quite common for CF cards, unfortunately) is fuzzy and
therefore can only be enabled if we are sure no (other) driver matches. And
that's currently done by waiting for userspace telling the kernel that it
already modprobed all available modules. In the long term, we should try to
get rid of all "Function ID" matches, and use the more specific Manufactor,
Device and Product ID matches. So patches adding more IDs are welcome.

Thanks,
        Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

• Previous message: Pavel Machek: "Re: Heads up for distro folks: PCMCIA hotplug differences (Re: -rc4: arm broken?)"
• In reply to: Pavel Machek: "Re: Heads up for distro folks: PCMCIA hotplug differences (Re: -rc4: arm broken?)"
• Next in thread: Grant Coady: "Re: Heads up for distro folks: PCMCIA hotplug differences (Re: -rc4: arm broken?)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]