Re: Network drivers that don't suspend on interface down

2006-12-20 Thread Stephen Hemminger

David Brownell wrote:

Hmm, this reminds me of a thread from last summer, following up on
some PM discussions at OLS.  Thread "Runtime power management for
network interfaces", at the end of July.


  

2) Network device infrastructure should make it easier for devices:
bring interface down on suspend and bring it up after resume
(if it was running when suspended). This would allow many devices to
have no suspend/resume hook; except those that have some better power
control over hardware.



The _intent_ of the class suspend() and resume() methods is to let
infrastructure (the network stack was explicitly mentioned!) handle
pretty much everything except putting the hardware in low power
modes ... which last step might, for PCI devices at least, most
naturally be done in suspend_late().  That way it'd be decoupled
cleanly from anything else.
  
The class methods don't work right for that because the physical class 
(PCI) gets

called before the virtual class  (network devices).


Now, I recently tried refreshing a patch that used those class
suspend() and resume() methods, and for some reason they're not
getting called.  I believe they used to get called, although it's
true their parameter wasn't very useful ... it was called with the
underlying device, not the class_device holding state that the
class driver manages.

I just wanted to point out that yes, this ground has been covered
before, with some agreement on that approach.  It'd be good to see
it pursued.  :)

- Dave

  


-
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] eeprom_93cx6: Add write support

2006-12-20 Thread Ivo Van Doorn

Hi,


This patch addes support for writing to the eeprom,
this also moves some duplicate code into seperate functions.


John: Do you want me to merge this path with the eeprom merge patch,
and move the patch that moves rt2x00 to use this eeprom module into a
separate patch or all these 2 patches good enough?

Ivo
-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread David Brownell
Hmm, this reminds me of a thread from last summer, following up on
some PM discussions at OLS.  Thread "Runtime power management for
network interfaces", at the end of July.


> 2) Network device infrastructure should make it easier for devices:
> bring interface down on suspend and bring it up after resume
> (if it was running when suspended). This would allow many devices to
> have no suspend/resume hook; except those that have some better power
> control over hardware.

The _intent_ of the class suspend() and resume() methods is to let
infrastructure (the network stack was explicitly mentioned!) handle
pretty much everything except putting the hardware in low power
modes ... which last step might, for PCI devices at least, most
naturally be done in suspend_late().  That way it'd be decoupled
cleanly from anything else.

Now, I recently tried refreshing a patch that used those class
suspend() and resume() methods, and for some reason they're not
getting called.  I believe they used to get called, although it's
true their parameter wasn't very useful ... it was called with the
underlying device, not the class_device holding state that the
class driver manages.

I just wanted to point out that yes, this ground has been covered
before, with some agreement on that approach.  It'd be good to see
it pursued.  :)

- Dave

-
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.6.20-rc1 05/10] if_fddi.h: Add a missing inclusion

2006-12-20 Thread Andrew Morton
On Wed, 20 Dec 2006 12:01:55 + (GMT)
"Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote:

>  This is a change to include  in  
> which is needed for "struct fddi_statistics".
> 
> Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]>
> ---
> 
>  Please apply.
> 
>   Maciej
> 
> patch-mips-2.6.18-20060920-if_fddi-netdev-0
> diff -up --recursive --new-file 
> linux-mips-2.6.18-20060920.macro/include/linux/if_fddi.h 
> linux-mips-2.6.18-20060920/include/linux/if_fddi.h
> --- linux-mips-2.6.18-20060920.macro/include/linux/if_fddi.h  2006-09-20 
> 20:51:20.0 +
> +++ linux-mips-2.6.18-20060920/include/linux/if_fddi.h2006-12-14 
> 04:36:58.0 +
> @@ -103,6 +103,8 @@ struct fddihdr
>   } __attribute__ ((packed));
>  
>  #ifdef __KERNEL__
> +#include 
> +
>  /* Define FDDI statistics structure */
>  struct fddi_statistics {
>  

I'll treat this a a bugfix, unrelated to the turbochannel changes.

Which may be wrong, but I doubt it.
-
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.6.20-rc1 01/10] TURBOchannel update to the driver model

2006-12-20 Thread Andrew Morton
On Wed, 20 Dec 2006 12:01:30 + (GMT)
"Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote:

> +/**
> + * tc_register_driver - register a new TC driver
> + * @drv: the driver structure to register
> + *
> + * Adds the driver structure to the list of registered drivers
> + * Returns a negative value on error, otherwise 0.
> + * If no error occurred, the driver remains registered even if
> + * no device was claimed during registration.
> + */
> +int tc_register_driver(struct tc_driver *tdrv)
> +{
> + return driver_register(&tdrv->driver);
> +}
> +EXPORT_SYMBOL(tc_register_driver);
> +
> +/**
> + * tc_unregister_driver - unregister a TC driver
> + * @drv: the driver structure to unregister
> + *
> + * Deletes the driver structure from the list of registered TC drivers,
> + * gives it a chance to clean up by calling its remove() function for
> + * each device it was responsible for, and marks those devices as
> + * driverless.
> + */
> +void tc_unregister_driver(struct tc_driver *tdrv)
> +{
> + driver_unregister(&tdrv->driver);
> +}
> +EXPORT_SYMBOL(tc_unregister_driver);

I spose making these inline would save a bit of code, stack space and 
a couple of exports.
-
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.6.20-rc1 03/10] defxx: TURBOchannel support

2006-12-20 Thread Andrew Morton
On Wed, 20 Dec 2006 12:01:42 + (GMT)
"Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote:

> 
>  This is a set of changes to add TURBOchannel support to the defxx driver.  

my, what a lot of rejects.

> patch-mips-2.6.18-20060920-defta-69

2.6.18?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Please pull 'upstream-fixes' branch of wireless-2.6

2006-12-20 Thread John W. Linville
The following changes since commit e25db641c0e6dd49c5db24dbe154048d4a466727:
  Linus Torvalds (1):
Merge master.kernel.org:/.../davej/cpufreq

are found in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git 
upstream-fixes

Ulrich Kunitz (3):
  zd1211rw: Call ieee80211_rx in tasklet
  ieee80211softmac: Fix errors related to the work_struct changes
  ieee80211softmac: Fix mutex_lock at exit of ieee80211_softmac_get_genie

 drivers/net/wireless/zd1211rw/zd_mac.c |   96 +---
 drivers/net/wireless/zd1211rw/zd_mac.h |5 +-
 drivers/net/wireless/zd1211rw/zd_usb.c |4 +-
 net/ieee80211/softmac/ieee80211softmac_assoc.c |4 +-
 net/ieee80211/softmac/ieee80211softmac_wx.c|2 +-
 5 files changed, 79 insertions(+), 32 deletions(-)

diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c 
b/drivers/net/wireless/zd1211rw/zd_mac.c
index 00ca704..a085241 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -41,6 +41,8 @@ static void housekeeping_disable(struct zd_mac *mac);
 
 static void set_multicast_hash_handler(struct work_struct *work);
 
+static void do_rx(unsigned long mac_ptr);
+
 int zd_mac_init(struct zd_mac *mac,
struct net_device *netdev,
struct usb_interface *intf)
@@ -53,6 +55,10 @@ int zd_mac_init(struct zd_mac *mac,
INIT_DELAYED_WORK(&mac->set_rts_cts_work, set_rts_cts_work);
INIT_DELAYED_WORK(&mac->set_basic_rates_work, set_basic_rates_work);
 
+   skb_queue_head_init(&mac->rx_queue);
+   tasklet_init(&mac->rx_tasklet, do_rx, (unsigned long)mac);
+   tasklet_disable(&mac->rx_tasklet);
+
ieee_init(ieee);
softmac_init(ieee80211_priv(netdev));
zd_chip_init(&mac->chip, netdev, intf);
@@ -140,6 +146,8 @@ out:
 void zd_mac_clear(struct zd_mac *mac)
 {
flush_workqueue(zd_workqueue);
+   skb_queue_purge(&mac->rx_queue);
+   tasklet_kill(&mac->rx_tasklet);
zd_chip_clear(&mac->chip);
ZD_ASSERT(!spin_is_locked(&mac->lock));
ZD_MEMCLEAR(mac, sizeof(struct zd_mac));
@@ -168,6 +176,8 @@ int zd_mac_open(struct net_device *netdev)
struct zd_chip *chip = &mac->chip;
int r;
 
+   tasklet_enable(&mac->rx_tasklet);
+
r = zd_chip_enable_int(chip);
if (r < 0)
goto out;
@@ -218,6 +228,8 @@ int zd_mac_stop(struct net_device *netdev)
 */
 
zd_chip_disable_rx(chip);
+   skb_queue_purge(&mac->rx_queue);
+   tasklet_disable(&mac->rx_tasklet);
housekeeping_disable(mac);
ieee80211softmac_stop(netdev);
 
@@ -470,13 +482,13 @@ static void bssinfo_change(struct net_device *netdev, u32 
changes)
 
if (changes & IEEE80211SOFTMAC_BSSINFOCHG_RATES) {
/* Set RTS rate to highest available basic rate */
-   u8 rate = ieee80211softmac_highest_supported_rate(softmac,
+   u8 hi_rate = ieee80211softmac_highest_supported_rate(softmac,
&bssinfo->supported_rates, 1);
-   rate = rate_to_zd_rate(rate);
+   hi_rate = rate_to_zd_rate(hi_rate);
 
spin_lock_irqsave(&mac->lock, flags);
-   if (rate != mac->rts_rate) {
-   mac->rts_rate = rate;
+   if (hi_rate != mac->rts_rate) {
+   mac->rts_rate = hi_rate;
need_set_rts_cts = 1;
}
spin_unlock_irqrestore(&mac->lock, flags);
@@ -1072,43 +1084,75 @@ static int fill_rx_stats(struct ieee80211_rx_stats 
*stats,
return 0;
 }
 
-int zd_mac_rx(struct zd_mac *mac, const u8 *buffer, unsigned int length)
+static void zd_mac_rx(struct zd_mac *mac, struct sk_buff *skb)
 {
int r;
struct ieee80211_device *ieee = zd_mac_to_ieee80211(mac);
struct ieee80211_rx_stats stats;
const struct rx_status *status;
-   struct sk_buff *skb;
 
-   if (length < ZD_PLCP_HEADER_SIZE + IEEE80211_1ADDR_LEN +
-IEEE80211_FCS_LEN + sizeof(struct rx_status))
-   return -EINVAL;
+   if (skb->len < ZD_PLCP_HEADER_SIZE + IEEE80211_1ADDR_LEN +
+  IEEE80211_FCS_LEN + sizeof(struct rx_status))
+   {
+   dev_dbg_f(zd_mac_dev(mac), "Packet with length %u to small.\n",
+skb->len);
+   goto free_skb;
+   }
 
-   r = fill_rx_stats(&stats, &status, mac, buffer, length);
-   if (r)
-   return r;
+   r = fill_rx_stats(&stats, &status, mac, skb->data, skb->len);
+   if (r) {
+   /* Only packets with rx errors are included here. */
+   goto free_skb;
+   }
 
-   length -= ZD_PLCP_HEADER_SIZE+IEEE80211_FCS_LEN+
- sizeof(struct rx_status);
-   buffer += ZD_PLCP_HEADER_SIZE;
+   __skb_pull(skb, ZD_PLCP_HEADER_SIZE);
+

Please pull 'upstream' branch of wireless-2.6

2006-12-20 Thread John W. Linville
The following changes since commit 0c234ae655a45ac3ee53a25b2e56e9bb6c27d71d:
  Ulrich Kunitz (1):
ieee80211softmac: Fix mutex_lock at exit of ieee80211_softmac_get_genie

are found in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git 
upstream

Roy Marples (1):
  prism54: set carrier flags correctly

 drivers/net/wireless/prism54/isl_ioctl.c  |5 -
 drivers/net/wireless/prism54/islpci_dev.c |4 +++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/prism54/isl_ioctl.c 
b/drivers/net/wireless/prism54/isl_ioctl.c
index 838d510..25d42ac 100644
--- a/drivers/net/wireless/prism54/isl_ioctl.c
+++ b/drivers/net/wireless/prism54/isl_ioctl.c
@@ -2093,8 +2093,11 @@ link_changed(struct net_device *ndev, u32 bitrate)
} else
send_simple_event(netdev_priv(ndev),
  "Link established");
-   } else
+   netif_carrier_on(ndev);
+   } else {
send_simple_event(netdev_priv(ndev), "Link lost");
+   netif_carrier_off(ndev);
+   }
 }
 
 /* Beacon/ProbeResp payload header */
diff --git a/drivers/net/wireless/prism54/islpci_dev.c 
b/drivers/net/wireless/prism54/islpci_dev.c
index f057fd9..9c8c6f2 100644
--- a/drivers/net/wireless/prism54/islpci_dev.c
+++ b/drivers/net/wireless/prism54/islpci_dev.c
@@ -386,7 +386,9 @@ islpci_open(struct net_device *ndev)
}
 
netif_start_queue(ndev);
-/*  netif_mark_up( ndev ); */
+
+   /* Turn off carrier unless we know we have associated */
+   netif_carrier_off(ndev);
 
return 0;
 }
-- 
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Dan Williams
On Thu, 2006-12-21 at 03:25 +, Matthew Garrett wrote:
> On Wed, Dec 20, 2006 at 10:08:22PM -0500, Daniel Drake wrote:
> > Matthew Garrett wrote:
> > >Hm. Does the spec not set any upper bound on how long it might take for 
> > >APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. 
> > 
> > I'm not sure, but thats not entirely relevant either.  The time it takes 
> > for the AP to respond is not related to the delay between userspace 
> > sending the siwscan and giwscan ioctls (unless you're thinking of 
> > userspace being too quick, but GIWSCAN already returns -EINPROGRESS when 
> > appropriate so this is detectable)
> 
> Ah - I've mostly been looking at the ipw* drivers, where giwscan just 
> seems to return information cached by the ieee80211 layer. A quick scan 
> suggests that most cards behave like this, but prism54 seems to refer to 
> the hardware. I can see why that would cause problems.

Prism54 (fullmac) does background scanning all the time when the
interface is up.  You can't turn it off AFAIK.  If you look at SIWSCAN,
you'll see that it's essentially a NOP since the firmware is always
scanning, and you'll always have up-to-date scan results.  Ideally, all
drivers would do it like prism54 does (and some later ipw versions, I
think).

Dan

> 
> > I think it's reasonable to keep the interface down, but then when the 
> > user does want to connect, bring the interface up, scan, present scan 
> > results. Scanning is quick, there would be minimal wait needed here.
> 
> Yeah, that's true.
> 

-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Dan Williams
On Thu, 2006-12-21 at 03:14 +, Matthew Garrett wrote:
> On Wed, Dec 20, 2006 at 10:06:51PM -0500, Dan Williams wrote:
> 
> > a) tied to the wireless hardware, switch kills hardware directly
> > b) tied to wireless hardware, but driver handles the kill request
> > c) just another key, a separate key driver handles the event and asks
> > the wireless driver to kill the card
> > 
> > It's also complicated because some switches are supposed to rfkill both
> > an 802.11 module _and_ a bluetooth module at the same time, or I guess
> > some laptops may even have one rfkill switch for each wireless device.
> > Furthermore, some people want to 'softkill' the hardware via software
> > without pushing the key, which is a subset of (b) or (c) above.
> 
> If we define interface down as meaning that the device is powered down 
> and the radio switched off, then (b) and (c) would presumably just need 
> to ensure that the interface is downed. (a) is a slightly more special 
> case - if the switch disables the radio, I guess we then want the driver 
> to down the interface as well.

Correct.

> In the (a) case, drivers should presumably refuse to bring the interface 
> up if the radio is disabled?

Right; the driver simply can't do anything about it, because the switch
is hardwired to the card and either the card's firmware takes care of
it, or the chipset takes care of it.  The driver has no say whatsoever
in the state of the card's radio for this case.  I tend to think this
case is on it's way out in the same way that fullmac cards are falling
out of favor (ie, do everything in software and save $$$), but they are
around and we need to support them.

In this case, down really does mean down too.  The driver cannot honor
requests to set SSID, frequency, etc, because it's simply not possible
at that time.

Dan


-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Dan Williams
On Wed, 2006-12-20 at 22:08 -0500, Daniel Drake wrote:
> Matthew Garrett wrote:
> >> There are additional implementation problems: scanning requires 2 
> >> different ioctl calls: siwscan, then several giwscan. If you want the 
> >> driver to effectively temporarily bring the interface up when userspace 
> >> requests a scan but the interface was down, then how does the driver 
> >> know when to bring it down again?
> > 
> > Hm. Does the spec not set any upper bound on how long it might take for 
> > APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. 
> 
> I'm not sure, but thats not entirely relevant either.  The time it takes 
> for the AP to respond is not related to the delay between userspace 
> sending the siwscan and giwscan ioctls (unless you're thinking of 
> userspace being too quick, but GIWSCAN already returns -EINPROGRESS when 
> appropriate so this is detectable)

Channel dwell time for a passive scan is usually around 100ms - 250ms,
depending on how accurate you want your scan results (== wait longer),
and how much power you want to save (== don't wait long).

Correct userspace apps should:

1) Set a timer for, say, 8 seconds
2) Issue an SIWSCAN command
3) Wait for the GIWSCAN netlink event from the card, get results via
GIWSCAN command when it comes; cancel the timer from (2)
4) If the timer fires because no GIWSCAN event was received, try to get
scan results via GIWSCAN command from the driver anyway


Note that NDIS requires a driver to return _something_ within 2 seconds
of a scan request.  Even if you're an 802.11a card (madwifi *cough*, I'm
starting a new thing where I cough after...).  So it's certainly
possible to return scan results in a timely manner, since the Windows
drivers for these cards are obviously doing it just fine.

Drivers should buffer scan results from past scans, age them
appropriately, and purge them when they get too old.  Drivers should
never, ever, clear the scan result list when SIWSCAN or GIWSCAN is
called, because that means there's a window when a scan result request
from some other app could illegitimately return no BSSID records.


> > Picking a number out of thin air would be one answer, but clearly less 
> > than ideal. This may be a case of us not being able to satisfy everyone, 
> > and so just having to force the user to choose between low power or 
> > wireless scanning.
> 
> I think it's reasonable to keep the interface down, but then when the 
> user does want to connect, bring the interface up, scan, present scan 
> results. Scanning is quick, there would be minimal wait needed here.

Unless you're madwifi *cough* and then you may have to wait up to _14_
seconds for a full scan of all a/bg channels.  That's just insane.  I
have no idea why that's the case (or at least was up to earlier this
year) but it's just unacceptable.

> Alternatively, if you do want to prepare scan results in the background 
> every 2 minutes, use a sequence something like:
> 
> - bring interface up
> - siwscan
> - giwscan [...]
> - bring interface down
> - repeat after 2 mins
> 
> If this kind of thing was implemented at the driver level, in most cases 
> it would be identical to doing the above anyway.

Right.  It should 100% be in userspace and not in the drivers.  Who says
2 minutes is the right interval?  Putting that stuff, and the get/set
commands for changing that interval, in the driver is just plain wrong.

Dan

> Daniel
> -
> 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

-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Matthew Garrett
On Wed, Dec 20, 2006 at 10:08:22PM -0500, Daniel Drake wrote:
> Matthew Garrett wrote:
> >Hm. Does the spec not set any upper bound on how long it might take for 
> >APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. 
> 
> I'm not sure, but thats not entirely relevant either.  The time it takes 
> for the AP to respond is not related to the delay between userspace 
> sending the siwscan and giwscan ioctls (unless you're thinking of 
> userspace being too quick, but GIWSCAN already returns -EINPROGRESS when 
> appropriate so this is detectable)

Ah - I've mostly been looking at the ipw* drivers, where giwscan just 
seems to return information cached by the ieee80211 layer. A quick scan 
suggests that most cards behave like this, but prism54 seems to refer to 
the hardware. I can see why that would cause problems.

> I think it's reasonable to keep the interface down, but then when the 
> user does want to connect, bring the interface up, scan, present scan 
> results. Scanning is quick, there would be minimal wait needed here.

Yeah, that's true.

-- 
Matthew Garrett | [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: Network drivers that don't suspend on interface down

2006-12-20 Thread Matthew Garrett
On Wed, Dec 20, 2006 at 10:06:51PM -0500, Dan Williams wrote:

> a) tied to the wireless hardware, switch kills hardware directly
> b) tied to wireless hardware, but driver handles the kill request
> c) just another key, a separate key driver handles the event and asks
> the wireless driver to kill the card
> 
> It's also complicated because some switches are supposed to rfkill both
> an 802.11 module _and_ a bluetooth module at the same time, or I guess
> some laptops may even have one rfkill switch for each wireless device.
> Furthermore, some people want to 'softkill' the hardware via software
> without pushing the key, which is a subset of (b) or (c) above.

If we define interface down as meaning that the device is powered down 
and the radio switched off, then (b) and (c) would presumably just need 
to ensure that the interface is downed. (a) is a slightly more special 
case - if the switch disables the radio, I guess we then want the driver 
to down the interface as well.

