Re: [PATCHv2 1/2]: [NET]: Supporting UDP-Lite (RFC 3828) in Linux
| [NET]: Supporting UDP-Lite (RFC 3828) in Linux
| applied to net-2.6.20, thanks Gerrit.
Many thanks indeed. During these changes I accidentally
forgot to restore udp_push_pending_frames to its static state.
Can you please consider the attached patch --
[NET/IPv4]: Make udp_push_pending_frames static
udp_push_pending_frames is only referenced within
net/ipv4/udp.c and hence can remain static.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 227655c..ac613ed 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -447,7 +447,7 @@ static void udp4_hwcsum_outgoing(struct
/*
* Push out all pending data as one UDP datagram. Socket is locked.
*/
-int udp_push_pending_frames(struct sock *sk, struct udp_sock *up)
+static int udp_push_pending_frames(struct sock *sk, struct udp_sock *up)
{
struct inet_sock *inet = inet_sk(sk);
struct flowi *fl = inet-cork.fl;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: status of route matching work?
* Kumar Gala [EMAIL PROTECTED] 2006-11-14 15:08 And was wondering what the status of this work was. I'm interested in being able to force packets for a local address out a real ethernet device. I'm working on it. For now, use SO_BINDTODEVICE. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/2]: [NET]: Supporting UDP-Lite (RFC 3828) in Linux
From: Gerrit Renker [EMAIL PROTECTED] Date: Wed, 15 Nov 2006 07:58:17 + [NET/IPv4]: Make udp_push_pending_frames static udp_push_pending_frames is only referenced within net/ipv4/udp.c and hence can remain static. Signed-off-by: Gerrit Renker [EMAIL PROTECTED] Applied, thanks Gerrit. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless notes / pre d80211 merge
On Wed, 2006-11-15 at 01:11 +0100, Jiri Benc wrote: I wouldn't say useless. It's actually a hack (and you yourself described in (7) why it is currently necessary). We'll need to live with it or cripple the stack to support only very basic features or rewrite the Linux networking core. Choose your own favorite solution :-) I'd be fine with living with what you think of as a hack for a while if the medium- to long-term plan is to rewrite the networking core to get rid of it. I'm just not sure it makes sense. During the tx handlers phase that copy of skb-cb is extended quite a lot with other information determined in the tx handlers. The result is a structure that doesn't fit into cb anymore. This is a reason for not using cb to pass tx information to drivers. Actually, no, it isn't :) The part that is passed to drivers does fit, only the internal stuff doesn't. Straying a bit from the discussion of frames and similar, let me describe the wiphy concept we currently have. Currently, in sysfs we have class/ieee80211/phy%d/ and below that a wealth of information not only about various hardware related things but also, for example, a list of all stations associated to any virtual access points intermixed with those 'stations' that we are associated to on any virtual interface. Also, we here find 'add_iface' and 'remove_iface', knobs to create and destroy virtual interfaces. The second wiphy concept is currently present in cfg80211 which currently requires this concept in the userspace interface and should effectively replace the 'add_iface' and 'remove_iface' hooks and make them more generically available for non-d80211 drivers. I was thinking of ipw2200 when I wrote it which allows adding a monitor device (currently through some config option I think). Not a big problem to combine these two wiphys into just one. Right, that's no biggie. I was just trying to describe what we currently have an forgot to mention it. Please note that master interface has been always considered as a hack. Of course, this perception can be changed if it's desirable. Has it? Simon seems to disagree ;) The master netdev and wiphy create two orthogonal interfaces to userspace that nonetheless pretty much represent the same thing---the underlying hardware. Yup. You just say it like that. Aren't you unhappy about that at all? There is one thing you haven't mentioned and which was probably the key reason for not believing this concept was wrong: we want to make the transition to the new stack as smooth to the users as possible. Users are not used to use the master interface. But since we're going to have a new set of userspace tools anyway, this point is no longer valid. No, wait! We're transitioning from something that only supports one interface to something that supports many virtual ones. As long as we can represent the semantics of the previous single one as the default virtual one, we're fine. Which is actually very possible and cfg80211's WE compat code tries to show that. I don't think the master interface matters here at all. It's just an additional netdev that users previously didn't have, but so what? If this is your biggest problem with d80211 you're really happy :-) Try to fix some locking issue ;-) Let me qualify to externally visible problems :) I'm not too concerned about the internal stuff. That can be cleaned up with some effort, but the externally visible stuff can't actually just be cleaned up without thought and a plan. A full conversion to 802.11 protocol should do much more things and is not possible until we rewrite bridging. You converted the master interface only. That's not what I would call converting d80211 to a 802.11 protocol. I've said this before but let me repeat. There are two ends to d80211 top:virtual interfaces, most likely 802.3 for at least a while if not forever bottom: communication with hardware, qdiscs, etc. I've never wanted to change the top part (so far anyway :) ). It's orthogonal. And whether d80211 behaves as an 802.11 protocol is something that's visible only in the RX path really, struct packet_type and associated things. This seems quite elegant, but there are a couple of problems with it: - skb-cb is sort of abused, and might be too small in the future. If This is a blocker issue for me. it becomes too small, we could put a pointer into skb-cb instead and do lifetime management with an skb desctructor. Not very effective but will work. Not really less effective than copying it around all the time as we do now and then kmalloc()ing it in some circumstances. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless notes / pre d80211 merge
On Tue, 14 Nov 2006 18:10:50 -0800, Simon Barber wrote: I disagree that the master device is a hack It's a clever hack but still a hack. The Linux network interfaces wasn't designed for the sort of things we do with master interface. Actually, the networking core doesn't support the concept of wiphys at all. Yes, Jouni found a really clever way around this. But the most correct solution is different. In particular: - The operations that make sense for user to perform on wiphy/master interface are different than the ones on virtual interfaces. It isn't this way now. - Why should master interface appear in ifconfig and similar tools the same way as virtual interfaces? If you want to know how users are confused by this, just search some forums. - Does attaching of qdiscs to virtual interfaces make sense? - Etc. To me, the master interface in its current shape is a nice workaround of kernel limitations, but still not a clean solution. I also disagree that we should use 802.11 format frames anywhere but internally inside the 802.11 stack. The 802.11 specification does not use 802.11 format frames to communicate with the upper layers - it uses almost exactly the same interface as 802.3 ethernet does. This is a 2 address interface. I believe that using the standard 2 address format to talk with upper layers matches well with the spec and is the right way to do things. This is a different thing. See the difference between SOCK_RAW and SOCK_DGRAM. The interface you are talking about is SOCK_DGRAM. Except it supports only one address. The correct solution would be extending sockaddr_ll (that's not possible, I know) or introduce a new SOCK_SOMETHING type (not possible either, at least in a short term). If you put 802.11 frame format directly into the L3 protocols then you make all these protocols depend on the MAC - since they will now implement part of the MAC inside the L3 protocol. I don't think this is the right thing to do. I believe that the mapping of 3 and 4 address frames to a particular virtual 2 address port is the right way to do this mapping. For some kind of applications SOCK_RAW on 802.11 interfaces makes sense. (Actually, that's not so simple as they need to specify other things like tx rate but that's an another story.) It is normal to have a single interface to represent the physical hardware network interface. Except that all other hardware doesn't need things that we need. They need just one virtual interface - so their master and virtual interface is merged. This is net_device. We need to split it into two things. This is exactly the pattern that many other physical network devices use. Things like sniffing should go on on this physical interface - and the changes that johannes proposes are exactly the right things to enable this. I would go further - and perhaps move some of the meta-data that is in the skb-cb into a d80211 specific hardware header. This would allow sniffers to directly attach to the master device and both send and receive frames complete with the meta data. It would also reduce the amount of cb space we need. Virtual devices could be created in order to use sniffers that use a different hardware header format (with a small performance penalty when using those). This seems as a really bad solution to me. I fully agree with Johannes regarding this. Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: wireless notes / pre d80211 merge
I would go further - and perhaps move some of the meta-data that is in the skb-cb into a d80211 specific hardware header. This would allow sniffers to directly attach to the master device and both send and receive frames complete with the meta data. It would also reduce the amount of cb space we need. Virtual devices could be created in order to use sniffers that use a different hardware header format (with a small performance penalty when using those). I'm not sure this is a good idea, it locks us in to some format because user-space uses it and we'd need to serialise to that format to be extensible. On the other hand, we could fix some part of the structure to be user-space visible, make it a real struct that just lives before the 802.11 header and don't serialise like it would be necessary with something that is extensible. On RX, we could do the same. For TX, this would allow applications to control whatever we put into that struct (I would not, for example, allow tx status notifications to ever go over a netdev as we do now), while for RX it would allow apps to see almost everything. It might complicate code a bit because different things would come from different places (some things from a special header and some from skb-cb), but I don't think it would be bad. Other than this, I agree with you. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless notes / pre d80211 merge
On Wed, 15 Nov 2006 10:16:18 +0100, Johannes Berg wrote: During the tx handlers phase that copy of skb-cb is extended quite a lot with other information determined in the tx handlers. The result is a structure that doesn't fit into cb anymore. This is a reason for not using cb to pass tx information to drivers. Actually, no, it isn't :) The part that is passed to drivers does fit, only the internal stuff doesn't. Sorry, I was wrong here. I rechecked it now and starting from the last diet (made by me long time ago, grr) it fits. Please note that master interface has been always considered as a hack. Of course, this perception can be changed if it's desirable. Has it? Simon seems to disagree ;) And I disagree with Simon :-) The master netdev and wiphy create two orthogonal interfaces to userspace that nonetheless pretty much represent the same thing---the underlying hardware. Yup. You just say it like that. Aren't you unhappy about that at all? I wasn't in times when there was no cfg80211. But now... yes, you're right. The sysfs ieee80211 class exports just some interesting informations (we already agreed that add_interface and remove_interface would go away). Feel free to move it wherever you think is appropriate. I don't think the master interface matters here at all. It's just an additional netdev that users previously didn't have, but so what? As I said, my pre-cfg80211 arguments are not valid now. Let me qualify to externally visible problems :) Okay :-) I've never wanted to change the top part (so far anyway :) ). It's orthogonal. And whether d80211 behaves as an 802.11 protocol is something that's visible only in the RX path really, struct packet_type and associated things. I just said it's a confusing term, nothing against the idea. it becomes too small, we could put a pointer into skb-cb instead and do lifetime management with an skb desctructor. Not very effective but will work. Not really less effective than copying it around all the time as we do now and then kmalloc()ing it in some circumstances. That's true. Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless notes / pre d80211 merge
On Wed, 2006-11-15 at 10:43 +0100, Jiri Benc wrote: In particular: - The operations that make sense for user to perform on wiphy/master interface are different than the ones on virtual interfaces. It isn't this way now. Which particular operations do you have in mind? Granted, you won't ever be able to specify the master device as the default route for IP, but hey. I'd almost bet there are other devices that you can't do this with. - Why should master interface appear in ifconfig and similar tools the same way as virtual interfaces? If you want to know how users are confused by this, just search some forums. Because it manages the qdiscs and frames actually show up there. Even now, you can there see what you're transmitting :) - Does attaching of qdiscs to virtual interfaces make sense? Yes, I do think so. Why not? This is a different thing. See the difference between SOCK_RAW and SOCK_DGRAM. The interface you are talking about is SOCK_DGRAM. Except it supports only one address. The correct solution would be extending sockaddr_ll (that's not possible, I know) or introduce a new SOCK_SOMETHING type (not possible either, at least in a short term). I still haven't quite understood this argument. Could you elaborate? Except that all other hardware doesn't need things that we need. They need just one virtual interface - so their master and virtual interface is merged. This is net_device. We need to split it into two things. That's not really true, if you have a 802.1q network then the raw netdev is useless without vlan virtuals above unless you unpack the vlan on the switch giving you a non-802.1q network again. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless notes / pre d80211 merge
On Wed, 2006-11-15 at 11:05 +0100, Jiri Benc wrote: I wasn't in times when there was no cfg80211. But now... yes, you're right. The sysfs ieee80211 class exports just some interesting informations (we already agreed that add_interface and remove_interface would go away). Feel free to move it wherever you think is appropriate. Even with cfg80211 we have the wiphy concept embedded in there. Not much difference because we still have to do tc on wmasterN and wiconf on wiphyN. So that doesn't really change anything. Now, we could of course drop the wiphy concept from cfg80211 easily and require doing all these things on wmasterN. That's the option I considered in section (8). I don't like it too much, but I think I could live with it. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: watchdog timeout panic in e1000 driver
Hi,
Even if the total lock time can be reduced, it's possible that interrupt
handler is executed while the interrupted code is still holding the
semaphore.
I think your method only decrease the frequency of this problem.
Why does reducing the lock time solve this problem?
there are several problems here that need addressing. It's not acceptable
for our driver to wait up to 15 seconds, and we can (presumably) reduce it
to milliseconds, so that would help a lot. We should in no case at all hold
it for any period longer than (give or take) half a second, so working
towards that is a very good step in the right direction.
Adding the timer task back may also help, as we are no longer trying to
aqcuire the sw_fw_semaphore in interrupt context, but we removed it for a
reason, and I need to dig up what reason this exactly was before we can
revert it. Jesse might know, so I'll talk to him. But this will not fix the
fact that the semaphore is held for a long time :)
[...]
I think this problem occurs because interrupt handler is executed in same
CPU as process that acquires semaphore.
How about disabling interrupt while the process is holding the semaphore?
I think this is possible, if the total lock time has been reduced.
I created the attached patch based on the method described above.
This patch disables interrupt while the process is holding the semaphore.
I measured how long interrupts are being disabled 10,000 times using the
following method. TSC was read by rdtscll when interrupt was disabled
and interrupt was enabled again, then I subtract these two value.
The longest period interrupt was disabled is under 10usec, which seems
acceptable. The evaluation environment is;
CPU: Intel Xeon CPU 3.73GHz
kernel : 2.6.19-rc5
I also ran the reproduction TP I sent previously and confirmed that the
system didn't panic.
http://marc.theaimsgroup.com/?l=linux-netdevm=116125332319850w=2
How about this method?
I welcome any comments.
--
Kenzo Iwami ([EMAIL PROTECTED])
Signed-off-by: Kenzo Iwami [EMAIL PROTECTED]
diff -urpN linux-2.6.19-rc5_org/drivers/net/e1000/e1000_hw.c
linux-2.6.19-rc5/drivers/net/e1000/e1000_hw.c
--- linux-2.6.19-rc5_org/drivers/net/e1000/e1000_hw.c 2006-11-14
17:47:28.0 +0900
+++ linux-2.6.19-rc5/drivers/net/e1000/e1000_hw.c 2006-11-15
17:49:39.0
+0900
@@ -3379,6 +3379,7 @@ e1000_swfw_sync_acquire(struct e1000_hw
uint32_t swmask = mask;
uint32_t fwmask = mask 16;
int32_t timeout = 200;
+unsigned long flags;
DEBUGFUNC(e1000_swfw_sync_acquire);
@@ -3389,8 +3390,11 @@ e1000_swfw_sync_acquire(struct e1000_hw
return e1000_get_hw_eeprom_semaphore(hw);
while (timeout) {
-if (e1000_get_hw_eeprom_semaphore(hw))
+local_irq_save(flags);
+if (e1000_get_hw_eeprom_semaphore(hw)) {
+local_irq_restore(flags);
return -E1000_ERR_SWFW_SYNC;
+}
swfw_sync = E1000_READ_REG(hw, SW_FW_SYNC);
if (!(swfw_sync (fwmask | swmask))) {
@@ -3400,6 +3404,7 @@ e1000_swfw_sync_acquire(struct e1000_hw
/* firmware currently using resource (fwmask) */
/* or other software thread currently using resource (swmask) */
e1000_put_hw_eeprom_semaphore(hw);
+local_irq_restore(flags);
mdelay(5);
timeout--;
}
@@ -3413,6 +3418,7 @@ e1000_swfw_sync_acquire(struct e1000_hw
E1000_WRITE_REG(hw, SW_FW_SYNC, swfw_sync);
e1000_put_hw_eeprom_semaphore(hw);
+local_irq_restore(flags);
return E1000_SUCCESS;
}
@@ -3421,6 +3427,7 @@ e1000_swfw_sync_release(struct e1000_hw
{
uint32_t swfw_sync;
uint32_t swmask = mask;
+unsigned long flags;
DEBUGFUNC(e1000_swfw_sync_release);
@@ -3434,6 +3441,7 @@ e1000_swfw_sync_release(struct e1000_hw
return;
}
+local_irq_save(flags);
/* if (e1000_get_hw_eeprom_semaphore(hw))
*return -E1000_ERR_SWFW_SYNC; */
while (e1000_get_hw_eeprom_semaphore(hw) != E1000_SUCCESS);
@@ -3444,6 +3452,7 @@ e1000_swfw_sync_release(struct e1000_hw
E1000_WRITE_REG(hw, SW_FW_SYNC, swfw_sync);
e1000_put_hw_eeprom_semaphore(hw);
+local_irq_restore(flags);
}
/*
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: watchdog timeout panic in e1000 driver
Kenzo Iwami wrote:
Hi,
Even if the total lock time can be reduced, it's possible that interrupt
handler is executed while the interrupted code is still holding the
semaphore.
I think your method only decrease the frequency of this problem.
Why does reducing the lock time solve this problem?
there are several problems here that need addressing. It's not acceptable
for our driver to wait up to 15 seconds, and we can (presumably) reduce it
to milliseconds, so that would help a lot. We should in no case at all hold
it for any period longer than (give or take) half a second, so working
towards that is a very good step in the right direction.
Adding the timer task back may also help, as we are no longer trying to
aqcuire the sw_fw_semaphore in interrupt context, but we removed it for a
reason, and I need to dig up what reason this exactly was before we can
revert it. Jesse might know, so I'll talk to him. But this will not fix the
fact that the semaphore is held for a long time :)
[...]
I think this problem occurs because interrupt handler is executed in same
CPU as process that acquires semaphore.
How about disabling interrupt while the process is holding the semaphore?
I think this is possible, if the total lock time has been reduced.
I created the attached patch based on the method described above.
This patch disables interrupt while the process is holding the semaphore.
I measured how long interrupts are being disabled 10,000 times using the
following method. TSC was read by rdtscll when interrupt was disabled
and interrupt was enabled again, then I subtract these two value.
The longest period interrupt was disabled is under 10usec, which seems
acceptable. The evaluation environment is;
CPU: Intel Xeon CPU 3.73GHz
kernel : 2.6.19-rc5
I also ran the reproduction TP I sent previously and confirmed that the
system didn't panic.
http://marc.theaimsgroup.com/?l=linux-netdevm=116125332319850w=2
How about this method?
I'm not sure why you would have to disable interrupts when freeing the semaphore, but
more importantly I don't want to introduce irq code in the swfw handling functions.
Since the major (only) user running this piece of code in intterupt context is the
watchdog, we might as well see if we can only disable interrupts for that code path,
which would only be once per 2 seconds. We don't need to protect the ethtool path into
this code as it doesn't run in irq context.
Would you mind giving attached patch a try and let me know if it works for you? It will
disable irqs for a bit longer time than your patch, and it begs for a special
check-link-in-watchdog function that doesn't take so damn long :(
Thanks,
Auke
Signed-off-by: Auke Kok [EMAIL PROTECTED]
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index a2f1464..0b52ded 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -2430,8 +2430,12 @@ e1000_watchdog(unsigned long data)
struct e1000_tx_ring *txdr = adapter-tx_ring;
uint32_t link, tctl;
int32_t ret_val;
+ unsigned long flags;
+ local_irq_save(flags);
ret_val = e1000_check_for_link(adapter-hw);
+ local_irq_restore(flags);
+
if ((ret_val == E1000_ERR_PHY)
(adapter-hw.phy_type == e1000_phy_igp_3)
(E1000_READ_REG(adapter-hw, CTRL) E1000_PHY_CTRL_GBE_DISABLE)) {
Re: [patch 1/2]d80211: hardware TKIP support for ipw3945
On Tue, 2006-11-14 at 10:22 +0800, Hong Liu wrote: Resend the patch according to Johannes's comments. Thanks :) Still put he tkip_key in tx_control structure. Having the tkip_key in there is actually pretty bad for when/if we want to push the tx_control into skb-cb (possibly combined with some header or whatever). I don't think that has been decided on yet, will be a large change anyway and this helps a lot so :) Instead of putting all this into the stack, however, I think we could make those drivers that require it do the bookkeeping and export ieee80211_tkip_gen_phase1key and ieee80211_tkip_gen_rc4key for their use. Maybe that's too much against Jiri's doctrine of be easy on drivers though :) This might actually also go some way towards unification with ipw2x00's ieee80211 because those drivers require such functions as well as far as I know. Haven't looked too deeply though. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Setup of testing lab and work on development
Hello, From the previous response that i received, now i have the code and now m browsing thru it. 1. if i understood correctly.. The discussion thread : wireless notes / pre d80211 merge discussion applies to the directory net/d80211/ from git:.. 2. Test environment to setup for d80211 would be like this : Laptop (Centrino - with ipw2200 or would it be some other) PC acting as Access Point (with Wireless modem) Any other that you would suggest that would be a more reasonable test environment setup ? Also if you have suggestions which company of appliances i should go for.. I can have 2 PCs i386 (Fedora Linux) easily available. So if some add ons can be used would be pretty good also. Few points that for clarification. 1. I intend to do the same so that I can also check if I make any changes how are they reflected. I hope my purpose would be solved with above setup. 2. How frequently would there be changes required in h/w here ? tia.. Regards, Udayan Tata Consultancy Services - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch] qla3xxx: Add support for Qlogic ISP4032 chipset.
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index ec640f6..b23ab70 100644
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -22,6 +22,7 @@ #include linux/interrupt.h
#include linux/errno.h
#include linux/ioport.h
#include linux/ip.h
+#include linux/in.h
#include linux/if_arp.h
#include linux/if_ether.h
#include linux/netdevice.h
@@ -38,7 +39,7 @@ #include qla3xxx.h
#define DRV_NAME qla3xxx
#define DRV_STRING QLogic ISP3XXX Network Driver
-#define DRV_VERSIONv2.02.00-k36
+#define DRV_VERSIONv2.03.00-k2
#define PFXDRV_NAME
static const char ql3xxx_driver_name[] = DRV_NAME;
@@ -61,8 +62,9 @@ static int msi;
module_param(msi, int, 0);
MODULE_PARM_DESC(msi, Turn on Message Signaled Interrupts.);
-static struct pci_device_id ql3xxx_pci_tbl[] __devinitdata = {
+static const struct pci_device_id ql3xxx_pci_tbl[] __devinitdata = {
{PCI_DEVICE(PCI_VENDOR_ID_QLOGIC, QL3022_DEVICE_ID)},
+ {PCI_DEVICE(PCI_VENDOR_ID_QLOGIC, QL3032_DEVICE_ID)},
/* required last entry */
{0,}
};
@@ -1466,6 +1468,9 @@ static int ql_mii_setup(struct ql3_adapt
2) 7))
return -1;
+ if (qdev-device_id == QL3032_DEVICE_ID)
+ ql_write_page0_reg(qdev, port_regs-macMIIMgmtControlReg,
0x0f0); /* clear bits 4-7 */
+
/* Divide 125MHz clock by 28 to meet PHY timing requirements */
reg = MAC_MII_CONTROL_CLK_SEL_DIV28;
@@ -1697,18 +1702,43 @@ static void ql_process_mac_tx_intr(struc
struct ob_mac_iocb_rsp *mac_rsp)
{
struct ql_tx_buf_cb *tx_cb;
+ int i;
tx_cb = qdev-tx_buf[mac_rsp-transaction_id];
+
pci_unmap_single(qdev-pdev,
-pci_unmap_addr(tx_cb, mapaddr),
-pci_unmap_len(tx_cb, maplen), PCI_DMA_TODEVICE);
- dev_kfree_skb_irq(tx_cb-skb);
+pci_unmap_addr(tx_cb-map[0], mapaddr),
+pci_unmap_len(tx_cb-map[0], maplen),
+PCI_DMA_TODEVICE);
+ tx_cb-seg_count--;
+ if (tx_cb-seg_count) {
+ for (i = 1; i tx_cb-seg_count; i++) {
+ pci_unmap_page(qdev-pdev,
+ pci_unmap_addr(tx_cb-map[i],
+ mapaddr),
+ pci_unmap_len(tx_cb-map[i], maplen),
+ PCI_DMA_TODEVICE);
+ }
+ }
qdev-stats.tx_packets++;
qdev-stats.tx_bytes += tx_cb-skb-len;
+ dev_kfree_skb_irq(tx_cb-skb);
tx_cb-skb = NULL;
atomic_inc(qdev-tx_count);
}
+/*
+ * The difference between 3022 and 3032 for inbound completions:
+ * 3022 uses two buffers per completion. The first buffer contains
+ * (some) header info, the second the remainder of the headers plus
+ * the data. For this chip we reserve some space at the top of the
+ * receive buffer so that the header info in buffer one can be
+ * prepended to the buffer two. Buffer two is the sent up while
+ * buffer one is returned to the hardware to be reused.
+ * 3032 receives all of it's data and headers in one buffer for a
+ * simpler process. 3032 also supports checksum verification as
+ * can be seen in ql_process_macip_rx_intr().
+ */
static void ql_process_mac_rx_intr(struct ql3_adapter *qdev,
struct ib_mac_iocb_rsp *ib_mac_rsp_ptr)
{
@@ -1731,14 +1761,17 @@ static void ql_process_mac_rx_intr(struc
qdev-last_rsp_offset = qdev-small_buf_phy_addr_low + offset;
qdev-small_buf_release_cnt++;
- /* start of first buffer */
- lrg_buf_phy_addr_low = le32_to_cpu(*curr_ial_ptr);
- lrg_buf_cb1 = qdev-lrg_buf[qdev-lrg_buf_index];
- qdev-lrg_buf_release_cnt++;
- if (++qdev-lrg_buf_index == NUM_LARGE_BUFFERS)
- qdev-lrg_buf_index = 0;
- curr_ial_ptr++; /* 64-bit pointers require two incs. */
- curr_ial_ptr++;
+ if (qdev-device_id == QL3022_DEVICE_ID) {
+ /* start of first buffer (3022 only) */
+ lrg_buf_phy_addr_low = le32_to_cpu(*curr_ial_ptr);
+ lrg_buf_cb1 = qdev-lrg_buf[qdev-lrg_buf_index];
+ qdev-lrg_buf_release_cnt++;
+ if (++qdev-lrg_buf_index == NUM_LARGE_BUFFERS) {
+ qdev-lrg_buf_index = 0;
+ }
+ curr_ial_ptr++; /* 64-bit pointers require two incs. */
+ curr_ial_ptr++;
+ }
/* start of second buffer */
lrg_buf_phy_addr_low = le32_to_cpu(*curr_ial_ptr);
@@ -1769,7 +1802,8 @@ static void ql_process_mac_rx_intr(struc
qdev-ndev-last_rx = jiffies;
lrg_buf_cb2-skb = NULL;
- ql_release_to_lrg_buf_free_list(qdev, lrg_buf_cb1);
+ if (qdev-device_id ==
[PATCH 1/3] leak tracking for kmalloc_node
We have variants of kmalloc and kmem_cache_alloc that leave leak
tracking to the caller. This is used for subsystem-specific allocators
like skb_alloc.
To make skb_alloc node-aware we need similar routines for the node-aware
slab allocator, which this patch adds.
Note that the code is rather ugly, but it mirrors the non-node-aware
code 1:1:
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/include/linux/slab.h
===
--- linux-2.6.orig/include/linux/slab.h 2006-10-23 17:20:14.0 +0200
+++ linux-2.6/include/linux/slab.h 2006-10-30 13:13:52.0 +0100
@@ -236,7 +236,25 @@
}
return __kmalloc_node(size, flags, node);
}
+
+/*
+ * kmalloc_node_track_caller is a special version of kmalloc_node that
+ * records the calling function of the routine calling it for slab leak
+ * tracking instead of just the calling function (confusing, eh?).
+ * It's useful when the call to kmalloc_node comes from a widely-used
+ * standard allocator where we care about the real place the memory
+ * allocation request comes from.
+ */
+#ifndef CONFIG_DEBUG_SLAB
+#define kmalloc_node_track_caller(size, flags, node) \
+ __kmalloc_node(size, flags, node)
#else
+extern void *__kmalloc_node_track_caller(size_t, gfp_t, int, void *);
+#define kmalloc_node_track_caller(size, flags, node) \
+ __kmalloc_node_track_caller(size, flags, node, \
+ __builtin_return_address(0))
+#endif
+#else /* CONFIG_NUMA */
static inline void *kmem_cache_alloc_node(kmem_cache_t *cachep, gfp_t flags,
int node)
{
return kmem_cache_alloc(cachep, flags);
@@ -245,6 +263,9 @@
{
return kmalloc(size, flags);
}
+
+#define kmalloc_node_track_caller(size, flags, node) \
+ kmalloc_track_caller(size, flags)
#endif
extern int FASTCALL(kmem_cache_reap(int));
@@ -283,6 +304,8 @@
#define kzalloc(s, f) __kzalloc(s, f)
#define kmalloc_track_caller kmalloc
+#define kmalloc_node_track_caller kmalloc_node
+
#endif /* CONFIG_SLOB */
/* System wide caches */
Index: linux-2.6/mm/slab.c
===
--- linux-2.6.orig/mm/slab.c2006-10-23 17:21:47.0 +0200
+++ linux-2.6/mm/slab.c 2006-10-30 13:14:20.0 +0100
@@ -996,7 +996,7 @@
return NULL;
}
-static inline void *__cache_alloc_node(struct kmem_cache *cachep,
+static inline void *cache_alloc_node(struct kmem_cache *cachep,
gfp_t flags, int nodeid)
{
return NULL;
@@ -1004,7 +1004,7 @@
#else /* CONFIG_NUMA */
-static void *__cache_alloc_node(struct kmem_cache *, gfp_t, int);
+static void *cache_alloc_node(struct kmem_cache *, gfp_t, int);
static void *alternate_node_alloc(struct kmem_cache *, gfp_t);
static struct array_cache **alloc_alien_cache(int node, int limit)
@@ -3105,10 +3105,10 @@
objp = cache_alloc(cachep, flags);
/*
* We may just have run out of memory on the local node.
-* __cache_alloc_node() knows how to locate memory on other nodes
+* cache_alloc_node() knows how to locate memory on other nodes
*/
if (NUMA_BUILD !objp)
- objp = __cache_alloc_node(cachep, flags, numa_node_id());
+ objp = cache_alloc_node(cachep, flags, numa_node_id());
local_irq_restore(save_flags);
objp = cache_alloc_debugcheck_after(cachep, flags, objp,
caller);
@@ -3135,7 +3135,7 @@
else if (current-mempolicy)
nid_alloc = slab_node(current-mempolicy);
if (nid_alloc != nid_here)
- return __cache_alloc_node(cachep, flags, nid_alloc);
+ return cache_alloc_node(cachep, flags, nid_alloc);
return NULL;
}
@@ -3158,7 +3158,7 @@
if (zone_idx(*z) = ZONE_NORMAL
cpuset_zone_allowed(*z, flags)
cache-nodelists[nid])
- obj = __cache_alloc_node(cache,
+ obj = cache_alloc_node(cache,
flags | __GFP_THISNODE, nid);
}
return obj;
@@ -3167,7 +3167,7 @@
/*
* A interface to enable slab creation on nodeid
*/
-static void *__cache_alloc_node(struct kmem_cache *cachep, gfp_t flags,
+static void *cache_alloc_node(struct kmem_cache *cachep, gfp_t flags,
int nodeid)
{
struct list_head *entry;
@@ -3440,7 +3440,9 @@
* New and improved: it will now make sure that the object gets
* put on the correct node list so that there is no false sharing.
*/
-void *kmem_cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid)
+static __always_inline void *
+__cache_alloc_node(struct kmem_cache *cachep, gfp_t flags,
+ int nodeid, void *caller)
{
unsigned long save_flags;
[PATCH 2/3] add numa node information to struct device
For node-aware skb allocations we need information about the node
in struct net_device or struct device. Davem suggested to put
it into struct device which this patch does.
In particular:
- struct device gets a new int numa_node member if CONFIG_NUMA is set
- there are two new helpers, dev_to_node and set_dev_node to
transparently deal with the non-numa case
- for pci devices the node-info is set to the value we get from
pcibus_to_node.
Note that for some architectures pcibus_to_node doesn't work yet at the
time we call it currently. This is harmless and will just mean skb
allocations aren't node-local on this architectures until the
implementation of pcibus_to_node on these architectures have been
updated (There are patches for x86 and x86_64 floating around)
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/include/linux/device.h
===
--- linux-2.6.orig/include/linux/device.h 2006-11-05 00:16:09.0
+0100
+++ linux-2.6/include/linux/device.h2006-11-05 00:39:22.0 +0100
@@ -347,6 +347,9 @@
BIOS data),reserved for device core*/
struct dev_pm_info power;
+#ifdef CONFIG_NUMA
+ int numa_node; /* NUMA node this device is close to */
+#endif
u64 *dma_mask; /* dma mask (if dma'able device) */
u64 coherent_dma_mask;/* Like dma_mask, but for
alloc_coherent mappings as
@@ -368,6 +371,14 @@
void(*release)(struct device * dev);
};
+#ifdef CONFIG_NUMA
+#define dev_to_node(dev) ((dev)-numa_node)
+#define set_dev_node(dev, node)((dev)-numa_node = node)
+#else
+#define dev_to_node(dev) (-1)
+#define set_dev_node(dev, node)do { } while (0)
+#endif
+
static inline void *
dev_get_drvdata (struct device *dev)
{
Index: linux-2.6/drivers/base/core.c
===
--- linux-2.6.orig/drivers/base/core.c 2006-11-05 00:16:09.0 +0100
+++ linux-2.6/drivers/base/core.c 2006-11-05 00:40:01.0 +0100
@@ -381,6 +381,7 @@
INIT_LIST_HEAD(dev-node);
init_MUTEX(dev-sem);
device_init_wakeup(dev, 0);
+ set_dev_node(dev, -1);
}
/**
Index: linux-2.6/drivers/pci/probe.c
===
--- linux-2.6.orig/drivers/pci/probe.c 2006-11-05 00:16:09.0 +0100
+++ linux-2.6/drivers/pci/probe.c 2006-11-05 00:39:55.0 +0100
@@ -846,6 +846,7 @@
dev-dev.release = pci_release_dev;
pci_dev_get(dev);
+ set_dev_node(dev-dev, pcibus_to_node(bus));
dev-dev.dma_mask = dev-dma_mask;
dev-dev.coherent_dma_mask = 0xull;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] node-aware skb allocations
This is the final version of the node-aware skb allocations, implementing davem's suggestion of storing the numa node in struct device. I'd love to get this into 2.6.20 now that I don't hear negative comments about it anymre, but I wonder how. The first patch toches mm/slab.c, the second struct device and assorted files and only the last one is actually in the networking code. Should Dave push all this through net-2.6.20 or should we get it in purely through -mm? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] node-aware skb allocation
Node-aware allocation of skbs for the receive path.
Details:
- __alloc_skb gets a new node argument and cals the node-aware
slab functions with it.
- netdev_alloc_skb passed the node number it gets from dev_to_node
to it, everyone else passes -1 (any node)
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/include/linux/skbuff.h
===
--- linux-2.6.orig/include/linux/skbuff.h 2006-11-02 12:47:50.0
+0100
+++ linux-2.6/include/linux/skbuff.h2006-11-02 12:48:22.0 +0100
@@ -331,17 +331,17 @@
extern void kfree_skb(struct sk_buff *skb);
extern void __kfree_skb(struct sk_buff *skb);
extern struct sk_buff *__alloc_skb(unsigned int size,
- gfp_t priority, int fclone);
+ gfp_t priority, int fclone, int node);
static inline struct sk_buff *alloc_skb(unsigned int size,
gfp_t priority)
{
- return __alloc_skb(size, priority, 0);
+ return __alloc_skb(size, priority, 0, -1);
}
static inline struct sk_buff *alloc_skb_fclone(unsigned int size,
gfp_t priority)
{
- return __alloc_skb(size, priority, 1);
+ return __alloc_skb(size, priority, 1, -1);
}
extern struct sk_buff *alloc_skb_from_cache(kmem_cache_t *cp,
Index: linux-2.6/net/core/skbuff.c
===
--- linux-2.6.orig/net/core/skbuff.c2006-11-02 12:47:50.0 +0100
+++ linux-2.6/net/core/skbuff.c 2006-11-02 12:48:22.0 +0100
@@ -131,6 +131,7 @@
* @gfp_mask: allocation mask
* @fclone: allocate from fclone cache instead of head cache
* and allocate a cloned (child) skb
+ * @node: numa node to allocate memory on
*
* Allocate a new sk_buff. The returned buffer has no headroom and a
* tail room of size bytes. The object has a reference count of one.
@@ -140,7 +141,7 @@
* %GFP_ATOMIC.
*/
struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
- int fclone)
+ int fclone, int node)
{
kmem_cache_t *cache;
struct skb_shared_info *shinfo;
@@ -150,14 +151,14 @@
cache = fclone ? skbuff_fclone_cache : skbuff_head_cache;
/* Get the HEAD */
- skb = kmem_cache_alloc(cache, gfp_mask ~__GFP_DMA);
+ skb = kmem_cache_alloc_node(cache, gfp_mask ~__GFP_DMA, node);
if (!skb)
goto out;
/* Get the DATA. Size must match skb_add_mtu(). */
size = SKB_DATA_ALIGN(size);
- data = kmalloc_track_caller(size + sizeof(struct skb_shared_info),
- gfp_mask);
+ data = kmalloc_node_track_caller(size + sizeof(struct skb_shared_info),
+ gfp_mask, node);
if (!data)
goto nodata;
@@ -266,9 +267,10 @@
struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
unsigned int length, gfp_t gfp_mask)
{
+ int node = dev-class_dev.dev ? dev_to_node(dev-class_dev.dev) : -1;
struct sk_buff *skb;
- skb = alloc_skb(length + NET_SKB_PAD, gfp_mask);
+ skb = __alloc_skb(length + NET_SKB_PAD, gfp_mask, 0, node);
if (likely(skb)) {
skb_reserve(skb, NET_SKB_PAD);
skb-dev = dev;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qla3xxx: Add support for Qlogic ISP4032 chip.
borked again. Patch applied cleanly when I mailed it to myself, but not from list. Third try all will be corrected. oops, that patch is borked (line-wrapped). will resend ASAP. Ron Mercer. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix up sysctl_tcp_mem initialization
David Miller wrote: However, I wonder if we want to set this differently than the way this patch does it. Depending on how far off the memory size is from a power of two (exactly equal to a power of two is the worst case), and if total memory 128M, it can be substantially less than 3/4. Longer term, yes, probably a better way exists. So you concern is that when we round to a power of 2 like we do now, we often mis-shoot? I'm not that concerned about it, but basically yes, there are big (x2) jumps on power-of-two memory size boundaries. There's also a bigger (x8) discontinuity at 128k pages. It could be smoother. -John - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Setup of testing lab and work on development
On Wed, 2006-11-15 at 22:27 +0530, Udayan Singh wrote: 1. if i understood correctly.. The discussion thread : wireless notes / pre d80211 merge discussion applies to the directory net/d80211/ from git:.. Right. I CCed you because you seemed interested in d80211. 2. Test environment to setup for d80211 would be like this : Laptop (Centrino - with ipw2200 or would it be some other) PC acting as Access Point (with Wireless modem) no, ipw2200 doesn't do d80211. check drivers/net/wireless/d80211/ Any other that you would suggest that would be a more reasonable test environment setup ? Also if you have suggestions which company of appliances i should go for.. What do you want a test environment for? That's the key issue. I have a bunch of wireless hardware and an access point... Few points that for clarification. 1. I intend to do the same so that I can also check if I make any changes how are they reflected. I hope my purpose would be solved with above setup. Not sure what you mean? Do the same what? 2. How frequently would there be changes required in h/w here ? Umm, never? You fail to state what you actually want to do... johannes signature.asc Description: This is a digitally signed message part
[PATCH] Adapt ucc_geth driver to use new of_platform_device support
Include of_platform header, and use
new of_[un]register_platform_driver() fns.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
please consider for 2.6.20
drivers/net/ucc_geth.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index b378880..1f05511 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -30,7 +30,7 @@ #include linux/fsl_devices.h
#include linux/ethtool.h
#include linux/mii.h
-#include asm/of_device.h
+#include asm/of_platform.h
#include asm/uaccess.h
#include asm/irq.h
#include asm/io.h
@@ -4301,12 +4301,12 @@ static int __init ucc_geth_init(void)
memcpy((ugeth_info[i]), ugeth_primary_info,
sizeof(ugeth_primary_info));
- return of_register_driver(ucc_geth_driver);
+ return of_register_platform_driver(ucc_geth_driver);
}
static void __exit ucc_geth_exit(void)
{
- of_unregister_driver(ucc_geth_driver);
+ of_unregister_platform_driver(ucc_geth_driver);
}
module_init(ucc_geth_init);
--
1.4.2.3
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless notes / pre d80211 merge
Simon Barber wrote: I disagree that the master device is a hack - I also disagree that we should use 802.11 format frames anywhere but internally inside the 802.11 stack. The 802.11 specification does not use 802.11 format frames to communicate with the upper layers - it uses almost exactly the same interface as 802.3 ethernet does. This is a 2 address interface. I The 802.11 specification doesn't communicate with any layer :) The Linux kernel code in question does that. In Linux it is generally bad form to emulate something (802.3 ethernet, in this case). Overhead increases, performance decreases, and there are inevitably emulation bugs. 802.11 /is not ethernet/, and you are already breaking assumptions by pretending that it is. It is normal to have a single interface to represent the physical hardware network interface. This is exactly the pattern that many other physical network devices use. Things like sniffing should go on on this physical interface - and the changes that johannes proposes are exactly the right things to enable this. Sure... when it behaves like a normal interface. Stuff like TX goes through the interface, but not RX is definitely /not/ normal. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
On Wednesday 15 November 2006 04:10, John W. Linville wrote: It is my pleasure to announce that the SFLC [1] has assisted the ar5k developers in evaluating the development history of Reyk Floeter's OpenBSD reverse-engineered Atheros HAL, ar5k [2]. SFLC's assessment leads to the conclusion that free software developers should not be worried about using/extending ar5k or porting ar5k to other platforms. In the past there were serious questions raised and even dire warnings made about ar5k's copyright status. The purpose of this statement is to refute those claims and to publicly clarify ar5k's status to developers. SFLC has made independent inquiries with the OpenBSD team regarding the development history of ar5k source. The responses received provide a reasonable basis for SFLC to believe that the OpenBSD developers who worked on ar5k did not misappropriate code, and that the ar5k implementation is OpenBSD's original copyrighted work. This announcement should serve to remove the cloud which has prevented progress towards an in-kernel driver for Atheros hardware. This should be of particular interest to those involved with the DadWifi project [3]. I'd like to take this opportunity to thank the folks at the SFLC for their hard work, and I'd also like to personally thank Luis Rodriguez for the role he played in coordinating contact between the SFLC and the community at large. Thanks! John [1] http://www.softwarefreedom.org/ [2] http://team.vantronix.net/ar5k/ [3] http://marc.theaimsgroup.com/?l=linux-netdevm=116113064513921w=2 So, who is finally going to _DO_ the work? Some of you know that I started an atheros driver at http://bu3sch.de/ath/atheros.git/ It's not really a driver, yet, as nobody got to continue on the specification, so I was stuck. Now that it seems to be ok to use these openbsd sources, should I port them to my driver framework? I looked over the ar5k code and, well, I don't like it. ;) I don't really like having a HAL. I'd rather prefer a real driver without that HAL obfuscation. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote: Now that it seems to be ok to use these openbsd sources, should I port them to my driver framework? I looked over the ar5k code and, well, I don't like it. ;) I don't really like having a HAL. I'd rather prefer a real driver without that HAL obfuscation. I don't think anyone likes the HAL-based architecture. I don't think we will accept a HAL-based driver into the upstream kernel. The point is that the ar5k is now safe to be used as a reference and source of information (and code, as appropriate) without copyright FUD. Distilling that information into a proper Linux driver is work that remains to be done. John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Michael Buesch wrote: Yeah, ok. I'll look what I can do. First I'll have to read the code. and understand it. DMA stuff seems to be really obfuscated though dozens of callbacks, heh. :) I'd certainly like to see solid Atheros chipset support in mainline. If you need any hardware or other resources to help with this effort, let me know. Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote: On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote: Now that it seems to be ok to use these openbsd sources, should I port them to my driver framework? I looked over the ar5k code and, well, I don't like it. ;) I don't really like having a HAL. I'd rather prefer a real driver without that HAL obfuscation. I don't think anyone likes the HAL-based architecture. I don't think we will accept a HAL-based driver into the upstream kernel. The point is that the ar5k is now safe to be used as a reference and source of information (and code, as appropriate) without copyright FUD. Distilling that information into a proper Linux driver is work that remains to be done. there have been several efforts on this before; is it worth revitalizing one of them? Also I suspect that if you merge a provisional driver early, lots of folks will switch to it and start beating on it and fixing the style etc issues... -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Hello! On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote: On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote: Now that it seems to be ok to use these openbsd sources, should I port them to my driver framework? I looked over the ar5k code and, well, I don't like it. ;) I don't really like having a HAL. I'd rather prefer a real driver without that HAL obfuscation. I don't think anyone likes the HAL-based architecture. I don't think we will accept a HAL-based driver into the upstream kernel. I said it before, and it's worth repeating. Dissolving HAL in the sources is easy. It's just a matter of moving functions around without serious chances of breaking anything as long as the source compiles. The whole HAL-based architecture can be reshuffled and eliminated by one person in a few days. Making things work properly takes years. That's what MadWifi has been working on for a long time, using contributions and bug reports from scores of users and developers. Rejecting MadWifi because it's HAL based is like throwing away a diamond ring because it's too narrow. -- Regards, Pavel Roskin - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
bcm43xx regression 2.6.19rc3 - rc5, rtnl_lock trouble?
Hey all, I ran 2.6.19-rc3 for almost two weeks or so with no difficulties (none related to the bcm43xx driver, at least). However, Andrew asked me to double check the latest release to see if my problem report against 2.6.18 (hard locks) was fixed. Good news is that it still is fixed. Bad news is that 2.6.19-rc5 is worse than rc3 in other ways. I've come back to my laptop being mostly dead after hours of it being off on its own (twice now). Mostly dead meaning the keyboard is nearly non-responsive, but the mouse works great (I'm in X, of course). I say 'nearly dead' as sysrq-t,b works, so I'm sorta stumped there. (x-session seems to use netlink, so perhaps that's the connection? ctrl-alt-f[1-7] don't do anything, however.) It seems to be a locking problem, though lockdep isn't catching it. I'll let you guys decide though. Regardless, here's what's I can see. My logs start filling with: $ grep 'NETDEV WATCHDOG:' /var/log/messages | cut -d '[' -f 2- | head 50025.388173] NETDEV WATCHDOG: eth1: transmit timed out 50029.019574] NETDEV WATCHDOG: eth1: transmit timed out 50030.835313] NETDEV WATCHDOG: eth1: transmit timed out 50032.651049] NETDEV WATCHDOG: eth1: transmit timed out 50034.466785] NETDEV WATCHDOG: eth1: transmit timed out 50036.282523] NETDEV WATCHDOG: eth1: transmit timed out 50038.098237] NETDEV WATCHDOG: eth1: transmit timed out 50039.913974] NETDEV WATCHDOG: eth1: transmit timed out 50041.729709] NETDEV WATCHDOG: eth1: transmit timed out 50043.545447] NETDEV WATCHDOG: eth1: transmit timed out (...1249 of these, so it doesn't fix itself.) and then the system becomes pretty worthless. (Full /var/log/messages with sysrq-t at: http://madrabbit.org/~ray/messages.gz ). Interesting bits of that: $ grep -B5 -A10 'Nov 13 01:5.*mutex' /var/log/messages | cut -d ']' -f2- DWARF2 unwinder stuck at child_rip+0xa/0x12 Leftover inexact backtrace: [restore_args+0/48] restore_args+0x0/0x30 [mutex_lock+9/16] mutex_lock+0x9/0x10 [kthread+0/272] kthread+0x0/0x110 [child_rip+0/18] child_rip+0x0/0x12 khelper S 810037fbe318 0 5 1 6 4 (L-TLB) 810037907e60 0046 810037907e70 810037fbe140 81001095f140 3b5d 810001e3e668 0286 810037907e40 8026bbb2 810037907e70 810001e3e600 Call Trace: [worker_thread+236/352] worker_thread+0xec/0x160 [kthread+211/272] kthread+0xd3/0x110 -- DWARF2 unwinder stuck at child_rip+0xa/0x12 Leftover inexact backtrace: [restore_args+0/48] restore_args+0x0/0x30 [mutex_lock+9/16] mutex_lock+0x9/0x10 [kthread+0/272] kthread+0x0/0x110 [child_rip+0/18] child_rip+0x0/0x12 kthread S 810037fad218 0 6 1252129 5 (L-TLB) 810037f01e60 0046 810037f01e70 810037fad040 81002b3df140 062b 810001e3e468 0286 810037f01e40 8026bbb2 810037f01e70 810001e3e400 Call Trace: [worker_thread+236/352] worker_thread+0xec/0x160 [kthread+211/272] kthread+0xd3/0x110 -- DWARF2 unwinder stuck at child_rip+0xa/0x12 Leftover inexact backtrace: [restore_args+0/48] restore_args+0x0/0x30 [mutex_lock+9/16] mutex_lock+0x9/0x10 [kthread+0/272] kthread+0x0/0x110 [child_rip+0/18] child_rip+0x0/0x12 kblockd/0 S 810037989318 025 626 (L-TLB) 81003798fe60 0046 81003798fe70 810037989140 8100379a5100 078b 810037fa2468 0286 81003798fe40 8026bbb2 81003798fe70 810037fa2400 Call Trace: [worker_thread+236/352] worker_thread+0xec/0x160 [kthread+211/272] kthread+0xd3/0x110 -- NetworkManage D 810037943258 0 4833 1 4853 4809 (NOTLB) 81002bfefbe8 0046 81002bfefb98 810037943080 81002e6d2100 000122a6 8062ce80 0046 0246 810037943080 81002e47b3f0 81002e47b3a0 Call Trace: [__mutex_lock_slowpath+344/624] __mutex_lock_slowpath+0x158/0x270 [mutex_lock+9/16] mutex_lock+0x9/0x10 [_end+126343345/2126632680] :bcm43xx:bcm43xx_wx_get_mode+0x29/0x60 [ioctl_standard_call+139/944] ioctl_standard_call+0x8b/0x3b0 [wireless_process_ioctl+260/976] wireless_process_ioctl+0x104/0x3d0 [dev_ioctl+854/944] dev_ioctl+0x356/0x3b0 [sock_ioctl+576/624] sock_ioctl+0x240/0x270 [do_ioctl+49/160] do_ioctl+0x31/0xa0 [vfs_ioctl+683/720] vfs_ioctl+0x2ab/0x2d0 [sys_ioctl+106/160] sys_ioctl+0x6a/0xa0 [system_call+126/131] system_call+0x7e/0x83 DWARF2 unwinder stuck at system_call+0x7e/0x83 -- x-session-man D 81002ef02298 0 5625 4565 5672 4586 (NOTLB) 810028a1fad8 0046 8062c500 81002ef020c0 8100249a6040 8c5d 0046 0246 81002ef020c0 805505b0 80550560 Call Trace: [__mutex_lock_slowpath+344/624]
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
On Wednesday 15 November 2006 20:39, Pavel Roskin wrote: Hello! On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote: On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote: Now that it seems to be ok to use these openbsd sources, should I port them to my driver framework? I looked over the ar5k code and, well, I don't like it. ;) I don't really like having a HAL. I'd rather prefer a real driver without that HAL obfuscation. I don't think anyone likes the HAL-based architecture. I don't think we will accept a HAL-based driver into the upstream kernel. I said it before, and it's worth repeating. Dissolving HAL in the sources is easy. It's just a matter of moving functions around without serious chances of breaking anything as long as the source compiles. The whole HAL-based architecture can be reshuffled and eliminated by one person in a few days. I'll look at it tomorrow. Probably best to merge this stuff into the tree somehow to get it working and clean it up afterwards. Shouldn't be too hard to merge. Making things work properly takes years. That's what MadWifi has been working on for a long time, using contributions and bug reports from scores of users and developers. Rejecting MadWifi because it's HAL based is like throwing away a diamond ring because it's too narrow. Well, it never worked for me. But I gave up trying about half a year ago. But maybe it's just stupid me. ;) -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Setup of testing lab and work on development
On 11/15/06, Johannes Berg [EMAIL PROTECTED] wrote: On Wed, 2006-11-15 at 22:27 +0530, Udayan Singh wrote: 1. if i understood correctly.. The discussion thread : wireless notes / pre d80211 merge discussion applies to the directory net/d80211/ from git:.. Right. I CCed you because you seemed interested in d80211. Thanks.. Johannes.. :) 2. Test environment to setup for d80211 would be like this : Laptop (Centrino - with ipw2200 or would it be some other) PC acting as Access Point (with Wireless modem) no, ipw2200 doesn't do d80211. check drivers/net/wireless/d80211/ ok. you are referring to bcm43xx , etc Any other that you would suggest that would be a more reasonable test environment setup ? Also if you have suggestions which company of appliances i should go for.. What do you want a test environment for? That's the key issue. I have a bunch of wireless hardware and an access point... lets say we have development happening in d80211 driver. now if i want to participate in the development of the (d80211), i can do it in a much better manner if i am trying out modificaitons on my own on the drivers that are using d80211 (my feeling) e.g. bcm43xx, etc. Hence i would like to setup a test environment where i can make modifications in code (of d80211 or related driver) and test it Few points that for clarification. 1. I intend to do the same so that I can also check if I make any changes how are they reflected. I hope my purpose would be solved with above setup. Not sure what you mean? Do the same what? same - participate in development on d80211 2. How frequently would there be changes required in h/w here ? Umm, never? You fail to state what you actually want to do... sorry for that, will surely try to give a complete picture in future (tried that today again - hope its ok..). johannes thanks.. Udayan Tata Consultancy Services - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Setup of testing lab and work on development
On Thu, 2006-11-16 at 02:34 +0530, Udayan Singh wrote: ok. you are referring to bcm43xx , etc right, all of those drivers use d80211. lets say we have development happening in d80211 driver. now if i want to participate in the development of the (d80211), i can do it in a much better manner if i am trying out modificaitons on my own on the drivers that are using d80211 (my feeling) I doubt you'll get far without ever testing your code changes. :) e.g. bcm43xx, etc. Hence i would like to setup a test environment where i can make modifications in code (of d80211 or related driver) and test it You'll need one of the cards that is supported by a d80211 driver. I've used bcm43xx and rt2500usb so far. same - participate in development on d80211 Well, check http://wireless.sipsolutions.net for things we still have to do... and then send patches :) Or do something else you're interested in and send patches. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/1] myri10ge: use physical pages for skb allocation
Hi Jeff, It looks like you didn't apply this patch to #upstream for 2.6.20 so far. We would really like to get ith in 2.6.20 (we already missed 2.6.19 by a couple days :)). But, I guess we need some testing in -mm first, so... thanks, Brice Brice Goglin wrote: Physical pages are used instead of 16kB contiguous buffers for the skb frags. And we also put as much fragments as possible in any page so that we do not have to allocate a page for every fragments. Signed-off-by: Brice Goglin [EMAIL PROTECTED] Signed-off-by: Andrew J. Gallatin [EMAIL PROTECTED] --- drivers/net/myri10ge/myri10ge.c | 499 1 file changed, 254 insertions(+), 245 deletions(-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] add numa node information to struct device
On Wed, 15 Nov 2006 18:37:01 +0100
Christoph Hellwig [EMAIL PROTECTED] wrote:
+#ifdef CONFIG_NUMA
+#define dev_to_node(dev) ((dev)-numa_node)
+#define set_dev_node(dev, node) ((dev)-numa_node = node)
+#else
+#define dev_to_node(dev) (-1)
+#define set_dev_node(dev, node) do { } while (0)
+#endif
minor point: using inlines here would give typechecking, prevent possible
unused-var warnings, etc.
Maybe there was a reason for not doing that.
does it
No doubt I'll find out ;)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] netdev do down on suspend and up on resume
This is a demo only. IMHO the network device code should take care of bringing
down network devices and restoring them on resume. Some distro's do this with
scripts
and many devices do it themselves in the suspend code. But doing it in the main
netdevice code is best, and means that many network devices would need no
special
suspend/resume code, since the default suspend for pci devices does a
save/restore
state and power control.
It is compatiable with older devices (and distro's like Ubuntu) that do the same
thing already, because luckily calling dev_close on a down device does nothing,
and
calling dev_open on an up device does nothing.
It is not possible to use the class interface (net_class) for a couple of
reasons,
first the classes are called in registration order so the interesting ones like
pci
have already suspended the device. Second, the class interface is based off
hardware
not pseudo-devices like netdevice objects.
--- linux-2.6.19-rc5.orig/include/linux/netdevice.h 2006-11-15
11:27:54.0 -0800
+++ linux-2.6.19-rc5/include/linux/netdevice.h 2006-11-15 11:40:50.0
-0800
@@ -351,6 +351,7 @@
unsigned intflags; /* interface flags (a la BSD) */
+ unsigned intsave_flags; /* during suspend/resume */
unsigned short gflags;
unsigned short priv_flags; /* Like 'flags' but invisible to
userspace. */
unsigned short padded; /* How much padding added by
alloc_netdev() */
@@ -988,6 +989,14 @@
extern voidnet_enable_timestamp(void);
extern voidnet_disable_timestamp(void);
+#ifdef CONFIG_NET
+extern voidnetdev_suspend(void);
+extern voidnetdev_resume(void);
+#else
+#define netdev_suspend() do { } while(0)
+#define netdev_resume()do { } while(0)
+#endif
+
#ifdef CONFIG_PROC_FS
extern void *dev_seq_start(struct seq_file *seq, loff_t *pos);
extern void *dev_seq_next(struct seq_file *seq, void *v, loff_t *pos);
--- sky2.orig/kernel/power/main.c 2006-11-15 11:35:42.0 -0800
+++ sky2/kernel/power/main.c2006-11-15 11:37:24.0 -0800
@@ -18,6 +18,7 @@
#include linux/console.h
#include linux/cpu.h
#include linux/resume-trace.h
+#include linux/netdevice.h
#include power.h
@@ -61,6 +62,8 @@
pm_prepare_console();
+ netdev_suspend();
+
error = disable_nonboot_cpus();
if (error)
goto Enable_cpu;
@@ -98,6 +101,7 @@
thaw_processes();
Enable_cpu:
enable_nonboot_cpus();
+ netdev_resume();
pm_restore_console();
return error;
}
@@ -139,6 +143,7 @@
if (pm_ops pm_ops-finish)
pm_ops-finish(state);
pm_restore_console();
+ netdev_resume();
}
--- sky2.orig/net/core/dev.c2006-11-15 11:28:00.0 -0800
+++ sky2/net/core/dev.c 2006-11-15 11:33:53.0 -0800
@@ -949,6 +949,45 @@
return 0;
}
+#ifdef CONFIG_PM
+/*
+ * netdev_suspend - close all network devices
+ * During suspend, bring down all network interfaces and save state.
+ */
+void netdev_suspend(void)
+{
+ struct net_device *d;
+
+ rtnl_lock();
+ for (d = dev_base; d; d = d-next) {
+ d-save_flags = d-flags;
+ dev_close(d);
+ }
+ rtnl_unlock();
+}
+
+
+/*
+ * netdev_resume - restore all network devices
+ * During resume, bring up all network interfaces that were up before
suspend.
+ */
+void netdev_resume(void)
+{
+ struct net_device *d;
+
+ rtnl_lock();
+ for (d = dev_base; d; d = d-next)
+ if (d-save_flags IFF_UP) {
+ err = dev_open(d);
+ if (err) {
+ printk(KERN_INFO %s: failed to come back up
(%d)\n,
+ d-name, err);
+ }
+ }
+
+ rtnl_unlock();
+}
+#endif
/*
* Device change register/unregister. These are not inline or static
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.19][TG3]: Disable TSO on 5906 if CLKREQ is enabled.
[TG3]: Disable TSO on 5906 if CLKREQ is enabled.
Due to hardware errata, TSO must be disabled if the PCI Express clock
request is enabled on 5906. The chip may hang when transmitting TSO
frames if CLKREQ is enabled.
Update version to 3.69.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 6e86866..1dbdd6b 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -68,8 +68,8 @@ #include tg3.h
#define DRV_MODULE_NAMEtg3
#define PFX DRV_MODULE_NAME:
-#define DRV_MODULE_VERSION 3.68
-#define DRV_MODULE_RELDATE November 02, 2006
+#define DRV_MODULE_VERSION 3.69
+#define DRV_MODULE_RELDATE November 15, 2006
#define TG3_DEF_MAC_MODE 0
#define TG3_DEF_RX_MODE0
@@ -10366,7 +10366,7 @@ static int __devinit tg3_get_invariants(
u32 pci_state_reg, grc_misc_cfg;
u32 val;
u16 pci_cmd;
- int err;
+ int err, pcie_cap;
/* Force memory write invalidate off. If we leave it on,
* then on 5700_BX chips we have to enable a workaround.
@@ -10541,8 +10541,19 @@ static int __devinit tg3_get_invariants(
GET_ASIC_REV(tp-pci_chip_rev_id) != ASIC_REV_5906)
tp-tg3_flags2 |= TG3_FLG2_JUMBO_CAPABLE;
- if (pci_find_capability(tp-pdev, PCI_CAP_ID_EXP) != 0)
+ pcie_cap = pci_find_capability(tp-pdev, PCI_CAP_ID_EXP);
+ if (pcie_cap != 0) {
tp-tg3_flags2 |= TG3_FLG2_PCI_EXPRESS;
+ if (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5906) {
+ u16 lnkctl;
+
+ pci_read_config_word(tp-pdev,
+pcie_cap + PCI_EXP_LNKCTL,
+lnkctl);
+ if (lnkctl PCI_EXP_LNKCTL_CLKREQ_EN)
+ tp-tg3_flags2 = ~TG3_FLG2_HW_TSO_2;
+ }
+ }
/* If we have an AMD 762 or VIA K8T800 chipset, write
* reordering to the mailbox registers done by the host
@@ -11809,6 +11820,7 @@ #if TG3_TSO_SUPPORT != 0
else if (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5700 ||
GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5701 ||
tp-pci_chip_rev_id == CHIPREV_ID_5705_A0 ||
+ GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5906 ||
(tp-tg3_flags TG3_FLAG_ENABLE_ASF) != 0) {
tp-tg3_flags2 = ~TG3_FLG2_TSO_CAPABLE;
} else {
diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
index c312a12..c321316 100644
--- a/include/linux/pci_regs.h
+++ b/include/linux/pci_regs.h
@@ -371,6 +371,7 @@ #define PCI_EXP_DEVSTA_AUXPD 0x10/* AU
#define PCI_EXP_DEVSTA_TRPND 0x20/* Transactions Pending */
#define PCI_EXP_LNKCAP 12 /* Link Capabilities */
#define PCI_EXP_LNKCTL 16 /* Link Control */
+#define PCI_EXP_LNKCTL_CLKREQ_EN 0x100/* Enable clkreq */
#define PCI_EXP_LNKSTA 18 /* Link Status */
#define PCI_EXP_SLTCAP 20 /* Slot Capabilities */
#define PCI_EXP_SLTCTL 24 /* Slot Control */
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cxgb3: Chelsio T3 1G/10G ethernet device driver
My stuff really should have been in response to a differnt mail thread. driver support for Chelsio T210 10Gb ethernet in 2.6.x - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Sysctl syscall
Compiling the program which uses a lot sysctl syscalls, gives me this warning on Debian unstable: warning: the `sysctl' syscall has been removed from 2.6.18+ kernels, direct access to `/proc/sys' should be used instead. Is it true? And what can be used as alternative which would work with both 2.4 and 2.6 kernels and would work with capabilities (sys/capability.h)? Accessing `/proc/sys' directly isn't such alternative as it doesn't work with capabilities. regards, -- Hasso Tepper Elion Enterprises Ltd. [AS3249] Data Communication Network Administrator - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sysctl syscall
On Nov 16 2006 00:03, Hasso Tepper wrote: Compiling the program which uses a lot sysctl syscalls, gives me this warning on Debian unstable: warning: the `sysctl' syscall has been removed from 2.6.18+ kernels, direct access to `/proc/sys' should be used instead. Is it true? Well it was unobsoleted in 2.6.19 if I followed the list correctly. And what can be used as alternative which would work with both 2.4 and 2.6 kernels and would work with capabilities (sys/capability.h)? Accessing `/proc/sys' directly isn't such alternative as it doesn't work with capabilities. -`J' -- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cxgb3: Chelsio T3 1G/10G ethernet device driver
Hi, This patch adds support for the latest Chelsio adapter, T3. Since some files are bigger than the 40kB advertized in the submit guidelines, a monolithic patch against 2.6.19-rc5 is posted at the following URL: http://service.chelsio.com/kernel.org/cxgb3.patch.bz2 Please advise on any other form you would like to see the code. We wish this patch to be considered for inclusion in 2.6.20. This driver will be required by the Chelsio T3 RDMA driver which will be posted for review asap. Cheers, Divy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cxgb3: Chelsio T3 1G/10G ethernet device driver
On Wed, 15 Nov 2006 16:11:36 -0800 divy [EMAIL PROTECTED] wrote: Hi, This patch adds support for the latest Chelsio adapter, T3. Since some files are bigger than the 40kB advertized in the submit guidelines, a monolithic patch against 2.6.19-rc5 is posted at the following URL: http://service.chelsio.com/kernel.org/cxgb3.patch.bz2 Please advise on any other form you would like to see the code. We wish this patch to be considered for inclusion in 2.6.20. This driver will be required by the Chelsio T3 RDMA driver which will be posted for review asap. Cheers, Divy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html This took me an afternoon, so I don't see why Chelsio didn't do it. Port of Chelsio's 2.2.0 version driver from: http://service.chelsio.com/drivers/linux/t210/cxgb2toe-2.2.0.tar.gz De-vendorized: - removed all TCP Offload Engine support because those changes will not be accepted in mainline kernel. - new files run through Lindent - removed code that was '#ifdef' for older kernel versions - fix for 2.6.19 irq - replace usage of TSC with ktime - remove /proc trace debug stuff - remove dead code - incorporate GSO, etc. - get rid of FILE_IDENT() macro - fix sparse warnings by adding __iomem and __user Also, I kept as many of the filenames and device names the same since it is really just an extension of existing driver. I'm testing it now. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cxgb3: Chelsio T3 1G/10G ethernet device driver
On Thursday 16 November 2006 01:11, divy wrote: This patch adds support for the latest Chelsio adapter, T3. Since some files are bigger than the 40kB advertized in the submit guidelines, a monolithic patch against 2.6.19-rc5 is posted at the following URL: http://service.chelsio.com/kernel.org/cxgb3.patch.bz2 Please advise on any other form you would like to see the code. You should still attempt to post it as inline email for better review. The hard limit on mails is 100kb right now, IIRC, so it should be possible to split it up into smaller chunks for review. We wish this patch to be considered for inclusion in 2.6.20. This driver will be required by the Chelsio T3 RDMA driver which will be posted for review asap. Two things I noticed on a very brief review: - The driver is _huge_. Even if your hardware is terribly complicated, the fact that you need 600kb to drive it is a hint that you do something wrong. In particular, the header files contain hundreds of macros that are completely unused. You should get rid of them. - You define a driver specific multiplexing ioctl method. This is something you really shouldn't do in a network driver, since the ioctl number will conflict with other drivers. In order to get the rest of your code merged, I'd suggest you split out the private ioctl handling into a separate patch that you don't submit for now, and then we can think of how to replace the interfaces with something better, e.g. new driver-independent calls like ioctl or ethtool or sysfs, or get rid of them if they turn out to be not required. Arnd - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 07/30] bcm43xx: Drain TX status before starting IRQs
-stable review patch. If anyone has any objections, please let us know.
--
From: Michael Buesch [EMAIL PROTECTED]
Drain the Microcode TX-status-FIFO before we enable IRQs.
This is required, because the FIFO may still have entries left
from a previous run. Those would immediately fire after enabling
IRQs and would lead to an oops in the DMA TXstatus handling code.
Cc: John W. Linville [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 18 ++
1 file changed, 18 insertions(+)
--- linux-2.6.18.2.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6.18.2/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1463,6 +1463,23 @@ static void handle_irq_transmit_status(s
}
}
+static void drain_txstatus_queue(struct bcm43xx_private *bcm)
+{
+ u32 dummy;
+
+ if (bcm-current_core-rev 5)
+ return;
+ /* Read all entries from the microcode TXstatus FIFO
+* and throw them away.
+*/
+ while (1) {
+ dummy = bcm43xx_read32(bcm, BCM43xx_MMIO_XMITSTAT_0);
+ if (!dummy)
+ break;
+ dummy = bcm43xx_read32(bcm, BCM43xx_MMIO_XMITSTAT_1);
+ }
+}
+
static void bcm43xx_generate_noise_sample(struct bcm43xx_private *bcm)
{
bcm43xx_shm_write16(bcm, BCM43xx_SHM_SHARED, 0x408, 0x7F7F);
@@ -3517,6 +3534,7 @@ int bcm43xx_select_wireless_core(struct
bcm43xx_macfilter_clear(bcm, BCM43xx_MACFILTER_ASSOC);
bcm43xx_macfilter_set(bcm, BCM43xx_MACFILTER_SELF, (u8
*)(bcm-net_dev-dev_addr));
bcm43xx_security_init(bcm);
+ drain_txstatus_queue(bcm);
ieee80211softmac_start(bcm-net_dev);
/* Let's go! Be careful after enabling the IRQs.
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cxgb3: Chelsio T3 1G/10G ethernet device driver
On Wed, 2006-11-15 at 16:33 -0800, Stephen Hemminger wrote: On Wed, 15 Nov 2006 16:11:36 -0800 divy [EMAIL PROTECTED] wrote: Hi, This patch adds support for the latest Chelsio adapter, T3. Since some files are bigger than the 40kB advertized in the submit guidelines, a monolithic patch against 2.6.19-rc5 is posted at the following URL: http://service.chelsio.com/kernel.org/cxgb3.patch.bz2 Please advise on any other form you would like to see the code. We wish this patch to be considered for inclusion in 2.6.20. This driver will be required by the Chelsio T3 RDMA driver which will be posted for review asap. Cheers, Divy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html This took me an afternoon, so I don't see why Chelsio didn't do it. Port of Chelsio's 2.2.0 version driver from: http://service.chelsio.com/drivers/linux/t210/cxgb2toe-2.2.0.tar.gz De-vendorized: - removed all TCP Offload Engine support because those changes will not be accepted in mainline kernel. - new files run through Lindent - removed code that was '#ifdef' for older kernel versions - fix for 2.6.19 irq - replace usage of TSC with ktime - remove /proc trace debug stuff - remove dead code - incorporate GSO, etc. - get rid of FILE_IDENT() macro - fix sparse warnings by adding __iomem and __user Also, I kept as many of the filenames and device names the same since it is really just an extension of existing driver. I'm testing it now. Stephen, Divy posted a new driver to support the new Chelsio T3 hardware, not the 210 hardware. Steve. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Hi. Michael Buesch wrote: Well, it never worked for me. But I gave up trying about half a year ago. But maybe it's just stupid me. ;) Well, we have various support channels (an IRC channel besides two mailing lists, for example) that you are welcome to make use of in case of problems :) Bye, Mike - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/13] Chelsio T3 RDMA Driver
Roland / All: The following series implements the Chelsio T3 iWARP/RDMA Driver to be considered for inclusion in 2.6.20. It depends on the Chelsio T3 Ethernet Driver which is also under review now for 2.6.20 (http://marc.theaimsgroup.com/?l=linux-netdevm=116363600816597w=2). The patches are against 2.6.19-rc5. This patch series can also be pulled from: http://www.opengridcomputing.com/downloads/iw_cxgb3_patches.tar.bz2 The Chelsio T3 Ethernet Driver patch can be pulled from: http://service.chelsio.com/kernel.org/cxgb3.patch.bz2 Thanks, Steve. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/13] Linux RDMA Core Changes
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/hw/amso1100/c2.h |2 +-
drivers/infiniband/hw/amso1100/c2_cq.c|3 ++-
drivers/infiniband/hw/ehca/ehca_iverbs.h |3 ++-
drivers/infiniband/hw/ehca/ehca_reqs.c|3 ++-
drivers/infiniband/hw/ipath/ipath_cq.c|4 +++-
drivers/infiniband/hw/ipath/ipath_verbs.h |3 ++-
drivers/infiniband/hw/mthca/mthca_cq.c|6 --
drivers/infiniband/hw/mthca/mthca_dev.h |4 ++--
include/rdma/ib_verbs.h |5 +++--
10 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/infiniband/core/uverbs_cmd.c
b/drivers/infiniband/core/uverbs_cmd.c
index 743247e..5dd1de9 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -959,6 +959,7 @@ ssize_t ib_uverbs_req_notify_cq(struct i
int out_len)
{
struct ib_uverbs_req_notify_cq cmd;
+ struct ib_udata udata;
struct ib_cq *cq;
if (copy_from_user(cmd, buf, sizeof cmd))
@@ -968,8 +969,12 @@ ssize_t ib_uverbs_req_notify_cq(struct i
if (!cq)
return -EINVAL;
- ib_req_notify_cq(cq, cmd.solicited_only ?
-IB_CQ_SOLICITED : IB_CQ_NEXT_COMP);
+ INIT_UDATA(udata, buf + sizeof cmd, 0,
+ in_len - sizeof cmd, 0);
+
+ cq-device-req_notify_cq(cq, cmd.solicited_only ?
+ IB_CQ_SOLICITED : IB_CQ_NEXT_COMP,
+ udata);
put_cq_read(cq);
diff --git a/drivers/infiniband/hw/amso1100/c2.h
b/drivers/infiniband/hw/amso1100/c2.h
index 1b17dcd..716f9dc 100644
--- a/drivers/infiniband/hw/amso1100/c2.h
+++ b/drivers/infiniband/hw/amso1100/c2.h
@@ -519,7 +519,7 @@ extern void c2_free_cq(struct c2_dev *c2
extern void c2_cq_event(struct c2_dev *c2dev, u32 mq_index);
extern void c2_cq_clean(struct c2_dev *c2dev, struct c2_qp *qp, u32 mq_index);
extern int c2_poll_cq(struct ib_cq *ibcq, int num_entries, struct ib_wc
*entry);
-extern int c2_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify notify);
+extern int c2_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify notify, struct
ib_udata *udata);
/* CM */
extern int c2_llp_connect(struct iw_cm_id *cm_id,
diff --git a/drivers/infiniband/hw/amso1100/c2_cq.c
b/drivers/infiniband/hw/amso1100/c2_cq.c
index 05c9154..7ce8bca 100644
--- a/drivers/infiniband/hw/amso1100/c2_cq.c
+++ b/drivers/infiniband/hw/amso1100/c2_cq.c
@@ -217,7 +217,8 @@ int c2_poll_cq(struct ib_cq *ibcq, int n
return npolled;
}
-int c2_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify notify)
+int c2_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify notify,
+ struct ib_udata *udata)
{
struct c2_mq_shared __iomem *shared;
struct c2_cq *cq;
diff --git a/drivers/infiniband/hw/ehca/ehca_iverbs.h
b/drivers/infiniband/hw/ehca/ehca_iverbs.h
index 3720e30..566b30c 100644
--- a/drivers/infiniband/hw/ehca/ehca_iverbs.h
+++ b/drivers/infiniband/hw/ehca/ehca_iverbs.h
@@ -135,7 +135,8 @@ int ehca_poll_cq(struct ib_cq *cq, int n
int ehca_peek_cq(struct ib_cq *cq, int wc_cnt);
-int ehca_req_notify_cq(struct ib_cq *cq, enum ib_cq_notify cq_notify);
+int ehca_req_notify_cq(struct ib_cq *cq, enum ib_cq_notify cq_notify,
+ struct ib_udata *udata);
struct ib_qp *ehca_create_qp(struct ib_pd *pd,
struct ib_qp_init_attr *init_attr,
diff --git a/drivers/infiniband/hw/ehca/ehca_reqs.c
b/drivers/infiniband/hw/ehca/ehca_reqs.c
index b46bda1..3ed6992 100644
--- a/drivers/infiniband/hw/ehca/ehca_reqs.c
+++ b/drivers/infiniband/hw/ehca/ehca_reqs.c
@@ -634,7 +634,8 @@ poll_cq_exit0:
return ret;
}
-int ehca_req_notify_cq(struct ib_cq *cq, enum ib_cq_notify cq_notify)
+int ehca_req_notify_cq(struct ib_cq *cq, enum ib_cq_notify cq_notify,
+ struct ib_udata *udata)
{
struct ehca_cq *my_cq = container_of(cq, struct ehca_cq, ib_cq);
diff --git a/drivers/infiniband/hw/ipath/ipath_cq.c
b/drivers/infiniband/hw/ipath/ipath_cq.c
index 87462e0..27ba4db 100644
--- a/drivers/infiniband/hw/ipath/ipath_cq.c
+++ b/drivers/infiniband/hw/ipath/ipath_cq.c
@@ -307,13 +307,15 @@ int ipath_destroy_cq(struct ib_cq *ibcq)
* ipath_req_notify_cq - change the notification type for a completion queue
* @ibcq: the completion queue
* @notify: the type of notification to request
+ * @udata: user data
*
* Returns 0 for success.
*
* This may be called from interrupt context. Also called by
* ib_req_notify_cq() in the generic verbs code.
*/
-int ipath_req_notify_cq(struct ib_cq *ibcq, enum ib_cq_notify notify)
+int ipath_req_notify_cq(struct ib_cq
[PATCH 05/13] Queue Pairs
Code to manipulate the QP.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_qp.c | 996 +
1 files changed, 996 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_qp.c
b/drivers/infiniband/hw/cxgb3/iwch_qp.c
new file mode 100644
index 000..dc1c55e
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch_qp.c
@@ -0,0 +1,996 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include iwch_provider.h
+#include iwch.h
+#include iwch_cm.h
+#include cxio_hal.h
+
+#define NO_SUPPORT -1
+
+static inline int iwch_build_rdma_send(union t3_wr *wqe,
+ struct ib_send_wr *wr,
+ u8 * flit_cnt)
+{
+ int i;
+ switch (wr-opcode) {
+ case IB_WR_SEND:
+ case IB_WR_SEND_WITH_IMM:
+ if (wr-send_flags IB_SEND_SOLICITED)
+ wqe-send.rdmaop = T3_SEND_WITH_SE;
+ else
+ wqe-send.rdmaop = T3_SEND;
+ wqe-send.rem_stag = 0;
+ break;
+#if 0 /* Not currently supported */
+ case TYPE_SEND_INVALIDATE:
+ case TYPE_SEND_INVALIDATE_IMMEDIATE:
+ wqe-send.rdmaop = T3_SEND_WITH_INV;
+ wqe-send.rem_stag = cpu_to_be32(wr-wr.rdma.rkey);
+ break;
+ case TYPE_SEND_SE_INVALIDATE:
+ wqe-send.rdmaop = T3_SEND_WITH_SE_INV;
+ wqe-send.rem_stag = cpu_to_be32(wr-wr.rdma.rkey);
+ break;
+#endif
+ default:
+ break;
+ }
+ if (wr-num_sge T3_MAX_SGE)
+ return -EINVAL;
+ wqe-send.reserved = 0;
+ if (wr-opcode == IB_WR_SEND_WITH_IMM) {
+ wqe-send.plen = 4;
+ wqe-send.sgl[0].stag = wr-imm_data;
+ wqe-send.sgl[0].len = 0;
+ wqe-send.num_sgle = 0;
+ *flit_cnt = 5;
+ } else {
+ wqe-send.plen = 0;
+ for (i = 0; i wr-num_sge; i++) {
+ if ((wqe-send.plen + wr-sg_list[i].length)
+ wqe-send.plen) {
+ return -EMSGSIZE;
+ }
+ wqe-send.plen += wr-sg_list[i].length;
+ wqe-send.sgl[i].stag =
+ cpu_to_be32(wr-sg_list[i].lkey);
+ wqe-send.sgl[i].len =
+ cpu_to_be32(wr-sg_list[i].length);
+ wqe-send.sgl[i].to = cpu_to_be64(wr-sg_list[i].addr);
+ }
+ wqe-send.plen = cpu_to_be32(wqe-send.plen);
+ wqe-send.num_sgle = cpu_to_be32(wr-num_sge);
+ *flit_cnt = 4 + ((wr-num_sge) 1);
+ }
+ return 0;
+}
+
+static inline int iwch_build_rdma_write(union t3_wr *wqe,
+ struct ib_send_wr *wr,
+ u8 *flit_cnt)
+{
+ int i;
+ if (wr-num_sge T3_MAX_SGE)
+ return -EINVAL;
+ wqe-write.rdmaop = T3_RDMA_WRITE;
+ wqe-write.reserved = 0;
+ wqe-write.stag_sink = cpu_to_be32(wr-wr.rdma.rkey);
+ wqe-write.to_sink = cpu_to_be64(wr-wr.rdma.remote_addr);
+
+ wqe-write.num_sgle = wr-num_sge;
+
+ if (wr-opcode == IB_WR_RDMA_WRITE_WITH_IMM) {
+ wqe-write.plen = cpu_to_be32(4);
+
[PATCH 06/13] Completion Queues
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/iwch_cq.c
new file mode 100644
index 000..aa5c0f6
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch_cq.c
@@ -0,0 +1,231 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include iwch_provider.h
+#include iwch.h
+
+/*
+ * Get one cq entry from cxio and map it to openib.
+ *
+ * Returns:
+ * 0 EMPTY;
+ * 1 cqe returned
+ * -EAGAIN caller must try again
+ * any other -errnofatal error
+ */
+int iwch_poll_cq_one(struct iwch_dev *rhp, struct iwch_cq *chp,
+struct ib_wc *wc)
+{
+ struct iwch_qp *qhp = NULL;
+ struct t3_cqe cqe, *rd_cqe;
+ struct t3_wq *wq;
+ u32 credit = 0;
+ u8 cqe_flushed;
+ u64 cookie;
+ int ret = 1;
+
+ rd_cqe = cxio_next_cqe(chp-cq);
+
+ if (!rd_cqe)
+ return 0;
+
+ qhp = get_qhp(rhp, CQE_QPID(*rd_cqe));
+ if (!qhp)
+ wq = NULL;
+ else {
+ spin_lock(qhp-lock);
+ wq = (qhp-wq);
+ }
+ ret = cxio_poll_cq(wq, (chp-cq), cqe, cqe_flushed, cookie,
+ credit);
+ if (t3a_device(chp-rhp) credit) {
+ PDBG(%s updating %d cq credits on id %d\n, __FUNCTION__,
+credit, chp-cq.cqid);
+ cxio_hal_cq_op(rhp-rdev, chp-cq, CQ_CREDIT_UPDATE, credit);
+ }
+
+ if (ret) {
+ ret = -EAGAIN;
+ goto out;
+ }
+ ret = 1;
+
+ wc-wr_id = cookie;
+ wc-qp_num = qhp-wq.qpid;
+ wc-vendor_err = CQE_STATUS(cqe);
+
+ PDBG(%s qpid 0x%x type %d opcode %d status 0x%x wrid hi 0x%x
+lo 0x%x cookie 0x%llx\n, __FUNCTION__,
+CQE_QPID(cqe), CQE_TYPE(cqe),
+CQE_OPCODE(cqe), CQE_STATUS(cqe), CQE_WRID_HI(cqe),
+CQE_WRID_LOW(cqe), cookie);
+
+ if (CQE_TYPE(cqe) == 0) {
+ if (!CQE_STATUS(cqe))
+ wc-byte_len = CQE_LEN(cqe);
+ else
+ wc-byte_len = 0;
+ wc-opcode = IB_WC_RECV;
+ } else {
+ switch (CQE_OPCODE(cqe)) {
+ case T3_RDMA_WRITE:
+ wc-opcode = IB_WC_RDMA_WRITE;
+ break;
+ case T3_READ_REQ:
+ wc-opcode = IB_WC_RDMA_READ;
+ wc-byte_len = CQE_LEN(cqe);
+ break;
+ case T3_SEND:
+ case T3_SEND_WITH_SE:
+ wc-opcode = IB_WC_SEND;
+ break;
+ case T3_BIND_MW:
+ wc-opcode = IB_WC_BIND_MW;
+ break;
+
+ /* these aren't supported yet */
+ case T3_SEND_WITH_INV:
+ case T3_SEND_WITH_SE_INV:
+ case T3_LOCAL_INV:
+ case T3_FAST_REGISTER:
+ default:
+ printk(KERN_ERR MOD Unexpected opcode %d
+ in the CQE received for QPID=0x%0x\n,
+ CQE_OPCODE(cqe), CQE_QPID(cqe));
+ ret = -EINVAL;
+
[PATCH 12/13] Core Debug functions
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/cxgb3/core/cxio_dbg.c
b/drivers/infiniband/hw/cxgb3/core/cxio_dbg.c
new file mode 100644
index 000..ffe5261
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/core/cxio_dbg.c
@@ -0,0 +1,205 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#ifdef DEBUG
+#include linux/types.h
+#include common.h
+#include cxgb3_ioctl.h
+#include cxio_hal.h
+#include cxio_wr.h
+
+void cxio_dump_tpt(struct cxio_rdev *rdev, u32 stag)
+{
+ struct ch_mem_range *m;
+ u64 *data;
+ int rc;
+ int size = 32;
+
+ m = kmalloc(sizeof(*m) + size, GFP_ATOMIC);
+ if (!m) {
+ PDBG(%s couldn't allocate memory.\n, __FUNCTION__);
+ return;
+ }
+ m-mem_id = MEM_PMRX;
+ m-addr = (stag8) * 32 + rdev-rnic_info.tpt_base;
+ m-len = size;
+ PDBG(%s TPT addr 0x%x len %d\n, __FUNCTION__, m-addr, m-len);
+ rc = rdev-t3cdev_p-ctl(rdev-t3cdev_p, RDMA_GET_MEM, m);
+ if (rc) {
+ PDBG(%s toectl returned error %d\n, __FUNCTION__, rc);
+ kfree(m);
+ return;
+ }
+
+ data = (u64 *)m-buf;
+ while (size 0) {
+ PDBG(TPT %08x: %016llx\n, m-addr, (u64)*data);
+ size -= 8;
+ data++;
+ m-addr += 8;
+ }
+ kfree(m);
+}
+
+void cxio_dump_pbl(struct cxio_rdev *rdev, u32 pbl_addr, uint len, u8 shift)
+{
+ struct ch_mem_range *m;
+ u64 *data;
+ int rc;
+ int size, npages;
+
+ shift += 12;
+ npages = (len + (1ULL shift) - 1) shift;
+ size = npages * sizeof(u64);
+
+ m = kmalloc(sizeof(*m) + size, GFP_ATOMIC);
+ if (!m) {
+ PDBG(%s couldn't allocate memory.\n, __FUNCTION__);
+ return;
+ }
+ m-mem_id = MEM_PMRX;
+ m-addr = pbl_addr;
+ m-len = size;
+ PDBG(%s PBL addr 0x%x len %d depth %d\n,
+ __FUNCTION__, m-addr, m-len, npages);
+ rc = rdev-t3cdev_p-ctl(rdev-t3cdev_p, RDMA_GET_MEM, m);
+ if (rc) {
+ PDBG(%s toectl returned error %d\n, __FUNCTION__, rc);
+ kfree(m);
+ return;
+ }
+
+ data = (u64 *)m-buf;
+ while (size 0) {
+ PDBG(PBL %08x: %016llx\n, m-addr, (u64)*data);
+ size -= 8;
+ data++;
+ m-addr += 8;
+ }
+ kfree(m);
+}
+
+void cxio_dump_wqe(union t3_wr *wqe)
+{
+ u64 *data = (u64 *)wqe;
+ uint size = (uint)(be64_to_cpu(*data) 0xff);
+
+ if (size == 0)
+ size = 8;
+ while (size 0) {
+ PDBG(WQE %p: %016llx\n, data, be64_to_cpu(*data));
+ size--;
+ data++;
+ }
+}
+
+void cxio_dump_wce(struct t3_cqe *wce)
+{
+ u64 *data = (u64 *)wce;
+ int size = sizeof(*wce);
+
+ while (size 0) {
+ PDBG(WCE %p: %016llx\n, data, be64_to_cpu(*data));
+ size -= 8;
+ data++;
+ }
+}
+
+void cxio_dump_rqt(struct cxio_rdev *rdev, u32 hwtid, int nents)
+{
+ struct ch_mem_range *m;
+ int size = nents * 64;
+ u64 *data;
+ int rc;
+
+ m = kmalloc(sizeof(*m) + size, GFP_ATOMIC);
[PATCH 03/13] Provider Methods and Data Structures
Provider methods to support the Linux RDMA verbs.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_provider.c | 1186 +++
drivers/infiniband/hw/cxgb3/iwch_provider.h | 390 +
drivers/infiniband/hw/cxgb3/iwch_user.h | 68 ++
3 files changed, 1644 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c
b/drivers/infiniband/hw/cxgb3/iwch_provider.c
new file mode 100644
index 000..11afe0c
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c
@@ -0,0 +1,1186 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/device.h
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include linux/delay.h
+#include linux/errno.h
+#include linux/list.h
+#include linux/spinlock.h
+#include linux/ethtool.h
+
+#include asm/io.h
+#include asm/irq.h
+#include asm/byteorder.h
+
+#include rdma/iw_cm.h
+#include rdma/ib_verbs.h
+#include rdma/ib_smi.h
+#include rdma/ib_user_verbs.h
+
+#include cxio_hal.h
+#include iwch.h
+#include iwch_provider.h
+#include iwch_cm.h
+#include iwch_user.h
+
+static int iwch_modify_port(struct ib_device *ibdev,
+ u8 port, int port_modify_mask,
+ struct ib_port_modify *props)
+{
+ return -ENOSYS;
+}
+
+static struct ib_ah *iwch_ah_create(struct ib_pd *pd,
+ struct ib_ah_attr *ah_attr)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
+static int iwch_ah_destroy(struct ib_ah *ah)
+{
+ return -ENOSYS;
+}
+
+static int iwch_multicast_attach(struct ib_qp *ibqp, union ib_gid *gid, u16
lid)
+{
+ return -ENOSYS;
+}
+
+static int iwch_multicast_detach(struct ib_qp *ibqp, union ib_gid *gid, u16
lid)
+{
+ return -ENOSYS;
+}
+
+static int iwch_process_mad(struct ib_device *ibdev,
+ int mad_flags,
+ u8 port_num,
+ struct ib_wc *in_wc,
+ struct ib_grh *in_grh,
+ struct ib_mad *in_mad, struct ib_mad *out_mad)
+{
+ return -ENOSYS;
+}
+
+static int iwch_dealloc_ucontext(struct ib_ucontext *context)
+{
+ struct iwch_dev *rhp = to_iwch_dev(context-device);
+ struct iwch_ucontext *ucontext = to_iwch_ucontext(context);
+ PDBG(%s context %p\n, __FUNCTION__, context);
+ cxio_release_ucontext(rhp-rdev, ucontext-uctx);
+ kfree(ucontext);
+ return 0;
+}
+
+static struct ib_ucontext *iwch_alloc_ucontext(struct ib_device *ibdev,
+ struct ib_udata *udata)
+{
+ struct iwch_ucontext *context;
+ struct iwch_dev *rhp = to_iwch_dev(ibdev);
+
+ PDBG(%s ibdev %p\n, __FUNCTION__, ibdev);
+ context = kmalloc(sizeof(*context), GFP_KERNEL);
+ if (!context)
+ return ERR_PTR(-ENOMEM);
+ cxio_init_ucontext(rhp-rdev, context-uctx);
+ INIT_LIST_HEAD(context-mmaps);
+ return context-ibucontext;
+}
+
+static int iwch_destroy_cq(struct ib_cq *ib_cq)
+{
+ struct iwch_cq *chp;
+
+ PDBG(%s ib_cq %p\n, __FUNCTION__, ib_cq);
+ chp = to_iwch_cq(ib_cq);
+
+ spin_lock_irq(chp-rhp-lock);
+ chp-rhp-cqid2ptr[chp-cq.cqid] = NULL;
+ spin_unlock_irq(chp-rhp-lock);
+
+ atomic_dec(chp-refcnt);
+ wait_event(chp-wait, !atomic_read(chp-refcnt));
+
+ cxio_destroy_cq(chp-rhp-rdev, chp-cq);
+
[PATCH 11/13] Core Resource Allocation
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 | 357 ++
drivers/infiniband/hw/cxgb3/core/cxio_resource.h | 70
2 files changed, 427 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_resource.c
b/drivers/infiniband/hw/cxgb3/core/cxio_resource.c
new file mode 100644
index 000..ada44b9
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/core/cxio_resource.c
@@ -0,0 +1,357 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+/* Crude resource management */
+#include linux/kernel.h
+#include linux/random.h
+#include linux/slab.h
+#include linux/kfifo.h
+#include linux/spinlock.h
+#include linux/errno.h
+#include cxio_resource.h
+#include cxio_hal.h
+
+static struct kfifo *rhdl_fifo;
+static spinlock_t rhdl_fifo_lock;
+
+#define RANDOM_SIZE 16
+
+
+/* Loosely based on the Mersenne twister algorithm */
+static u32 next_random(u32 rand)
+{
+ u32 y, ylast;
+
+ y = rand;
+ ylast = y;
+ y = (y * 69069) 0x;
+ y = (y 0x8000) + (ylast 0x7fff);
+ if ((y 1))
+ y = ylast ^ (y 1) ^ (2567483615UL);
+ else
+ y = ylast ^ (y 1);
+ y = y ^ (y 11);
+ y = y ^ ((y 7) 2636928640UL);
+ y = y ^ ((y 15) 4022730752UL);
+ y = y ^ (y 18);
+ return y;
+}
+static int __cxio_init_resource_fifo(struct kfifo **fifo,
+ spinlock_t *fifo_lock,
+ u32 nr, u32 skip_low,
+ u32 skip_high,
+ int random)
+{
+ u32 i, j, entry = 0, idx;
+ u32 random_bytes;
+ u32 rarray[16];
+ spin_lock_init(fifo_lock);
+
+ *fifo = kfifo_alloc(nr * sizeof(u32), GFP_KERNEL, fifo_lock);
+ if (IS_ERR(*fifo))
+ return -ENOMEM;
+
+ for (i = 0; i skip_low + skip_high; i++)
+ __kfifo_put(*fifo, (unsigned char *) entry, sizeof(u32));
+ if (random) {
+ j = 0;
+ get_random_bytes(random_bytes,sizeof(random_bytes));
+ for (i = 0; i RANDOM_SIZE; i++)
+ rarray[i] = i + skip_low;
+ for (i = skip_low + RANDOM_SIZE; i nr - skip_high; i++) {
+ if (j = RANDOM_SIZE) {
+ j = 0;
+ random_bytes = next_random(random_bytes);
+ }
+ idx = (random_bytes (j * 2)) 0xF;
+ __kfifo_put(*fifo,
+ (unsigned char *) rarray[idx],
+ sizeof(u32));
+ rarray[idx] = i;
+ j++;
+ }
+ for (i = 0; i RANDOM_SIZE; i++)
+ __kfifo_put(*fifo,
+ (unsigned char *) rarray[i],
+ sizeof(u32));
+ } else
+ for (i = skip_low; i nr - skip_high; i++)
+ __kfifo_put(*fifo, (unsigned char *) i, sizeof(u32));
+
+ for (i = 0; i skip_low + skip_high; i++)
+ kfifo_get(*fifo, (unsigned char *) entry, sizeof(u32));
+ return 0;
+}
+
+static int cxio_init_resource_fifo(struct kfifo **fifo, spinlock_t * fifo_lock,
+ u32 nr, u32 skip_low, u32
[PATCH 02/13] Device Discovery and ULLD Linkage
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 | 222
drivers/infiniband/hw/cxgb3/iwch.h | 134 ++
2 files changed, 356 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch.c
b/drivers/infiniband/hw/cxgb3/iwch.c
new file mode 100644
index 000..f45f005
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch.c
@@ -0,0 +1,222 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include linux/module.h
+#include linux/moduleparam.h
+
+#include rdma/ib_verbs.h
+
+#include cxgb3_offload.h
+#include iwch_provider.h
+#include iwch_user.h
+#include iwch.h
+#include iwch_cm.h
+
+#define DRV_VERSION 1.1
+
+MODULE_AUTHOR(Boyd Faulkner, Steve Wise);
+MODULE_DESCRIPTION(Chelsio T3 RDMA Driver);
+MODULE_LICENSE(Dual BSD/GPL);
+MODULE_VERSION(DRV_VERSION);
+
+cxgb3_cpl_handler_func t3c_handlers[NUM_CPL_CMDS];
+
+static void open_rnic_dev(struct t3cdev *);
+static void close_rnic_dev(struct t3cdev *);
+
+struct cxgb3_client t3c_client = {
+ .name = iw_cxgb3,
+ .add = open_rnic_dev,
+ .remove = close_rnic_dev,
+ .handlers = t3c_handlers,
+ .redirect = iwch_ep_redirect
+};
+
+static LIST_HEAD(dev_list);
+static DEFINE_MUTEX(dev_mutex);
+
+static inline void *vzmalloc(int size)
+{
+ void *p = vmalloc(size);
+ memset(p, 0, size);
+ return p;
+}
+
+static int open_rnic_init(struct iwch_dev *rnicp)
+{
+ PDBG(%s iwch_dev %p\n, __FUNCTION__, rnicp);
+ rnicp-pdid2ptr = vzmalloc(sizeof(void*) * T3_MAX_NUM_PD);
+ if (!rnicp-pdid2ptr)
+ goto pdid_err;
+ rnicp-cqid2ptr = vzmalloc(sizeof(void*) * T3_MAX_NUM_CQ);
+ if (!rnicp-cqid2ptr)
+ goto cqid_err;
+ rnicp-qpid2ptr = vzmalloc(sizeof(void*) * T3_MAX_NUM_QP);
+ if (!rnicp-qpid2ptr)
+ goto qpid_err;
+ rnicp-mmid2ptr = vzmalloc(sizeof(void*) *
+ cxio_num_stags(rnicp-rdev));
+ if (!rnicp-mmid2ptr)
+ goto stag_err;
+
+ spin_lock_init(rnicp-lock);
+
+ rnicp-attr.vendor_id = 0x168;
+ rnicp-attr.vendor_part_id = 7;
+ rnicp-attr.max_qps = T3_MAX_NUM_QP - 32;
+ rnicp-attr.max_wrs = (1UL 24) - 1;
+ rnicp-attr.max_sge_per_wr = T3_MAX_SGE;
+ rnicp-attr.max_sge_per_rdma_write_wr = T3_MAX_SGE;
+ rnicp-attr.max_cqs = T3_MAX_NUM_CQ - 1;
+ rnicp-attr.max_cqes_per_cq = (1UL 24) - 1;
+ rnicp-attr.max_mem_regs = cxio_num_stags(rnicp-rdev);
+ rnicp-attr.max_phys_buf_entries = T3_MAX_PBL_SIZE;
+ rnicp-attr.max_pds = T3_MAX_NUM_PD - 1;
+ rnicp-attr.mem_pgsizes_bitmask = 0x7FFF; /* 4KB-128MB */
+ rnicp-attr.can_resize_wq = 0;
+ rnicp-attr.max_rdma_reads_per_qp = 8;
+ rnicp-attr.max_rdma_read_resources =
+ rnicp-attr.max_rdma_reads_per_qp * rnicp-attr.max_qps;
+ rnicp-attr.max_rdma_read_qp_depth = 8; /* IRD */
+ rnicp-attr.max_rdma_read_depth =
+ rnicp-attr.max_rdma_read_qp_depth * rnicp-attr.max_qps;
+ rnicp-attr.rq_overflow_handled = 0;
+ rnicp-attr.can_modify_ird = 0;
+ rnicp-attr.can_modify_ord = 0;
+ rnicp-attr.max_mem_windows = rnicp-attr.max_mem_regs - 1;
+ rnicp-attr.stag0_value = 1;
+ rnicp-attr.zbva_support = 1;
+ rnicp-attr.local_invalidate_fence = 1;
+
[PATCH 08/13] Memory Registration
Functions to register memory regions.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_mem.c | 175
1 files changed, 175 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_mem.c
b/drivers/infiniband/hw/cxgb3/iwch_mem.c
new file mode 100644
index 000..9aad3a0
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch_mem.c
@@ -0,0 +1,175 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include asm/byteorder.h
+
+#include rdma/iw_cm.h
+#include rdma/ib_verbs.h
+
+#include cxio_hal.h
+#include iwch.h
+#include iwch_provider.h
+
+int iwch_register_mem(struct iwch_dev *rhp, struct iwch_pd *php,
+ struct iwch_mr *mhp,
+ int shift,
+ u64 *page_list)
+{
+ u32 stag;
+ u32 mmid;
+
+
+ if (cxio_register_phys_mem(rhp-rdev,
+ stag, mhp-attr.pdid,
+ mhp-attr.perms,
+ mhp-attr.zbva,
+ mhp-attr.va_fbo,
+ mhp-attr.len,
+ shift-12,
+ page_list,
+ mhp-attr.pbl_size, mhp-attr.pbl_addr)) {
+ return -ENOMEM;
+ }
+ mhp-attr.state = 1;
+ mhp-attr.stag = stag;
+ mmid = stag 8;
+ mhp-ibmr.rkey = mhp-ibmr.lkey = stag;
+ rhp-mmid2ptr[mmid] = mhp;
+ PDBG(%s mmid 0x%x mhp %p\n, __FUNCTION__, mmid, mhp);
+ return 0;
+}
+
+int iwch_reregister_mem(struct iwch_dev *rhp, struct iwch_pd *php,
+ struct iwch_mr *mhp,
+ int shift,
+ u64 *page_list,
+ int npages)
+{
+ u32 stag;
+ u32 mmid;
+
+
+ /* We could support this... */
+ if (npages mhp-attr.pbl_size)
+ return -ENOMEM;
+
+ stag = mhp-attr.stag;
+ if (cxio_reregister_phys_mem(rhp-rdev,
+ stag, mhp-attr.pdid,
+ mhp-attr.perms,
+ mhp-attr.zbva,
+ mhp-attr.va_fbo,
+ mhp-attr.len,
+ shift-12,
+ page_list,
+ mhp-attr.pbl_size, mhp-attr.pbl_addr)) {
+ return -ENOMEM;
+ }
+ mhp-attr.state = 1;
+ mhp-attr.stag = stag;
+ mmid = stag 8;
+ mhp-ibmr.rkey = mhp-ibmr.lkey = stag;
+ rhp-mmid2ptr[mmid] = mhp;
+ PDBG(%s mmid 0x%x mhp %p\n, __FUNCTION__, mmid, mhp);
+ return 0;
+}
+
+int build_phys_page_list(struct ib_phys_buf *buffer_list,
+ int num_phys_buf,
+ u64 *iova_start,
+ u64 *total_size,
+ int *npages,
+ int *shift,
+ u64 **page_list)
+{
+ u64 mask;
+ int i, j, n;
+
+ mask = 0;
+ *total_size = 0;
+ for (i = 0; i num_phys_buf; ++i) {
+ if (i != 0 buffer_list[i].addr ~PAGE_MASK)
+ return
[PATCH 09/13] Core WQE/CQE Types
T3 WQE and CQE structures, defines, etc...
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/core/cxio_wr.h | 658
1 files changed, 658 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_wr.h
b/drivers/infiniband/hw/cxgb3/core/cxio_wr.h
new file mode 100644
index 000..ad84708
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/core/cxio_wr.h
@@ -0,0 +1,658 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#ifndef __CXIO_WR_H__
+#define __CXIO_WR_H__
+
+#include asm/io.h
+#include linux/pci.h
+#include linux/timer.h
+#include firmware_exports.h
+
+#define T3_MAX_SGE 4
+
+#define Q_EMPTY(rptr,wptr) ((rptr)==(wptr))
+#define Q_FULL(rptr,wptr,size_log2) ( (((wptr)-(rptr))(size_log2)) \
+ ((rptr)!=(wptr)) )
+#define Q_GENBIT(ptr,size_log2) (!(((ptr)size_log2)0x1))
+#define Q_FREECNT(rptr,wptr,size_log2) ((1ULsize_log2)-((wptr)-(rptr)))
+#define Q_COUNT(rptr,wptr) ((wptr)-(rptr))
+#define Q_PTR2IDX(ptr,size_log2) (ptr ((1ULsize_log2)-1))
+#define RING_DOORBELL(doorbell, QPID) { \
+ (writel(((131) | (QPID)), doorbell)); \
+}
+
+#define SEQ32_GE(x,y) (!( (((u32) (x)) - ((u32) (y))) 0x8000 ))
+
+enum t3_wr_flags {
+ T3_COMPLETION_FLAG = 0x01,
+ T3_NOTIFY_FLAG = 0x02,
+ T3_SOLICITED_EVENT_FLAG = 0x04,
+ T3_READ_FENCE_FLAG = 0x08,
+ T3_LOCAL_FENCE_FLAG = 0x10
+} __attribute__ ((packed));
+
+enum t3_wr_opcode {
+ T3_WR_BP = FW_WROPCODE_RI_BYPASS,
+ T3_WR_SEND = FW_WROPCODE_RI_SEND,
+ T3_WR_WRITE = FW_WROPCODE_RI_RDMA_WRITE,
+ T3_WR_READ = FW_WROPCODE_RI_RDMA_READ,
+ T3_WR_INV_STAG = FW_WROPCODE_RI_LOCAL_INV,
+ T3_WR_BIND = FW_WROPCODE_RI_BIND_MW,
+ T3_WR_RCV = FW_WROPCODE_RI_RECEIVE,
+ T3_WR_INIT = FW_WROPCODE_RI_RDMA_INIT,
+ T3_WR_QP_MOD = FW_WROPCODE_RI_MODIFY_QP
+} __attribute__ ((packed));
+
+enum t3_rdma_opcode {
+ T3_RDMA_WRITE, /* IETF RDMAP v1.0 ... */
+ T3_READ_REQ,
+ T3_READ_RESP,
+ T3_SEND,
+ T3_SEND_WITH_INV,
+ T3_SEND_WITH_SE,
+ T3_SEND_WITH_SE_INV,
+ T3_TERMINATE,
+ T3_RDMA_INIT, /* CHELSIO RI specific ... */
+ T3_BIND_MW,
+ T3_FAST_REGISTER,
+ T3_LOCAL_INV,
+ T3_QP_MOD,
+ T3_BYPASS
+} __attribute__ ((packed));
+
+static inline enum t3_rdma_opcode wr2opcode(enum t3_wr_opcode wrop)
+{
+ switch (wrop) {
+ case T3_WR_BP: return T3_BYPASS;
+ case T3_WR_SEND: return T3_SEND;
+ case T3_WR_WRITE: return T3_RDMA_WRITE;
+ case T3_WR_READ: return T3_READ_REQ;
+ case T3_WR_INV_STAG: return T3_LOCAL_INV;
+ case T3_WR_BIND: return T3_BIND_MW;
+ case T3_WR_INIT: return T3_RDMA_INIT;
+ case T3_WR_QP_MOD: return T3_QP_MOD;
+ default: break;
+ }
+ return -1;
+}
+
+
+/* Work request id */
+union t3_wrid {
+ struct {
+ u32 hi:32;
+ u32 low:32;
+ } id0;
+ u64 id1;
+};
+
+#define WRID(wrid) (wrid.id1)
+#define WRID_GEN(wrid) (wrid.id0.wr_gen)
+#define WRID_IDX(wrid) (wrid.id0.wr_idx)
+#define WRID_LO(wrid) (wrid.id0.wr_lo)
+
+struct fw_riwrh {
+ u32 op_seop_flags;
+ u32 gen_tid_len;
+};
+
+#define S_FW_RIWR_OP 24
+#define M_FW_RIWR_OP 0xff
+#define V_FW_RIWR_OP(x)((x)
[PATCH 13/13] Kconfig/Makefile
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 drivers/infiniband/hw/cxgb3/locking.txt | 25 + 5 files changed, 66 insertions(+), 0 deletions(-) diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig index 59b3932..06453ab 100644 --- a/drivers/infiniband/Kconfig +++ b/drivers/infiniband/Kconfig @@ -38,6 +38,7 @@ source drivers/infiniband/hw/mthca/Kcon source drivers/infiniband/hw/ipath/Kconfig source drivers/infiniband/hw/ehca/Kconfig source drivers/infiniband/hw/amso1100/Kconfig +source drivers/infiniband/hw/cxgb3/Kconfig source drivers/infiniband/ulp/ipoib/Kconfig diff --git a/drivers/infiniband/Makefile b/drivers/infiniband/Makefile index 570b30a..69bdd55 100644 --- a/drivers/infiniband/Makefile +++ b/drivers/infiniband/Makefile @@ -3,6 +3,7 @@ obj-$(CONFIG_INFINIBAND_MTHCA) += hw/mt obj-$(CONFIG_INFINIBAND_IPATH) += hw/ipath/ obj-$(CONFIG_INFINIBAND_EHCA) += hw/ehca/ obj-$(CONFIG_INFINIBAND_AMSO1100) += hw/amso1100/ +obj-$(CONFIG_INFINIBAND_CXGB3) += hw/cxgb3/ obj-$(CONFIG_INFINIBAND_IPOIB) += ulp/ipoib/ obj-$(CONFIG_INFINIBAND_SRP) += ulp/srp/ obj-$(CONFIG_INFINIBAND_ISER) += ulp/iser/ diff --git a/drivers/infiniband/hw/cxgb3/Kconfig b/drivers/infiniband/hw/cxgb3/Kconfig new file mode 100644 index 000..84f0f6e --- /dev/null +++ b/drivers/infiniband/hw/cxgb3/Kconfig @@ -0,0 +1,27 @@ +config INFINIBAND_CXGB3 + tristate Chelsio RDMA Driver + depends on CHELSIO_T3 INFINIBAND + select GENERIC_ALLOCATOR + ---help--- + This is an iWARP/RDMA driver for the Chelsio T3 1GbE and + 10GbE adapters. + + For general information about Chelsio and our products, visit + our website at http://www.chelsio.com. + + For customer support, please visit our customer support page at + http://www.chelsio.com/support.htm. + + Please send feedback to [EMAIL PROTECTED]. + + To compile this driver as a module, choose M here: the module + will be called iw_cxgb3. + +config INFINIBAND_CXGB3_DEBUG + bool Verbose debugging output + depends on INFINIBAND_CXGB3 + default n + ---help--- + This option causes the Chelsio RDMA driver to produce copious + amounts of debug messages. Select this if you are developing + the driver or trying to diagnose a problem. diff --git a/drivers/infiniband/hw/cxgb3/Makefile b/drivers/infiniband/hw/cxgb3/Makefile new file mode 100644 index 000..0df2b3d --- /dev/null +++ b/drivers/infiniband/hw/cxgb3/Makefile @@ -0,0 +1,12 @@ +EXTRA_CFLAGS += -I$(TOPDIR)/drivers/net/cxgb3 \ + -I$(TOPDIR)/drivers/infiniband/hw/cxgb3/core + +obj-$(CONFIG_INFINIBAND_CXGB3) += iw_cxgb3.o + +iw_cxgb3-y := iwch_cm.o iwch_ev.o iwch_cq.o iwch_qp.o iwch_mem.o \ + iwch_provider.o iwch.o core/cxio_hal.o core/cxio_resource.o + +ifdef CONFIG_INFINIBAND_CXGB3_DEBUG +EXTRA_CFLAGS += -DDEBUG -O1 -g +iw_cxgb3-y += core/cxio_dbg.o +endif diff --git a/drivers/infiniband/hw/cxgb3/locking.txt b/drivers/infiniband/hw/cxgb3/locking.txt new file mode 100644 index 000..e5e9991 --- /dev/null +++ b/drivers/infiniband/hw/cxgb3/locking.txt @@ -0,0 +1,25 @@ +cq lock: + - spin lock + - used to synchronize the t3_cq + +qp lock: + - spin lock + - used to synchronize updates to the qp state, attrs, and the t3_wq. + - touched on interrupt and process context + +rnicp lock: + - spin lock + - touched on interrupt and process context + - used around lookup tables mapping CQID and QPID to a structure. + - used also to bump the refcnt atomically with the lookup. + +poll: + lock+disable on cq lock + lock qp lock for each cqe that is polled around the call + to cxio_poll_cq(). + +post: + lock+disable qp lock + +global mutex iwch_mutex: + used to maintain global device list. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/13] Core HAL
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 | 1306 +++
drivers/infiniband/hw/cxgb3/core/cxio_hal.h | 201
2 files changed, 1507 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_hal.c
b/drivers/infiniband/hw/cxgb3/core/cxio_hal.c
new file mode 100644
index 000..9821a72
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/core/cxio_hal.c
@@ -0,0 +1,1306 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include asm/semaphore.h
+#include asm/delay.h
+
+#include linux/netdevice.h
+#include linux/sched.h
+#include linux/spinlock.h
+#include linux/pci.h
+
+#include cxio_resource.h
+#include cxio_hal.h
+#include cxgb3_offload.h
+#include sge_defs.h
+
+static struct cxio_rdev *rdev_tbl[T3_MAX_NUM_RNIC];
+static cxio_hal_ev_callback_func_t cxio_ev_cb = NULL;
+
+static inline struct cxio_rdev *cxio_hal_find_rdev_by_name(char *dev_name)
+{
+ int i;
+ for (i = 0; i T3_MAX_NUM_RNIC; i++)
+ if (rdev_tbl[i])
+ if (!strcmp(rdev_tbl[i]-dev_name, dev_name))
+ return rdev_tbl[i];
+ return NULL;
+}
+
+static inline struct cxio_rdev *cxio_hal_find_rdev_by_t3cdev(struct t3cdev
+*tdev)
+{
+ int i;
+ for (i = 0; i T3_MAX_NUM_RNIC; i++)
+ if (rdev_tbl[i])
+ if (rdev_tbl[i]-t3cdev_p == tdev)
+ return rdev_tbl[i];
+ return NULL;
+}
+
+static inline int cxio_hal_add_rdev(struct cxio_rdev *rdev_p)
+{
+ int i;
+ for (i = 0; i T3_MAX_NUM_RNIC; i++) {
+ if (!rdev_tbl[i]) {
+ rdev_tbl[i] = rdev_p;
+ break;
+ }
+ }
+ return (i == T3_MAX_NUM_RNIC);
+}
+
+static inline void cxio_hal_delete_rdev(struct cxio_rdev *rdev_p)
+{
+ int i;
+ for (i = 0; i T3_MAX_NUM_RNIC; i++)
+ if (rdev_tbl[i] == rdev_p) {
+ rdev_tbl[i] = NULL;
+ break;
+ }
+}
+
+int cxio_hal_cq_op(struct cxio_rdev *rdev_p, struct t3_cq *cq,
+ enum t3_cq_opcode op, u32 credit)
+{
+ int ret;
+ struct t3_cqe *cqe;
+ u32 rptr;
+
+ struct rdma_cq_op setup;
+ setup.id = cq-cqid;
+ setup.credits = (op == CQ_CREDIT_UPDATE) ? credit : 0;
+ setup.op = op;
+ ret = rdev_p-t3cdev_p-ctl(rdev_p-t3cdev_p, RDMA_CQ_OP, setup);
+
+ if ((ret 0) || (op == CQ_CREDIT_UPDATE))
+ return ret;
+
+ /*
+* If the rearm returned an index other than our current index,
+* then there might be CQE's in flight (being DMA'd). We must wait
+* here for them to complete or the consumer can miss a notification.
+*/
+ if (Q_PTR2IDX((cq-rptr), cq-size_log2) != ret) {
+ int i=0;
+
+ rptr = cq-rptr;
+
+ /*
+* Keep the generation correct by bumping rptr until it
+* matches the index returned by the rearm - 1.
+*/
+ while (Q_PTR2IDX((rptr+1), cq-size_log2) != ret)
+ rptr++;
+
+ /*
+* Now rptr is the index for the (last) cqe that was
+* in-flight at the time the HW rearmed
[PATCH 07/13] Async Event Handler
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 | 228 +
1 files changed, 228 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_ev.c
b/drivers/infiniband/hw/cxgb3/iwch_ev.c
new file mode 100644
index 000..0726fa6
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch_ev.c
@@ -0,0 +1,228 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include linux/slab.h
+#include linux/mman.h
+#include net/sock.h
+#include iwch_provider.h
+#include iwch.h
+#include iwch_cm.h
+#include cxio_hal.h
+#include cxio_wr.h
+
+static void post_qp_event(struct iwch_dev *rnicp, struct iwch_cq *chp,
+ struct respQ_msg_t *rsp_msg,
+ enum ib_event_type ib_event,
+ int send_term)
+{
+ struct ib_event event;
+ struct iwch_qp_attributes attrs;
+ struct iwch_qp *qhp;
+
+ printk(KERN_ERR %s - AE qpid 0x%x opcode %d status 0x%x
+ type %d wrid.hi 0x%x wrid.lo 0x%x \n, __FUNCTION__,
+ CQE_QPID(rsp_msg-cqe), CQE_OPCODE(rsp_msg-cqe),
+ CQE_STATUS(rsp_msg-cqe), CQE_TYPE(rsp_msg-cqe),
+ CQE_WRID_HI(rsp_msg-cqe), CQE_WRID_LOW(rsp_msg-cqe));
+
+ spin_lock(rnicp-lock);
+ qhp = rnicp-qpid2ptr[CQE_QPID(rsp_msg-cqe)];
+
+ if (!qhp) {
+ printk(KERN_ERR %s unaffiliated error 0x%x qpid 0x%x\n,
+ __FUNCTION__, CQE_STATUS(rsp_msg-cqe),
+ CQE_QPID(rsp_msg-cqe));
+ spin_unlock(rnicp-lock);
+ return;
+ }
+
+ if ((qhp-attr.state == IWCH_QP_STATE_ERROR) ||
+ (qhp-attr.state == IWCH_QP_STATE_TERMINATE)) {
+ PDBG(%s AE received after RTS -
+qp state %d qpid 0x%x status 0x%x\n, __FUNCTION__,
+qhp-attr.state, qhp-wq.qpid, CQE_STATUS(rsp_msg-cqe));
+ spin_unlock(rnicp-lock);
+ return;
+ }
+
+ atomic_inc(qhp-refcnt);
+ spin_unlock(rnicp-lock);
+
+ event.event = ib_event;
+ event.device = chp-ibcq.device;
+ if (ib_event == IB_EVENT_CQ_ERR)
+ event.element.cq = chp-ibcq;
+ else
+ event.element.qp = qhp-ibqp;
+
+ if (qhp-ibqp.event_handler)
+ (*qhp-ibqp.event_handler)(event, qhp-ibqp.qp_context);
+
+ attrs.next_state = IWCH_QP_STATE_TERMINATE;
+ if (send_term (qhp-attr.state == IWCH_QP_STATE_RTS)
+ !iwch_modify_qp(qhp-rhp, qhp, IWCH_QP_ATTR_NEXT_STATE, attrs, 1))
+ iwch_post_terminate(qhp, rsp_msg);
+
+ if (atomic_dec_and_test(qhp-refcnt))
+ wake_up(qhp-wait);
+}
+
+void iwch_ev_dispatch(struct cxio_rdev *rdev_p, struct sk_buff *skb)
+{
+ struct iwch_dev *rnicp;
+ struct respQ_msg_t *rsp_msg = (struct respQ_msg_t *) skb-data;
+ struct iwch_cq *chp;
+ struct iwch_qp *qhp;
+ u32 cqid = RSPQ_CQID(rsp_msg);
+
+ rnicp = (struct iwch_dev *) rdev_p-ulp;
+ spin_lock(rnicp-lock);
+ chp = rnicp-cqid2ptr[cqid];
+ qhp = rnicp-qpid2ptr[CQE_QPID(rsp_msg-cqe)];
+ if (!chp || !qhp) {
+ printk(KERN_ERR MOD BAD AE cqid 0x%x qpid 0x%x opcode %d
+ status 0x%x type %d wrid.hi 0x%x wrid.lo 0x%x \n,
+ cqid, CQE_QPID(rsp_msg-cqe),
+
Re: 2.6.19-rc5-mm2 -- bcm43xx busted (backing out the bcm43xx patches fixes it)
Rafael J. Wysocki wrote:
On Wednesday, 15 November 2006 00:21, Miles Lane wrote:
Hello,
The last three MM kernels have fail to give me a working bcm43xx driver.
The odd thing is that dmesg output seems to indicate that the driver
is working okay. NetworkManager doesn't see the driver, though.
iwlist scan fails to find any access points, too. iwconfig shows
Access Point: invalid.
I can confirm the symptoms, I see them too on my test boxes.
I tried backing out the following patches, and it fixes the problem:
drivers/net/wireless/bcm43xx/bcm43xx.h
drivers/net/wireless/bcm43xx/bcm43xx_main.c
drivers/net/wireless/bcm43xx/bcm43xx_power.c
drivers/net/wireless/bcm43xx/bcm43xx_wx.c
drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
The missing patch is shown below. This patch was entitled [PATCH] bcm43xx:
Readd dropped
assignment and submitted to wireless-2.6 by Daniel Drake on 10/17/06, but it
seems to have fallen
through the cracks. It is a fix to a patch entitled [PATCH] ieee80211: Move
IV/ICV stripping into
ieee80211_rx also submitted by Daniel Drake on 9/26/2006.
NOTE to maintainers: This problem affects BOTH wireless-2.6 and 2.6.19-rcX-mmY.
At present, the
Move IV/ICV patch has not been incorporated into 2.6.19-rcX and it is OK.
Larry
In the patch sent by Daniel Drake under the title [PATCH] ieee80211: Move
IV/ICV stripping into ieee80211_rx, a needed line was accidentally removed.
As my current copy of wireless-2.6.git does not contain this line, I am
(re)submitting a patch to restore that line.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
@@ -543,6 +543,7 @@ int bcm43xx_rx(struct bcm43xx_private *b
break;
}
+ frame_ctl = le16_to_cpu(wlhdr-frame_ctl);
switch (WLAN_FC_GET_TYPE(frame_ctl)) {
case IEEE80211_FTYPE_MGMT:
ieee80211_rx_mgt(bcm-ieee, wlhdr, stats);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bcm43xx regression 2.6.19rc3 - rc5, rtnl_lock trouble?
Ray Lee wrote: Michael Buesch wrote: On Wednesday 15 November 2006 20:01, Ray Lee wrote: Suggestions? Requests for shudder even more info? Yeah, enable bcm43xx debugging. Sigh, didn't even think to look for that. Okay, enabled and compiling a new kernel. This will take a few days to trigger, if the pattern holds, so in the meantime, any *other* thoughts? Which chip and revision do you have? Send me your equivalent of the line bcm43xx: Chip ID 0x4306, rev 0x2. Thanks, Larry - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.19-rc5-mm2 -- bcm43xx busted (backing out the bcm43xx patches fixes it)
On 11/15/06, Larry Finger [EMAIL PROTECTED] wrote:
Rafael J. Wysocki wrote:
On Wednesday, 15 November 2006 00:21, Miles Lane wrote:
Hello,
The last three MM kernels have fail to give me a working bcm43xx driver.
The odd thing is that dmesg output seems to indicate that the driver
is working okay. NetworkManager doesn't see the driver, though.
iwlist scan fails to find any access points, too. iwconfig shows
Access Point: invalid.
I can confirm the symptoms, I see them too on my test boxes.
I tried backing out the following patches, and it fixes the problem:
drivers/net/wireless/bcm43xx/bcm43xx.h
drivers/net/wireless/bcm43xx/bcm43xx_main.c
drivers/net/wireless/bcm43xx/bcm43xx_power.c
drivers/net/wireless/bcm43xx/bcm43xx_wx.c
drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
The missing patch is shown below. This patch was entitled [PATCH] bcm43xx:
Readd dropped
assignment and submitted to wireless-2.6 by Daniel Drake on 10/17/06, but it
seems to have fallen
through the cracks. It is a fix to a patch entitled [PATCH] ieee80211: Move
IV/ICV stripping into
ieee80211_rx also submitted by Daniel Drake on 9/26/2006.
NOTE to maintainers: This problem affects BOTH wireless-2.6 and 2.6.19-rcX-mmY.
At present, the
Move IV/ICV patch has not been incorporated into 2.6.19-rcX and it is OK.
Larry
In the patch sent by Daniel Drake under the title [PATCH] ieee80211: Move
IV/ICV stripping into ieee80211_rx, a needed line was accidentally removed.
As my current copy of wireless-2.6.git does not contain this line, I am
(re)submitting a patch to restore that line.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
@@ -543,6 +543,7 @@ int bcm43xx_rx(struct bcm43xx_private *b
break;
}
+ frame_ctl = le16_to_cpu(wlhdr-frame_ctl);
switch (WLAN_FC_GET_TYPE(frame_ctl)) {
case IEEE80211_FTYPE_MGMT:
ieee80211_rx_mgt(bcm-ieee, wlhdr, stats);
Thanks! I have verified that this patch solves the problem for me.
Miles
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bcm43xx regression 2.6.19rc3 - rc5, rtnl_lock trouble?
Larry Finger wrote:
Ray Lee wrote:
Michael Buesch wrote:
On Wednesday 15 November 2006 20:01, Ray Lee wrote:
Suggestions? Requests for shudder even more info?
Yeah, enable bcm43xx debugging.
Sigh, didn't even think to look for that. Okay, enabled and compiling
a new kernel. This will take a few days to trigger, if the pattern holds, so
in the meantime, any *other* thoughts?
Which chip and revision do you have? Send me your equivalent of the line
bcm43xx: Chip ID 0x4306, rev 0x2.
bcm43xx: Chip ID 0x4306, rev 0x3
Also, another thing I wasn't clear about in my first email was that the netdev
watchdog timeouts are new with rc5:
$ zgrep 'NETDEV WATCH' /var/log/messages{,.0,.1.gz} | cut -d: -f2| cut -c 1-6
| uniq -c
1249 Nov 13
6 Nov 6
1 Nov 7
3 Nov 8
2 Nov 9
5717 Nov 10
5652 Nov 11
5 Oct 29
3 Oct 30
3 Oct 31
4 Nov 1
1 Nov 2
1 Nov 3
I booted into 2.6.19-rc5 on November 10th. Previous to that was 2.6.19-rc3.
There really does seem to be something suspicious with that patch, yes?
Thanks,
Ray
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
