Re: [PATCH] 3c59x and resume

Jeff Garzik (
Mon, 25 Mar 2002 23:10:27 -0500

christophe barbé wrote:

>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
>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 ?

Just exactly what I described.

The current system increments the card id on each ->probe, and does not
decrement on ->remove, which makes sense if you are hotplugging one card
and then another -- you don't want to reuse the same module options for
a different card. Your patch changes this logic to, "oh wait, let's
stop doing this and have a special case once we reach MAX_UNITS" Thus,
you could potentially reuse the final slot when that was not the desired

Note that I am not defending this method of card_idx usage, because
different use cases have different requirements (as indeed you do). But
your patch fixes one thing at the expense of another.

I just had another idea. Create a new module option 'default_options',
a single integer value. Instead of assigning "-1" to options when we
run out of MAX_UNITS ids, assign the default_options value.

>>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.
"same id" is vague. Same PCI id? Sure, but that doesn't mean it's the
same card, from the driver's point of view. The driver really needs to
keep track of whether or not a new ->probe indicates a card whose MAC
address we have seen before.

To reiterate another issue, however, suspend/resume should _not_ be
calling the code added in your patch. That's a non-3c59x bug somewhere.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at