[PATCH 2.6.12-rc5] m32r: Update m32r_cfc.[ch] to support Mappi-III platform

[Dominik Brodowski]

Hi,

A few minutes ago I found out that you indeed pushed a change from
CONFIG_PCMCIA_STATIC to CONFIG_PCMCIA_NONSTATIC to Linus which is CLEARLY
INVALID. Please re-read my last message where I propose to track down the
problematic issue (let's call it a bug, even), instead of doing an invalid
workaround.

> OK, here's what I think causes the trouble:
> 
> pccard_static_ops are for bridges where the ioports and iomem windows are
> statically assigned by the firmwire, by the driver or some other entity
> during the boot initialization time. Therefore, there must not be any
> userspace interaction  (most notably no /etc/pcmcia/config.opts), but the
> driver must be able to determine these "windows" itself.
> 
> pccard_nonstatic_ops means that the PCMCIA bridge is able to select ioports
> and iomem differently for each card inserted.
> 
> AFAICS your driver is clearly of the former category -- i.e. the memory and
> ioports area the device has available is known in advance. The fact that
> your driver works after "pccardctl insert" is a clear indication that this
> is the correct approach...
> 
> >     NG ... In STATIC (!CONFIG_NONSTATIC, pccard_static_ops) case,
> >            a CF disk/memory device can *not* be probed automatically now.
> >            But a CF device can be mounted after "pccardctl insert" command
> >            execution, and also a CF device insert event can be handled 
> >            correctly.
> 
> ... so now we have to determine why it doesn't work at boot time. Somewhen
> during initialization pcmcia_register_socket() is called (can you check
> _when_ this happens in your case), then pcmcia_parse_events() should lead to
> socket_detect_change() being called eventually. If a card is present, it
> should call socket_insert(); which in turn should cause ds_event() with
> event==CS_EVENT_CARD_INSERTION being called eventually. Can you check
> whether all this happens as expected for pccard_static_ops? Then we'll also
> be much closer to finding the cause for this bug.

	Dominik