Hi!
> > about your driver list;
> > do you have an idea of what the top 5 relevant ones would be?
> > I'd be surprised if the top 5 together had less than 95% market share,
> > so if we fix those we'd be mostly done already.
>
> In terms of what I've seen on vaguely modern hardware, I'd guess at
On Thu, Dec 21, 2006 at 01:27:55PM -0500, [EMAIL PROTECTED] wrote:
> On Wed, 20 Dec 2006 22:06:51 EST, Dan Williams said:
> > It's also complicated because some switches are supposed to rfkill both
> > an 802.11 module _and_ a bluetooth module at the same time, or I guess
> > some laptops may even
Matthew Garrett <[EMAIL PROTECTED]> wrote:
>
> In terms of what I've seen on vaguely modern hardware, I'd guess at
> e1000 and sky2 as the top ones. b44 is still common in cheaper hardware,
> with via-rhine appearing at the very low end. I'll try to grep through
> our hardware database results
On Wed, 20 Dec 2006 22:06:51 EST, Dan Williams said:
> It's also complicated because some switches are supposed to rfkill both
> an 802.11 module _and_ a bluetooth module at the same time, or I guess
> some laptops may even have one rfkill switch for each wireless device.
On my Dell D820, it's bio
On Thu, 2006-12-21 at 14:19 +0100, Sven-Haegar Koch wrote:
> On Wed, 20 Dec 2006, Dan Williams wrote:
>
> >> If we define interface down as meaning that the device is powered down
> >> and the radio switched off, then (b) and (c) would presumably just need
> >> to ensure that the interface is down
On Wed, 20 Dec 2006, Dan Williams wrote:
If we define interface down as meaning that the device is powered down
and the radio switched off, then (b) and (c) would presumably just need
to ensure that the interface is downed. (a) is a slightly more special
case - if the switch disables the radio,
On Wed, 2006-20-12 at 22:14 -0500, Dan Williams wrote:
...
> Simple == good. Down == down. Lets just agree on that and save
> ourselves a lot of pain.
netdevices have well defined operational and administrative state
machines. And very well defined relationship between operational and
admin
Stephen Hemminger <[EMAIL PROTECTED]> :
[...]
> We need to allow ethtool setting to be done before device has been brought
> up and started autonegotiation. The current MII library doesn't really support
> it.
I completely agree.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscr
> Is there some reason why we can't have the OS just do the D3
> transition for all drivers that register support? I mean, this power
> management using D states is actually driver *independent* and at
> least way back in the day was supposed to be implemented for "OS power
> management"
all you
On Wednesday 20 December 2006 11:08 pm, Stephen Hemminger wrote:
> David Brownell wrote:
> > Hmm, this reminds me of a thread from last summer, following up on
> > some PM discussions at OLS. Thread "Runtime power management for
> > network interfaces", at the end of July.
> >
> >
> >
> >> 2) N
David Brownell wrote:
Hmm, this reminds me of a thread from last summer, following up on
some PM discussions at OLS. Thread "Runtime power management for
network interfaces", at the end of July.
2) Network device infrastructure should make it easier for devices:
bring interface down on
Hmm, this reminds me of a thread from last summer, following up on
some PM discussions at OLS. Thread "Runtime power management for
network interfaces", at the end of July.
> 2) Network device infrastructure should make it easier for devices:
> bring interface down on suspend and bring it up
On Thu, 2006-12-21 at 03:25 +, Matthew Garrett wrote:
> On Wed, Dec 20, 2006 at 10:08:22PM -0500, Daniel Drake wrote:
> > Matthew Garrett wrote:
> > >Hm. Does the spec not set any upper bound on how long it might take for
> > >APs to respond? I'm afraid that my 802.11 knowledge is pretty slim.
On Thu, 2006-12-21 at 03:14 +, Matthew Garrett wrote:
> On Wed, Dec 20, 2006 at 10:06:51PM -0500, Dan Williams wrote:
>
> > a) tied to the wireless hardware, switch kills hardware directly
> > b) tied to wireless hardware, but driver handles the kill request
> > c) just another key, a separate
On Wed, 2006-12-20 at 22:08 -0500, Daniel Drake wrote:
> Matthew Garrett wrote:
> >> 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 user
On Wed, Dec 20, 2006 at 10:08:22PM -0500, Daniel Drake wrote:
> Matthew Garrett wrote:
> >Hm. Does the spec not set any upper bound on how long it might take for
> >APs to respond? I'm afraid that my 802.11 knowledge is pretty slim.
>
> I'm not sure, but thats not entirely relevant either. The
On Wed, Dec 20, 2006 at 10:06:51PM -0500, Dan Williams wrote:
> a) tied to the wireless hardware, switch kills hardware directly
> b) tied to wireless hardware, but driver handles the kill request
> c) just another key, a separate key driver handles the event and asks
> the wireless driver to kill
On Thu, 2006-12-21 at 02:18 +, Matthew Garrett wrote:
> On Wed, Dec 20, 2006 at 09:05:27PM -0500, Michael Wu wrote:
>
> > Softmac isn't the only wireless code that likes to be configured after
> > going
> > up first. Configuring after the card goes up has generally been more
> > reliable, t
Matthew Garrett wrote:
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 dr
On Thu, 2006-12-21 at 01:15 +, Matthew Garrett wrote:
> 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 th
On Thu, 2006-12-21 at 02:20 +, Matthew Garrett wrote:
> On Wed, Dec 20, 2006 at 08:57:05PM -0500, Michael Wu wrote:
>
> (allowing scanning while the interface is down)
>
> > No, it's absolutely a bug. It just so happens that some drivers incorrectly
> > allowed it.
>
> Ok. Would it be reaso
Matthew Garrett wrote:
Veering off at something of a tangent - how much of this should be true
for wireless devices? Softmac seems to be unhappy about setting the
essid unless the card is up, which breaks various assumptions...
You might regard that as a bug - I agree it probably makes sense f
On Wed, Dec 20, 2006 at 09:38:20PM -0500, Daniel Drake wrote:
> 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/re
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. Woul
On Wed, Dec 20, 2006 at 08:57:05PM -0500, Michael Wu wrote:
(allowing scanning while the interface is down)
> No, it's absolutely a bug. It just so happens that some drivers incorrectly
> allowed it.
Ok. Would it be reasonable to add warnings to any devices that allow it?
--
Matthew Garrett |
On Wed, Dec 20, 2006 at 09:05:27PM -0500, Michael Wu wrote:
> Softmac isn't the only wireless code that likes to be configured after going
> up first. Configuring after the card goes up has generally been more
> reliable, though that should not be necessary and is a bug IMHO.
Ok, that's nice t
On 12/20/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> Yeah, I guess that's a problem. From a user perspective, the
> functionality is only really useful if the latency is very small. I
> think where possible we'd want to power down the chip while keeping the
> phy up, but it would be nice t
On Wednesday 20 December 2006 20:12, Matthew Garrett wrote:
> Veering off at something of a tangent - how much of this should be true
> for wireless devices? Softmac seems to be unhappy about setting the
> essid unless the card is up, which breaks various assumptions...
>
Softmac isn't the only wir
On Wednesday 20 December 2006 20:15, Matthew Garrett wrote:
> 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, dec
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. Y
On Wed, Dec 20, 2006 at 02:49:06PM -0800, Stephen Hemminger wrote:
> When device is down, it should:
>a) use as few resources as possible:
> - not grab memory for buffers
> - not assign IRQ unless it could get one
> - turn off all power consumpt
On Thu, 21 Dec 2006 01:11:12 +0100
Francois Romieu <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger <[EMAIL PROTECTED]> :
> [...]
> >IMHO:
> > When device is down, it should:
> > a) use as few resources as possible:
> >- not grab memory for buffers
> >- not assig
Stephen Hemminger <[EMAIL PROTECTED]> :
[...]
>IMHO:
> When device is down, it should:
>a) use as few resources as possible:
> - not grab memory for buffers
> - not assign IRQ unless it could get one
> - turn off all power consumption possibl
There are two different problems:
1) Behavior seems to be different depending on device driver
author. We should document the expected semantics better.
IMHO:
When device is down, it should:
a) use as few resources as possible:
- not grab memory for buffers
On Wed, 20 Dec 2006 15:37:41 -0800
Rick Jones <[EMAIL PROTECTED]> wrote:
> > There are two different problems:
> >
> > 1) Behavior seems to be different depending on device driver
> >author. We should document the expected semantics better.
> >
> >IMHO:
> > When device is down, it sh
On Wed, 20 Dec 2006 16:51:39 +0100
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> > Yeah, I guess that's a problem. From a user perspective, the
> > functionality is only really useful if the latency is very small. I
> > think where possible we'd want to power down the chip while keeping the
On Wed, 2006-12-20 at 21:40 +0100, Benny Amorsen wrote:
> > "AvdV" == Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> AvdV> even if you have NO power savings you still don't meet your
> AvdV> criteria. That's basic ethernet for you
>
> AvdV> That's what I was trying to say; your criteria
Am Mittwoch, 20. Dezember 2006 16:34 schrieb Arjan van de Ven:
> 5 seconds is unfair and unrealistic though. The *hardware* negotiation
> before link is seen can easily take upto 45 seconds already.
> That's a network topology/hardware issue (spanning tree fun) that
> software or even the hardware
> "AvdV" == Arjan van de Ven <[EMAIL PROTECTED]> writes:
AvdV> even if you have NO power savings you still don't meet your
AvdV> criteria. That's basic ethernet for you
AvdV> That's what I was trying to say; your criteria is unrealistic
AvdV> regardless of what the kernel does, ethernet a
On Wed, 2006-12-20 at 15:00 +0100, Jiri Benc wrote:
> On Wed, 20 Dec 2006 12:53:14 +, Matthew Garrett wrote:
> > The situation is more complicated for wireless. Userspace expects to be
> > able to get scan results from the card even if the interface is down.
>
> User space should get an error
On Wed, 2006-12-20 at 17:40 +0100, Olivier Galibert wrote:
> On Wed, Dec 20, 2006 at 04:34:17PM +0100, Arjan van de Ven wrote:
> > 5 seconds is unfair and unrealistic though. The *hardware* negotiation
> > before link is seen can easily take upto 45 seconds already.
> > That's a network topology/ha
On Wed, Dec 20, 2006 at 04:34:17PM +0100, Arjan van de Ven wrote:
> 5 seconds is unfair and unrealistic though. The *hardware* negotiation
> before link is seen can easily take upto 45 seconds already.
> That's a network topology/hardware issue (spanning tree fun) that
> software or even the hardwa
On Wed, 20 Dec 2006, Matthew Garrett wrote:
> As far as I can tell, the following network devices don't put the
> hardware into D3 on interface down:
[...]
> defxx
No support in the hardware for that. Even revision 3 of the board which
is the last one and the only to support PCI 2.2 says:
Ca
On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote:
> [1] What kind of latency would be allowed? Would an implementation be
> allowed to power up the phy say once per minute or once per 5 minutes to
> see if there is link? The implementation could do this progressively;
> first poll e
> Yeah, I guess that's a problem. From a user perspective, the
> functionality is only really useful if the latency is very small. I
> think where possible we'd want to power down the chip while keeping the
> phy up, but it would be nice to know how much power that would actually
> cost us.
On Wed, 2006-12-20 at 16:27 +0100, Olivier Galibert wrote:
> On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote:
> > [1] What kind of latency would be allowed? Would an implementation be
> > allowed to power up the phy say once per minute or once per 5 minutes to
> > see if there is l
On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote:
> about your driver list;
> do you have an idea of what the top 5 relevant ones would be?
> I'd be surprised if the top 5 together had less than 95% market share,
> so if we fix those we'd be mostly done already.
In terms of what I'
On Wed, 20 Dec 2006 12:53:14 +, Matthew Garrett wrote:
> The situation is more complicated for wireless. Userspace expects to be
> able to get scan results from the card even if the interface is down.
User space should get an error when trying to get scan results from the
interface that is do
about your driver list;
do you have an idea of what the top 5 relevant ones would be?
I'd be surprised if the top 5 together had less than 95% market share,
so if we fix those we'd be mostly done already.
> The situation is more complicated for wireless. Userspace expects to be
> able to get scan
On Wed, Dec 20, 2006 at 08:50:24AM +0100, Arjan van de Ven wrote:
(Adding netdev - context is the altering of the runtime power
management interface, with the effect that it's no longer possible for
userspace to request that drivers suspend a device, so Arjan has
suggested that we do it via oth
50 matches
Mail list logo
