From: Rusty Russell <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 10:22:40 +1000
> You're thinking the card would place the packet in the mmap'ed buffer,
> but the protocol handling would still be done (on that user-accessible
> buffer) in kernelspace?
Exactly.
> I hadn't considered that. Are the
From what I have seen currently, the issue is resolved. Based on a
test across multiple systems on x86-64, i386, and ia64 builds.
On 4/28/06, Auke Kok <[EMAIL PROTECTED]> wrote:
On Fri, 28 Apr 2006 00:14:40 -0700 (PDT), "David S. Miller" <[EMAIL PROTECTED]>
wrote:
> From: Auke Kok <[EMAIL
>>-Original Message-
>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Linas Vepstas
>>Sent: 2006年3月25日 11:22
>>To: Greg KH
>>Cc: Jeff Garzik; Ronciak, John; Brandeburg, Jesse; Kirsher, Jeffrey T;
>>linux-kernel@vger.kernel.org; netdev@vger.kernel.org;
>>[EMAIL PROTECTED]; [
On Fri, 2006-04-07 at 06:24, Linas Vepstas wrote:
> Please apply and forward upstream.
>
> --linas
>
> [PATCH] PCI Error Recovery: e100 network device driver
>
> Various PCI bus errors can be signaled by newer PCI controllers. This
> patch adds the PCI error recovery callbacks to the intel ethe
Add a reset_phy parameter to tg3_reset_hw() and tg3_init_hw(). With
the full chip reset during MAC address change, the automatic PHY reset
during chip reset will cause a link down and bonding will not work
properly as a result. With this reset_phy parameter, we can do a chip
reset without link down
Update version to 3.57.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0779544..beeb612 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -69,8 +69,8 @@
#define DRV_MODULE_NAME"tg3"
#define PFX DRV_MODULE_NAME
Fix bug in nvram write function. If the starting nvram address offset
happens to be the last dword of the page, the NVRAM_CMD_LAST bit will
not get set in the existing code. This patch fixes the bug by changing
the "else if" to "if" so that the last dword condition always gets
checked.
Signed-off-
Add some PHY workaround code to reduce jitter on some PHYs.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index a28accb..a307340 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1030,6 +1030,12 @@ out:
tg3_writephy(tp
Do the full chip reset when changing MAC address if ASF is enabled.
ASF sometimes uses a different MAC address than the driver. Without
the reset, the ASF MAC address may be overwritten when the driver's
MAC address is changed.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/driver
Add netif_carrier_off() call during tg3_phy_reset(). This is needed
to properly track the netif_carrier state in cases where we do a
PHY reset with interrupts disabled. The SerDes code will not run
properly if the netif_carrier state is wrong.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff
On Wed, Apr 26, 2006 at 07:54:31PM -0500, Larry Finger wrote:
> I don't think it would make that much difference as the user could easily
> lie about their locality and get any set of parameters that they wanted.
Well, not any set.. One of the configured countries, yes, but that is
not same as
On Fri, 2006-04-28 at 15:40 -0700, David S. Miller wrote:
> From: Rusty Russell <[EMAIL PROTECTED]>
> Date: Sat, 29 Apr 2006 08:17:01 +1000
> > However, in future, if intelligent cards exist, having an API which lets
> > them do zero-copy and not overly penalize less intelligent cards makes
> > sen
On Fri, 2006-04-28 at 15:38 -0700, David S. Miller wrote:
> From: Rusty Russell <[EMAIL PROTECTED]>
> Date: Sat, 29 Apr 2006 08:04:04 +1000
>
> > You're still thinking you can bypass classifiers for established
> > sockets, but I really don't think you can. I think the simplest
> > solution is to
On Wed, 26 Apr 2006, Sven Schuster wrote:
but don't hold your breath waiting for me, kernel compile
takes more than two hours on my box :-)
Ouch. Takes 5/7 minutes here on the AMD64 resp. P4. Computer museum? :P
Anyhow, I tested PPP for 2.5 hours on the AMD64 the day before
yesterday with a b
David S. Miller wrote:
> From: Rusty Russell <[EMAIL PROTECTED]>
> Date: Sat, 29 Apr 2006 08:04:04 +1000
>
>> You're still thinking you can bypass classifiers for established
>> sockets, but I really don't think you can. I think the simplest
>> solution is to effectively remove from (or flag) the
On Fri, 28 Apr 2006, David S. Miller wrote:
From: Hua Zhong <[EMAIL PROTECTED]>
Date: Wed, 26 Apr 2006 09:50:28 -0700 (PDT)
[I hope this time it's OK - I'm sending from pine/Linux]
It adds an extra space in the diff lines which corrupts
the patch.
You can work around this by enabling quell
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 02:04:56 +0900 (JST)
> We eliminated rt6_dflt_lock (to protect default router pointer)
> at 2.6.17-rc1, and introduced rt6_select() for general router selection.
> The function is called in the context of rt6_lock read-lock held,
>
On Wed, Apr 26, 2006 at 07:54:31PM -0500, Larry Finger wrote:
> I am leaning toward putting the geographical information into a
> userland daemon.
I like that idea very much. This is all control metadate that doesn't
really need to be in the kernel.
> That way we won't have to patch the kernel
From: Rusty Russell <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 08:17:01 +1000
> On Fri, 2006-04-28 at 10:55 -0700, Caitlin Bestler wrote:
> > vj_netchannels represent a strategy of minimizing
> > registration/pinning costs even if it means paying for an extra copy.
> > Because the extra copy is cl
From: Rusty Russell <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 08:04:04 +1000
> You're still thinking you can bypass classifiers for established
> sockets, but I really don't think you can. I think the simplest
> solution is to effectively remove from (or flag) the established &
> listening hashe
From: Hua Zhong <[EMAIL PROTECTED]>
Date: Wed, 26 Apr 2006 09:50:28 -0700 (PDT)
> [I hope this time it's OK - I'm sending from pine/Linux]
It adds an extra space in the diff lines which corrupts
the patch.
I've applied this by hand, but please try to get something
which works before providing ne
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2006 21:56:45 +1000
> I was looking through the xfrm input/output code in order to abstract
> out the address family specific encapsulation/decapsulation code. During
> that process I found this bug in the IP ID selection code in xfrm4_output
On Fri, 2006-04-28 at 10:55 -0700, Caitlin Bestler wrote:
> vj_netchannels represent a strategy of minimizing
> registration/pinning costs even if it means paying for an extra copy.
> Because the extra copy is closely tied to the activation of the data
> sink consumer the cost of that extra copy is
On Fri, 2006-04-28 at 12:21 -0700, David S. Miller wrote:
> From: Rusty Russell <[EMAIL PROTECTED]>
> Date: Fri, 28 Apr 2006 18:24:08 +1000
>
> > Note that the problem space AFAICT includes strange advanced routing
> > setups, ingress qos and possibly others, not just netfilter. But
> > perhaps t
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 23:59:30 +0400
> kevent can be used as poll without any changes to the socket code.
> There are two types of network related kevents - socket events
> (recv/send/accept) and network aio, which can be turned completely off
> in confi
From: S P <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 13:51:43 -0700 (PDT)
> 1 line removal, of unused macro.
> ran 'egrep -r' from linux-2.6.16/ for Nprintk and
> didn't see it anywhere else but here, in #define...
>
>
> signed off by: soyoung park
Hi Pekka,
On Apr 28 at 02:59:01, Pekka J Enberg wrote:
> Here are some suggestions for coding style cleanups:
Couple of questions,
> - Use dev_{dbg,err,info,warn} for logging
Cannot, i need a "struct device" and most of the
there's only access to a "struct net_device". Am i
missing something?
Santiago Leon wrote:
This patch provides a sysfs interface to change some properties of the
ibmveth buffer pools (size of the buffers, number of buffers per pool,
and whether a pool is active). Ethernet drivers use ethtool to provide
this type of functionality. However, the buffers in the ibmv
This patch adds NETPOLL support for the ibmveth driver. Please apply.
Signed-off-by: Santiago Leon <[EMAIL PROTECTED]>
ibmveth.c | 11 +++
1 file changed, 11 insertions(+)
--- a/drivers/net/ibmveth.c 2006-04-28 13:16:22.244724056 -0500
+++ b/drivers/net/ibmveth.c 2006-04-28 13
1 line removal, of unused macro.
ran 'egrep -r' from linux-2.6.16/ for Nprintk and
didn't see it anywhere else but here, in #define...
signed off by: soyoung park<[EMAIL PROTECTED]>--- linux-2.6.16/net/netlink/af_netlink.c~ Sun Mar 19 21:53:29
On Friday 28 April 2006 14:10, David S. Miller wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Fri, 28 Apr 2006 10:18:33 -0700
>
> > Please just use existing AIO interface.
>
> I totally disagree, the existing AIO interface is garbage.
>
> We need new APIs to do this right, to get the
On Fri, Apr 28, 2006 at 12:49:15PM -0700, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
> But there is this huge semantic overload of kevent, poll, epoll, aio,
> regular sendmsg/recv, posix aio, etc.
>
> Perhaps a clean break with the socket interface is needed. Otherwise, there
> are nasty comp
Michael Ellerman wrote:
Looks like this hit the floor. Any chance of getting it into to 2.6.17
Jeff? AFAICT it should still apply cleanly.
/me knocks politely
Actually, it doesn't apply cleanly anymore. Here's a patch that does.
--
Santiago A. Leon
Power Linux Development
IBM Linux Technolog
On Fri, Apr 28, 2006 at 12:16:36PM -0700, David S. Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Fri, 28 Apr 2006 21:55:39 +0400
>
> > On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger ([EMAIL
> > PROTECTED]) wrote:
> > > Second, introducing
> >
On Fri, 28 Apr 2006 12:16:36 -0700 (PDT)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Fri, 28 Apr 2006 21:55:39 +0400
>
> > On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger ([EMAIL
> > PROTECTED]) wrote:
> > > Second, introducing
>
From: Rusty Russell <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 18:24:08 +1000
> Note that the problem space AFAICT includes strange advanced routing
> setups, ingress qos and possibly others, not just netfilter. But
> perhaps the same solutions apply, so I'll concentrate on nf.
Yes, this hasn't
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 21:55:39 +0400
> On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger ([EMAIL
> PROTECTED]) wrote:
> > Second, introducing
> > kevents, seems unnecessary and hasn't been accepted in the mainline.
>
> kevent was never sent t
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 21:25:36 +0400
> The more complex userspace interface we create the less users it will
> have. It is completely unconvenient to read 100 bytes and receive only
> 80, since 20 were eaten by header.
These bytes are charged to socket
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 10:22:40 -0700
> The following one line fix is needed to make loss function of
> netem work right when doing loss on the local host.
> Otherwise, higher layers just recover.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 10:18:33 -0700
> Please just use existing AIO interface.
I totally disagree, the existing AIO interface is garbage.
We need new APIs to do this right, to get the ring buffer
and the zero-copy'ness correct.
-
To unsubscribe from t
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 20:12:21 +0400
> If there is dataflow, not flow of packets or flow of data with holes,
> it could be possible to modify recv() to just return the right pointer,
> so in theory userspace modifications would be minimal.
> With copy in
From: Shaun Pereira <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 15:03:23 +1000
> From: [EMAIL PROTECTED]
>
> When the sk_timer function x25_heartbeat_expiry() is called by the kernel
> in a running/terminating process, spinlock-recursion and spinlock-lockup
> locks up the kernel.
> This has happe
From: Ivo van Doorn <[EMAIL PROTECTED]>
During CVS merge I noticed several compilation errors have sneaked
into the git version of rt2x00.
- PRIO_ENTRIES define has been removed, TX_ENTRIES should be used
- poll_delay module argument is of the type short
- Remove LINUX_VERSION_CODE checks.
- Fix m
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 11:32:16 +0400
> Definitely, userspace application must be very smart to deal with
> ip/tcp/option headers...
That is why we will put an "offset+len" in the ring so they need not
parse the packet headers.
-
To unsubscribe from thi
Evgeniy Polyakov wrote:
>
> I see your point, and respectfully disagree.
> The more complex userspace interface we create the less users
> it will have. It is completely unconvenient to read 100 bytes
> and receive only 80, since 20 were eaten by header. And what
> if we need only 20, but packet
On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
> On Fri, 28 Apr 2006 21:29:32 +0400
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Apr 28, 2006 at 10:18:33AM -0700, Stephen Hemminger ([EMAIL
> > PROTECTED]) wrote:
> > > Please just use existin
On Fri, 28 Apr 2006 21:29:32 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 28, 2006 at 10:18:33AM -0700, Stephen Hemminger ([EMAIL
> PROTECTED]) wrote:
> > Please just use existing AIO interface. We don't need another
> > interface. The number of interfaces increases the expose
On Fri, Apr 28, 2006 at 10:18:33AM -0700, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
> Please just use existing AIO interface. We don't need another
> interface. The number of interfaces increases the exposed bug
> surface geometrically. Which means for each new interface, it
> means testing a
On Fri, Apr 28, 2006 at 10:02:10AM -0700, Caitlin Bestler ([EMAIL PROTECTED])
wrote:
> If the app is really ready to use a modified interface we might as well
> just give them a QP/CQ interface. But I suppose "receive by pointer"
> interfaces don't really stretch the sockets interface all that bad
Loss was broken, patch sent.
The following works now:
# tc qdisc add dev eth1 root handle 1:0 netem loss 20%
# tc qdisc add dev eth1 parent 1:1 handle 10: tbf \
rate 256kbit buffer 1600 limit 3000
# ping -f -c 1000 shell
1000 packets transmitted, 781 received, 21% packet loss, time 3214ms
rtt
The following one line fix is needed to make loss function of
netem work right when doing loss on the local host.
Otherwise, higher layers just recover.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- linux-2.6.orig/net/sched/sch_netem.c
+++ linux-2.6/net/sched/sch_netem.c
@@ -167,7 +167
On Fri, 28 Apr 2006 10:02:10 -0700
"Caitlin Bestler" <[EMAIL PROTECTED]> wrote:
> Evgeniy Polyakov wrote:
> > On Fri, Apr 28, 2006 at 08:59:19AM -0700, Caitlin Bestler
> > ([EMAIL PROTECTED]) wrote:
> >>> Btw, how is it supposed to work without header split capabale
> >>> hardware?
> >>
> >> Hard
Evgeniy Polyakov wrote:
> On Fri, Apr 28, 2006 at 08:59:19AM -0700, Caitlin Bestler
> ([EMAIL PROTECTED]) wrote:
>>> Btw, how is it supposed to work without header split capabale
>>> hardware?
>>
>> Hardware that can classify packets is obviously capable of doing
>> header data separation, but tha
On Fri, Apr 28, 2006 at 08:59:19AM -0700, Caitlin Bestler ([EMAIL PROTECTED])
wrote:
> > Btw, how is it supposed to work without header split capabale
> > hardware?
>
> Hardware that can classify packets is obviously capable of doing
> header data separation, but that does not mean that it has to
Evgeniy Polyakov wrote:
> On Thu, Apr 27, 2006 at 02:12:09PM -0700, Caitlin Bestler
> ([EMAIL PROTECTED]) wrote:
>> So the real issue is when there is an intelligent device that uses
>> hardware packet classification to place the packet in the correct
>> ring. We don't want to bypass packet filteri
On Wed, 26 Apr 2006 15:39:12 -0400, John W. Linville wrote:
> Hacky or not, I'm applying this patch to keep the bcm43xx driver
> from breaking. I don't suppose you have a patch for the rt2x00 driver?
The patch for bcm43xx was really just quick fix, only partially
tested...
Signed-off-by: Jiri Be
On Friday 28 April 2006 15:46, Christoph Hellwig wrote:
> On Fri, Apr 28, 2006 at 03:42:29PM +0200, Michael Buesch wrote:
> > I guess you are confusing something here:
> > MMIO access versus values in structs (for example) that
> > are accessed through DMA (for example).
>
> so there's two genera
From: Ivo van Doorn <[EMAIL PROTECTED]>
Remove unneeded casts when working with a void* pointer.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.
Hi,
Here is a small update for the rt2x00 drivers in the wireless-dev tree.
They all contain fixes and requests from the feedback from the last series.
And they should be applied after the last series.
A short summary of all patches the are following:
[PATCH 1/6] rt2x00 update: Remove casts from
From: Ivo van Doorn <[EMAIL PROTECTED]>
Return correct error code at failure, and
request debug report when the function _tx()
has received an invalid queue.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-d
From: Ivo van Doorn <[EMAIL PROTECTED]>
Use __le32 annotations for all fields in the descriptor,
since these should always be treated as little endian.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
wireless-dev-rt2
From: Ivo van Doorn <[EMAIL PROTECTED]>
Set monitor_during_oper to 0 for the time being,
this feature will be supported in the future.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-rt2x00-patch/drivers
From: Ivo van Doorn <[EMAIL PROTECTED]>
Remove __attribute__ ((packed)) for structures that
are not being send to the device.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00.h
wireless-dev-rt2x00-patch/drivers/net/wireles
From: Ivo van Doorn <[EMAIL PROTECTED]>
Make the vals arrays static const.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-rt2
On Friday 28 April 2006 16:30, Jiri Benc wrote:
> On Fri, 28 Apr 2006 16:25:09 +0200, Ivo van Doorn wrote:
> > I am not really fan on such messages. But when the control->queue is indeed
> > invalid, it is a serious bug. Perhaps a BUG() should be used as well?
> > If so, I'll put it into a new patc
On Fri, 28 Apr 2006 16:25:09 +0200, Ivo van Doorn wrote:
> I am not really fan on such messages. But when the control->queue is indeed
> invalid, it is a serious bug. Perhaps a BUG() should be used as well?
> If so, I'll put it into a new patch along with the fixes below.
BUG() is not a good idea,
On Friday 28 April 2006 12:52, Jiri Benc wrote:
> On Fri, 28 Apr 2006 00:03:13 +0200, Ivo van Doorn wrote:
> > Use seperate function to convert a dscape ring ID
> > to the address of the actual ring.
>
> Just minor things:
>
> > [...]
> > @@ -1386,20 +1412,19 @@ rt2400pci_tx(struct net_device *ne
On Friday 28 April 2006 15:46, you wrote:
> On Fri, Apr 28, 2006 at 03:42:29PM +0200, Michael Buesch wrote:
> > I guess you are confusing something here:
> > MMIO access versus values in structs (for example) that
> > are accessed through DMA (for example).
>
> so there's two general problems:
>
On Fri, Apr 28, 2006 at 03:42:29PM +0200, Michael Buesch wrote:
> I guess you are confusing something here:
> MMIO access versus values in structs (for example) that
> are accessed through DMA (for example).
so there's two general problems:
mmio/pio - linux expects the device to be le there
On Friday 28 April 2006 15:42, Michael Buesch wrote:
> On Friday 28 April 2006 15:31, you wrote:
> > On Friday 28 April 2006 15:14, Christoph Hellwig wrote:
> > > On Fri, Apr 28, 2006 at 02:59:23PM +0200, Ivo van Doorn wrote:
> > > > I am not sure if that would be a wise idea,
> > > > there is no b
On Friday 28 April 2006 13:12, Jiri Benc wrote:
> On Fri, 28 Apr 2006 00:03:19 +0200, Ivo van Doorn wrote:
> > Latest dscape patches have broken rt2x00,
> > fix compile issues, and support the new features.
>
> > @@ -2466,6 +2568,7 @@ rt2500pci_init_hw(struct rt2x00_pci *rt2
> > hw->no_tkip_wm
On Friday 28 April 2006 13:45, Ingo Oeser wrote:
> Hi Ivo,
>
> Ivo van Doorn wrote:
> > diff -uprN
> > wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
> > wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
> > --- wireless-dev-rt2x00/drivers/net/wireless/
On Friday 28 April 2006 13:26, Ingo Oeser wrote:
> Sie schrieben:
> > From: Ivo van Doorn <[EMAIL PROTECTED]>
> >
> > The vals[] arrays in *_init_hw_channels can be made
> > static to optimize memory and reduce stack size.
>
> What about static const? They are also constants, right?
> But please
On Friday 28 April 2006 15:33, Michael Buesch wrote:
> On Friday 28 April 2006 15:24, you wrote:
> > struct data_ring{
> > /*
> > * net_device where this ring belongs to.
> > */
> > struct net_device *net_dev;
> >
> > /*
> > * Work structure for bot
On Friday 28 April 2006 15:31, you wrote:
> On Friday 28 April 2006 15:14, Christoph Hellwig wrote:
> > On Fri, Apr 28, 2006 at 02:59:23PM +0200, Ivo van Doorn wrote:
> > > I am not sure if that would be a wise idea,
> > > there is no byte ordering done in rt2500usb except for the EEPROM
> > > cont
On Friday 28 April 2006 15:14, Christoph Hellwig wrote:
> On Fri, Apr 28, 2006 at 02:59:23PM +0200, Ivo van Doorn wrote:
> > I am not sure if that would be a wise idea,
> > there is no byte ordering done in rt2500usb except for the EEPROM
> > contents which is little endian.
> > So when the module
On Friday 28 April 2006 15:24, you wrote:
> struct data_ring{
> /*
>* net_device where this ring belongs to.
>*/
> struct net_device *net_dev;
>
> /*
>* Work structure for bottom half interrupt handling.
>*/
> struct wor
On Thu, Apr 27, 2006 at 05:54:58AM -0400, Jeff Garzik wrote:
> >Provide a module option which configures the natsemi driver to use the
> >external MII port on the chip but ignore any PHYs that may be attached to
> >it. The link state will be left as it was when the driver started and can
> The
On Friday 28 April 2006 15:15, Christoph Hellwig wrote:
> On Fri, Apr 28, 2006 at 02:57:31PM +0200, Ivo van Doorn wrote:
> > On Friday 28 April 2006 00:11, Christoph Hellwig wrote:
> > > On Fri, Apr 28, 2006 at 12:02:52AM +0200, Ivo van Doorn wrote:
> > > > From: Ivo van Doorn <[EMAIL PROTECTED]>
>
On Fri, Apr 28, 2006 at 02:59:23PM +0200, Ivo van Doorn wrote:
> I am not sure if that would be a wise idea,
> there is no byte ordering done in rt2500usb except for the EEPROM
> contents which is little endian.
> So when the module is used on a normal x86 platform, there won't be
> any big endian
On Fri, Apr 28, 2006 at 02:57:31PM +0200, Ivo van Doorn wrote:
> On Friday 28 April 2006 00:11, Christoph Hellwig wrote:
> > On Fri, Apr 28, 2006 at 12:02:52AM +0200, Ivo van Doorn wrote:
> > > From: Ivo van Doorn <[EMAIL PROTECTED]>
> > >
> > > Instead of dma_*_coherent
> > > use pci_*consistent
On Friday 28 April 2006 00:13, Christoph Hellwig wrote:
> On Fri, Apr 28, 2006 at 12:03:12AM +0200, Ivo van Doorn wrote:
> > From: Ivo van Doorn <[EMAIL PROTECTED]>
> >
> > Fix various little/big endian conversions.
> > rt2500pci should use cpu_to_le32 and rt2500usb should not.
>
> While you're a
On Friday 28 April 2006 00:11, Christoph Hellwig wrote:
> On Fri, Apr 28, 2006 at 12:02:52AM +0200, Ivo van Doorn wrote:
> > From: Ivo van Doorn <[EMAIL PROTECTED]>
> >
> > Instead of dma_*_coherent
> > use pci_*consistent functions.
>
> No point in doing that, quite reverse as you use the gfp_ma
Hi David,
David Gómez wrote:
> On Apr 28 at 01:58:04, Pekka Enberg wrote:
> > Needs some serious coding style cleanup and conversion to proper 2.6
> > APIs for starters.
>
> Ok, i could take care of that, and it's a good way of getting my hands
> dirty with kernel programming ;). David, if it's o
Hi David,
On Fri, 28 Apr 2006, David Gómezz wrote:
> Ok, i could take care of that, and it's a good way of getting my hands
> dirty with kernel programming ;). David, if it's ok to you i'll do the
> cleanup thing.
Here are some suggestions for coding style cleanups:
- Use Lindet for initial fo
On Apr 28 at 01:58:04, Pekka Enberg wrote:
> > Needs some serious coding style cleanup and conversion to proper 2.6
> > APIs for starters.
On Fri, 28 Apr 2006, David Gómezz wrote:
> Ok, i could take care of that, and it's a good way of getting my hands
> dirty with kernel programming ;). David, if
Hi Ivo,
Ivo van Doorn wrote:
> diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
> wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
> --- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
> 2006-04-27 21:48:21.0
Hi Pekka,
On Apr 28 at 01:58:04, Pekka Enberg wrote:
> Needs some serious coding style cleanup and conversion to proper 2.6
> APIs for starters.
Ok, i could take care of that, and it's a good way of getting my hands
dirty with kernel programming ;). David, if it's ok to you i'll do the
cleanup th
Sie schrieben:
> From: Ivo van Doorn <[EMAIL PROTECTED]>
>
> The vals[] arrays in *_init_hw_channels can be made
> static to optimize memory and reduce stack size.
What about static const? They are also constants, right?
But please try first, if this helps in terms of code size.
Regards
Ingo Oe
On Fri, 28 Apr 2006 00:03:19 +0200, Ivo van Doorn wrote:
> Latest dscape patches have broken rt2x00,
> fix compile issues, and support the new features.
> @@ -2466,6 +2568,7 @@ rt2500pci_init_hw(struct rt2x00_pci *rt2
> hw->no_tkip_wmm_hwaccel = 1;
> hw->extra_hdr_room = 0;
> hw-
On 4/28/06, David Gómez <[EMAIL PROTECTED]> wrote:
> I could help. What things do you think need to be fixed before
> submitting the driver?
Needs some serious coding style cleanup and conversion to proper 2.6
APIs for starters.
-
To unsubscribe from this list: send the line "unsubscribe netdev" i
On Fri, 28 Apr 2006 00:03:13 +0200, Ivo van Doorn wrote:
> Use seperate function to convert a dscape ring ID
> to the address of the actual ring.
Just minor things:
> [...]
> @@ -1386,20 +1412,19 @@ rt2400pci_tx(struct net_device *net_dev,
>
> rt2x00_register_read(rt2x00pci, TXCSR0, ®);
>
On Thu, 2006-04-27 at 14:12 -0700, Caitlin Bestler wrote:
> So the real issue is when there is an intelligent device that
> uses hardware packet classification to place the packet in
> the correct ring. We don't want to bypass packet filtering,
> but it would be terribly wasteful to reclassify the
Hi David,
On Apr 27 at 11:26:07, David Vrabel wrote:
> I finally got around to putting a 2nd NIC in my box that has one of this
> chips and was going to start fixing the driver up and preparing it for
> submission this weekend.
Great!
> Or I might try rewriting from scratch based on
> the da
Hi Francois,
On Apr 27 at 08:56:27, Francois Romieu wrote:
> /me goes to http://www.icplus.com.tw/driver-pp-IP1000A.html
>
> $ unzip -c IP1000A-Linux-driver-v2.09f.zip | grep MODULE_LICENSE
> MODULE_LICENSE("GPL");
Thanks, i didn't notice it ;-)
> It's a bit bloaty but it does not seem too
On Fri, Apr 28, 2006 at 12:20:27AM -0700, David S. Miller ([EMAIL PROTECTED])
wrote:
> > Btw, how is it supposed to work without header split capabale hardware?
>
> I do not see header splitting as a requirement, let the raw
> headers sit in the user queue and provide an offset to the data.
> All
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 10:10:54 +0400
> On Thu, Apr 27, 2006 at 02:12:09PM -0700, Caitlin Bestler ([EMAIL PROTECTED])
> wrote:
> > So the real issue is when there is an intelligent device that
> > uses hardware packet classification to place the packet i
Török Edwin wrote:
> Patrick what is the status of solving the skfilter issues? Can I help with
> testing patches, etc.?
Not yet. If nothing gets in between I plan to get the patches ready
next week.
> On Monday 20 February 2006 18:42, Patrick McHardy wrote:
>
>>Confirmation of conntrack entri
From: Auke Kok <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2006 18:54:28 -0700
> Dave Jones wrote:
> > With 2.6.17-rc3, my E1000 won't get a dhcp lease.
> > Looking at tcpdump and ifconfig output, it's easy to see why.
> > It's recieving packets, but the packets transmitted field
> > of ifconfig never i
99 matches
Mail list logo
