Ok I have found why.
When I resinsert the card, the driver give it a new id (this driver
supports multiple cards) and the option as I set it is only defined for
the card #0. I would expect that the driver give the same id back.
Christophe
On Tue, Feb 26, 2002 at 12:58:19PM -0500, christophe barbé wrote:
> On Tue, Feb 26, 2002 at 09:40:39AM -0800, Andrew Morton wrote:
> > christophe barbé wrote:
> > >
> > > When you remove a 3c59x-based cardbus, the fonction vortex_remove_one
> > > is called and this function end with kfree(dev).
> > >
> > > I was looking why enable_wol loose its value after a remove/insert cycle
> > > but this value is store in the private part of dev so it's free with
> > > dev.
> > >
> > > The driver is not unloaded during the remove/insert cycle so it's a
> > > kernel space problem.
> >
> > Yes, all driver state is destroyed when the hardware is removed.
> > Look at it the other way: if this was not done, the driver would
> > have a memory leak.
>
> Yes but as I said the driver is not unloaded.
> So when I reinsert the card the kernel himself take care of it (no way
> to give an option) but the result is that the enable_wol is lost.
>
> >
> > I guess it would be possible to retain some state across insertion
> > cycles, keyed off the MAC address or something. What's it needed
> > for?
> >
> >
> > -
>
> --
> Christophe Barbé <christophe.barbe@ufies.org>
> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
>
> Cats seem go on the principle that it never does any harm to ask for
> what you want. --Joseph Wood Krutch
-- Christophe Barbé <christophe.barbe@ufies.org> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41EIn a cat's eye, all things belong to cats. --English proverb
This archive was generated by hypermail 2b29 : Thu Feb 28 2002 - 21:00:30 EST