From: "christophe barbé" <christophe.barbe.ml@online.fr>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: "christophe barbé" <christophe.barbe.ml@online.fr>,
"Marcelo Tosatti" <marcelo@conectiva.com.br>,
lkml <linux-kernel@vger.kernel.org>,
"Andrew Morton" <akpm@zip.com.au>
Subject: Re: [PATCH] 3c59x and resume
Date: Mon, 25 Mar 2002 20:40:51 -0500 [thread overview]
Message-ID: <20020326014050.GP1853@ufies.org> (raw)
In-Reply-To: <20020323161647.GA11471@ufies.org> <3C9FC76F.6050900@mandrakesoft.com>
[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]
On Mon, Mar 25, 2002 at 07:57:19PM -0500, Jeff Garzik wrote:
> This patch causes module defaults to be reused -- potentially incorrectly.
Wrong. How can the fact that a suspend/resume cycle increment the id be
worst than the fact that the same cycle return idx to the previous
state?
The argument you have against this patch is WRONG.
You think about NICs in a PCI slot.
That's changed the day the cardbus support was moved from pcmcia to the
today implementation.
You can't expect cardbus user to stop using the suspend mode because you
expect your id to be attributed one time (that doesn't even make sense).
I agree that this patch is not a full fix (I said it in my original
post) but I disagree that it does any bad things. I would be interested
to learn about a real case ?
But ethtool seems to be very interesting and it looks like what I was
looking for. I will have a closer look at it, thank you for pointing it
to me.
> This is a personal solution, that might live on temporary as an
> outside-the-tree patch... but we cannot apply this to the stable kernel.
>
> I agree the card idx is wrong on remove. Insert and remove a 3c59x
> cardbus card several times, and you will lose your module options too.
NO -- If I can remove/insert suspend/remove my card as I want I ever get
the same ID.
If you want to fail the patch you need to remove/insert 2 cards in FILO
order. Then you will get a ever bigger ID but this is what you get by
default without the patch.
> However... take note that this problem cannot be solved "the easy way"
> -- because one solution people may desire will potentially result in
> module options getting re-used incorrectly. The above is one such solution.
I am waiting for a real case.
> If you want WOL options to "stick" or vary per-interface, we already
> have an API for that -- ethtool. Check out drivers/net/natsemi.c for an
> example implementation. _Tested_ patches to 3c59x that add WOL ethtool
> support are welcome, pending Andrew's approval. Do not remove
> enable_wol for now in a stable series, but we will deprecate its use
> once ethtool support appears.
Noted.
Christophe
> Jeff
--
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
Dogs come when they're called;
cats take a message and get back to you later. --Mary Bly
[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]
next prev parent reply other threads:[~2002-03-26 1:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-23 16:16 [PATCH] 3c59x and resume christophe barbé
2002-03-23 18:39 ` Andrew Morton
2002-03-23 20:06 ` Robert Love
2002-03-23 22:44 ` christophe barbé
2002-03-24 8:07 ` Greg KH
2002-03-24 14:25 ` christophe barbé
2002-03-25 18:01 ` Greg KH
2002-03-25 18:19 ` christophe barbé
2002-03-25 19:11 ` Greg KH
2002-03-25 20:27 ` christophe barbé
2002-03-25 20:58 ` christophe barbé
2002-03-25 11:34 ` Joachim Breuer
2002-03-25 11:53 ` Xavier Bestel
2002-03-25 21:31 ` Joachim Breuer
2002-03-25 19:44 ` Bill Davidsen
2002-03-25 20:16 ` christophe barbé
2002-03-26 0:57 ` Jeff Garzik
2002-03-26 1:40 ` christophe barbé [this message]
2002-03-26 4:10 ` Jeff Garzik
2002-03-26 4:39 ` christophe barbé
2002-03-26 4:50 ` Andrew Morton
2002-03-26 16:56 ` christophe barbé
2002-03-26 16:57 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020326014050.GP1853@ufies.org \
--to=christophe.barbe.ml@online.fr \
--cc=akpm@zip.com.au \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox