> > Or: maybe there is another way to make "pccardctl eject"
> > work reasonably fast in the case of a retrying command. Any
> > idea?
>
> Does it set priv->surpriseremoved? We should honour that.
Unfortunately not. Manually ejecting the card sets this (via
ISR). Then the driver very quickly disables the card, retrying
commands or not. It's just "pccardctl eject" that can, under
circumstances, take ages. Unfortunately this circumstances
happen in my (embedded) hardware setup, e.g. when
suspending/resuming.
At resume time, I simply do "pccardctl eject" / "pccardctl
insert" to get the driver correctly initialized again and
associating. Because doing "real" suspend/resume is currently
impossible for me with my knowledge of the firmware.
> No, it just waits until the timer has been properly removed.
> If the timer was set for some time in the future, it doesn't
> wait for it to happen naturally.
Oh, this is what I thought would happen. In this case, it
{c/sh}ould stay at del_timer_sync().
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
