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
Hi,
This patch addes support for writing to the eeprom,
this also moves some duplicate code into seperate functions.
John: Do you want me to merge this path with the eeprom merge patch,
and move the patch that moves rt2x00 to use this eeprom module into a
separate patch or all these 2 patches
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 Wed, 20 Dec 2006 12:01:55 + (GMT)
"Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote:
> This is a change to include in
> which is needed for "struct fddi_statistics".
>
> Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]>
> ---
>
> Please apply.
>
> Maciej
>
> patch-mips-2.6.18-2006
On Wed, 20 Dec 2006 12:01:30 + (GMT)
"Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote:
> +/**
> + * tc_register_driver - register a new TC driver
> + * @drv: the driver structure to register
> + *
> + * Adds the driver structure to the list of registered drivers
> + * Returns a negative value on
On Wed, 20 Dec 2006 12:01:42 + (GMT)
"Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote:
>
> This is a set of changes to add TURBOchannel support to the defxx driver.
my, what a lot of rejects.
> patch-mips-2.6.18-20060920-defta-69
2.6.18?
-
To unsubscribe from this list: send the line "unsu
The following changes since commit e25db641c0e6dd49c5db24dbe154048d4a466727:
Linus Torvalds (1):
Merge master.kernel.org:/.../davej/cpufreq
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-fixes
Ulrich Kunitz (3):
The following changes since commit 0c234ae655a45ac3ee53a25b2e56e9bb6c27d71d:
Ulrich Kunitz (1):
ieee80211softmac: Fix mutex_lock at exit of ieee80211_softmac_get_genie
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream
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
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Wed, 20 Dec 2006 16:01:06 -0800
> [SCTP]: make 2 functions static
>
> This patch makes the following needlessly global functions static:
> - ipv6.c: sctp_inet6addr_event()
> - protocol.c: sctp_inetaddr_event()
>
> Signed-off-by: Adrian Bunk <[EMA
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Wed, 20 Dec 2006 16:00:57 -0800
> [SCTP]: Implement SCTP_FRAGMENT_INTERLEAVE socket option.
>
> This option was introduced in draft-ietf-tsvwg-sctpsocket-13. It
> prevents head-of-line blocking in the case of one-to-many endpoint.
> Applications
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Wed, 20 Dec 2006 16:00:50 -0800
> [SCTP]: Fix typo adaption -> adaptation as per the latest API draft.
>
> Signed-off-by: Ivan Skytte Jorgensen <[EMAIL PROTECTED]>
> Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
Applied, thanks Sridhar.
-
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Wed, 20 Dec 2006 16:00:39 -0800
> [SCTP]: Don't export include/linux/sctp.h to userspace.
>
> This file contains protocol definitions and there are no SCTP apps that use
> this file.
>
> Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
Appli
[SCTP]: Implement SCTP_FRAGMENT_INTERLEAVE socket option.
This option was introduced in draft-ietf-tsvwg-sctpsocket-13. It
prevents head-of-line blocking in the case of one-to-many endpoint.
Applications enabling this option really must enable SCTP_SNDRCV event
so that they would know where the d
[SCTP]: make 2 functions static
This patch makes the following needlessly global functions static:
- ipv6.c: sctp_inet6addr_event()
- protocol.c: sctp_inetaddr_event()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
---
include/net/sctp/sctp.h
[SCTP]: Fix typo adaption -> adaptation as per the latest API draft.
Signed-off-by: Ivan Skytte Jorgensen <[EMAIL PROTECTED]>
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
---
commit 1a7a0d391fb51bb26892aec4c7d36e7d8ba09d57
tree bd77592b453c53ff1988b29fa8aad1e54f95a842
parent 28e1d37084a68
[SCTP]: Don't export include/linux/sctp.h to userspace.
This file contains protocol definitions and there are no SCTP apps that use
this file.
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
---
include/linux/Kbuild |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/i
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
Arjan,
Thanks for the review. Please see my replies inline.
Arjan van de Ven wrote:
+/*
+ * Interrupt handler for asynchronous events used with MSI-X.
+ */
+static irqreturn_t t3_async_intr_handler(int irq, void *cookie)
+{
+ t3_slow_intr_handler(cookie);
+ return IRQ_HANDLED;
+}
Arjan van de Ven wrote:
+void t3_port_intr_disable(struct adapter *adapter, int idx)
+{
+ struct cphy *phy = &adap2pinfo(adapter, idx)->phy;
+
+ t3_write_reg(adapter, XGM_REG(A_XGM_INT_ENABLE, idx), 0);
+ phy->ops->intr_disable(phy);
you seem to be missing a pci posting f
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 Thu, Dec 14, 2006 at 03:07:06PM +, Gerrit Renker wrote:
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index c99774f..b7d8317 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -242,14 +242,9 @@ extern int tcp_memory_pressure;
>
> static inline int before(__u32 seq1,
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/Kconfig |1 +
drivers/infiniband/Makefile |1 +
drivers/infiniband/hw/cxgb3/Kconfig | 27 +++
drivers/infiniband/hw/cxgb3/Makefile | 12
4 files changed, 41 i
Debug code to dump various data structs, some of which are in
adapter memory.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/core/cxio_dbg.c | 205 +++
1 files changed, 205 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw
Core functions to carve up adapter memory, stag, qp, and cq IDs.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/core/cxio_resource.c | 331 ++
drivers/infiniband/hw/cxgb3/core/cxio_resource.h | 70 +
2 files changed, 401 insertions(+), 0
The RDMA Core interfaces with the T3 HW and ULLD providing a low level
RDMA interface.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/core/cxio_hal.c | 1302 +++
drivers/infiniband/hw/cxgb3/core/cxio_hal.h | 201
2 files changed, 1503
T3 WQE and CQE structures, defines, etc...
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/core/cxio_wr.h | 685
1 files changed, 685 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_wr.h
b/drivers/inf
Functions to register memory regions.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_mem.c | 170
1 files changed, 170 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_mem.c
b/drivers/infiniband/h
Functions to manipulate CQs.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_cq.c | 231 +
1 files changed, 231 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cq.c
b/drivers/infiniband/hw/cxgb3/iw
Code to handle async events coming from the T3 RDMA Core.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_ev.c | 231 +
1 files changed, 231 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_ev.c
b/d
Code to manipulate the QP.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_qp.c | 1007 +
1 files changed, 1007 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_qp.c
b/drivers/infiniband/hw/cxgb3/iwc
Provider methods to support the Linux RDMA verbs.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_provider.c | 1171 +++
drivers/infiniband/hw/cxgb3/iwch_provider.h | 363
drivers/infiniband/hw/cxgb3/iwch_user.h | 68 ++
Code to discover all the T3 devices and register them
with the T3 RDMA Core and the Linux RDMA Core.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch.c | 189
drivers/infiniband/hw/cxgb3/iwch.h | 175 +
Support provider-specific data in ib_uverbs_cmd_req_notify_cq().
The Chelsio iwarp provider library needs to pass information to the
kernel verb for re-arming the CQ.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/core/uverbs_cmd.c |9 +++--
drivers/infiniband
Roland,
I think this is ready to go once the ethernet driver is pulled in by Jeff.
Also: I'm gone after today returning Wednesday Jan 3rd. I'll address any
new issues when I return.
Cheers!
Steve.
Version 5 changes:
- BugFix: fixed broken endpoint state serialization
- Merged up
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 14 Dec 2006 12:48:17 -0800
> Make softnet_data local to dev.c.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Slight mistake here, I think:
> +#ifdef CONFIG_NETPOLL
> +extern void netpoll_do_completion(void);
> +#endif
From: Gerrit Renker <[EMAIL PROTECTED]>
Date: Thu, 14 Dec 2006 15:07:06 +
> While looking at DCCP sequence numbers, I stumbled over a problem with
> the following definition of before in tcp.h:
>
> static inline int before(__u32 seq1, __u32 seq2)
> {
> return (__s32)(seq1-seq2) < 0;
>
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
this patch tweaks the makefile so that it respects user environment variables
such as CC/CFLAGS/etc... and cleans out some cruft that is no longer utilized
-mike
pgplx9s90lvR9.pgp
Description: PGP signature
Respect user environment variables.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
d
In article <[EMAIL PROTECTED]> (at Wed, 20 Dec 2006 10:09:03 -0500), Mike
Frysinger <[EMAIL PROTECTED]> says:
> the ipg script only works with the old "pg3" module and not the new "pktgen"
> module ... attached patch updates the ipg script to support both
Applied. Thanks.
--yoshfuji
-
To unsu
a bunch of places in the tracepath code use goto's rather than real loop code,
or goto's to jump out of loop's ... some versions (like gcc-3.3.x iirc, older
admittedly) would miscompile this and it's cleaner anyways to just use real
loops
the attached patch isnt applicable as is (style changes
In article <[EMAIL PROTECTED]> (at Wed, 20 Dec 2006 10:00:32 -0500), Mike
Frysinger <[EMAIL PROTECTED]> says:
> a bunch of places in iputils utilize "int" lengths when in reality they
> should
> be using socklen_t
Patch applied. Thanks.
Please add some prefix in subject, please;
e.g. Subject
the ipg script only works with the old "pg3" module and not the new "pktgen"
module ... attached patch updates the ipg script to support both
-mike
pgpDCI0UbHEoD.pgp
Description: PGP signature
Only load modules if kernel supports modules and try a little bit
harder to locate the pg directory in
a bunch of places in iputils utilize "int" lengths when in reality they should
be using socklen_t
-mike
pgpSqlzw2arsi.pgp
Description: PGP signature
Use socklen_t in all the right places.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
diff --git a/arping.c b/arping.c
index 73a7e6f..86f1607
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'
> +void t3_port_intr_disable(struct adapter *adapter, int idx)
> +{
> + struct cphy *phy = &adap2pinfo(adapter, idx)->phy;
> +
> + t3_write_reg(adapter, XGM_REG(A_XGM_INT_ENABLE, idx), 0);
> + phy->ops->intr_disable(phy);
you seem to be missing a pci posting flush here
--
if yo
> +/*
> + * Interrupt handler for asynchronous events used with MSI-X.
> + */
> +static irqreturn_t t3_async_intr_handler(int irq, void *cookie)
> +{
> + t3_slow_intr_handler(cookie);
> + return IRQ_HANDLED;
> +}
this looks very wrong; why is t3_slow_intr_handler a void rather than
returni
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
From: Divy Le Ray <[EMAIL PROTECTED]>
This patch implements build files and versioning for the
Chelsio T3 network adapter's driver.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/Kconfig | 18 ++
drivers/net/Makefile|1 +
drivers/net/cxgb3/
From: Divy Le Ray <[EMAIL PROTECTED]>
This patch implements on board memory, MAC and PHY management
for the Chelsio T3 network adapter's driver.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/ael1002.c | 231 ++
drivers/net/cxgb3/mc5.c | 453 +
From: Divy Le Ray <[EMAIL PROTECTED]>
This patch implements the offload capabilities of the
Chelsio network adapter's driver.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_offload.c | 1222 +
drivers/net/cxgb3/l2t.c | 4
From: Divy Le Ray <[EMAIL PROTECTED]>
This patch implements the registers definitions for the
Chelsio network adapter's driver.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/regs.h | 2195 ++
1 files changed, 2195 insertions(+),
From: Divy Le Ray <[EMAIL PROTECTED]>
This patch implements the offload operations header files
for the Chelsio T3 network adapter's driver.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_ctl_defs.h | 142
drivers/net/cxgb3/cxgb3_defs.h | 99 ++
drivers/n
From: Divy Le Ray <[EMAIL PROTECTED]>
This patch implements the HW access routines for the
Chelsio T3 network adapter's driver.
This patch is split. This is the second part.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
+/**
+ * t3_port_intr_enable - enable port-specific interrupts
+ *
From: Divy Le Ray <[EMAIL PROTECTED]>
This patch implements the HW access routines for the
Chelsio T3 network adapter's driver.
This patch is split. This is the first part.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/t3_hw.c | 3353 +++
From: Divy Le Ray <[EMAIL PROTECTED]>
This patch implements the main header files of
the Chelsio T3 network driver.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/adapter.h | 255
drivers/net/cxgb3/common.h | 709 ++
Hello,
It has been much longer than expected, but finally it is here! This
series of patches converts support for the TURBOchannel bus to the driver
model. As a nice side effect, the generic part of the code is now really
generic, that is no more dependencies on MIPS specifics under drivers/
This is a set of changes to convert support for the TURBOchannel bus to
the driver model. It implements the usual set of calls similar to what
other bus drivers have: tc_register_driver(), tc_unregister_driver(), etc.
All the platform-specific bits have been removed and headers from
asm-mips
This is a change to include in
which is needed for "struct fddi_statistics".
Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]>
---
Please apply.
Maciej
patch-mips-2.6.18-20060920-if_fddi-netdev-0
diff -up --recursive --new-file
linux-mips-2.6.18-20060920.macro/include/linux/if_fddi.h
This is a set of changes to add TURBOchannel support to the defxx driver.
As at this point the EISA support in the driver has become the only not
having been converted to the driver model, I took the opportunity to
convert it as well. Plus support for MMIO in addition to PIO operation as
TUR
This is a change for the EISA bus support to permit drivers to call
un/registration functions even if EISA support has not been enabled. This
is similar to what PCI (and now TC) does and reduces the need for #ifdef
clutter.
Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]>
---
This is re
On Wed, 20 Dec 2006 14:43:51 +0800, Hong Liu wrote:
> The local->scan_work.data is not clear after scan is completed.
>
> This will cause softlockup when removing driver module because
> the local->scan_work is not initialized for hw_scan card
> and we are trying to cancel the scan_work with an u
Hi,
RFC2461 specifies in section 7.2.6 that a host may send unsolicited
NA(s) for example when its link layer address changes or IP address is
added to inform the neighbors that their ND cache may need to be
updated.
Some current routers (probably) erroneously depend on this to reduce
the "
On Wed, 20 Dec 2006 16:04:25 +0800, Hong Liu wrote:
> get_tsf passes the wrong pointer to driver.
Already fixed, see commit 0690925f2f99f6d43322ec8507eaabdcf1435c3c.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a messag
The rx_data.header struct is ieee80211_hdr_4addr. If a wireless frame uses
ieee80211_hdr_3addr header and is less than 6 bytes, it will be discarded.
This is not likely going to happen for normal packets (since there is TCP, IP
headers). But if fragmentation is used, there will be such small traili
get_tsf passes the wrong pointer to driver.
Signed-off-by: Hong Liu <[EMAIL PROTECTED]>
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index 3b55427..e48295e 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -2482,7 +2482,7 @@ #ifdef CONFIG_D80211_
98 matches
Mail list logo
