[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1F354B08-BE21-4084-8B97-5CF90BAB4156@mac.com>
Date: Wed, 20 Dec 2006 19:08:30 -0500
From: Kyle Moffett <mrmacman_g4@....com>
To: Arjan van de Ven <arjan@...radead.org>
Cc: Matthew Garrett <mjg59@...f.ucam.org>,
linux-kernel@...r.kernel.org, david-b@...bell.net, gregkh@...e.de
Subject: Re: Changes to sysfs PM layer break userspace
On Dec 19, 2006, at 15:55:43, Arjan van de Ven wrote:
> On Tue, 2006-12-19 at 20:32 +0000, Matthew Garrett wrote:
>> On Tue, Dec 19, 2006 at 09:23:05PM +0100, Arjan van de Ven wrote:
>>> On Tue, 2006-12-19 at 20:08 +0000, Matthew Garrett wrote:
>>>> I'm not sure. Suspending the chip means you lose things like
>>>> link beat detection, so it's not something you necessarily want
>>>> to automatically tie to something like interface status.
>>>
>>> right now the "spec" for Linux network drivers assumes that you
>>> put the NIC into D3 on down, except for cases where Wake-on-Lan
>>> is enabled etc.
>>
>> Really? I can't find any drivers that seem to do this. The only
>> calls to pci_set_power_state seem to be in the suspend, resume,
>> init and exit routines.
>
> your grep missed tg3.c for example, which has a wrapper around the
> power state code and goes to D3hot on downing of the interface.
> (just the first one I looked at as a "reference driver", others
> probably do the same thing)
I actually kind of like this feature; it makes it possible for
"ifdown" to virtually "unplug" the cable, such that the remote end
doesn't have an activated link. Admittedly it would be slightly more
useful to have the ifdown and the virtual-unplug be separate events.
There have been at least a few times where my Linux box is connected
to a network port I don't control that maintains some independent
state, and it's handy to be able to reset that state remotely.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists