[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061221011526.GB32625@srcf.ucam.org>
Date: Thu, 21 Dec 2006 01:15:26 +0000
From: Matthew Garrett <mjg59@...f.ucam.org>
To: Dan Williams <dcbw@...hat.com>
Cc: Jiri Benc <jbenc@...e.cz>, Arjan van de Ven <arjan@...radead.org>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 01:12:51PM -0500, Dan Williams wrote:
> Entirely correct. If the card is DOWN, the radio should be off (both TX
> & RX) and it should be in max power save mode. If userspace expects to
> be able to get the card to do _anything_ when it's down, that's just
> 110% wrong. You can't get link events for many wired cards when they
> are down, so I fail to see where userspace could expect to do anything
> with a wireless card when it's down too.
Because it works on the common hardware? If there's documentation about
what userspace can legitimately expect, then I'm happy to defer to that.
But in the absence of any indication as to what functionality users can
depend on, deciding that existing functionality is a bug is, well,
impolite.
> Also, how does rfkill fit into this? rfkill implies killing TX, but do
> we have the granularity to still receive while the transmit paths are
> powered down?
Is rfkill not just primarily an interface for us getting events when the
radio changes state? Every time I read up on it I get a little more
confused - some time I really need to make sense of it...
--
Matthew Garrett | mjg59@...f.ucam.org
-
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