From: Daniel Drake <dsd@gentoo.org>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Michael Wu <flamingice@sourmilk.net>,
Stephen Hemminger <shemminger@osdl.org>,
Arjan van de Ven <arjan@infradead.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: Network drivers that don't suspend on interface down
Date: Wed, 20 Dec 2006 21:38:20 -0500 [thread overview]
Message-ID: <4589F39C.7010201@gentoo.org> (raw)
In-Reply-To: <20061221021832.GA723@srcf.ucam.org>
Matthew Garrett wrote:
>> In order to scan, we need to have the radio on and we need to be able to send
>> and receive. What are you gonna turn off?
>
> The obvious route would be to power the card down, but come back up
> every two minutes to perform a scan, or if userspace explicitly requests
> one. Would this cause problems in some cases?
I don't think it makes sense. For zd1211 the power consumption and heat
emission goes up considerably when the interface is brought up (radio
on, interrupts enabled, etc), and this is also a relatively long
operation in terms of duration needed to bring the interface up and
down. A scanning operation requires radio on, interrupts enabled, lots
of register reading, RF calibration, RX/TX ringbuffers allocation, etc.
I don't think that supporting scanning when the interface is supposed to
be disabled is sensible. If you want to scan, you are simply sending and
receiving frames, it's no different from having the interface up and
sending/receiving data frames.
There are additional implementation problems: scanning requires 2
different ioctl calls: siwscan, then several giwscan. If you want the
driver to effectively temporarily bring the interface up when userspace
requests a scan but the interface was down, then how does the driver
know when to bring it down again?
Daniel
next prev parent reply other threads:[~2006-12-21 2:38 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20061219185223.GA13256@srcf.ucam.org>
[not found] ` <200612191959.43019.david-b@pacbell.net>
[not found] ` <20061220042648.GA19814@srcf.ucam.org>
[not found] ` <200612192114.49920.david-b@pacbell.net>
[not found] ` <20061220053417.GA29877@suse.de>
[not found] ` <20061220055209.GA20483@srcf.ucam.org>
[not found] ` <1166601025.3365.1345.camel@laptopd505.fenrus.org>
2006-12-20 12:53 ` Network drivers that don't suspend on interface down Matthew Garrett
2006-12-20 13:38 ` Arjan van de Ven
2006-12-20 14:31 ` Matthew Garrett
2006-12-20 15:51 ` Arjan van de Ven
2006-12-20 22:49 ` Stephen Hemminger
2006-12-20 23:37 ` Rick Jones
2006-12-19 23:51 ` Stephen Hemminger
2006-12-21 0:11 ` Francois Romieu
2006-12-20 0:26 ` Stephen Hemminger
2006-12-21 11:18 ` Francois Romieu
2006-12-21 1:12 ` Matthew Garrett
2006-12-21 2:05 ` Michael Wu
2006-12-21 2:18 ` Matthew Garrett
2006-12-21 2:38 ` Daniel Drake [this message]
2006-12-21 2:45 ` Matthew Garrett
2006-12-21 3:08 ` Daniel Drake
2006-12-21 3:25 ` Matthew Garrett
2006-12-21 3:37 ` Dan Williams
2006-12-21 3:29 ` Dan Williams
2006-12-21 3:14 ` Dan Williams
2006-12-21 13:14 ` jamal
2006-12-21 2:29 ` Daniel Drake
2006-12-21 2:10 ` Jesse Brandeburg
2006-12-21 8:54 ` Arjan van de Ven
2006-12-22 1:03 ` Herbert Xu
2006-12-23 8:54 ` Pavel Machek
2006-12-20 15:27 ` Olivier Galibert
2006-12-20 15:34 ` Arjan van de Ven
2006-12-20 16:40 ` Olivier Galibert
2006-12-20 17:21 ` Arjan van de Ven
2006-12-20 20:40 ` Benny Amorsen
2006-12-20 21:49 ` Arjan van de Ven
2006-12-20 21:15 ` Stefan Rompf
2006-12-20 14:00 ` Jiri Benc
2006-12-20 18:12 ` Dan Williams
2006-12-21 1:15 ` Matthew Garrett
2006-12-21 1:57 ` Michael Wu
2006-12-21 2:20 ` Matthew Garrett
2006-12-21 3:02 ` Dan Williams
2006-12-21 3:06 ` Dan Williams
2006-12-21 3:14 ` Matthew Garrett
2006-12-21 3:32 ` Dan Williams
2006-12-21 13:19 ` Sven-Haegar Koch
2006-12-21 17:16 ` Dan Williams
2006-12-21 18:27 ` Valdis.Kletnieks
2006-12-22 1:25 ` Matt Domsch
2006-12-20 16:04 ` Maciej W. Rozycki
2006-12-21 5:25 David Brownell
2006-12-21 7:08 ` Stephen Hemminger
2006-12-21 8:11 ` David Brownell
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=4589F39C.7010201@gentoo.org \
--to=dsd@gentoo.org \
--cc=arjan@infradead.org \
--cc=flamingice@sourmilk.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=netdev@vger.kernel.org \
--cc=shemminger@osdl.org \
/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;
as well as URLs for NNTP newsgroup(s).