In the (a) case, drivers should presumably refuse to bring the interface 
up if the radio is disabled?
-- 
Matthew Garrett | [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: Network drivers that don't suspend on interface down

2006-12-20 Thread Dan Williams
On Thu, 2006-12-21 at 02:18 +, Matthew Garrett wrote:
> On Wed, Dec 20, 2006 at 09:05:27PM -0500, Michael Wu wrote:
> 
> > Softmac isn't the only wireless code that likes to be configured after 
> > going 
> > up first. Configuring after the card goes up has generally been more 
> > reliable, though that should not be necessary and is a bug IMHO. 
> 
> Ok, that's nice to know. 
> 
> > In order to scan, we need to have the radio on and we need to be able to 
> > send 
> > and receive. What are you gonna turn off?
> 
> The obvious route would be to power the card down, but come back up 
> every two minutes to perform a scan, or if userspace explicitly requests 
> one. Would this cause problems in some cases?

Seriously, having all these different capabilities when the card is
"down" is just madness.  Down == Down!!!  Furthermore, every card is
going to support some other subset of capabilities when it's "down".
When you bring "up" prism54 fullmac card, you have to power up the
hardware, reload the firmware, let the firmware boot, and then talk to
it.  Doing that every 2 minutes is just a waste of time, effort, and
power.

If you want to scan, just bring the darn card up to do it.  It's so much
simpler that way, and I just don't see what having all this "every 2
minutes do a scan" policy really buys us.  That doesn't belong in the
kernel.  If something wants to scan, userspace can wake the card up and
do the scan.  It's userspace that's using the scan results to configure
the card anyway, so userspace can do the scan.

Simple == good.  Down == down.  Lets just agree on that and save
ourselves a lot of pain.

Dan


-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Daniel Drake

Matthew Garrett wrote:
There are additional implementation problems: scanning requires 2 
different ioctl calls: siwscan, then several giwscan. If you want the 
driver to effectively temporarily bring the interface up when userspace 
requests a scan but the interface was down, then how does the driver 
know when to bring it down again?


Hm. Does the spec not set any upper bound on how long it might take for 
APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. 


I'm not sure, but thats not entirely relevant either.  The time it takes 
for the AP to respond is not related to the delay between userspace 
sending the siwscan and giwscan ioctls (unless you're thinking of 
userspace being too quick, but GIWSCAN already returns -EINPROGRESS when 
appropriate so this is detectable)


Picking a number out of thin air would be one answer, but clearly less 
than ideal. This may be a case of us not being able to satisfy everyone, 
and so just having to force the user to choose between low power or 
wireless scanning.


I think it's reasonable to keep the interface down, but then when the 
user does want to connect, bring the interface up, scan, present scan 
results. Scanning is quick, there would be minimal wait needed here.


Alternatively, if you do want to prepare scan results in the background 
every 2 minutes, use a sequence something like:


- bring interface up
- siwscan
- giwscan [...]
- bring interface down
- repeat after 2 mins

If this kind of thing was implemented at the driver level, in most cases 
it would be identical to doing the above anyway.


Daniel
-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Dan Williams
On Thu, 2006-12-21 at 01:15 +, Matthew Garrett wrote:
> On Wed, Dec 20, 2006 at 01:12:51PM -0500, Dan Williams wrote:
> 
> > Entirely correct.  If the card is DOWN, the radio should be off (both TX
> > & RX) and it should be in max power save mode.  If userspace expects to
> > be able to get the card to do _anything_ when it's down, that's just
> > 110% wrong.  You can't get link events for many wired cards when they
> > are down, so I fail to see where userspace could expect to do anything
> > with a wireless card when it's down too.
> 
> Because it works on the common hardware? If there's documentation about 
> what userspace can legitimately expect, then I'm happy to defer to that. 
> But in the absence of any indication as to what functionality users can 
> depend on, deciding that existing functionality is a bug is, well, 
> impolite.
> 
> > Also, how does rfkill fit into this?  rfkill implies killing TX, but do
> > we have the granularity to still receive while the transmit paths are
> > powered down?
> 
> Is rfkill not just primarily an interface for us getting events when the 
> radio changes state? Every time I read up on it I get a little more 
> confused - some time I really need to make sense of it...

That's OK, it's really complicated.  There are 3 cases of rfkill
switches AFAICT:

a) tied to the wireless hardware, switch kills hardware directly
b) tied to wireless hardware, but driver handles the kill request
c) just another key, a separate key driver handles the event and asks
the wireless driver to kill the card

It's also complicated because some switches are supposed to rfkill both
an 802.11 module _and_ a bluetooth module at the same time, or I guess
some laptops may even have one rfkill switch for each wireless device.
Furthermore, some people want to 'softkill' the hardware via software
without pushing the key, which is a subset of (b) or (c) above.

It sucks.  But we _need_ a unified interface to handle it.

Dan


-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Dan Williams
On Thu, 2006-12-21 at 02:20 +, Matthew Garrett wrote:
> On Wed, Dec 20, 2006 at 08:57:05PM -0500, Michael Wu wrote:
> 
> (allowing scanning while the interface is down)
> 
> > No, it's absolutely a bug. It just so happens that some drivers incorrectly 
> > allowed it.
> 
> Ok. Would it be reasonable to add warnings to any devices that allow it?

Quite reasonable.

Dan


-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Daniel Drake

Matthew Garrett wrote:
Veering off at something of a tangent - how much of this should be true 
for wireless devices? Softmac seems to be unhappy about setting the 
essid unless the card is up, which breaks various assumptions...


You might regard that as a bug - I agree it probably makes sense for you 
to be able to set certain configuration variables before the interface 
is up, within reason.


However, the mentality adopted by most wireless drivers is the SIWESSID 
wireless extension ioctl means *associate*, something which obviously 
shouldn't be possible when the interface is down (radio off, etc).


While you might blame drivers for this possible misinterpretation, it 
can also be viewed as a design flaw in WE: the drivers have to handle 
the ioctl's directly, meaning that if you want some kind of 
configuration management then you have to do it on the driver level, and 
this doesn't feel right.


The situation is also made worse due to WE generally being hard to 
implement, and also the lack of documentation (really the only source 
here is the iwconfig man page).


This screams out for an 802.11-centric configuration system, and it 
looks like we have one on the way: cfg80211
From reading some mails, it looks like the drivers will simply have to 
provide functions for "associate", "scan", etc, and the configuration 
management will be offloaded to the upper layers.


For the time being, I suggest you bring the interface up before setting 
the configuration. Regardless of the inconsistency of the current 
situation, and lack documentation saying which way it should be done, 
you are at least playing it safe and guaranteeing it works on all drivers.


Daniel
-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Matthew Garrett
On Wed, Dec 20, 2006 at 09:38:20PM -0500, Daniel Drake wrote:

> I don't think that supporting scanning when the interface is supposed to 
> be disabled is sensible. If you want to scan, you are simply sending and 
> receiving frames, it's no different from having the interface up and 
> sending/receiving data frames.

>From a usability point of view, it's helpful to power the card down as 
much as possible while it's not being actively used. However, it's also 
helpful to be able to provide a list of available wireless networks, 
though some degree of latency would be acceptable in that. These two 
desires are obviously not entirely compatible with one another, so it 
would be helpful if there was some means of providing an intermediate 
state.

> There are additional implementation problems: scanning requires 2 
> different ioctl calls: siwscan, then several giwscan. If you want the 
> driver to effectively temporarily bring the interface up when userspace 
> requests a scan but the interface was down, then how does the driver 
> know when to bring it down again?

Hm. Does the spec not set any upper bound on how long it might take for 
APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. 
Picking a number out of thin air would be one answer, but clearly less 
than ideal. This may be a case of us not being able to satisfy everyone, 
and so just having to force the user to choose between low power or 
wireless scanning.

-- 
Matthew Garrett | [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: Network drivers that don't suspend on interface down

2006-12-20 Thread Daniel Drake

Matthew Garrett wrote:
In order to scan, we need to have the radio on and we need to be able to send 
and receive. What are you gonna turn off?


The obvious route would be to power the card down, but come back up 
every two minutes to perform a scan, or if userspace explicitly requests 
one. Would this cause problems in some cases?


I don't think it makes sense. For zd1211 the power consumption and heat 
emission goes up considerably when the interface is brought up (radio 
on, interrupts enabled, etc), and this is also a relatively long 
operation in terms of duration needed to bring the interface up and 
down. A scanning operation requires radio on, interrupts enabled, lots 
of register reading, RF calibration, RX/TX ringbuffers allocation, etc.


I don't think that supporting scanning when the interface is supposed to 
be disabled is sensible. If you want to scan, you are simply sending and 
receiving frames, it's no different from having the interface up and 
sending/receiving data frames.


There are additional implementation problems: scanning requires 2 
different ioctl calls: siwscan, then several giwscan. If you want the 
driver to effectively temporarily bring the interface up when userspace 
requests a scan but the interface was down, then how does the driver 
know when to bring it down again?


Daniel
-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Matthew Garrett
On Wed, Dec 20, 2006 at 08:57:05PM -0500, Michael Wu wrote:

(allowing scanning while the interface is down)

> No, it's absolutely a bug. It just so happens that some drivers incorrectly 
> allowed it.

Ok. Would it be reasonable to add warnings to any devices that allow it?
-- 
Matthew Garrett | [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: Network drivers that don't suspend on interface down

2006-12-20 Thread Matthew Garrett
On Wed, Dec 20, 2006 at 09:05:27PM -0500, Michael Wu wrote:

> Softmac isn't the only wireless code that likes to be configured after going 
> up first. Configuring after the card goes up has generally been more 
> reliable, though that should not be necessary and is a bug IMHO. 

Ok, that's nice to know. 

> In order to scan, we need to have the radio on and we need to be able to send 
> and receive. What are you gonna turn off?

The obvious route would be to power the card down, but come back up 
every two minutes to perform a scan, or if userspace explicitly requests 
one. Would this cause problems in some cases?

-- 
Matthew Garrett | [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: Network drivers that don't suspend on interface down

2006-12-20 Thread Jesse Brandeburg

On 12/20/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote:


> Yeah, I guess that's a problem. From a user perspective, the
> functionality is only really useful if the latency is very small. I
> think where possible we'd want to power down the chip while keeping the
> phy up, but it would be nice to know how much power that would actually
> cost us.

I'm no expert but afaik the PHY is the power hungry part, the rest is
peanuts. So if we can get the PHY to sleep most of the time that would
be great.


The MAC uses some part of power, but FYI at least e1000 already does
phy power management when IF_DOWN, if wake on lan isn't enabled, smbus
isn't enabled, etc etc.  If we started using D3 power management its
possible a whole bunch of code would go away out of e1000.

Is there some reason why we can't have the OS just do the D3
transition for all drivers that register support?  I mean, this power
management using D states is actually driver *independent* and at
least way back in the day was supposed to be implemented for "OS power
management"
-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Michael Wu
On Wednesday 20 December 2006 20:12, Matthew Garrett wrote:
> Veering off at something of a tangent - how much of this should be true
> for wireless devices? Softmac seems to be unhappy about setting the
> essid unless the card is up, which breaks various assumptions...
>
Softmac isn't the only wireless code that likes to be configured after going 
up first. Configuring after the card goes up has generally been more 
reliable, though that should not be necessary and is a bug IMHO. 

> Beyond that, I think your descriptions of up and down states make sense
> for userspace. As Arjan suggests, there's then the intermediate state of
> "disable as much as possible while still providing scanning and link
> detection".
>
In order to scan, we need to have the radio on and we need to be able to send 
and receive. What are you gonna turn off?

-Michael Wu


pgpKX2wvw2Sk4.pgp
Description: PGP signature


Re: Network drivers that don't suspend on interface down

2006-12-20 Thread Michael Wu
On Wednesday 20 December 2006 20:15, Matthew Garrett wrote:
> Because it works on the common hardware? If there's documentation about
> what userspace can legitimately expect, then I'm happy to defer to that.
> But in the absence of any indication as to what functionality users can
> depend on, deciding that existing functionality is a bug is, well,
> impolite.
>
No, it's absolutely a bug. It just so happens that some drivers incorrectly 
allowed it.

-Michael Wu


pgpc8jW7GJRT5.pgp
Description: PGP signature


Re: Network drivers that don't suspend on interface down

2006-12-20 Thread Matthew Garrett
On Wed, Dec 20, 2006 at 01:12:51PM -0500, Dan Williams wrote:

> Entirely correct.  If the card is DOWN, the radio should be off (both TX
> & RX) and it should be in max power save mode.  If userspace expects to
> be able to get the card to do _anything_ when it's down, that's just
> 110% wrong.  You can't get link events for many wired cards when they
> are down, so I fail to see where userspace could expect to do anything
> with a wireless card when it's down too.

Because it works on the common hardware? If there's documentation about 
what userspace can legitimately expect, then I'm happy to defer to that. 
But in the absence of any indication as to what functionality users can 
depend on, deciding that existing functionality is a bug is, well, 
impolite.

> Also, how does rfkill fit into this?  rfkill implies killing TX, but do
> we have the granularity to still receive while the transmit paths are
> powered down?

Is rfkill not just primarily an interface for us getting events when the 
radio changes state? Every time I read up on it I get a little more 
confused - some time I really need to make sense of it...

-- 
Matthew Garrett | [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: Network drivers that don't suspend on interface down

2006-12-20 Thread Matthew Garrett
On Wed, Dec 20, 2006 at 02:49:06PM -0800, Stephen Hemminger wrote:

>   When device is down, it should:
>a) use as few resources as possible:
>  - not grab memory for buffers
>  - not assign IRQ unless it could get one
>  - turn off all power consumption possible
>b) allow setting parameters like speed/duplex/autonegotiation,
> ring buffers, ... with ethtool, and remember the state

Veering off at something of a tangent - how much of this should be true 
for wireless devices? Softmac seems to be unhappy about setting the 
essid unless the card is up, which breaks various assumptions...

Beyond that, I think your descriptions of up and down states make sense 
for userspace. As Arjan suggests, there's then the intermediate state of 
"disable as much as possible while still providing scanning and link 
detection".

> 2) Network device infrastructure should make it easier for devices:
> bring interface down on suspend and bring it up after resume
> (if it was running when suspended). This would allow many devices to
> have no suspend/resume hook; except those that have some better power
> control over hardware.

I'd have some concerns over how that would interact with the rest of the 
PM infrastructure, but it certainly sounds good in principle.

-- 
Matthew Garrett | [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: Network drivers that don't suspend on interface down

2006-12-20 Thread Stephen Hemminger
On Thu, 21 Dec 2006 01:11:12 +0100
Francois Romieu <[EMAIL PROTECTED]> wrote:

> Stephen Hemminger <[EMAIL PROTECTED]> :
> [...]
> >IMHO:
> > When device is down, it should:
> >  a) use as few resources as possible:
> >- not grab memory for buffers
> >- not assign IRQ unless it could get one
> >- turn off all power consumption possible
> >  b) allow setting parameters like speed/duplex/autonegotiation,
> > ring buffers, ... with ethtool, and remember the state
> >  c) not accept data coming in, and drop packets queued
> 
> 
> Imho speed/duplex/autoneg is not the business of the device: they belong
> to the phy and it's up to it to decide if its state allows to set the
> requested parameters or not.
> 
> 

We need to allow ethtool setting to be done before device has been brought
up and started autonegotiation. The current MII library doesn't really support
it.

-- 
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Francois Romieu
Stephen Hemminger <[EMAIL PROTECTED]> :
[...]
>IMHO:
>   When device is down, it should:
>a) use as few resources as possible:
>  - not grab memory for buffers
>  - not assign IRQ unless it could get one
>  - turn off all power consumption possible
>b) allow setting parameters like speed/duplex/autonegotiation,
> ring buffers, ... with ethtool, and remember the state
>c) not accept data coming in, and drop packets queued


Imho speed/duplex/autoneg is not the business of the device: they belong
to the phy and it's up to it to decide if its state allows to set the
requested parameters or not.


-- 
Ueimor
-
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 4/4][SCTP]: make 2 functions static

2006-12-20 Thread David Miller
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Wed, 20 Dec 2006 16:01:06 -0800

> [SCTP]: make 2 functions static
> 
> This patch makes the following needlessly global functions static:
> - ipv6.c: sctp_inet6addr_event()
> - protocol.c: sctp_inetaddr_event()
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>

Applied, thanks a lot.
-
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 3/4][SCTP]: Implement SCTP_FRAGMENT_INTERLEAVE socket option.

2006-12-20 Thread David Miller
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Wed, 20 Dec 2006 16:00:57 -0800

> [SCTP]: Implement SCTP_FRAGMENT_INTERLEAVE socket option.
> 
> This option was introduced in draft-ietf-tsvwg-sctpsocket-13.  It
> prevents head-of-line blocking in the case of one-to-many endpoint.
> Applications enabling this option really must enable SCTP_SNDRCV event
> so that they would know where the data belongs.  Based on an
> earlier patch by Ivan Skytte Jørgensen.
> 
> Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
> Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>

The merge window for 2.6.20 features is closed, therefore I cannot
merge this now.  Please resubmit during the 2.6.21 merge window, thank
you.
-
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/4][SCTP]: Fix typo adaption -> adaptation as per the latest API draft.

2006-12-20 Thread David Miller
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Wed, 20 Dec 2006 16:00:50 -0800

> [SCTP]: Fix typo adaption -> adaptation as per the latest API draft.
> 
> Signed-off-by: Ivan Skytte Jorgensen <[EMAIL PROTECTED]>
> Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>

Applied, thanks Sridhar.
-
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 1/4][SCTP]: Don't export include/linux/sctp.h to userspace.

2006-12-20 Thread David Miller
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Wed, 20 Dec 2006 16:00:39 -0800

> [SCTP]: Don't export include/linux/sctp.h to userspace.
> 
> This file contains protocol definitions and there are no SCTP apps that use
> this file.
> 
> Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>

Applied, thanks for resolving the status of this header file.
-
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/4][SCTP]: Implement SCTP_FRAGMENT_INTERLEAVE socket option.

2006-12-20 Thread Sridhar Samudrala
[SCTP]: Implement SCTP_FRAGMENT_INTERLEAVE socket option.

This option was introduced in draft-ietf-tsvwg-sctpsocket-13.  It
prevents head-of-line blocking in the case of one-to-many endpoint.
Applications enabling this option really must enable SCTP_SNDRCV event
so that they would know where the data belongs.  Based on an
earlier patch by Ivan Skytte Jørgensen.

Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>

---
 include/net/sctp/structs.h |1 +
 include/net/sctp/user.h|4 ++
 net/sctp/socket.c  |   75 +++-
 net/sctp/ulpqueue.c|   30 --
 4 files changed, 97 insertions(+), 13 deletions(-)

diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index c9075d0..7497cec 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -306,6 +306,7 @@ struct sctp_sock {
__u8 disable_fragments;
__u8 pd_mode;
__u8 v4mapped;
+   __u8 frag_interleave;
__u32 adaptation_ind;
 
/* Receive to here while partial delivery is in effect. */
diff --git a/include/net/sctp/user.h b/include/net/sctp/user.h
index 4116b0d..8c1d68c 100644
--- a/include/net/sctp/user.h
+++ b/include/net/sctp/user.h
@@ -97,6 +97,8 @@ #define SCTP_GET_PEER_ADDR_INFO SCTP_GET
 #define SCTP_DELAYED_ACK_TIME SCTP_DELAYED_ACK_TIME
SCTP_CONTEXT,   /* Receive Context */
 #define SCTP_CONTEXT SCTP_CONTEXT
+   SCTP_FRAGMENT_INTERLEAVE,
+#define SCTP_FRAGMENT_INTERLEAVE SCTP_FRAGMENT_INTERLEAVE
 
/* Internal Socket Options. Some of the sctp library functions are 
 * implemented using these socket options.
@@ -530,7 +532,7 @@ struct sctp_paddrparams {
__u32   spp_flags;
 } __attribute__((packed, aligned(4)));
 
-/* 7.1.24. Delayed Ack Timer (SCTP_DELAYED_ACK_TIME)
+/* 7.1.23. Delayed Ack Timer (SCTP_DELAYED_ACK_TIME)
  *
  *   This options will get or set the delayed ack timer.  The time is set
  *   in milliseconds.  If the assoc_id is 0, then this sets or gets the
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index ec70201..91bef1e 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -2249,7 +2249,7 @@ static int sctp_setsockopt_peer_addr_par
return 0;
 }
 
-/* 7.1.24. Delayed Ack Timer (SCTP_DELAYED_ACK_TIME)
+/* 7.1.23. Delayed Ack Timer (SCTP_DELAYED_ACK_TIME)
  *
  *   This options will get or set the delayed ack timer.  The time is set
  *   in milliseconds.  If the assoc_id is 0, then this sets or gets the
@@ -2786,6 +2786,46 @@ static int sctp_setsockopt_context(struc
return 0;
 }
 
+/*
+ * 7.1.24.  Get or set fragmented interleave (SCTP_FRAGMENT_INTERLEAVE)
+ *
+ * This options will at a minimum specify if the implementation is doing
+ * fragmented interleave.  Fragmented interleave, for a one to many
+ * socket, is when subsequent calls to receive a message may return
+ * parts of messages from different associations.  Some implementations
+ * may allow you to turn this value on or off.  If so, when turned off,
+ * no fragment interleave will occur (which will cause a head of line
+ * blocking amongst multiple associations sharing the same one to many
+ * socket).  When this option is turned on, then each receive call may
+ * come from a different association (thus the user must receive data
+ * with the extended calls (e.g. sctp_recvmsg) to keep track of which
+ * association each receive belongs to.
+ *
+ * This option takes a boolean value.  A non-zero value indicates that
+ * fragmented interleave is on.  A value of zero indicates that
+ * fragmented interleave is off.
+ *
+ * Note that it is important that an implementation that allows this
+ * option to be turned on, have it off by default.  Otherwise an unaware
+ * application using the one to many model may become confused and act
+ * incorrectly.
+ */
+static int sctp_setsockopt_fragment_interleave(struct sock *sk,
+  char __user *optval,
+  int optlen)
+{
+   int val;
+
+   if (optlen != sizeof(int))
+   return -EINVAL;
+   if (get_user(val, (int __user *)optval))
+   return -EFAULT;
+
+   sctp_sk(sk)->frag_interleave = (val == 0) ? 0 : 1;
+
+   return 0;
+}
+
 /* API 6.2 setsockopt(), getsockopt()
  *
  * Applications use setsockopt() and getsockopt() to set or retrieve
@@ -2900,7 +2940,9 @@ SCTP_STATIC int sctp_setsockopt(struct s
case SCTP_CONTEXT:
retval = sctp_setsockopt_context(sk, optval, optlen);
break;
-
+   case SCTP_FRAGMENT_INTERLEAVE:
+   retval = sctp_setsockopt_fragment_interleave(sk, optval, 
optlen);
+   break;
default:
retval = -ENOPROTOOPT;
break;
@@ -3130,6 +3172,7 @@ SCTP_STATIC int sctp_init_sock(struct so
/* Control variables for partial data 

[PATCH 4/4][SCTP]: make 2 functions static

2006-12-20 Thread Sridhar Samudrala
[SCTP]: make 2 functions static

This patch makes the following needlessly global functions static:
- ipv6.c: sctp_inet6addr_event()
- protocol.c: sctp_inetaddr_event()

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>

---
 include/net/sctp/sctp.h |2 --
 net/sctp/ipv6.c |4 ++--
 net/sctp/protocol.c |4 ++--
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index c818f87..28af680 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -128,8 +128,6 @@ extern int sctp_copy_local_addr_list(str
 int flags);
 extern struct sctp_pf *sctp_get_pf_specific(sa_family_t family);
 extern int sctp_register_pf(struct sctp_pf *, sa_family_t);
-int sctp_inetaddr_event(struct notifier_block *this, unsigned long ev,
-void *ptr);
 
 /*
  * sctp/socket.c
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index d8d36de..ef36be0 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -79,8 +79,8 @@ #include 
 #include 
 
 /* Event handler for inet6 address addition/deletion events.  */
-int sctp_inet6addr_event(struct notifier_block *this, unsigned long ev,
-void *ptr)
+static int sctp_inet6addr_event(struct notifier_block *this, unsigned long ev,
+   void *ptr)
 {
struct inet6_ifaddr *ifa = (struct inet6_ifaddr *)ptr;
struct sctp_sockaddr_entry *addr;
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 3a3db56..225f39b 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -601,8 +601,8 @@ static void sctp_v4_seq_dump_addr(struct
 }
 
 /* Event handler for inet address addition/deletion events.  */
-int sctp_inetaddr_event(struct notifier_block *this, unsigned long ev,
-void *ptr)
+static int sctp_inetaddr_event(struct notifier_block *this, unsigned long ev,
+  void *ptr)
 {
struct in_ifaddr *ifa = (struct in_ifaddr *)ptr;
struct sctp_sockaddr_entry *addr;


-
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/4][SCTP]: Fix typo adaption -> adaptation as per the latest API draft.

2006-12-20 Thread Sridhar Samudrala
[SCTP]: Fix typo adaption -> adaptation as per the latest API draft.

Signed-off-by: Ivan Skytte Jorgensen <[EMAIL PROTECTED]>
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>

---
commit 1a7a0d391fb51bb26892aec4c7d36e7d8ba09d57
tree bd77592b453c53ff1988b29fa8aad1e54f95a842
parent 28e1d37084a686f37cc6cc56f94d96954edf920e
author Ivan Skytte Jorgensen <[EMAIL PROTECTED]> Wed, 20 Dec 2006 14:53:39 -0800
committer Sridhar Samudrala <[EMAIL PROTECTED]> Wed, 20 Dec 2006 14:53:39 -0800

 include/linux/sctp.h|   10 +-
 include/net/sctp/structs.h  |8 
 include/net/sctp/ulpevent.h |2 +-
 include/net/sctp/user.h |   28 ++--
 net/sctp/sm_make_chunk.c|   24 
 net/sctp/sm_statefuns.c |   32 
 net/sctp/socket.c   |   34 +-
 net/sctp/ulpevent.c |   20 ++--
 8 files changed, 79 insertions(+), 79 deletions(-)

diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index 35108fe..d4f8656 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -180,7 +180,7 @@ typedef enum {
SCTP_PARAM_ERR_CAUSE= __constant_htons(0xc003),
SCTP_PARAM_SET_PRIMARY  = __constant_htons(0xc004),
SCTP_PARAM_SUCCESS_REPORT   = __constant_htons(0xc005),
-   SCTP_PARAM_ADAPTION_LAYER_IND   = __constant_htons(0xc006),
+   SCTP_PARAM_ADAPTATION_LAYER_IND = __constant_htons(0xc006),
 
 } sctp_param_t; /* enum */
 
@@ -281,11 +281,11 @@ typedef struct sctp_ecn_capable_param {
sctp_paramhdr_t param_hdr;
 } __attribute__((packed)) sctp_ecn_capable_param_t;
 
-/* ADDIP Section 3.2.6 Adaption Layer Indication */
-typedef struct sctp_adaption_ind_param {
+/* ADDIP Section 3.2.6 Adaptation Layer Indication */
+typedef struct sctp_adaptation_ind_param {
struct sctp_paramhdr param_hdr;
-   __be32 adaption_ind;
-} __attribute__((packed)) sctp_adaption_ind_param_t;
+   __be32 adaptation_ind;
+} __attribute__((packed)) sctp_adaptation_ind_param_t;
 
 /* RFC 2960.  Section 3.3.3 Initiation Acknowledgement (INIT ACK) (2):
  *   The INIT ACK chunk is used to acknowledge the initiation of an SCTP
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 8d7f26d..c9075d0 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -306,7 +306,7 @@ struct sctp_sock {
__u8 disable_fragments;
__u8 pd_mode;
__u8 v4mapped;
-   __u32 adaption_ind;
+   __u32 adaptation_ind;
 
/* Receive to here while partial delivery is in effect. */
struct sk_buff_head pd_lobby;
@@ -388,7 +388,7 @@ struct sctp_cookie {
/* Padding for future use */
__u8 padding;   
 
-   __u32 adaption_ind; 
+   __u32 adaptation_ind;
 

/* This is a shim for my peer's INIT packet, followed by
@@ -431,7 +431,7 @@ union sctp_params {
struct sctp_ipv4addr_param *v4;
struct sctp_ipv6addr_param *v6;
union sctp_addr_param *addr;
-   struct sctp_adaption_ind_param *aind;
+   struct sctp_adaptation_ind_param *aind;
 };
 
 /* RFC 2960.  Section 3.3.5 Heartbeat.
@@ -1483,7 +1483,7 @@ struct sctp_association {
__u8asconf_capable;  /* Does peer support ADDIP? */
__u8prsctp_capable;  /* Can peer do PR-SCTP? */
 
-   __u32   adaption_ind;/* Adaption Code point. */
+   __u32   adaptation_ind;  /* Adaptation Code point. */
 
/* This mask is used to disable sending the ASCONF chunk
 * with specified parameter to peer.
diff --git a/include/net/sctp/ulpevent.h b/include/net/sctp/ulpevent.h
index 1a4ddc1..2923e3d 100644
--- a/include/net/sctp/ulpevent.h
+++ b/include/net/sctp/ulpevent.h
@@ -120,7 +120,7 @@ struct sctp_ulpevent *sctp_ulpevent_make
const struct sctp_association *asoc,
__u32 indication, gfp_t gfp);
 
-struct sctp_ulpevent *sctp_ulpevent_make_adaption_indication(
+struct sctp_ulpevent *sctp_ulpevent_make_adaptation_indication(
const struct sctp_association *asoc, gfp_t gfp);
 
 struct sctp_ulpevent *sctp_ulpevent_make_rcvmsg(struct sctp_association *asoc,
diff --git a/include/net/sctp/user.h b/include/net/sctp/user.h
index 9e4a39f..4116b0d 100644
--- a/include/net/sctp/user.h
+++ b/include/net/sctp/user.h
@@ -75,8 +75,8 @@ #define SCTP_AUTOCLOSE SCTP_AUTOCLOSE
 #define SCTP_SET_PEER_PRIMARY_ADDR SCTP_SET_PEER_PRIMARY_ADDR
SCTP_PRIMARY_ADDR,
 #define SCTP_PRIMARY_ADDR SCTP_PRIMARY_ADDR
-   SCTP_ADAPTION_LAYER,  
-#define SCTP_ADAPTION_LAYER SCTP_ADAPTION_LAYER
+   SCTP_ADAPTATION_LAYER,
+#define SCTP_ADAPTATION_LAYER SCTP_ADAPTATION_LAYER
SCTP_DISABLE_FRAGMENTS,
 #define SCTP_DISABLE_FRAGMENTS SCTP_DISABLE_FRAGMENTS
SCTP_PEER_ADDR_PARAMS,
@@ -331,17 +331,17 @@ struct sctp_shutdown_event {
 };
 
 /*
- * 5.3.1.6 SCTP_ADAPTION_INDICATIO

[PATCH 1/4][SCTP]: Don't export include/linux/sctp.h to userspace.

2006-12-20 Thread Sridhar Samudrala
[SCTP]: Don't export include/linux/sctp.h to userspace.

This file contains protocol definitions and there are no SCTP apps that use
this file.

Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>

---
 include/linux/Kbuild |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index a1b04d8..f2d75f3 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -138,7 +138,6 @@ header-y += radeonfb.h
 header-y += raw.h
 header-y += resource.h
 header-y += rose.h
-header-y += sctp.h
 header-y += smbno.h
 header-y += snmp.h
 header-y += sockios.h


-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Rick Jones

There are two different problems:

1) Behavior seems to be different depending on device driver
   author. We should document the expected semantics better.

   IMHO:
When device is down, it should:
 a) use as few resources as possible:
   - not grab memory for buffers
   - not assign IRQ unless it could get one
   - turn off all power consumption possible
 b) allow setting parameters like speed/duplex/autonegotiation,
ring buffers, ... with ethtool, and remember the state
 c) not accept data coming in, and drop packets queued


What implications does c have for something like tcpdump?

rick jones
-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Stephen Hemminger
On Wed, 20 Dec 2006 15:37:41 -0800
Rick Jones <[EMAIL PROTECTED]> wrote:

> > There are two different problems:
> > 
> > 1) Behavior seems to be different depending on device driver
> >author. We should document the expected semantics better.
> > 
> >IMHO:
> > When device is down, it should:
> >  a) use as few resources as possible:
> >- not grab memory for buffers
> >- not assign IRQ unless it could get one
> >- turn off all power consumption possible
> >  b) allow setting parameters like speed/duplex/autonegotiation,
> > ring buffers, ... with ethtool, and remember the state
> >  c) not accept data coming in, and drop packets queued
> 
> What implications does c have for something like tcpdump?
> 
> rick jones

None, you can bring up the device without actually assigning an address to it.

-- 
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 2/10] cxgb3 - main source file

2006-12-20 Thread Divy Le Ray

Arjan,

Thanks for the review. Please see my replies inline.

Arjan van de Ven wrote:

+/*
+ * Interrupt handler for asynchronous events used with MSI-X.
+ */
+static irqreturn_t t3_async_intr_handler(int irq, void *cookie)
+{
+   t3_slow_intr_handler(cookie);
+   return IRQ_HANDLED;
+}


this looks very wrong; why is t3_slow_intr_handler a void rather than
returning IRQ_HANDLED etc? And why wrap around it ?

t3_slow_intr_handler() processes non-data events such as board errors.
In line interupt and MSI mode, the intr handler deals with both data
and non-data events and calls t3_slow_intr_handler for the latter.
In MSI-X mode, t3_async_intr_handler() is registered to deal with these
non-data interrupts exclusively.


+
+static ssize_t attr_show(struct class_device *cd, char *buf,
+ssize_t(*format) (struct adapter *, char *))
+{
+   ssize_t len;
+   struct adapter *adap = to_net_dev(cd)->priv;
+
+   /* Synchronize with ioctls that may shut down the device */
+   rtnl_lock();
+   len = (*format) (adap, buf);
+   rtnl_unlock();
+   return len;
+}


I'm usually kind of nervous with drivers taking the rtnl_lock; to me
that sounds like a layering violation.. why shouldn't your attributes
etc live in the net layer instead?


These attributes are really device specific.
The net layer does not support device specific attributes.


+#ifdef ETHTOOL_GPERMADDR
+   .get_perm_addr = ethtool_op_get_perm_addr
+#endif


what is this ifdef for?

it will be removed.

+static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
+{
+   int ret;
+   u32 cmd;
+   struct adapter *adapter = dev->priv;
+
+   if (copy_from_user(&cmd, useraddr, sizeof(cmd)))
+   return -EFAULT;
+
+   switch (cmd) {
+   case CHELSIO_SETREG:{


what are these for ?

They are used to parameter the HW:
register access, configuration of queue sets, on board memory 
configuration,

firmware load, etc ...

+
+   /*
+* Can't use pci_request_regions() here because some kernels want to
+* request the MSI-X BAR in pci_enable_msix.


are these "some kernels" actual current mainline kernels?

Will fix both comment and related code.

+   if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
+   pci_using_dac = 1;
+   err = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
+   if (err) {
+   dev_err(&pdev->dev, "unable to obtain 64-bit DMA for "
+  "coherent allocations\n");
+   goto out_release_regions;


this looks wrong; if you can't get 64 bit coherent allocs but can get 32
bit ones.. why error out ?

This is how most of the existing drivers behave.

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 4/10] cxgb3 - HW access routines - part 2

2006-12-20 Thread Divy Le Ray

Arjan van de Ven wrote:

+void t3_port_intr_disable(struct adapter *adapter, int idx)
+{
+   struct cphy *phy = &adap2pinfo(adapter, idx)->phy;
+
+   t3_write_reg(adapter, XGM_REG(A_XGM_INT_ENABLE, idx), 0);
+   phy->ops->intr_disable(phy);



you seem to be missing a pci posting flush here
  

Thanks for catching this. Will fix.
-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Stephen Hemminger
On Wed, 20 Dec 2006 16:51:39 +0100
Arjan van de Ven <[EMAIL PROTECTED]> wrote:

> 
> > Yeah, I guess that's a problem. From a user perspective, the 
> > functionality is only really useful if the latency is very small. I 
> > think where possible we'd want to power down the chip while keeping the 
> > phy up, but it would be nice to know how much power that would actually 
> > cost us.
> 
> 
> I'm no expert but afaik the PHY is the power hungry part, the rest is
> peanuts. So if we can get the PHY to sleep most of the time that would
> be great.
> 

There are two different problems:

1) Behavior seems to be different depending on device driver
   author. We should document the expected semantics better.

   IMHO:
When device is down, it should:
 a) use as few resources as possible:
   - not grab memory for buffers
   - not assign IRQ unless it could get one
   - turn off all power consumption possible
 b) allow setting parameters like speed/duplex/autonegotiation,
ring buffers, ... with ethtool, and remember the state
 c) not accept data coming in, and drop packets queued

When device is up, it should:
 a) Start negotiation if needed
 b) Not bring up carrier till it is ready
 c) Allow reconfiguration

Wake on Lan should be disabled by default, until changed.

2) Network device infrastructure should make it easier for devices:
bring interface down on suspend and bring it up after resume
(if it was running when suspended). This would allow many devices to
have no suspend/resume hook; except those that have some better power
control over hardware.




-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Arjan van de Ven
On Wed, 2006-12-20 at 21:40 +0100, Benny Amorsen wrote:
> > "AvdV" == Arjan van de Ven <[EMAIL PROTECTED]> writes:
> 
> AvdV> even if you have NO power savings you still don't meet your
> AvdV> criteria. That's basic ethernet for you
> 
> AvdV> That's what I was trying to say; your criteria is unrealistic
> AvdV> regardless of what the kernel does, ethernet already dictates 30
> AvdV> to 45 seconds there.
> 
> Can you get to such high numbers without STP?

you can get the 30 seconds yes. Usually not with home equipment though,
but with longer cables and expensive switches.. it does happen.

-- 
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Stefan Rompf
Am Mittwoch, 20. Dezember 2006 16:34 schrieb Arjan van de Ven:

> 5 seconds is unfair and unrealistic though. The *hardware* negotiation
> before link is seen can easily take upto 45 seconds already.
> That's a network topology/hardware issue (spanning tree fun) that
> software or even the hardware in your PC can do nothing about.

Spanning tree decides whether or not a port forwards traffic. It has nothing 
to do with link beat detection and autonegotation, so it shouldn't be an 
issue here.

Stefan
-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Benny Amorsen
> "AvdV" == Arjan van de Ven <[EMAIL PROTECTED]> writes:

AvdV> even if you have NO power savings you still don't meet your
AvdV> criteria. That's basic ethernet for you

AvdV> That's what I was trying to say; your criteria is unrealistic
AvdV> regardless of what the kernel does, ethernet already dictates 30
AvdV> to 45 seconds there.

Can you get to such high numbers without STP?


/Benny


-
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][RFC] tcp: fix ambiguity in the `before' relation

2006-12-20 Thread Christoph Hellwig
On Thu, Dec 14, 2006 at 03:07:06PM +, Gerrit Renker wrote:
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index c99774f..b7d8317 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -242,14 +242,9 @@ extern int tcp_memory_pressure;
>  
>  static inline int before(__u32 seq1, __u32 seq2)
>  {
> -return (__s32)(seq1-seq2) < 0;
> +return (__s32)(seq2-seq1) > 0;
>  }
> -
> -static inline int after(__u32 seq1, __u32 seq2)
> -{
> - return (__s32)(seq2-seq1) < 0;
> -}
> -
> +#define after(seq2, seq1)before(seq1, seq2)

Btw, these macfox/inlines are named quite a bit too generic for
something that is in tcp.h

-
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 v5 13/13] iw_cxgb3 Kconfig/Makefile

2006-12-20 Thread Steve Wise

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/Kconfig   |1 +
 drivers/infiniband/Makefile  |1 +
 drivers/infiniband/hw/cxgb3/Kconfig  |   27 +++
 drivers/infiniband/hw/cxgb3/Makefile |   12 
 4 files changed, 41 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..d3db264
--- /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 .
+
+ For customer support, please visit our customer support page at
+ .
+
+ 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..7a89f6d
--- /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 -g 
+iw_cxgb3-y += core/cxio_dbg.o
+endif
-
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 v5 12/13] iw_cxgb3 Core Debug functions

2006-12-20 Thread Steve Wise

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..dfaa704
--- /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 
+#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 = (stag>>8) * 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)
+{
+   __be64 *data = (__be64 *)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)
+{
+   __be64 *data = (__be64 *)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;
+   i

[PATCH v5 11/13] iw_cxgb3 Core Resource Allocation

2006-12-20 Thread Steve Wise

Core functions to carve up adapter memory, stag, qp, and cq IDs.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/core/cxio_resource.c |  331 ++
 drivers/infiniband/hw/cxgb3/core/cxio_resource.h |   70 +
 2 files changed, 401 insertions(+), 0 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..d1d8722
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/core/cxio_resource.c
@@ -0,0 +1,331 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "cxio_resource.h"
+#include "cxio_hal.h"
+
+static struct kfifo *rhdl_fifo;
+static spinlock_t rhdl_fifo_lock;
+
+#define RANDOM_SIZE 16
+
+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;
+   random_bytes = random32();
+   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 = random32();
+   }
+   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 skip_high)
+{
+   return (__cxio_init_resource_fifo(fifo, fifo_lock, nr, skip_low,
+ skip_high, 0));
+}
+
+static int cxio_init_resource_fifo_random(struct kfifo **fifo,
+  spinlock_t * fifo_lock,
+  u32 nr, u32 skip_low, u32 skip_high)
+{
+
+   return (__cxio_init_resource_fifo(fifo, fifo_lock, nr, skip_low,
+ skip_high, 1));
+}
+
+static int cxio_init_qpid_fifo(struct cxio_rdev *rdev_p)
+{
+   u32 i;
+
+   spin_lock_init(&rdev_p->rscp->qpid_fifo_lock);
+
+   

[PATCH v5 10/13] iw_cxgb3 Core HAL

2006-12-20 Thread Steve Wise

The RDMA Core interfaces with the T3 HW and ULLD providing a low level
RDMA interface.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/core/cxio_hal.c | 1302 +++
 drivers/infiniband/hw/cxgb3/core/cxio_hal.h |  201 
 2 files changed, 1503 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..5e31816
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/core/cxio_hal.c
@@ -0,0 +1,1302 @@
+/*
+ * 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 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#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 the CQ.  We
+* spin until that CQE is valid.
+   

[PATCH v5 09/13] iw_cxgb3 Core WQE/CQE Types

2006-12-20 Thread Steve Wise

T3 WQE and CQE structures, defines, etc...

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/core/cxio_wr.h |  685 
 1 files changed, 685 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_wr.h 
b/drivers/infiniband/hw/cxgb3/core/cxio_wr.h
new file mode 100644
index 000..234a084
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/core/cxio_wr.h
@@ -0,0 +1,685 @@
+/*
+ * 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 
+#include 
+#include 
+#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) ((1UL<> S_FW_RIWR_OP)) & M_FW_RIWR_OP)
+
+#define S_FW_RIWR_SOPEOP   22
+#define M_FW_RIWR_SOPEOP   0x3
+#define V_FW_RIWR_SOPEOP(x)((x) << S_FW_RIWR_SOPEOP)
+
+#define S_FW_RIWR_FLAGS8
+#define M_FW_RIWR_FLAGS0x3f
+#define V_FW_RIWR_FLAGS(x) ((x) << S_FW_RIWR_FLAGS)
+#define G_FW_RIWR_FLAGS(x) x) >> S_FW_RIWR_FLAGS)) & M_FW_RIWR_FLAGS)
+
+#define S_FW_RIWR_TID  8
+#define V_FW_RIWR_TID(x)   ((x) << S_FW_RIWR_TID)
+
+#define S_FW_RIWR_LEN  0
+#define V_FW_RIWR_LEN(x)   ((x) << S_FW_RIWR_LEN)
+
+#define S_FW_RIWR_GEN   31
+#define V_FW_RIWR_GEN(x)((x)  << S_FW_RIWR_GEN)
+
+struct t3_sge {
+   __be32 stag;
+   __be32 len;
+   __be64 to;
+};
+
+/* If num_sgle is zero, flit 5+ contains immediate data.*/
+struct t3_send_wr {
+   struct fw_riwrh wrh;/* 0 */
+   union t3_wrid wrid; /* 1 */
+
+   u8 rdmaop;  /* 2 */
+   u8 reserved[3];
+   __be32 rem_stag;
+   __be32 plen;/* 3 */
+   __be32 num_sgle;
+   struct t3_sge sgl[T3_MAX_SGE];  /* 4+ */
+};
+
+struct t3_local_inv_wr {
+   struct fw_riwrh wrh;/* 0 */
+   union t3_wrid wrid; /* 1 */
+   __be32 stag;/* 2 */
+   __be32 reserved3;
+};
+
+struct t3_rdma_write_wr {
+   struct fw_riwrh wrh;/* 0 */
+   union t3_wrid wrid; /* 1 */
+   u8 rdmaop;  /* 2 */
+   u8 reserved[3];
+   __be32 stag_sink;
+   __be64 to_sink; /* 3 */
+   __be32 plen;/* 4 */
+   __be32 num_sgle;
+   struct t3_sge sgl[T3_MAX_SGE];  /* 5+ */
+};
+
+struct t3_rdma_read_wr {
+   struct fw_riwrh wrh;/* 0 */
+   union t3_wrid wrid; /* 1 */
+   u8 rdmaop;  /* 2 */
+   u8 reserved[3];
+   __be32 rem_stag;
+   __be64 rem_to;  /* 3 */
+   __be32 local_stag;  /* 4 */
+   __be32 local_len;
+   __be64 local_to;/* 5 */
+};
+
+enum t3_addr_type {
+   T3_VA_BASED_TO = 0x0,
+   T3_ZERO_BASED_TO = 0x1
+} __attribute__ ((packed));
+
+enum t3_mem_perms {
+   T3_MEM_ACCESS_LOCAL_READ = 0x1,
+   T3_MEM_ACCESS_LOCAL_WRITE = 0x2,
+   T3_MEM_ACCESS_REM_READ = 0x4,
+   T3_MEM_ACCESS_REM_WRITE = 0x8
+} __attribute__ ((packed));
+
+struct t3_bind_mw_wr {
+   struct fw_riwrh wrh;/* 0 */
+   union t3_wrid wrid; /* 1 */
+   u16 reserved;   /* 2 */
+   u8 type;
+   u8 perms;
+   __be32 mr_stag;
+   __be32 mw_stag; /* 3 */
+  

[PATCH v5 08/13] iw_cxgb3 Memory Registration

2006-12-20 Thread Steve Wise

Functions to register memory regions.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/iwch_mem.c |  170 
 1 files changed, 170 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/iwch_mem.c 
b/drivers/infiniband/hw/cxgb3/iwch_mem.c
new file mode 100644
index 000..5909ec5
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch_mem.c
@@ -0,0 +1,170 @@
+/*
+ * 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 
+
+#include 
+#include 
+
+#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,
+   __be64 *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;
+   insert_handle(rhp, &rhp->mmidr, mhp, mmid);
+   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,
+   __be64 *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;
+   insert_handle(rhp, &rhp->mmidr, mhp, mmid);
+   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,
+   __be64 **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)
+  

[PATCH v5 06/13] iw_cxgb3 Completion Queues

2006-12-20 Thread Steve Wise

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..ff09509
--- /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));
+  

[PATCH v5 07/13] iw_cxgb3 Async Event Handler

2006-12-20 Thread Steve Wise

Code to handle async events coming from the T3 RDMA Core.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/iwch_ev.c |  231 +
 1 files changed, 231 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/iwch_ev.c 
b/drivers/infiniband/hw/cxgb3/iwch_ev.c
new file mode 100644
index 000..646f612
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch_ev.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 
+#include 
+#include 
+#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 = get_qhp(rnicp, 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);
+
+   if (qhp->attr.state == IWCH_QP_STATE_RTS) {
+   attrs.next_state = IWCH_QP_STATE_TERMINATE;
+   iwch_modify_qp(qhp->rhp, qhp, IWCH_QP_ATTR_NEXT_STATE,
+  &attrs, 1);
+   if (send_term)
+   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 = get_chp(rnicp, cqid);
+   qhp = get_qhp(rnicp, 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 0

[PATCH v5 05/13] iw_cxgb3 Queue Pairs

2006-12-20 Thread Steve Wise

Code to manipulate the QP.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/iwch_qp.c | 1007 +
 1 files changed, 1007 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/iwch_qp.c 
b/drivers/infiniband/hw/cxgb3/iwch_qp.c
new file mode 100644
index 000..ad044bd
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch_qp.c
@@ -0,0 +1,1007 @@
+/*
+ * 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;
+   u32 plen;
+
+   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] = 0;
+   wqe->send.reserved[1] = 0;
+   wqe->send.reserved[2] = 0;
+   if (wr->opcode == IB_WR_SEND_WITH_IMM) {
+   plen = 4;
+   wqe->send.sgl[0].stag = wr->imm_data;
+   wqe->send.sgl[0].len = __constant_cpu_to_be32(0);
+   wqe->send.num_sgle = __constant_cpu_to_be32(0);
+   *flit_cnt = 5;
+   } else {
+   plen = 0;
+   for (i = 0; i < wr->num_sge; i++) {
+   if ((plen + wr->sg_list[i].length) < plen) {
+   return -EMSGSIZE;
+   }
+   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.num_sgle = cpu_to_be32(wr->num_sge);
+   *flit_cnt = 4 + ((wr->num_sge) << 1);
+   }
+   wqe->send.plen = cpu_to_be32(plen);
+   return 0;
+}
+
+static inline int iwch_build_rdma_write(union t3_wr *wqe, struct ib_send_wr 
*wr,
+   u8 *flit_cnt)
+{
+   int i;
+   u32 plen;
+   if (wr->num_sge > T3_MAX_SGE)
+   return -EINVAL;
+   wqe->write.rdmaop = T3_RDMA_WRITE;
+   wqe->write.reserved[0] = 0;
+   wqe->write.reserved[1] = 0;
+   wqe->write.reserved[2] = 0;
+   wqe->write.stag_sink = cpu_to_be32(wr->wr.rdma.rkey);
+   wqe->write.to_sink = cpu_to_be64(wr->wr.rdma.remote_addr);
+
+   if (wr->opcode == IB_WR_RDMA_WRITE_WITH_IMM) {
+   plen = 4;
+ 

[PATCH v5 03/13] iw_cxgb3 Provider Methods and Data Structures

2006-12-20 Thread Steve Wise

Provider methods to support the Linux RDMA verbs.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/iwch_provider.c | 1171 +++
 drivers/infiniband/hw/cxgb3/iwch_provider.h |  363 
 drivers/infiniband/hw/cxgb3/iwch_user.h |   68 ++
 3 files changed, 1602 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..ab99202
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c
@@ -0,0 +1,1171 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#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);
+   spin_lock_init(&context->mmap_lock);
+   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);
+
+   remove_handle(chp->rhp, &chp->rhp->cqidr, chp->cq.cqid);
+   atomic_dec(&chp->refcnt);
+   wait_event(chp->wait, !atomic_read(&chp->refcnt));
+
+   cxio_destroy_cq(&chp->rhp->rdev, &chp->cq);
+   kfree(chp);
+   return 0;
+}
+
+static struct ib_cq *iwch_create_cq(struct ib_device *ibdev, int entries,
+struct ib_ucontext *context,
+struct ib_udata *udata)
+{
+   struct

[PATCH v5 02/13] iw_cxgb3 Device Discovery and ULLD Linkage

2006-12-20 Thread Steve Wise

Code to discover all the T3 devices and register them 
with the T3 RDMA Core and the Linux RDMA Core.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/iwch.c |  189 
 drivers/infiniband/hw/cxgb3/iwch.h |  175 +
 2 files changed, 364 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..0c95f2c
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch.c
@@ -0,0 +1,189 @@
+/*
+ * 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 
+#include 
+
+#include 
+
+#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 void rnic_init(struct iwch_dev *rnicp)
+{
+   PDBG("%s iwch_dev %p\n", __FUNCTION__,  rnicp);
+   idr_init(&rnicp->cqidr);
+   idr_init(&rnicp->qpidr);
+   idr_init(&rnicp->mmidr);
+   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;
+   rnicp->attr.cq_overflow_detection = 1;
+   return;
+}
+
+static void open_rnic_dev(struct t3cdev *tdev)
+{
+   struct iwch_dev *rnicp;
+   static int vers_printed;
+
+   PDBG("%s t3cdev %p\n", __FUNCTION__,  tdev);
+   if (!vers_printed++)
+   printk(KERN_INFO MOD "Chelsio T3 RDMA Driver - version %s\n",
+  DRV_VERSION);
+   rnicp = (struct iwch_dev *)ib_alloc_device(sizeof(*rnicp));
+   if (!rnicp) {
+   printk(KERN_ERR MOD "Cannot allocate ib device\n");
+   return;
+   }
+ 

[PATCH v5 01/13] iw_cxgb3 Linux RDMA Core Changes

2006-12-20 Thread Steve Wise

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 04a9db5..9a76869 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 v5 00/13] iw_cxgb3 - Chelsio T3 RDMA Driver

2006-12-20 Thread Steve Wise

Roland, 

I think this is ready to go once the ethernet driver is pulled in by Jeff.  

Also: I'm gone after today returning Wednesday Jan 3rd.  I'll address any
new issues when I return.  

Cheers!

Steve.



Version 5 changes:

- BugFix: fixed broken endpoint state serialization
- Merged up to linus's tree as of 12/18/2006 (2.6.20-rc1)
- Removed all blank characters at the end of lines

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. 

The latest Chelsio T3 Ethernet driver patch can be pulled from:

  http://service.chelsio.com/kernel.org/cxgb3.patch.bz2

This T3 iWARP/RDMA Driver patch series can be pulled from:

  http://www.opengridcomputing.com/downloads/iw_cxgb3_patches_v5.tar.bz2

A complete GIT kernel tree with all the T3 drivers can be pulled from:

  git://staging.openfabrics.org/~swise/cxgb3.git
-
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 3/4] net: move softnet_data

2006-12-20 Thread David Miller
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 14 Dec 2006 12:48:17 -0800

> Make softnet_data local to dev.c.  
> 
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>

Slight mistake here, I think:

> +#ifdef CONFIG_NETPOLL
> +extern void  netpoll_do_completion(void);
> +#endif

Ok.

> --- linux-2.6.20-rc1.orig/net/core/dev.c
> +++ linux-2.6.20-rc1/net/core/dev.c
 ...
> @@ -1673,6 +1686,34 @@ static inline struct net_device *skb_bon
>   return dev;
>  }
>  
> +#ifdef CONFIG_NETPOLL
> +void netpoll_do_completion(void)
> +{

Ok.

> --- linux-2.6.20-rc1.orig/net/core/netpoll.c
> +++ linux-2.6.20-rc1/net/core/netpoll.c
  ...
> @@ -181,7 +180,7 @@ static void refill_skbs(void)
>   spin_unlock_irqrestore(&skb_pool.lock, flags);
>  }
>  
> -static void zap_completion_queue(void)
> +static void netpoll_do_completion(void)
>  {
>   unsigned long flags;
>   struct softnet_data *sd = &get_cpu_var(softnet_data);
> @@ -212,7 +211,7 @@ static struct sk_buff *find_skb(struct n
>   int count = 0;
>   struct sk_buff *skb;
>  
> - zap_completion_queue();
> + netpoll_do_completion();
>   refill_skbs();
>  repeat:

-ENOTESTED, I think this makes netpoll_do_completion() call itself,
ie. the local static version here, not the one you are exporting from
net/core/dev.c

Because of the extern you added, I can't see how the compiler
didn't complain loudly about this mismatch.

I had to see this, so I compiled it myself, and it doesn't even
build:

  CC  net/core/netpoll.o
net/core/netpoll.c:184: error: static declaration of 
$,1rx(Bnetpoll_do_completion$,1ry(B follows non-static declaration
include/linux/netdevice.h:604: error: previous declaration of 
$,1rx(Bnetpoll_do_completion$,1ry(B was here
net/core/netpoll.c: In function $,1rx(Bnetpoll_do_completion$,1ry(B:
net/core/netpoll.c:186: error: $,1rx(Bper_cpu__softnet_data$,1ry(B 
undeclared (first use in this function)
net/core/netpoll.c:186: error: (Each undeclared identifier is reported only once
net/core/netpoll.c:186: error: for each function it appears in.)
net/core/netpoll.c:188: error: dereferencing pointer to incomplete type
net/core/netpoll.c:192: error: dereferencing pointer to incomplete type
net/core/netpoll.c:193: error: dereferencing pointer to incomplete type

Stephen... come on :-)

-
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][RFC] tcp: fix ambiguity in the `before' relation

2006-12-20 Thread David Miller
From: Gerrit Renker <[EMAIL PROTECTED]>
Date: Thu, 14 Dec 2006 15:07:06 +

> While looking at DCCP sequence numbers, I stumbled over a problem with
> the following definition of before in tcp.h:
> 
> static inline int before(__u32 seq1, __u32 seq2)
> {
> return (__s32)(seq1-seq2) < 0;
> }
> 
> Problem: This definition suffers from an an ambiguity, i.e. always
>
>before(a, (a + 2^31) % 2^32)) = 1
>before((a + 2^31) % 2^32), a) = 1
>  
>  In text: when the difference between a and b amounts to 2^31,
>  a is always considered `before' b, the function can not decide. 
>  The reason is that implicitly 0 is `before' 1 ... 2^31-1 ... 2^31
>   
> Solution: There is a simple fix, by defining before in such a way that 
>   0 is no longer `before' 2^31, i.e. 0 `before' 1 ... 2^31-1
>   By not using the middle between 0 and 2^32, before can be made 
>   unambiguous. 
>   This is achieved by testing whether seq2-seq1 > 0 (using signed
>   32-bit arithmetic).
> 
> I attach a patch to codify this. Also the `after' relation is basically 
> a redefinition of `before', it is now defined as a macro after before.
> 
> Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]>

Applied, thanks Gerrit.

I went over this patch and analysis a dozen times, because I
couldn't believe something like this has been broken for
so long :-)

Even BSD suffers of this issue, since the beginning.  See
SEQ_LT() in tcp_seq.h, and it seems that BSD's timestamp
sequence checking has the issue too (see TSTMP_LT() macro
in OpenBSD's tcp_input.c)

It seems that our PAWS timestamp checks are ok because we do:

(s32)(tp->rx_opt.ts_recent - tp->rx_opt.rcv_tsval) > TCP_PAWS_WINDOW

and

(s32)(tp->rx_opt.rcv_tsval - tp->rx_opt.ts_recent) >= 0

Thanks again 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: Network drivers that don't suspend on interface down

2006-12-20 Thread Dan Williams
On Wed, 2006-12-20 at 15:00 +0100, Jiri Benc wrote:
> On Wed, 20 Dec 2006 12:53:14 +, Matthew Garrett wrote:
> > The situation is more complicated for wireless. Userspace expects to be 
> > able to get scan results from the card even if the interface is down.
> 
> User space should get an error when trying to get scan results from the
> interface that is down. Some drivers are broken and don't do this but
> when they're fixed there is no problem here.

Entirely correct.  If the card is DOWN, the radio should be off (both TX
& RX) and it should be in max power save mode.  If userspace expects to
be able to get the card to do _anything_ when it's down, that's just
110% wrong.  You can't get link events for many wired cards when they
are down, so I fail to see where userspace could expect to do anything
with a wireless card when it's down too.

> > In that case, I'm pretty sure we need a third state rather than just
> > "up" or "down".
> 
> We have that third state, it's IFF_DORMANT. Not supported yet by any
> wireless driver/stack, unfortunately.

So we have 3 states?  What purpose does DORMANT serve and what is
allowed in DORMANT?

Also, how does rfkill fit into this?  rfkill implies killing TX, but do
we have the granularity to still receive while the transmit paths are
powered down?

Dan

> Thanks,
> 
>  Jiri
> 

-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Arjan van de Ven
On Wed, 2006-12-20 at 17:40 +0100, Olivier Galibert wrote:
> On Wed, Dec 20, 2006 at 04:34:17PM +0100, Arjan van de Ven wrote:
> > 5 seconds is unfair and unrealistic though. The *hardware* negotiation
> > before link is seen can easily take upto 45 seconds already.
> > That's a network topology/hardware issue (spanning tree fun) that
> > software or even the hardware in your PC can do nothing about.
> 
> It's about ergonomics, not technical capabilities or fairness.
not entirely.

> 
> 
> > this means that the "power up time" needs to be at least 45 seconds, if
> > it's then down 5 seconds inbetween... that's not real power savings.
> 
> Then that means you can't have usable autodetection and power savings
> at the same time. 

even if you have NO power savings you still don't meet your criteria.
That's basic ethernet for you

That's what I was trying to say; your criteria is unrealistic regardless
of what the kernel does, ethernet already dictates 30 to 45 seconds
there.


-- 
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Olivier Galibert
On Wed, Dec 20, 2006 at 04:34:17PM +0100, Arjan van de Ven wrote:
> 5 seconds is unfair and unrealistic though. The *hardware* negotiation
> before link is seen can easily take upto 45 seconds already.
> That's a network topology/hardware issue (spanning tree fun) that
> software or even the hardware in your PC can do nothing about.

It's about ergonomics, not technical capabilities or fairness.


> this means that the "power up time" needs to be at least 45 seconds, if
> it's then down 5 seconds inbetween... that's not real power savings.

Then that means you can't have usable autodetection and power savings
at the same time.  That's a pefectly acceptable answer, you just have
to give the choice between the two to the user.  From the kernel
p.o.v, it just means that you probably need 3 modes:
1- active and exchanging packets

2- inactive but waiting for plugging and able to tell something is
   going on fast (like 0.5s fast)

3- powered off

and they probably already exist (UP+addr/procmisc. set, UP and DOWN).
And if the second mode can't be lower power than the first, that's
just life.  An hypothetical mode 4 identical to 2 without the "fast"
part is just not worth bothering with.

  OG.
-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Maciej W. Rozycki
On Wed, 20 Dec 2006, Matthew Garrett wrote:

> As far as I can tell, the following network devices don't put the 
> hardware into D3 on interface down:
[...]
> defxx

 No support in the hardware for that.  Even revision 3 of the board which 
is the last one and the only to support PCI 2.2 says:

Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

;-)

  Maciej
-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Olivier Galibert
On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote:
> [1] What kind of latency would be allowed? Would an implementation be
> allowed to power up the phy say once per minute or once per 5 minutes to
> see if there is link? The implementation could do this progressively;
> first poll every X seconds, then after an hour, every minute etc.

I suspect that the hard maximum latency is the time needed by the user
to start the network himself, be it opening a root xterm and doing the
appropriate invocation or pulling up and clicking where appropriate in
a GUI.  That's probably around 5 seconds.  Over that, and they won't
even notice there is an autodetection running.

But still, 5 seconds is probably too much too, because it's going to
look like it's unreliable.  The user has to see something happen
within half-a-second or so, otherwise he's going to start doing it by
hand.  The "see" part is distribution/desktop-dependant and not the
kernel problem, but the top chrono happens when the rj45 is plugged
in.

  OG.
-
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Arjan van de Ven

> Yeah, I guess that's a problem. From a user perspective, the 
> functionality is only really useful if the latency is very small. I 
> think where possible we'd want to power down the chip while keeping the 
> phy up, but it would be nice to know how much power that would actually 
> cost us.


I'm no expert but afaik the PHY is the power hungry part, the rest is
peanuts. So if we can get the PHY to sleep most of the time that would
be great.

-- 
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Arjan van de Ven
On Wed, 2006-12-20 at 16:27 +0100, Olivier Galibert wrote:
> On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote:
> > [1] What kind of latency would be allowed? Would an implementation be
> > allowed to power up the phy say once per minute or once per 5 minutes to
> > see if there is link? The implementation could do this progressively;
> > first poll every X seconds, then after an hour, every minute etc.
> 
> I suspect that the hard maximum latency is the time needed by the user
> to start the network himself, be it opening a root xterm and doing the
> appropriate invocation or pulling up and clicking where appropriate in
> a GUI.  That's probably around 5 seconds.  Over that, and they won't
> even notice there is an autodetection running.
> 
> But still, 5 seconds is probably too much too, because it's going to
> look like it's unreliable.  The user has to see something happen
> within half-a-second or so, otherwise he's going to start doing it by
> hand.  The "see" part is distribution/desktop-dependant and not the
> kernel problem, but the top chrono happens when the rj45 is plugged
> in.

5 seconds is unfair and unrealistic though. The *hardware* negotiation
before link is seen can easily take upto 45 seconds already.
That's a network topology/hardware issue (spanning tree fun) that
software or even the hardware in your PC can do nothing about.

this means that the "power up time" needs to be at least 45 seconds, if
it's then down 5 seconds inbetween... that's not real power savings.

> .
-- 
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


[patch/iputils] tweak makefile to be more flexible

2006-12-20 Thread Mike Frysinger
this patch tweaks the makefile so that it respects user environment variables 
such as CC/CFLAGS/etc... and cleans out some cruft that is no longer utilized
-mike


pgplx9s90lvR9.pgp
Description: PGP signature
Respect user environment variables.

Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>

diff --git a/Makefile b/Makefile
index 54c1de5..7a7b045 100644
--- a/Makefile
+++ b/Makefile
@@ -1,20 +1,18 @@
 # Path to parent kernel include files directory
 LIBC_INCLUDE=/usr/include
 
-DEFINES= 
-
 #options if you have a bind>=4.9.4 libresolv (or, maybe, glibc)
 LDLIBS=-lresolv
-ADDLIB=
 
 #options if you compile with libc5, and without a bind>=4.9.4 libresolv
 # NOT AVAILABLE. Please, use libresolv.
 
-CC=gcc
+CC ?= gcc
 # What a pity, all new gccs are buggy and -Werror does not work. Sigh.
 #CCOPT=-D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g -Werror
-CCOPT=-D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g
-CFLAGS=$(CCOPT) $(GLIBCFIX) $(DEFINES) 
+CFLAGS ?= -O2 -g
+CFLAGS += -Wstrict-prototypes -Wall
+CPPFLAGS += -D_GNU_SOURCE
 
 IPV4_TARGETS=tracepath ping clockdiff rdisc arping tftpd rarpd
 IPV6_TARGETS=tracepath6 traceroute6 ping6
@@ -33,9 +31,8 @@ ping.o ping6.o ping_common.o: ping_common.h
 tftpd.o tftpsubs.o: tftp.h
 
 rdisc_srv: rdisc_srv.o
-
 rdisc_srv.o: rdisc.c
-	$(CC) $(CFLAGS) -DRDISC_SERVER -o rdisc_srv.o rdisc.c
+	$(CC) $(CFLAGS) $(CPPFLAGS) -DRDISC_SERVER -o rdisc_srv.o rdisc.c
 
 
 check-kernel:


Re: [patch] handle pktgen setup in newer kernels in iputils/ipg

2006-12-20 Thread YOSHIFUJI Hideaki / 吉藤英明
In article <[EMAIL PROTECTED]> (at Wed, 20 Dec 2006 10:09:03 -0500), Mike 
Frysinger <[EMAIL PROTECTED]> says:

> the ipg script only works with the old "pg3" module and not the new "pktgen" 
> module ... attached patch updates the ipg script to support both

Applied.  Thanks.

--yoshfuji
-
To 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/iputils] use proper loop constructs rather than goto's

2006-12-20 Thread Mike Frysinger
a bunch of places in the tracepath code use goto's rather than real loop code, 
or goto's to jump out of loop's ... some versions (like gcc-3.3.x iirc, older 
admittedly) would miscompile this and it's cleaner anyways to just use real 
loops

the attached patch isnt applicable as is (style changes required mostly) as i 
just want to see if people will accept it or the answer is "upgrade your gcc 
to like 4.1.x"
-mike


pgpNH4BfJuLjf.pgp
Description: PGP signature
use proper looping code rather than labels/gotos as some versions of
gcc may miscompile the code.

Signed-off-by: Robert Moss <[EMAIL PROTECTED]>
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>

diff --git a/tracepath.c b/tracepath.c
index c3f6f74..7ff85a2 100644
--- a/tracepath.c
+++ b/tracepath.c
@@ -77,7 +77,7 @@ int recverr(int fd, int ttl)
 	int progress = -1;
 	int broken_router;
 	
-restart:
+   while (1) {
 	memset(&rcvbuf, -1, sizeof(rcvbuf));
 	iov.iov_base = &rcvbuf;
 	iov.iov_len = sizeof(rcvbuf);
@@ -94,7 +94,7 @@ restart:
 	if (res < 0) {
 		if (errno == EAGAIN)
 			return progress;
-		goto restart;
+		continue;
 	}
 
 	progress = mtu;
@@ -217,7 +217,7 @@ restart:
 		perror("NET ERROR");
 		return 0;
 	}
-	goto restart;
+   }
 }
 
 int probe_ttl(int fd, int ttl)
@@ -228,7 +228,6 @@ int probe_ttl(int fd, int ttl)
 
 	memset(sndbuf,0,mtu);
 
-restart:
 	for (i=0; i<10; i++) {
 		int res;
 
@@ -244,7 +243,8 @@ restart:
 		if (res==0)
 			return 0;
 		if (res > 0)
-			goto restart;
+			i = 0;
+			continue;
 	}
 	hisptr = (hisptr + 1)&63;
 
diff --git a/tracepath6.c b/tracepath6.c
index 23d6a8c..6d2a95b 100644
--- a/tracepath6.c
+++ b/tracepath6.c
@@ -71,7 +71,7 @@ int recverr(int fd, int ttl)
 	int progress = -1;
 	int broken_router;
 
-restart:
+   while (1) {
 	memset(&rcvbuf, -1, sizeof(rcvbuf));
 	iov.iov_base = &rcvbuf;
 	iov.iov_len = sizeof(rcvbuf);
@@ -88,7 +88,7 @@ restart:
 	if (res < 0) {
 		if (errno == EAGAIN)
 			return progress;
-		goto restart;
+		continue;
 	}
 
 	progress = 2;
@@ -233,34 +233,29 @@ restart:
 		perror("NET ERROR");
 		return 0;
 	}
-	goto restart;
+   }
 }
 
 int probe_ttl(int fd, int ttl)
 {
-	int i;
+	int i=0, res;
 	char sndbuf[mtu];
 	struct probehdr *hdr = (struct probehdr*)sndbuf;
 
-restart:
-
-	for (i=0; i<10; i++) {
-		int res;
-
-		hdr->ttl = ttl;
-		gettimeofday(&hdr->tv, NULL);
-		if (send(fd, sndbuf, mtu-overhead, 0) > 0)
-			break;
-		res = recverr(fd, ttl);
-		if (res==0)
-			return 0;
-		if (res > 0)
-			goto restart;
-	}
-
-	if (i<10) {
-		int res;
-
+	while (i<10) {
+		for (i=0; i<10; i++) {
+			hdr->ttl = ttl;
+			gettimeofday(&hdr->tv, NULL);
+			if (send(fd, sndbuf, mtu-overhead, 0) > 0)
+break;
+			res = recverr(fd, ttl);
+			if (res==0)
+return 0;
+			if (res > 0) {
+i = 0;
+continue;
+			}
+		}
 		data_wait(fd);
 		if (recv(fd, sndbuf, sizeof(sndbuf), MSG_DONTWAIT) > 0) {
 			printf("%2d?: reply received 8)\n", ttl);
@@ -268,7 +263,7 @@ restart:
 		}
 		res = recverr(fd, ttl);
 		if (res == 1)
-			goto restart;
+			continue;
 		return res;
 	}
 


Re: [patch] use socklen_t in iputils rather than just int

2006-12-20 Thread YOSHIFUJI Hideaki / 吉藤英明
In article <[EMAIL PROTECTED]> (at Wed, 20 Dec 2006 10:00:32 -0500), Mike 
Frysinger <[EMAIL PROTECTED]> says:

> a bunch of places in iputils utilize "int" lengths when in reality they 
> should 
> be using socklen_t

Patch applied.  Thanks.

Please add some prefix in subject, please;
e.g. Subject: [IPUTILS] Use socklen_t in all the right places.

Regards,

-- 
YOSHIFUJI Hideaki @ USAGI Project  <[EMAIL PROTECTED]>
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
-
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] handle pktgen setup in newer kernels in iputils/ipg

2006-12-20 Thread Mike Frysinger
the ipg script only works with the old "pg3" module and not the new "pktgen" 
module ... attached patch updates the ipg script to support both
-mike


pgpDCI0UbHEoD.pgp
Description: PGP signature
Only load modules if kernel supports modules and try a little bit
harder to locate the pg directory in /proc with newer kernels.

Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>

--- a/ipg
+++ b/ipg
@@ -1,21 +1,32 @@
 #! /bin/bash
 
-modprobe pg3
+if [ -e /proc/modules ] ; then
+	modprobe pg3 >& /dev/null
+	modprobe pktgen >& /dev/null
+fi
+
+for PGDEV in /proc/net/pg /proc/net/pktgen/pg0 / ; do
+	[ -e ${PGDEV} ] && break
+done
+if [ "${PGDEV}" = "/" ] ; then
+	echo "Could not locate pg in /proc/net" 1>&2
+	exit 1
+fi
 
 function pgset() {
 local result
 
-echo $1 > /proc/net/pg
+echo $1 > ${PGDEV}
 
-result=`cat /proc/net/pg | fgrep "Result: OK:"`
+result=`cat ${PGDEV} | fgrep "Result: OK:"`
 if [ "$result" = "" ]; then
- cat /proc/net/pg | fgrep Result:
+ cat ${PGDEV} | fgrep Result:
 fi
 }
 
 function pg() {
-echo inject > /proc/net/pg
-cat /proc/net/pg
+echo inject > ${PGDEV}
+cat ${PGDEV}
 }
 
 pgset "odev eth0"


[patch] use socklen_t in iputils rather than just int

2006-12-20 Thread Mike Frysinger
a bunch of places in iputils utilize "int" lengths when in reality they should 
be using socklen_t
-mike


pgpSqlzw2arsi.pgp
Description: PGP signature
Use socklen_t in all the right places.

Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>

diff --git a/arping.c b/arping.c
index 73a7e6f..86f1607 100644
--- a/arping.c
+++ b/arping.c
@@ -439,7 +439,7 @@ main(int argc, char **argv)
 			}
 		} else if (!dad) {
 			int on = 1;
-			int alen = sizeof(saddr);
+			socklen_t alen = sizeof(saddr);
 
 			saddr.sin_port = htons(1025);
 			saddr.sin_addr = dst;
@@ -468,7 +468,7 @@ main(int argc, char **argv)
 	}
 
 	if (1) {
-		int alen = sizeof(me);
+		socklen_t alen = sizeof(me);
 		if (getsockname(s, (struct sockaddr*)&me, &alen) == -1) {
 			perror("getsockname");
 			exit(2);
@@ -500,9 +500,9 @@ main(int argc, char **argv)
 
 	while(1) {
 		sigset_t sset, osset;
-		char packet[4096];
+		unsigned char packet[4096];
 		struct sockaddr_ll from;
-		int alen = sizeof(from);
+		socklen_t alen = sizeof(from);
 		int cc;
 
 		if ((cc = recvfrom(s, packet, sizeof(packet), 0,
diff --git a/clockdiff.c b/clockdiff.c
index 009eed4..e17e0b8 100644
--- a/clockdiff.c
+++ b/clockdiff.c
@@ -121,7 +121,7 @@ long rtt_sigma = 0;
 int
 measure(struct sockaddr_in * addr)
 {
-	int length;
+	socklen_t length;
 	int msgcount;
 	int cc, count;
 	fd_set ready;
@@ -299,7 +299,7 @@ char *myname, *hisname;
 int
 measure_opt(struct sockaddr_in * addr)
 {
-	int length;
+	socklen_t length;
 	int msgcount;
 	int cc, count;
 	fd_set ready;
@@ -602,7 +602,7 @@ main(int argc, char *argv[])
 	}
 	if (ip_opt_len) {
 		struct sockaddr_in myaddr;
-		int addrlen = sizeof(myaddr);
+		socklen_t addrlen = sizeof(myaddr);
 		unsigned char rspace[ip_opt_len];
 
 	bzero(rspace, sizeof(rspace));
diff --git a/ping.c b/ping.c
index 825f85b..561e71a 100644
--- a/ping.c
+++ b/ping.c
@@ -259,7 +259,7 @@ main(int argc, char **argv)
 	}
 
 	if (source.sin_addr.s_addr == 0) {
-		int alen;
+		socklen_t alen;
 		struct sockaddr_in dst = whereto;
 		int probe_fd = socket(AF_INET, SOCK_DGRAM, 0);
 
diff --git a/ping6.c b/ping6.c
index 5aef459..d85a659 100644
--- a/ping6.c
+++ b/ping6.c
@@ -344,7 +344,7 @@ int main(int argc, char *argv[])
 	hostname = target;
 
 	if (ipv6_addr_any(&source.sin6_addr)) {
-		int alen;
+		socklen_t alen;
 		int probe_fd = socket(AF_INET6, SOCK_DGRAM, 0);
 
 		if (probe_fd < 0) {
diff --git a/ping_common.c b/ping_common.c
index dd111f7..acd9b8e 100644
--- a/ping_common.c
+++ b/ping_common.c
@@ -67,7 +67,7 @@ static void fill(char *patp)
 	int ii, jj, kk;
 	int pat[16];
 	char *cp;
-	char *bp = outpack+8;
+	u_char *bp = outpack+8;
 
 	for (cp = patp; *cp; cp++) {
 		if (!isxdigit(*cp)) {
@@ -393,7 +393,7 @@ resend:
 void sock_setbufs(int icmp_sock, int alloc)
 {
 	int rcvbuf, hold;
-	int tmplen = sizeof(hold);
+	socklen_t tmplen = sizeof(hold);
 
 	if (!sndbuf)
 		sndbuf = alloc;
@@ -464,7 +464,7 @@ void setup(int icmp_sock)
 
 	if (!(options & F_PINGFILLED)) {
 		int i;
-		char *p = outpack+8;
+		u_char *p = outpack+8;
 
 		/* Do not forget about case of small datalen,
 		 * fill timestamp area too!
diff --git a/rarpd.c b/rarpd.c
index 5cb0ab8..65fd57f 100644
--- a/rarpd.c
+++ b/rarpd.c
@@ -417,7 +417,7 @@ void serve_it(int fd)
 {
 	unsigned char buf[1024];
 	struct sockaddr_ll sll;
-	int sll_len = sizeof(sll);
+	socklen_t sll_len = sizeof(sll);
 	struct arphdr *a = (struct arphdr*)buf;
 	struct rarp_map *rmap;
 	unsigned char *ptr;
diff --git a/rdisc.c b/rdisc.c
index 5f598e2..dc52b3e 100644
--- a/rdisc.c
+++ b/rdisc.c
@@ -451,7 +451,7 @@ next:
 	for (;;) {
 		u_char	packet[MAXPACKET];
 		int len = sizeof (packet);
-		int fromlen = sizeof (from);
+		socklen_t fromlen = sizeof (from);
 		int cc;
 
 		cc=recvfrom(s, (char *)packet, len, 0, 
diff --git a/tftpd.c b/tftpd.c
index 301151e..39f2164 100644
--- a/tftpd.c
+++ b/tftpd.c
@@ -88,7 +88,7 @@ union {
 	struct	sockaddr_in  sin;
 	struct	sockaddr_in6 sin6;
 } from;
-int	fromlen;
+socklen_t	fromlen;
 
 #define MAXARG	1
 char	*dirs[MAXARG+1];
@@ -148,7 +148,8 @@ int main(int ac, char **av)
 	 */
 	{
 		int pid;
-		int i, j;
+		int i;
+		socklen_t j;
 
 		for (i = 1; i < 20; i++) {
 		pid = fork();
diff --git a/traceroute6.c b/traceroute6.c
index fdb631f..114cb0a 100644
--- a/traceroute6.c
+++ b/traceroute6.c
@@ -510,7 +510,7 @@ int main(int argc, char *argv[])
   (char *)&on, sizeof(on));
 
 	if (source == NULL) {
-		int alen;
+		socklen_t alen;
 		int probe_fd = socket(AF_INET6, SOCK_DGRAM, 0);
 
 		if (probe_fd < 0) {


Re: Network drivers that don't suspend on interface down

2006-12-20 Thread Matthew Garrett
On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote:
> about your driver list;
> do you have an idea of what the top 5 relevant ones would be?
> I'd be surprised if the top 5 together had less than 95% market share,
> so if we fix those we'd be mostly done already.

In terms of what I've seen on vaguely modern hardware, I'd guess at 
e1000 and sky2 as the top ones. b44 is still common in cheaper hardware, 
with via-rhine appearing at the very low end. I'll try to grep through 
our hardware database results to get a stronger idea about percentages.

> > The situation is more complicated for wireless. Userspace expects to be 
> > able to get scan results from the card even if the interface is down.
> 
> if it's down userspace cannot currently expect this (if it does it's
> broken), just as it currently can't expect link notifications when the
> interface is down. It needs to have the interface up for this. 
> (but point taken for a 3rd state)

The documentation for what userspace can legitimately expect of the 
kernel is distinctly lacking, and as far as I can tell most of the 
common drivers support scanning while the interface is down. It would be 
immensely helpful if we could have a better idea of which kernel 
behaviour is deliberate, and which bits of kernel functionality are 
accidental and might go away at any time. Right now, I have various 
scripts depending on this behaviour because there's absolutely no 
indication that I'm not supposed to be.

(Of course, I may have missed it somewhere - I've never been able to 
find terribly comprehensive documentation on WE)

> so what do you want from this 3rd state? rough guess based on what I
> think the desktop wants (so please correct/append)

Just to be clear: in this world view, "down" maps to "fully powered 
down", so this third state is a "low power consumption mode"? If so:

> In the third state you 
> * don't expect to get or send "regular" packets
> * don't have a dhcp lease or anything like that
> * you do expect to get link change notification [1]
> * you do expect to be able to scan for access points [2]

Yes, I think that's a fair summary. 

> open questions
> * what if you get a WOL event?

In an ideal world, I think the information would be passed to userspace 
and it would get to make the distinction. I appreciate that the hardware 
may have different ideas about what's appropriate...

> [1] What kind of latency would be allowed? Would an implementation be
> allowed to power up the phy say once per minute or once per 5 minutes to
> see if there is link? The implementation could do this progressively;
> first poll every X seconds, then after an hour, every minute etc.

Yeah, I guess that's a problem. From a user perspective, the 
functionality is only really useful if the latency is very small. I 
think where possible we'd want to power down the chip while keeping the 
phy up, but it would be nice to know how much power that would actually 
cost us.

(We have a similar issue when it comes to stuff like monitor hotplug - 
it's the sort of thing that many users are willing to accept losing some 
battery for, and there probably isn't a single right answer)
 
> [2] would it be permissible to temporarily power up the device on scan?
> Eg how frequently does the desktop expect to poll for scanning, and what
> kind of latency would be tolerable?

network-manager's behaviour when the interface is inactive is to scan 
every 2 minutes. I don't think latency is too much of an issue.

-- 
Matthew Garrett | [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 4/10] cxgb3 - HW access routines - part 2

2006-12-20 Thread Arjan van de Ven
> +void t3_port_intr_disable(struct adapter *adapter, int idx)
> +{
> + struct cphy *phy = &adap2pinfo(adapter, idx)->phy;
> +
> + t3_write_reg(adapter, XGM_REG(A_XGM_INT_ENABLE, idx), 0);
> + phy->ops->intr_disable(phy);

you seem to be missing a pci posting flush here



-- 
if 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: [PATCH 2/10] cxgb3 - main source file

2006-12-20 Thread Arjan van de Ven
> +/*
> + * Interrupt handler for asynchronous events used with MSI-X.
> + */
> +static irqreturn_t t3_async_intr_handler(int irq, void *cookie)
> +{
> + t3_slow_intr_handler(cookie);
> + return IRQ_HANDLED;
> +}

this looks very wrong; why is t3_slow_intr_handler a void rather than
returning IRQ_HANDLED etc? And why wrap around it ?

> +
> +static ssize_t attr_show(struct class_device *cd, char *buf,
> +  ssize_t(*format) (struct adapter *, char *))
> +{
> + ssize_t len;
> + struct adapter *adap = to_net_dev(cd)->priv;
> +
> + /* Synchronize with ioctls that may shut down the device */
> + rtnl_lock();
> + len = (*format) (adap, buf);
> + rtnl_unlock();
> + return len;
> +}

I'm usually kind of nervous with drivers taking the rtnl_lock; to me
that sounds like a layering violation.. why shouldn't your attributes
etc live in the net layer instead?

> +#ifdef ETHTOOL_GPERMADDR
> + .get_perm_addr = ethtool_op_get_perm_addr
> +#endif

what is this ifdef for?


> +static int cxgb_extension_ioctl(struct net_device *dev, void __user 
> *useraddr)
> +{
> + int ret;
> + u32 cmd;
> + struct adapter *adapter = dev->priv;
> +
> + if (copy_from_user(&cmd, useraddr, sizeof(cmd)))
> + return -EFAULT;
> +
> + switch (cmd) {
> + case CHELSIO_SETREG:{

what are these for ?

> +
> + /*
> +  * Can't use pci_request_regions() here because some kernels want to
> +  * request the MSI-X BAR in pci_enable_msix.

are these "some kernels" actual current mainline kernels?

> + if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
> + pci_using_dac = 1;
> + err = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
> + if (err) {
> + dev_err(&pdev->dev, "unable to obtain 64-bit DMA for "
> +"coherent allocations\n");
> + goto out_release_regions;

this looks wrong; if you can't get 64 bit coherent allocs but can get 32
bit ones.. why error out ?




-- 
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: Network drivers that don't suspend on interface down

2006-12-20 Thread Jiri Benc
On Wed, 20 Dec 2006 12:53:14 +, Matthew Garrett wrote:
> The situation is more complicated for wireless. Userspace expects to be 
> able to get scan results from the card even if the interface is down.

User space should get an error when trying to get scan results from the
interface that is down. Some drivers are broken and don't do this but
when they're fixed there is no problem here.

> In that case, I'm pretty sure we need a third state rather than just
> "up" or "down".

We have that third state, it's IFF_DORMANT. Not supported yet by any
wireless driver/stack, unfortunately.

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: Network drivers that don't suspend on interface down

2006-12-20 Thread Arjan van de Ven
about your driver list;
do you have an idea of what the top 5 relevant ones would be?
I'd be surprised if the top 5 together had less than 95% market share,
so if we fix those we'd be mostly done already.

> The situation is more complicated for wireless. Userspace expects to be 
> able to get scan results from the card even if the interface is down.

if it's down userspace cannot currently expect this (if it does it's
broken), just as it currently can't expect link notifications when the
interface is down. It needs to have the interface up for this. 
(but point taken for a 3rd state)

>  In 
> that case, I'm pretty sure we need a third state rather than just "up" 
> or "down".

so what do you want from this 3rd state? rough guess based on what I
think the desktop wants (so please correct/append)

In the third state you 
* don't expect to get or send "regular" packets
* don't have a dhcp lease or anything like that
* you do expect to get link change notification [1]
* you do expect to be able to scan for access points [2]

open questions
* what if you get a WOL event?



[1] What kind of latency would be allowed? Would an implementation be
allowed to power up the phy say once per minute or once per 5 minutes to
see if there is link? The implementation could do this progressively;
first poll every X seconds, then after an hour, every minute etc.

[2] would it be permissible to temporarily power up the device on scan?
Eg how frequently does the desktop expect to poll for scanning, and what
kind of latency would be tolerable?

-- 
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


Network drivers that don't suspend on interface down

2006-12-20 Thread Matthew Garrett
On Wed, Dec 20, 2006 at 08:50:24AM +0100, Arjan van de Ven wrote:

(Adding netdev - context is the altering of the runtime power 
management interface, with the effect that it's no longer possible for 
userspace to request that drivers suspend a device, so Arjan has 
suggested that we do it via other existing interfaces)

> > Seriously. How many pieces of userspace-visible functionality have 
> > recently been removed without there being any sort of alternative?
> 
> There IS an alternative, you're using it for networking:
>  
> You *down the interface*.
> 
> If there's a NIC that doesn't support that let us (or preferably netdev)
> know and it'll get fixed quickly I'm sure.

As far as I can tell, the following network devices don't put the 
hardware into D3 on interface down:

3c59x
8139too
acenic
amd8111e
b44
cassini
defxx
dl2k
e100
e1000
epic100
fealnx
forcedeth
hamachi
hp100
ioc3-eth
natsemi
ne2k-pci
ns83820
pcnet32
qla3xxx
rtl8169
rrunner
s2io
saa9730
sis190
sis900
skge
sky2
spider_net
starfire
sundance
sungem
sunhme
tc35815
tlan
via-rhine
yellowfin

while these ones do:

bnx2
tg3
typhoon
via-velocity

tulip is somewhere in between - it puts the chip in a lower power state, 
but not D3. It's possible that some of the other drivers do something 
similar, but nothing leapt out at me.

The situation is more complicated for wireless. Userspace expects to be 
able to get scan results from the card even if the interface is down. In 
that case, I'm pretty sure we need a third state rather than just "up" 
or "down".
-- 
Matthew Garrett | [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


[PATCH 10/10] cxgb3 - build files and versioning

2006-12-20 Thread Divy Le Ray
From: Divy Le Ray <[EMAIL PROTECTED]>

This patch implements build files and versioning for the 
Chelsio T3 network adapter's driver.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---

 drivers/net/Kconfig |   18 ++
 drivers/net/Makefile|1 +
 drivers/net/cxgb3/Makefile  |8 
 drivers/net/cxgb3/version.h |   24 
 4 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 8aa8dd0..f8742f1 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2392,6 +2392,24 @@ config CHELSIO_T1_NAPI
  NAPI is a driver API designed to reduce CPU and interrupt load
  when the driver is receiving lots of packets from the card.
 
+config CHELSIO_T3
+tristate "Chelsio Communications T3 10Gb Ethernet support"
+depends on PCI
+help
+  This driver supports Chelsio T3-based gigabit and 10Gb Ethernet
+  adapters.
+
+  For general information about Chelsio and our products, visit
+  our website at .
+
+  For customer support, please visit our customer support page at
+  .
+
+  Please send feedback to <[EMAIL PROTECTED]>.
+
+  To compile this driver as a module, choose M here: the module
+  will be called cxgb3.
+
 config EHEA
tristate "eHEA Ethernet support"
depends on IBMEBUS
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 4c0d4e5..5c66643 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_E1000) += e1000/
 obj-$(CONFIG_IBM_EMAC) += ibm_emac/
 obj-$(CONFIG_IXGB) += ixgb/
 obj-$(CONFIG_CHELSIO_T1) += chelsio/
+obj-$(CONFIG_CHELSIO_T3) += cxgb3/
 obj-$(CONFIG_EHEA) += ehea/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
diff --git a/drivers/net/cxgb3/Makefile b/drivers/net/cxgb3/Makefile
new file mode 100755
index 000..3434679
--- /dev/null
+++ b/drivers/net/cxgb3/Makefile
@@ -0,0 +1,8 @@
+#
+# Chelsio T3 driver
+#
+
+obj-$(CONFIG_CHELSIO_T3) += cxgb3.o
+
+cxgb3-objs := cxgb3_main.o ael1002.o vsc8211.o t3_hw.o mc5.o \
+ xgmac.o sge.o l2t.o cxgb3_offload.o
diff --git a/drivers/net/cxgb3/version.h b/drivers/net/cxgb3/version.h
new file mode 100755
index 000..1413ea3
--- /dev/null
+++ b/drivers/net/cxgb3/version.h
@@ -0,0 +1,24 @@
+/*
+ *   *
+ * File: *
+ *  version.h*
+ *   *
+ * Description:  *
+ *  Chelsio driver version defines.  *
+ *   *
+ * Copyright (c) 2003 - 2006 Chelsio Communications, Inc.*
+ * All rights reserved.  *
+ *   *
+ * Maintainers: [EMAIL PROTECTED]  *
+ *   *
+ * http://www.chelsio.com*
+ *   *
+ /
+/* $Date: 2006/10/31 18:57:51 $ $RCSfile: version.h,v $ $Revision: 1.3 $ */
+#ifndef __CHELSIO_VERSION_H
+#define __CHELSIO_VERSION_H
+#define DRV_DESC "Chelsio T3 Network Driver"
+#define DRV_NAME "cxgb3"
+/* Driver version */
+#define DRV_VERSION "1.0"
+#endif /* __CHELSIO_VERSION_H */
-
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 6/10] cxgb3 - on board memory, MAC and PHY

2006-12-20 Thread Divy Le Ray
From: Divy Le Ray <[EMAIL PROTECTED]>

This patch implements on board memory, MAC and PHY management
for the Chelsio T3 network adapter's driver.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---

 drivers/net/cxgb3/ael1002.c |  231 ++
 drivers/net/cxgb3/mc5.c |  453 +++
 drivers/net/cxgb3/vsc8211.c |  208 
 drivers/net/cxgb3/xgmac.c   |  389 +
 4 files changed, 1281 insertions(+), 0 deletions(-)

diff --git a/drivers/net/cxgb3/ael1002.c b/drivers/net/cxgb3/ael1002.c
new file mode 100755
index 000..93a90d8
--- /dev/null
+++ b/drivers/net/cxgb3/ael1002.c
@@ -0,0 +1,231 @@
+/*
+ * This file is part of the Chelsio T3 Ethernet driver.
+ *
+ * Copyright (C) 2005-2006 Chelsio Communications.  All rights reserved.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the LICENSE file included in this
+ * release for licensing terms and conditions.
+ */
+
+#include "common.h"
+#include "regs.h"
+
+enum {
+   AEL100X_TX_DISABLE = 9,
+   AEL100X_TX_CONFIG1 = 0xc002,
+   AEL1002_PWR_DOWN_HI = 0xc011,
+   AEL1002_PWR_DOWN_LO = 0xc012,
+   AEL1002_XFI_EQL = 0xc015,
+   AEL1002_LB_EN = 0xc017,
+
+   LASI_CTRL = 0x9002,
+   LASI_STAT = 0x9005
+};
+
+static void ael100x_txon(struct cphy *phy)
+{
+   int tx_on_gpio = phy->addr == 0 ? F_GPIO7_OUT_VAL : F_GPIO2_OUT_VAL;
+
+   msleep(100);
+   t3_set_reg_field(phy->adapter, A_T3DBG_GPIO_EN, 0, tx_on_gpio);
+   msleep(30);
+}
+
+static int ael1002_power_down(struct cphy *phy, int enable)
+{
+   int err;
+
+   err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL100X_TX_DISABLE, !!enable);
+   if (!err)
+   err = t3_mdio_change_bits(phy, MDIO_DEV_PMA_PMD, MII_BMCR,
+ BMCR_PDOWN, enable ? BMCR_PDOWN : 0);
+   return err;
+}
+
+static int ael1002_reset(struct cphy *phy, int wait)
+{
+   int err;
+
+   if ((err = ael1002_power_down(phy, 0)) ||
+   (err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL100X_TX_CONFIG1, 1)) ||
+   (err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL1002_PWR_DOWN_HI, 0)) ||
+   (err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL1002_PWR_DOWN_LO, 0)) ||
+   (err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL1002_XFI_EQL, 0x18)) ||
+   (err = t3_mdio_change_bits(phy, MDIO_DEV_PMA_PMD, AEL1002_LB_EN,
+  0, 1 << 5)))
+   return err;
+   return 0;
+}
+
+static int ael1002_intr_noop(struct cphy *phy)
+{
+   return 0;
+}
+
+static int ael100x_get_link_status(struct cphy *phy, int *link_ok,
+  int *speed, int *duplex, int *fc)
+{
+   if (link_ok) {
+   unsigned int status;
+   int err = mdio_read(phy, MDIO_DEV_PMA_PMD, MII_BMSR, &status);
+
+   /*
+* BMSR_LSTATUS is latch-low, so if it is 0 we need to read it
+* once more to get the current link state.
+*/
+   if (!err && !(status & BMSR_LSTATUS))
+   err = mdio_read(phy, MDIO_DEV_PMA_PMD, MII_BMSR,
+   &status);
+   if (err)
+   return err;
+   *link_ok = !!(status & BMSR_LSTATUS);
+   }
+   if (speed)
+   *speed = SPEED_1;
+   if (duplex)
+   *duplex = DUPLEX_FULL;
+   return 0;
+}
+
+static struct cphy_ops ael1002_ops = {
+   .reset = ael1002_reset,
+   .intr_enable = ael1002_intr_noop,
+   .intr_disable = ael1002_intr_noop,
+   .intr_clear = ael1002_intr_noop,
+   .intr_handler = ael1002_intr_noop,
+   .get_link_status = ael100x_get_link_status,
+   .power_down = ael1002_power_down,
+};
+
+void t3_ael1002_phy_prep(struct cphy *phy, struct adapter *adapter,
+int phy_addr, const struct mdio_ops *mdio_ops)
+{
+   cphy_init(phy, adapter, phy_addr, &ael1002_ops, mdio_ops);
+   ael100x_txon(phy);
+}
+
+static int ael1006_reset(struct cphy *phy, int wait)
+{
+   return t3_phy_reset(phy, MDIO_DEV_PMA_PMD, wait);
+}
+
+static int ael1006_intr_enable(struct cphy *phy)
+{
+   return mdio_write(phy, MDIO_DEV_PMA_PMD, LASI_CTRL, 1);
+}
+
+static int ael1006_intr_disable(struct cphy *phy)
+{
+   return mdio_write(phy, MDIO_DEV_PMA_PMD, LASI_CTRL, 0);
+}
+
+static int ael1006_intr_clear(struct cphy *phy)
+{
+   u32 val;
+
+   return mdio_read(phy, MDIO_DEV_PMA_PMD, LASI_STAT, &val);
+}
+
+static int ael1006_intr_handler(struct cphy *phy)
+{
+   unsigned int status;
+   int err = mdio_read(phy, MDIO_DEV_PMA_PMD, LASI_STAT, &status);
+
+   if (err)
+   return err;
+   return (status & 1) ? cphy_cause_li

[PATCH 8/10] cxgb3 - offload capabilities

2006-12-20 Thread Divy Le Ray
From: Divy Le Ray <[EMAIL PROTECTED]>

This patch implements the offload capabilities of the
Chelsio network adapter's driver.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---

 drivers/net/cxgb3/cxgb3_offload.c | 1222 +
 drivers/net/cxgb3/l2t.c   |  450 ++
 2 files changed, 1672 insertions(+), 0 deletions(-)

diff --git a/drivers/net/cxgb3/cxgb3_offload.c 
b/drivers/net/cxgb3/cxgb3_offload.c
new file mode 100755
index 000..3abd4d2
--- /dev/null
+++ b/drivers/net/cxgb3/cxgb3_offload.c
@@ -0,0 +1,1222 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "common.h"
+#include "regs.h"
+#include "cxgb3_ioctl.h"
+#include "cxgb3_ctl_defs.h"
+#include "cxgb3_defs.h"
+#include "l2t.h"
+#include "firmware_exports.h"
+#include "cxgb3_offload.h"
+
+static LIST_HEAD(client_list);
+static LIST_HEAD(ofld_dev_list);
+static DEFINE_MUTEX(cxgb3_db_lock);
+
+static DEFINE_RWLOCK(adapter_list_lock);
+static LIST_HEAD(adapter_list);
+
+static const unsigned int MAX_ATIDS = 64 * 1024;
+static const unsigned int ATID_BASE = 0x10;
+
+static inline int offload_activated(struct t3cdev *tdev)
+{
+   const struct adapter *adapter = tdev2adap(tdev);
+
+   return (test_bit(OFFLOAD_DEVMAP_BIT, &adapter->open_device_map));
+}
+
+/**
+ * cxgb3_register_client - register an offload client
+ * @client: the client
+ *
+ * Add the client to the client list,
+ * and call backs the client for each activated offload device
+ */
+void cxgb3_register_client(struct cxgb3_client *client)
+{
+   struct t3cdev *tdev;
+
+   mutex_lock(&cxgb3_db_lock);
+   list_add_tail(&client->client_list, &client_list);
+
+   if (client->add) {
+   list_for_each_entry(tdev, &ofld_dev_list, ofld_dev_list) {
+   if (offload_activated(tdev))
+   client->add(tdev);
+   }
+   }
+   mutex_unlock(&cxgb3_db_lock);
+}
+
+EXPORT_SYMBOL(cxgb3_register_client);
+
+/**
+ * cxgb3_unregister_client - unregister an offload client
+ * @client: the client
+ *
+ * Remove the client to the client list,
+ * and call backs the client for each activated offload device.
+ */
+void cxgb3_unregister_client(struct cxgb3_client *client)
+{
+   struct t3cdev *tdev;
+
+   mutex_lock(&cxgb3_db_lock);
+   list_del(&client->client_list);
+
+   if (client->remove) {
+   list_for_each_entry(tdev, &ofld_dev_list, ofld_dev_list) {
+   if (offload_activated(tdev))
+   client->remove(tdev);
+   }
+   }
+   mutex_unlock(&cxgb3_db_lock);
+}
+
+EXPORT_SYMBOL(cxgb3_unregister_client);
+
+/**
+ * cxgb3_add_clients - activate registered clients for an offload device
+ * @tdev: the offload device
+ *
+ * Call backs all registered clients once a offload device is activated
+ */
+void cxgb3_add_clients(struct t3cdev *tdev)
+{
+   struct cxgb3_client *client;
+
+   mutex_lock(&cxgb3_db_lock);
+   list_for_each_entry(client, &client_list, client_list) {
+   if (client->add)
+   client->add(tdev);
+   }
+   mutex_unlock(&cxgb3_db_lock);
+}
+
+/**
+ * cxgb3_remove_clients - deactivates registered clients
+ *for an offload device
+ * @tdev: the offload device
+ *
+ *  

[PATCH 9/10] cxgb3 - register definitions

2006-12-20 Thread Divy Le Ray
From: Divy Le Ray <[EMAIL PROTECTED]>

This patch implements the registers definitions for the
Chelsio network adapter's driver.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---

 drivers/net/cxgb3/regs.h | 2195 ++
 1 files changed, 2195 insertions(+), 0 deletions(-)

diff --git a/drivers/net/cxgb3/regs.h b/drivers/net/cxgb3/regs.h
new file mode 100755
index 000..b56c5f5
--- /dev/null
+++ b/drivers/net/cxgb3/regs.h
@@ -0,0 +1,2195 @@
+#define A_SG_CONTROL 0x0
+
+#define S_DROPPKT20
+#define V_DROPPKT(x) ((x) << S_DROPPKT)
+#define F_DROPPKTV_DROPPKT(1U)
+
+#define S_EGRGENCTRL19
+#define V_EGRGENCTRL(x) ((x) << S_EGRGENCTRL)
+#define F_EGRGENCTRLV_EGRGENCTRL(1U)
+
+#define S_USERSPACESIZE14
+#define M_USERSPACESIZE0x1f
+#define V_USERSPACESIZE(x) ((x) << S_USERSPACESIZE)
+
+#define S_HOSTPAGESIZE11
+#define M_HOSTPAGESIZE0x7
+#define V_HOSTPAGESIZE(x) ((x) << S_HOSTPAGESIZE)
+
+#define S_FLMODE9
+#define V_FLMODE(x) ((x) << S_FLMODE)
+#define F_FLMODEV_FLMODE(1U)
+
+#define S_PKTSHIFT6
+#define M_PKTSHIFT0x7
+#define V_PKTSHIFT(x) ((x) << S_PKTSHIFT)
+
+#define S_ONEINTMULTQ5
+#define V_ONEINTMULTQ(x) ((x) << S_ONEINTMULTQ)
+#define F_ONEINTMULTQV_ONEINTMULTQ(1U)
+
+#define S_BIGENDIANINGRESS2
+#define V_BIGENDIANINGRESS(x) ((x) << S_BIGENDIANINGRESS)
+#define F_BIGENDIANINGRESSV_BIGENDIANINGRESS(1U)
+
+#define S_ISCSICOALESCING1
+#define V_ISCSICOALESCING(x) ((x) << S_ISCSICOALESCING)
+#define F_ISCSICOALESCINGV_ISCSICOALESCING(1U)
+
+#define S_GLOBALENABLE0
+#define V_GLOBALENABLE(x) ((x) << S_GLOBALENABLE)
+#define F_GLOBALENABLEV_GLOBALENABLE(1U)
+
+#define S_AVOIDCQOVFL24
+#define V_AVOIDCQOVFL(x) ((x) << S_AVOIDCQOVFL)
+#define F_AVOIDCQOVFLV_AVOIDCQOVFL(1U)
+
+#define S_OPTONEINTMULTQ23
+#define V_OPTONEINTMULTQ(x) ((x) << S_OPTONEINTMULTQ)
+#define F_OPTONEINTMULTQV_OPTONEINTMULTQ(1U)
+
+#define S_CQCRDTCTRL22
+#define V_CQCRDTCTRL(x) ((x) << S_CQCRDTCTRL)
+#define F_CQCRDTCTRLV_CQCRDTCTRL(1U)
+
+#define A_SG_KDOORBELL 0x4
+
+#define S_SELEGRCNTX31
+#define V_SELEGRCNTX(x) ((x) << S_SELEGRCNTX)
+#define F_SELEGRCNTXV_SELEGRCNTX(1U)
+
+#define S_EGRCNTX0
+#define M_EGRCNTX0x
+#define V_EGRCNTX(x) ((x) << S_EGRCNTX)
+
+#define A_SG_GTS 0x8
+
+#define S_RSPQ29
+#define M_RSPQ0x7
+#define V_RSPQ(x) ((x) << S_RSPQ)
+#define G_RSPQ(x) (((x) >> S_RSPQ) & M_RSPQ)
+
+#define S_NEWTIMER16
+#define M_NEWTIMER0x1fff
+#define V_NEWTIMER(x) ((x) << S_NEWTIMER)
+
+#define S_NEWINDEX0
+#define M_NEWINDEX0x
+#define V_NEWINDEX(x) ((x) << S_NEWINDEX)
+
+#define A_SG_CONTEXT_CMD 0xc
+
+#define S_CONTEXT_CMD_OPCODE28
+#define M_CONTEXT_CMD_OPCODE0xf
+#define V_CONTEXT_CMD_OPCODE(x) ((x) << S_CONTEXT_CMD_OPCODE)
+
+#define S_CONTEXT_CMD_BUSY27
+#define V_CONTEXT_CMD_BUSY(x) ((x) << S_CONTEXT_CMD_BUSY)
+#define F_CONTEXT_CMD_BUSYV_CONTEXT_CMD_BUSY(1U)
+
+#define S_CQ_CREDIT20
+
+#define M_CQ_CREDIT0x7f
+
+#define V_CQ_CREDIT(x) ((x) << S_CQ_CREDIT)
+
+#define G_CQ_CREDIT(x) (((x) >> S_CQ_CREDIT) & M_CQ_CREDIT)
+
+#define S_CQ19
+
+#define V_CQ(x) ((x) << S_CQ)
+#define F_CQV_CQ(1U)
+
+#define S_RESPONSEQ18
+#define V_RESPONSEQ(x) ((x) << S_RESPONSEQ)
+#define F_RESPONSEQV_RESPONSEQ(1U)
+
+#define S_EGRESS17
+#define V_EGRESS(x) ((x) << S_EGRESS)
+#define F_EGRESSV_EGRESS(1U)
+
+#define S_FREELIST16
+#define V_FREELIST(x) ((x) << S_FREELIST)
+#define F_FREELISTV_FREELIST(1U)
+
+#define S_CONTEXT0
+#define M_CONTEXT0x
+#define V_CONTEXT(x) ((x) << S_CONTEXT)
+
+#define G_CONTEXT(x) (((x) >> S_CONTEXT) & M_CONTEXT)
+
+#define A_SG_CONTEXT_DATA0 0x10
+
+#define A_SG_CONTEXT_DATA1 0x14
+
+#define A_SG_CONTEXT_DATA2 0x18
+
+#define A_SG_CONTEXT_DATA3 0x1c
+
+#define A_SG_CONTEXT_MASK0 0x20
+
+#define A_SG_CONTEXT_MASK1 0x24
+
+#define A_SG_CONTEXT_MASK2 0x28
+
+#define A_SG_CONTEXT_MASK3 0x2c
+
+#define A_SG_RSPQ_CREDIT_RETURN 0x30
+
+#define S_CREDITS0
+#define M_CREDITS0x
+#define V_CREDITS(x) ((x) << S_CREDITS)
+
+#define A_SG_DATA_INTR 0x34
+
+#define S_ERRINTR31
+#define V_ERRINTR(x) ((x) << S_ERRINTR)
+#define F_ERRINTRV_ERRINTR(1U)
+
+#define A_SG_HI_DRB_HI_THRSH 0x38
+
+#define A_SG_HI_DRB_LO_THRSH 0x3c
+
+#define A_SG_LO_DRB_HI_THRSH 0x40
+
+#define A_SG_LO_DRB_LO_THRSH 0x44
+
+#define A_SG_RSPQ_FL_STATUS 0x4c
+
+#define S_RSPQ0DISABLED8
+
+#define A_SG_EGR_RCQ_DRB_THRSH 0x54
+
+#define S_HIRCQDRBTHRSH16
+#define M_HIRCQDRBTHRSH0x7ff
+#define V_HIRCQDRBTHRSH(x) ((x) << S_HIRCQDRBTHRSH)
+
+#define S_LORCQDRBTHRSH0
+#define M_LORCQDRBTHRSH0x7ff
+#define V_LORCQDRBTHRSH(x) ((x) << S_LORCQDRBTHRSH)
+
+#define A_SG_EGR_CNTX_BADDR 0x58
+
+#define A_SG_INT_CAUSE 0x5c
+
+#define S_RSPQDISABLED3
+#define V_RSPQDISABLED(x) ((x) << S_RSPQDISABLED)
+#define F_RSPQDISABLEDV_RSPQDISABLED(1U)
+
+#define S_RSPQCREDITOVE

[PATCH 7/10] cxgb3 - offload header files

2006-12-20 Thread Divy Le Ray
From: Divy Le Ray <[EMAIL PROTECTED]>

This patch implements the offload operations header files
for the Chelsio T3 network adapter's driver.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---

 drivers/net/cxgb3/cxgb3_ctl_defs.h |  142 
 drivers/net/cxgb3/cxgb3_defs.h |   99 ++
 drivers/net/cxgb3/cxgb3_offload.h  |  193 +
 drivers/net/cxgb3/l2t.h|  143 
 drivers/net/cxgb3/t3_cpl.h | 1426 
 drivers/net/cxgb3/t3cdev.h |   72 ++
 6 files changed, 2075 insertions(+), 0 deletions(-)

diff --git a/drivers/net/cxgb3/cxgb3_ctl_defs.h 
b/drivers/net/cxgb3/cxgb3_ctl_defs.h
new file mode 100755
index 000..0fdc365
--- /dev/null
+++ b/drivers/net/cxgb3/cxgb3_ctl_defs.h
@@ -0,0 +1,142 @@
+/*
+ * Copyright (C) 2003-2006 Chelsio Communications.  All rights reserved.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the LICENSE file included in this
+ * release for licensing terms and conditions.
+ */
+
+#ifndef _CXGB3_OFFLOAD_CTL_DEFS_H
+#define _CXGB3_OFFLOAD_CTL_DEFS_H
+
+enum {
+   GET_MAX_OUTSTANDING_WR,
+   GET_TX_MAX_CHUNK,
+   GET_TID_RANGE,
+   GET_STID_RANGE,
+   GET_RTBL_RANGE,
+   GET_L2T_CAPACITY,
+   GET_MTUS,
+   GET_WR_LEN,
+   GET_IFF_FROM_MAC,
+   GET_DDP_PARAMS,
+   GET_PORTS,
+
+   ULP_ISCSI_GET_PARAMS,
+   ULP_ISCSI_SET_PARAMS,
+
+   RDMA_GET_PARAMS,
+   RDMA_CQ_OP,
+   RDMA_CQ_SETUP,
+   RDMA_CQ_DISABLE,
+   RDMA_CTRL_QP_SETUP,
+   RDMA_GET_MEM,
+};
+
+/*
+ * Structure used to describe a TID range.  Valid TIDs are [base, base+num).
+ */
+struct tid_range {
+   unsigned int base;  /* first TID */
+   unsigned int num;   /* number of TIDs in range */
+};
+
+/*
+ * Structure used to request the size and contents of the MTU table.
+ */
+struct mtutab {
+   unsigned int size;  /* # of entries in the MTU table */
+   const unsigned short *mtus; /* the MTU table values */
+};
+
+struct net_device;
+
+/*
+ * Structure used to request the adapter net_device owning a given MAC address.
+ */
+struct iff_mac {
+   struct net_device *dev; /* the net_device */
+   const unsigned char *mac_addr;  /* MAC address to lookup */
+   u16 vlan_tag;
+};
+
+struct pci_dev;
+
+/*
+ * Structure used to request the TCP DDP parameters.
+ */
+struct ddp_params {
+   unsigned int llimit;/* TDDP region start address */
+   unsigned int ulimit;/* TDDP region end address */
+   unsigned int tag_mask;  /* TDDP tag mask */
+   struct pci_dev *pdev;
+};
+
+struct adap_ports {
+   unsigned int nports;/* number of ports on this adapter */
+   struct net_device *lldevs[2];
+};
+
+/*
+ * Structure used to return information to the iscsi layer.
+ */
+struct ulp_iscsi_info {
+   unsigned int offset;
+   unsigned int llimit;
+   unsigned int ulimit;
+   unsigned int tagmask;
+   unsigned int pgsz3;
+   unsigned int pgsz2;
+   unsigned int pgsz1;
+   unsigned int pgsz0;
+   unsigned int max_rxsz;
+   unsigned int max_txsz;
+   struct pci_dev *pdev;
+};
+
+/*
+ * Structure used to return information to the RDMA layer.
+ */
+struct rdma_info {
+   unsigned int tpt_base;  /* TPT base address */
+   unsigned int tpt_top;   /* TPT last entry address */
+   unsigned int pbl_base;  /* PBL base address */
+   unsigned int pbl_top;   /* PBL last entry address */
+   unsigned int rqt_base;  /* RQT base address */
+   unsigned int rqt_top;   /* RQT last entry address */
+   unsigned int udbell_len;/* user doorbell region length */
+   unsigned long udbell_physbase;  /* user doorbell physical start addr */
+   void __iomem *kdb_addr; /* kernel doorbell register address */
+   struct pci_dev *pdev;   /* associated PCI device */
+};
+
+/*
+ * Structure used to request an operation on an RDMA completion queue.
+ */
+struct rdma_cq_op {
+   unsigned int id;
+   unsigned int op;
+   unsigned int credits;
+};
+
+/*
+ * Structure used to setup RDMA completion queues.
+ */
+struct rdma_cq_setup {
+   unsigned int id;
+   unsigned long long base_addr;
+   unsigned int size;
+   unsigned int credits;
+   unsigned int credit_thres;
+   unsigned int ovfl_mode;
+};
+
+/*
+ * Structure used to setup the RDMA control egress context.
+ */
+struct rdma_ctrlqp_setup {
+   unsigned long long base_addr;
+   unsigned int size;
+};
+#endif /* _CXGB3_OFFLOAD_CTL_DEFS_H */
diff --git a/drivers/net/cxgb3/cxgb3_defs.h b/drivers/net/cxgb3/cxgb3_defs.h
new file mode 100755
index 000..82344c2
--- /dev/null
+++ b/drivers/net/cxgb3/cxgb3_defs.h
@@ -0,0 +1,99 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 

[PATCH 4/10] cxgb3 - HW access routines - part 2

2006-12-20 Thread divy
From: Divy Le Ray <[EMAIL PROTECTED]>

This patch implements the HW access routines for the
Chelsio T3 network adapter's driver.
This patch is split. This is the second part.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
+/**
+ * t3_port_intr_enable - enable port-specific interrupts
+ * @adapter: associated adapter
+ * @idx: index of port whose interrupts should be enabled
+ *
+ * Enable port-specific (i.e., MAC and PHY) interrupts for the given
+ * adapter port.
+ */
+void t3_port_intr_enable(struct adapter *adapter, int idx)
+{
+   struct cphy *phy = &adap2pinfo(adapter, idx)->phy;
+
+   t3_write_reg(adapter, XGM_REG(A_XGM_INT_ENABLE, idx), XGM_INTR_MASK);
+   phy->ops->intr_enable(phy);
+}
+
+/**
+ * t3_port_intr_disable - disable port-specific interrupts
+ * @adapter: associated adapter
+ * @idx: index of port whose interrupts should be disabled
+ *
+ * Disable port-specific (i.e., MAC and PHY) interrupts for the given
+ * adapter port.
+ */
+void t3_port_intr_disable(struct adapter *adapter, int idx)
+{
+   struct cphy *phy = &adap2pinfo(adapter, idx)->phy;
+
+   t3_write_reg(adapter, XGM_REG(A_XGM_INT_ENABLE, idx), 0);
+   phy->ops->intr_disable(phy);
+}
+
+/**
+ * t3_port_intr_clear - clear port-specific interrupts
+ * @adapter: associated adapter
+ * @idx: index of port whose interrupts to clear
+ *
+ * Clear port-specific (i.e., MAC and PHY) interrupts for the given
+ * adapter port.
+ */
+void t3_port_intr_clear(struct adapter *adapter, int idx)
+{
+   struct cphy *phy = &adap2pinfo(adapter, idx)->phy;
+
+   t3_write_reg(adapter, XGM_REG(A_XGM_INT_CAUSE, idx), 0x);
+   phy->ops->intr_clear(phy);
+}
+
+/**
+ * t3_sge_write_context - write an SGE context
+ * @adapter: the adapter
+ * @id: the context id
+ * @type: the context type
+ *
+ * Program an SGE context with the values already loaded in the
+ * CONTEXT_DATA? registers.
+ */
+static int t3_sge_write_context(struct adapter *adapter, unsigned int id,
+   unsigned int type)
+{
+   t3_write_reg(adapter, A_SG_CONTEXT_MASK0, 0x);
+   t3_write_reg(adapter, A_SG_CONTEXT_MASK1, 0x);
+   t3_write_reg(adapter, A_SG_CONTEXT_MASK2, 0x);
+   t3_write_reg(adapter, A_SG_CONTEXT_MASK3, 0x);
+   t3_write_reg(adapter, A_SG_CONTEXT_CMD,
+V_CONTEXT_CMD_OPCODE(1) | type | V_CONTEXT(id));
+   return t3_wait_op_done(adapter, A_SG_CONTEXT_CMD, F_CONTEXT_CMD_BUSY,
+  0, 5, 1);
+}
+
+/**
+ * t3_sge_init_ecntxt - initialize an SGE egress context
+ * @adapter: the adapter to configure
+ * @id: the context id
+ * @gts_enable: whether to enable GTS for the context
+ * @type: the egress context type
+ * @respq: associated response queue
+ * @base_addr: base address of queue
+ * @size: number of queue entries
+ * @token: uP token
+ * @gen: initial generation value for the context
+ * @cidx: consumer pointer
+ *
+ * Initialize an SGE egress context and make it ready for use.  If the
+ * platform allows concurrent context operations, the caller is
+ * responsible for appropriate locking.
+ */
+int t3_sge_init_ecntxt(struct adapter *adapter, unsigned int id, int 
gts_enable,
+  enum sge_context_type type, int respq, u64 base_addr,
+  unsigned int size, unsigned int token, int gen,
+  unsigned int cidx)
+{
+   unsigned int credits = type == SGE_CNTXT_OFLD ? 0 : FW_WR_NUM;
+
+   if (base_addr & 0xfff)  /* must be 4K aligned */
+   return -EINVAL;
+   if (t3_read_reg(adapter, A_SG_CONTEXT_CMD) & F_CONTEXT_CMD_BUSY)
+   return -EBUSY;
+
+   base_addr >>= 12;
+   t3_write_reg(adapter, A_SG_CONTEXT_DATA0, V_EC_INDEX(cidx) |
+V_EC_CREDITS(credits) | V_EC_GTS(gts_enable));
+   t3_write_reg(adapter, A_SG_CONTEXT_DATA1, V_EC_SIZE(size) |
+V_EC_BASE_LO(base_addr & 0x));
+   base_addr >>= 16;
+   t3_write_reg(adapter, A_SG_CONTEXT_DATA2, base_addr);
+   base_addr >>= 32;
+   t3_write_reg(adapter, A_SG_CONTEXT_DATA3,
+V_EC_BASE_HI(base_addr & 0xf) | V_EC_RESPQ(respq) |
+V_EC_TYPE(type) | V_EC_GEN(gen) | V_EC_UP_TOKEN(token) |
+F_EC_VALID);
+   return t3_sge_write_context(adapter, id, F_EGRESS);
+}
+
+/**
+ * t3_sge_init_flcntxt - initialize an SGE free-buffer list context
+ * @adapter: the adapter to configure
+ * @id: the context id
+ * @gts_enable: whether to enable GTS for the context
+ * @base_addr: base address of queue
+ * @size: number of queue entries
+ * @bsize: size of each buffer for this queue
+ * @cong_thres: threshold to signal congestion to upstream producers
+ * @gen: initial generation value fo

[PATCH 3/10] cxgb3 - HW access routines - part 1

2006-12-20 Thread divy
From: Divy Le Ray <[EMAIL PROTECTED]>

This patch implements the HW access routines for the
Chelsio T3 network adapter's driver.
This patch is split. This is the first part.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
 drivers/net/cxgb3/t3_hw.c | 3353 +
 1 files changed, 3353 insertions(+), 0 deletions(-)

diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
new file mode 100755
index 000..3c7d97e
--- /dev/null
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -0,0 +1,3353 @@
+/*
+ * This file is part of the Chelsio T3 Ethernet driver.
+ *
+ * Copyright (C) 2003-2006 Chelsio Communications.  All rights reserved.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the LICENSE file included in this
+ * release for licensing terms and conditions.
+ */
+
+#include "common.h"
+#include "regs.h"
+#include "sge_defs.h"
+#include "firmware_exports.h"
+
+ /**
+  *t3_wait_op_done_val - wait until an operation is completed
+  *@adapter: the adapter performing the operation
+  *@reg: the register to check for completion
+  *@mask: a single-bit field within @reg that indicates completion
+  *@polarity: the value of the field when the operation is completed
+  *@attempts: number of check iterations
+  *@delay: delay in usecs between iterations
+  *@valp: where to store the value of the register at completion time
+  *
+  *Wait until an operation is completed by checking a bit in a register
+  *up to @attempts times.  If @valp is not NULL the value of the register
+  *at the time it indicated completion is stored there.  Returns 0 if the
+  *operation completes and -EAGAIN otherwise.
+  */
+
+int t3_wait_op_done_val(struct adapter *adapter, int reg, u32 mask,
+   int polarity, int attempts, int delay, u32 *valp)
+{
+   while (1) {
+   u32 val = t3_read_reg(adapter, reg);
+
+   if (!!(val & mask) == polarity) {
+   if (valp)
+   *valp = val;
+   return 0;
+   }
+   if (--attempts == 0)
+   return -EAGAIN;
+   if (delay)
+   udelay(delay);
+   }
+}
+
+/**
+ * t3_write_regs - write a bunch of registers
+ * @adapter: the adapter to program
+ * @p: an array of register address/register value pairs
+ * @n: the number of address/value pairs
+ * @offset: register address offset
+ *
+ * Takes an array of register address/register value pairs and writes each
+ * value to the corresponding register.  Register addresses are adjusted
+ * by the supplied offset.
+ */
+void t3_write_regs(struct adapter *adapter, const struct addr_val_pair *p,
+  int n, unsigned int offset)
+{
+   while (n--) {
+   t3_write_reg(adapter, p->reg_addr + offset, p->val);
+   p++;
+   }
+}
+
+/**
+ * t3_set_reg_field - set a register field to a value
+ * @adapter: the adapter to program
+ * @addr: the register address
+ * @mask: specifies the portion of the register to modify
+ * @val: the new value for the register field
+ *
+ * Sets a register field specified by the supplied mask to the
+ * given value.
+ */
+void t3_set_reg_field(struct adapter *adapter, unsigned int addr, u32 mask,
+ u32 val)
+{
+   u32 v = t3_read_reg(adapter, addr) & ~mask;
+
+   t3_write_reg(adapter, addr, v | val);
+   t3_read_reg(adapter, addr); /* flush */
+}
+
+/**
+ * t3_read_indirect - read indirectly addressed registers
+ * @adap: the adapter
+ * @addr_reg: register holding the indirect address
+ * @data_reg: register holding the value of the indirect register
+ * @vals: where the read register values are stored
+ * @start_idx: index of first indirect register to read
+ * @nregs: how many indirect registers to read
+ *
+ * Reads registers that are accessed indirectly through an address/data
+ * register pair.
+ */
+void t3_read_indirect(struct adapter *adap, unsigned int addr_reg,
+ unsigned int data_reg, u32 *vals, unsigned int nregs,
+ unsigned int start_idx)
+{
+   while (nregs--) {
+   t3_write_reg(adap, addr_reg, start_idx);
+   *vals++ = t3_read_reg(adap, data_reg);
+   start_idx++;
+   }
+}
+
+/**
+ * t3_mc7_bd_read - read from MC7 through backdoor accesses
+ * @mc7: identifies MC7 to read from
+ * @start: index of first 64-bit word to read
+ * @n: number of 64-bit words to read
+ * @buf: where to store the read result
+ *
+ * Read n 64-bit words from MC7 starting at word start, using backdoor
+ * accesses.
+ */
+int t3_mc7_bd_read(struct mc7 *m

[PATCH 1/10] cxgb3 - main header files

2006-12-20 Thread Divy Le Ray
From: Divy Le Ray <[EMAIL PROTECTED]>

This patch implements the main header files of
the Chelsio T3 network driver.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---

 drivers/net/cxgb3/adapter.h  |  255 
 drivers/net/cxgb3/common.h   |  709 ++
 drivers/net/cxgb3/cxgb3_ioctl.h  |  165 
 drivers/net/cxgb3/firmware_exports.h |  144 +++
 4 files changed, 1273 insertions(+), 0 deletions(-)

diff --git a/drivers/net/cxgb3/adapter.h b/drivers/net/cxgb3/adapter.h
new file mode 100755
index 000..16643f6
--- /dev/null
+++ b/drivers/net/cxgb3/adapter.h
@@ -0,0 +1,255 @@
+/*
+ * This file is part of the Chelsio T3 Ethernet driver for Linux.
+ *
+ * Copyright (C) 2003-2006 Chelsio Communications.  All rights reserved.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the LICENSE file included in this
+ * release for licensing terms and conditions.
+ */
+
+/* This file should not be included directly.  Include common.h instead. */
+
+#ifndef __T3_ADAPTER_H__
+#define __T3_ADAPTER_H__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "t3cdev.h"
+#include 
+#include 
+#include 
+
+typedef irqreturn_t(*intr_handler_t) (int, void *);
+
+struct vlan_group;
+
+struct port_info {
+   struct vlan_group *vlan_grp;
+   const struct port_type_info *port_type;
+   u8 port_id;
+   u8 rx_csum_offload;
+   u8 nqsets;
+   u8 first_qset;
+   struct cphy phy;
+   struct cmac mac;
+   struct link_config link_config;
+   struct net_device_stats netstats;
+   int activity;
+};
+
+enum { /* adapter flags */
+   FULL_INIT_DONE = (1 << 0),
+   USING_MSI = (1 << 1),
+   USING_MSIX = (1 << 2),
+};
+
+struct rx_desc;
+struct rx_sw_desc;
+
+struct sge_fl {/* SGE per free-buffer list state */
+   unsigned int buf_size;  /* size of each Rx buffer */
+   unsigned int credits;   /* # of available Rx buffers */
+   unsigned int size;  /* capacity of free list */
+   unsigned int cidx;  /* consumer index */
+   unsigned int pidx;  /* producer index */
+   unsigned int gen;   /* free list generation */
+   struct rx_desc *desc;   /* address of HW Rx descriptor ring */
+   struct rx_sw_desc *sdesc;   /* address of SW Rx descriptor ring */
+   dma_addr_t phys_addr;   /* physical address of HW ring start */
+   unsigned int cntxt_id;  /* SGE context id for the free list */
+   unsigned long empty;/* # of times queue ran out of buffers */
+};
+
+/*
+ * Bundle size for grouping offload RX packets for delivery to the stack.
+ * Don't make this too big as we do prefetch on each packet in a bundle.
+ */
+# define RX_BUNDLE_SIZE 8
+
+struct rsp_desc;
+
+struct sge_rspq {  /* state for an SGE response queue */
+   unsigned int credits;   /* # of pending response credits */
+   unsigned int size;  /* capacity of response queue */
+   unsigned int cidx;  /* consumer index */
+   unsigned int gen;   /* current generation bit */
+   unsigned int polling;   /* is the queue serviced through NAPI? */
+   unsigned int holdoff_tmr;   /* interrupt holdoff timer in 100ns */
+   unsigned int next_holdoff;  /* holdoff time for next interrupt */
+   struct rsp_desc *desc;  /* address of HW response ring */
+   dma_addr_t phys_addr;   /* physical address of the ring */
+   unsigned int cntxt_id;  /* SGE context id for the response q */
+   spinlock_t lock;/* guards response processing */
+   struct sk_buff *rx_head;/* offload packet receive queue head */
+   struct sk_buff *rx_tail;/* offload packet receive queue tail */
+
+   unsigned long offload_pkts;
+   unsigned long offload_bundles;
+   unsigned long eth_pkts; /* # of ethernet packets */
+   unsigned long pure_rsps;/* # of pure (non-data) responses */
+   unsigned long imm_data; /* responses with immediate data */
+   unsigned long rx_drops; /* # of packets dropped due to no mem */
+   unsigned long async_notif; /* # of asynchronous notification events */
+   unsigned long empty;/* # of times queue ran out of credits */
+   unsigned long nomem;/* # of responses deferred due to no mem */
+   unsigned long unhandled_irqs;   /* # of spurious intrs */
+};
+
+struct tx_desc;
+struct tx_sw_desc;
+
+struct sge_txq {   /* state for an SGE Tx queue */
+   unsigned long flags;/* HW DMA fetch status */
+   unsigned int in_use;/* # of in-use Tx descriptors */
+   unsigned int size;  /* # of descriptors */
+   unsigned int processed; /* total # of descs HW has processed */
+   unsigned int cleaned;   /* total # of d

[PATCH 2.6.20-rc1 00/10] TURBOchannel update to the driver model

2006-12-20 Thread Maciej W. Rozycki
Hello,

 It has been much longer than expected, but finally it is here!  This 
series of patches converts support for the TURBOchannel bus to the driver 
model.  As a nice side effect, the generic part of the code is now really 
generic, that is no more dependencies on MIPS specifics under drivers/tc/ 
and platform specific code for MIPS got moved where it belongs.  As to 
whether other relevant platforms will add TURBOchannel support or not I 
cannot tell right now. ;-)

 All the changes have been successfully tested with a DECstation 5000/133 
and the necessary bits of additional hardware as appropriate.  Where 
drivers supporting different bus attachments were concerned, they were 
built for configurations enabling all the other buses supported and 
run-time checked if possible.

 And last but not least, thanks to James Simmons for beginning this work a 
while ago as his code was great to start with.

  Maciej
-
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.20-rc1 01/10] TURBOchannel update to the driver model

2006-12-20 Thread Maciej W. Rozycki
 This is a set of changes to convert support for the TURBOchannel bus to 
the driver model.  It implements the usual set of calls similar to what 
other bus drivers have: tc_register_driver(), tc_unregister_driver(), etc.  
All the platform-specific bits have been removed and headers from 
asm-mips/dec/ have been merged into linux/tc.h, which should be included 
by drivers.

Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]>
---

 Please apply.

  Maciej

patch-mips-2.6.18-20060920-tc-sysfs-78
diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/MAINTAINERS 
linux-mips-2.6.18-20060920/MAINTAINERS
--- linux-mips-2.6.18-20060920.macro/MAINTAINERS2006-09-20 
04:56:08.0 +
+++ linux-mips-2.6.18-20060920/MAINTAINERS  2006-11-30 01:54:54.0 
+
@@ -2910,6 +2910,11 @@ L:   [EMAIL PROTECTED]
 W: http://vtun.sourceforge.net/tun
 S: Maintained
 
+TURBOCHANNEL SUBSYSTEM
+P: Maciej W. Rozycki
+M: [EMAIL PROTECTED]
+S: Maintained
+
 U14-34F SCSI DRIVER
 P: Dario Ballabio
 M: [EMAIL PROTECTED]
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/tc/Makefile 
linux-mips-2.6.18-20060920/drivers/tc/Makefile
--- linux-mips-2.6.18-20060920.macro/drivers/tc/Makefile2003-06-05 
04:03:00.0 +
+++ linux-mips-2.6.18-20060920/drivers/tc/Makefile  2006-10-03 
21:01:58.0 +
@@ -4,7 +4,7 @@
 
 # Object file lists.
 
-obj-$(CONFIG_TC) += tc.o
+obj-$(CONFIG_TC) += tc.o tc-driver.o
 obj-$(CONFIG_ZS) += zs.o
 obj-$(CONFIG_VT) += lk201.o lk201-map.o lk201-remap.o
 
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/tc/tc-driver.c 
linux-mips-2.6.18-20060920/drivers/tc/tc-driver.c
--- linux-mips-2.6.18-20060920.macro/drivers/tc/tc-driver.c 1970-01-01 
00:00:00.0 +
+++ linux-mips-2.6.18-20060920/drivers/tc/tc-driver.c   2006-12-19 
22:29:49.0 +
@@ -0,0 +1,110 @@
+/*
+ * TURBOchannel driver services.
+ *
+ * Copyright (c) 2005  James Simmons
+ * Copyright (c) 2006  Maciej W. Rozycki
+ *
+ * Loosely based on drivers/dio/dio-driver.c and
+ * drivers/pci/pci-driver.c.
+ *
+ * This file is subject to the terms and conditions of the GNU
+ * General Public License.  See the file "COPYING" in the main
+ * directory of this archive for more details.
+ */
+
+#include 
+#include 
+#include 
+
+/**
+ * tc_register_driver - register a new TC driver
+ * @drv: the driver structure to register
+ *
+ * Adds the driver structure to the list of registered drivers
+ * Returns a negative value on error, otherwise 0.
+ * If no error occurred, the driver remains registered even if
+ * no device was claimed during registration.
+ */
+int tc_register_driver(struct tc_driver *tdrv)
+{
+   return driver_register(&tdrv->driver);
+}
+EXPORT_SYMBOL(tc_register_driver);
+
+/**
+ * tc_unregister_driver - unregister a TC driver
+ * @drv: the driver structure to unregister
+ *
+ * Deletes the driver structure from the list of registered TC drivers,
+ * gives it a chance to clean up by calling its remove() function for
+ * each device it was responsible for, and marks those devices as
+ * driverless.
+ */
+void tc_unregister_driver(struct tc_driver *tdrv)
+{
+   driver_unregister(&tdrv->driver);
+}
+EXPORT_SYMBOL(tc_unregister_driver);
+
+/**
+ * tc_match_device - tell if a TC device structure has a matching
+ *   TC device ID structure
+ * @tdrv: the TC driver to earch for matching TC device ID strings
+ * @tdev: the TC device structure to match against
+ *
+ * Used by a driver to check whether a TC device present in the
+ * system is in its list of supported devices.  Returns the matching
+ * tc_device_id structure or %NULL if there is no match.
+ */
+const struct tc_device_id *tc_match_device(struct tc_driver *tdrv,
+  struct tc_dev *tdev)
+{
+   const struct tc_device_id *id = tdrv->id_table;
+
+   if (id) {
+   while (id->name[0] || id->vendor[0]) {
+   if (strcmp(tdev->name, id->name) == 0 &&
+   strcmp(tdev->vendor, id->vendor) == 0)
+   return id;
+   id++;
+   }
+   }
+   return NULL;
+}
+EXPORT_SYMBOL(tc_match_device);
+
+/**
+ * tc_bus_match - Tell if a device structure has a matching
+ *TC device ID structure
+ * @dev: the device structure to match against
+ * @drv: the device driver to search for matching TC device ID strings
+ *
+ * Used by a driver to check whether a TC device present in the
+ * system is in its list of supported devices.  Returns 1 if there
+ * is a match or 0 otherwise.
+ */
+static int tc_bus_match(struct device *dev, struct device_driver *drv)
+{
+   struct tc_dev *tdev = to_tc_dev(dev);
+   struct tc_driver *tdrv = to_tc_driver(drv);
+   const struct tc_device_id *id;
+
+   id = tc_match_device(tdrv, t

[PATCH 2.6.20-rc1 05/10] if_fddi.h: Add a missing inclusion

2006-12-20 Thread Maciej W. Rozycki
 This is a change to include  in  
which is needed for "struct fddi_statistics".

Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]>
---

 Please apply.

  Maciej

patch-mips-2.6.18-20060920-if_fddi-netdev-0
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/include/linux/if_fddi.h 
linux-mips-2.6.18-20060920/include/linux/if_fddi.h
--- linux-mips-2.6.18-20060920.macro/include/linux/if_fddi.h2006-09-20 
20:51:20.0 +
+++ linux-mips-2.6.18-20060920/include/linux/if_fddi.h  2006-12-14 
04:36:58.0 +
@@ -103,6 +103,8 @@ struct fddihdr
} __attribute__ ((packed));
 
 #ifdef __KERNEL__
+#include 
+
 /* Define FDDI statistics structure */
 struct fddi_statistics {
 
-
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.20-rc1 03/10] defxx: TURBOchannel support

2006-12-20 Thread Maciej W. Rozycki
 This is a set of changes to add TURBOchannel support to the defxx driver.  
As at this point the EISA support in the driver has become the only not 
having been converted to the driver model, I took the opportunity to 
convert it as well.  Plus support for MMIO in addition to PIO operation as 
TURBOchannel requires it anyway.

Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]>
---

 These changes have been tested at the run time with TC and PCI variations 
of the board.  EISA support has only been verified to build correctly.  I 
do believe I got it mostly right, but if there is somebody interested in 
keeping the DEFEA supported, then please send me results of testing or, 
for long-term testing, I would not mind accepting such a board either. ;-)

 Please apply.

  Maciej

patch-mips-2.6.18-20060920-defta-69
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/Kconfig 
linux-mips-2.6.18-20060920/drivers/net/Kconfig
--- linux-mips-2.6.18-20060920.macro/drivers/net/Kconfig2006-09-10 
04:55:24.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/Kconfig  2006-12-15 
22:45:17.0 +
@@ -2443,7 +2443,7 @@ config RIONET_RX_SIZE
 
 config FDDI
bool "FDDI driver support"
-   depends on (PCI || EISA)
+   depends on (PCI || EISA || TC)
help
  Fiber Distributed Data Interface is a high speed local area network
  design; essentially a replacement for high speed Ethernet. FDDI can
@@ -2453,11 +2453,31 @@ config FDDI
  will say N.
 
 config DEFXX
-   tristate "Digital DEFEA and DEFPA adapter support"
-   depends on FDDI && (PCI || EISA)
-   help
- This is support for the DIGITAL series of EISA (DEFEA) and PCI
- (DEFPA) controllers which can connect you to a local FDDI network.
+   tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
+   depends on FDDI && (PCI || EISA || TC)
+   ---help---
+ This is support for the DIGITAL series of TURBOchannel (DEFTA),
+ EISA (DEFEA) and PCI (DEFPA) controllers which can connect you
+ to a local FDDI network.
+
+ To compile this driver as a module, choose M here: the module
+ will be called defxx.  If unsure, say N.
+
+config DEFXX_MMIO
+   bool
+   prompt "Use MMIO instead of PIO" if PCI || EISA
+   depends on DEFXX
+   default n if PCI || EISA
+   default y
+   ---help---
+ This instructs the driver to use EISA or PCI memory-mapped I/O
+ (MMIO) as appropriate instead of programmed I/O ports (PIO).
+ Enabling this gives an improvement in processing time in parts
+ of the driver, but it may cause problems with EISA (DEFEA)
+ adapters.  TURBOchannel does not have the concept of I/O ports,
+ so MMIO is always used for these (DEFTA) adapters.
+
+ If unsure, say N.
 
 config SKFP
tristate "SysKonnect FDDI PCI support"
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/defxx.c 
linux-mips-2.6.18-20060920/drivers/net/defxx.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/defxx.c2006-10-23 
22:58:19.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/defxx.c  2006-12-20 
00:22:01.0 +
@@ -10,10 +10,12 @@
  *
  * Abstract:
  *   A Linux device driver supporting the Digital Equipment Corporation
- *   FDDI EISA and PCI controller families.  Supported adapters include:
+ *   FDDI TURBOchannel, EISA and PCI controller families.  Supported
+ *   adapters include:
  *
- * DEC FDDIcontroller/EISA (DEFEA)
- * DEC FDDIcontroller/PCI  (DEFPA)
+ * DEC FDDIcontroller/TURBOchannel (DEFTA)
+ * DEC FDDIcontroller/EISA (DEFEA)
+ * DEC FDDIcontroller/PCI  (DEFPA)
  *
  * The original author:
  *   LVS   Lawrence V. Stefani <[EMAIL PROTECTED]>
@@ -193,24 +195,27 @@
  * 14 Aug 2004 macro   Fix device names reported.
  * 14 Jun 2005 macro   Use irqreturn_t.
  * 23 Oct 2006 macro   Big-endian host support.
+ * 14 Dec 2006 macro   TURBOchannel support.
  */
 
 /* Include files */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
-#include 
+#include 
 #include 
-#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -219,8 +224,8 @@
 
 /* Version information string should be updated prior to each new release!  */
 #define DRV_NAME "defxx"
-#define DRV_VERSION "v1.09"
-#define DRV_RELDATE "2006/10/23"
+#define DRV_VERSION "v1.10"
+#define DRV_RELDATE "2006/12/14"
 
 static char version[] __devinitdata =
DRV_NAME ": " DRV_VERSION " " DRV_RELDATE
@@ -235,12 +240,41 @@ static char version[] __devinitdata =
  */
 #define NEW_SKB_

[PATCH 2.6.20-rc1 04/10] EISA registration with !CONFIG_EISA

2006-12-20 Thread Maciej W. Rozycki
 This is a change for the EISA bus support to permit drivers to call 
un/registration functions even if EISA support has not been enabled.  This 
is similar to what PCI (and now TC) does and reduces the need for #ifdef 
clutter.

Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]>
---

 This is required by the updated defxx driver.

 Please apply.

  Maciej

patch-mips-2.6.18-20060920-eisa-register-0
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/include/linux/eisa.h 
linux-mips-2.6.18-20060920/include/linux/eisa.h
--- linux-mips-2.6.18-20060920.macro/include/linux/eisa.h   2003-10-10 
04:00:31.0 +
+++ linux-mips-2.6.18-20060920/include/linux/eisa.h 2006-12-14 
22:43:31.0 +
@@ -67,10 +67,20 @@ struct eisa_driver {
 
 #define to_eisa_driver(drv) container_of(drv,struct eisa_driver, driver)
 
+/* These external functions are only available when EISA support is enabled. */
+#ifdef CONFIG_EISA
+
 extern struct bus_type eisa_bus_type;
 int eisa_driver_register (struct eisa_driver *edrv);
 void eisa_driver_unregister (struct eisa_driver *edrv);
 
+#else /* !CONFIG_EISA */
+
+static inline int eisa_driver_register (struct eisa_driver *edrv) { return 0; }
+static inline void eisa_driver_unregister (struct eisa_driver *edrv) { }
+
+#endif /* !CONFIG_EISA */
+
 /* Mimics pci.h... */
 static inline void *eisa_get_drvdata (struct eisa_device *edev)
 {
-
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] d80211: fix softlockup in hw_scan card when rmmod

2006-12-20 Thread Jiri Benc
On Wed, 20 Dec 2006 14:43:51 +0800, Hong Liu wrote:
> The local->scan_work.data is not clear after scan is completed.
> 
> This will cause softlockup when removing driver module because 
> the local->scan_work is not initialized for hw_scan card
> and we are trying to cancel the scan_work with an uninitialized timer_list.

I think this is a better fix:
---
Subject: [PATCH] d80211: do not cancel uninitialized work

When ops->hw_scan is set, scan_work is never initialized thus canceling it
causes weird problems.

Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>

---
 net/d80211/ieee80211.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

--- dscape.orig/net/d80211/ieee80211.c
+++ dscape/net/d80211/ieee80211.c
@@ -2082,7 +2082,8 @@ void ieee80211_if_shutdown(struct net_de
case IEEE80211_IF_TYPE_IBSS:
sdata->u.sta.state = IEEE80211_DISABLED;
cancel_delayed_work(&sdata->u.sta.work);
-   if (local->scan_work.data == sdata->dev) {
+   if (!local->ops->hw_scan &&
+   local->scan_work.data == sdata->dev) {
local->sta_scanning = 0;
cancel_delayed_work(&local->scan_work);
flush_scheduled_work();
@@ -4660,7 +4661,7 @@ void ieee80211_unregister_hw(struct ieee
 
if (local->stat_time)
del_timer_sync(&local->stat_timer);
-   if (local->scan_work.data) {
+   if (!local->ops->hw_scan && local->scan_work.data) {
local->sta_scanning = 0;
cancel_delayed_work(&local->scan_work);
flush_scheduled_work();


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


ND unsolicited NAs when address is added?

2006-12-20 Thread Pekka Savola

Hi,

RFC2461 specifies in section 7.2.6 that a host may send unsolicited 
NA(s) for example when its link layer address changes or IP address is 
added to inform the neighbors that their ND cache may need to be 
updated.


Some current routers (probably) erroneously depend on this to reduce 
the "downtime" if an IP address is moved from one host to another 
(otherwise they'll continue to forward packets to the old link-layer 
address until their ND cache timeouts).


I tested this behaviour on Linux 2.6.18 and FreeBSD 6.2 and neither 
sends these unsolicited NAs when an IP address is configured.  Is 
there a reason not to add this optimization?


--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-
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] d80211: fix get_tsf call

2006-12-20 Thread Jiri Benc
On Wed, 20 Dec 2006 16:04:25 +0800, Hong Liu wrote:
> get_tsf passes the wrong pointer to driver.

Already fixed, see commit 0690925f2f99f6d43322ec8507eaabdcf1435c3c.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ipw2100: Fix dropping fragmented small packet problem

2006-12-20 Thread Zhu Yi
The rx_data.header struct is ieee80211_hdr_4addr. If a wireless frame uses
ieee80211_hdr_3addr header and is less than 6 bytes, it will be discarded.
This is not likely going to happen for normal packets (since there is TCP, IP
headers). But if fragmentation is used, there will be such small trailing
packets. And they will be lost for ever.

Signed-off-by: Zhu Yi <[EMAIL PROTECTED]>

diff -urp ipw2100-1.2.1/ipw2100.c ipw2100-1.2.1-frag/ipw2100.c
--- ipw2100-1.2.1/ipw2100.c 2006-02-22 02:46:17.0 +0800
+++ ipw2100-1.2.1-frag/ipw2100.c2006-12-15 17:16:15.0 +0800
@@ -2658,7 +2658,7 @@ static void __ipw2100_rx_process(struct 
break;
}
 #endif
-   if (stats.len < sizeof(u->rx_data.header))
+   if (stats.len < sizeof(struct ieee80211_hdr_3addr))
break;
switch (WLAN_FC_GET_TYPE(u->rx_data.header.frame_ctl)) {
case IEEE80211_FTYPE_MGMT:
-
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] d80211: fix get_tsf call

2006-12-20 Thread Hong Liu
get_tsf passes the wrong pointer to driver.


Signed-off-by: Hong Liu <[EMAIL PROTECTED]>

diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index 3b55427..e48295e 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -2482,7 +2482,7 @@ #ifdef CONFIG_D80211_IBSS_DEBUG
static unsigned long last_tsf_debug = 0;
u64 tsf;
if (local->ops->get_tsf)
-   tsf = local->ops->get_tsf(local->mdev);
+   tsf = local->ops->get_tsf(local_to_hw(local));
else
tsf = -1LLU;
if (time_after(jiffies, last_tsf_debug + 5 * HZ)) {
-
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