Re: Heads up for distro folks: PCMCIA hotplug differences (Re: -rc4: arm broken?)
From: Dominik Brodowski
Date: Sat Jul 30 2005 - 17:45:13 EST
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
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,
- 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)
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/