* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Rusty Russell @ 2006-04-29 0:10 UTC (permalink / raw)
To: David S. Miller; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <20060428.153833.68265167.davem@davemloft.net>
On Fri, 2006-04-28 at 15:38 -0700, David S. Miller wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
> Date: Sat, 29 Apr 2006 08:04:04 +1000
>
> > You're still thinking you can bypass classifiers for established
> > sockets, but I really don't think you can. I think the simplest
> > solution is to effectively remove from (or flag) the established &
> > listening hashes anything which could be effected by classifiers, so
> > those packets get send through the default channel.
>
> OK, when rules are installed, the socket channel mappings are
> flushed. This is your idea right?
Yeah. First off, all flushed. Later on, we get selective.
Rusty.
--
ccontrol: http://ozlabs.org/~rusty/ccontrol
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Rusty Russell @ 2006-04-29 0:22 UTC (permalink / raw)
To: David S. Miller; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <20060428.154003.25335370.davem@davemloft.net>
On Fri, 2006-04-28 at 15:40 -0700, David S. Miller wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
> Date: Sat, 29 Apr 2006 08:17:01 +1000
> > However, in future, if intelligent cards exist, having an API which lets
> > them do zero-copy and not overly penalize less intelligent cards makes
> > sense.
>
> I do not think intelligent cards imply protocol in user space.
> You can still get the zero copy, and moving the work to the
> remote cpu, without all the complexity assosciated with putting
> the protocol in userspace. It buys nothing but complexity.
You're thinking the card would place the packet in the mmap'ed buffer,
but the protocol handling would still be done (on that user-accessible
buffer) in kernelspace?
I hadn't considered that. Are the userspace-kernel interactions here
are a lesser problem than telling userspace "you want direct access to
the packets? Great, *you* handle the whole thing".
I am thinking the big payoff for this would be MPI et al (RDMA), so we
might be best leaving it alone.
> > Side note: my Xen I/O patches allow the implementation of exactly this
> > kind of virtual hardware (no coincidence 8), so intelligent cards might
> > not be as far away as you think...
>
> Such hardware can be prototyped in QEMU as well.
Absolutely (and writing QEMU devices is easier than writing a Linux
device driver, which says something sad).
But the Xen virtual intelligent NIC would be a "real" NIC, not (just) a
prototype.
Cheers!
Rusty.
--
ccontrol: http://ozlabs.org/~rusty/ccontrol
^ permalink raw reply
* Re: [RFC] Geographical/regulatory information for ieee80211
From: Jouni Malinen @ 2006-04-29 0:31 UTC (permalink / raw)
To: Larry Finger; +Cc: Rick Jones, Christoph Hellwig, netdev
In-Reply-To: <44501647.8070308@lwfinger.net>
On Wed, Apr 26, 2006 at 07:54:31PM -0500, Larry Finger wrote:
> I don't think it would make that much difference as the user could easily
> lie about their locality and get any set of parameters that they wanted.
Well, not any set.. One of the configured countries, yes, but that is
not same as setting arbitrary TX power limit and allowed channel sets..
Anyway, users should be allowed to move from one country to another and
still being able to use their wlan card (within the limits of the
current location).
> I am leaning toward putting the geographical information into a userland
> daemon. That way we won't have to patch the kernel every time a country
> modifies its regulations. In addition, the kernel will be smaller. The
> downside is that the daemon will have to be updated and supplied in some
> convenient form, perhaps as part of a wireless tools package.
I'm strongly in favor of doing this in user space, too. In order to
provide some control on what end users do with this, I would consider
including a signature on a data file and have the user space tool verify
that signature before accepting the data. This signature need not be
anything extra secure, i.e., it could just be a keyed checksum of the
file using a well-known key. The main point here is that it shows some
attempt on limiting end users from setting random values to regulatory
limits. Of course, if someone really wants to change these values, they
could do so since the source code for the tool would be available and so
would the key used for signing the file in the first place.
I don't know how secure a system would be needed to pass requirements
that FCC and similar organizations place on wireless devices. I would
like to handle this with fully open source tools and having some kind of
simple signature on the data file would be good starting point. It is up
to vendors then to decide whether they are fine with such a mechanism or
whether some additional tool (like the Intel plan on using a closed
source user space tool) would be needed on top of this.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* [PATCH 1/6] tg3: Call netif_carrier_off() during phy reset
From: Michael Chan @ 2006-04-28 23:35 UTC (permalink / raw)
To: davem; +Cc: netdev
Add netif_carrier_off() call during tg3_phy_reset(). This is needed
to properly track the netif_carrier state in cases where we do a
PHY reset with interrupts disabled. The SerDes code will not run
properly if the netif_carrier state is wrong.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 73e271e..a28accb 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -974,6 +974,8 @@ static int tg3_phy_reset_5703_4_5(struct
return err;
}
+static void tg3_link_report(struct tg3 *);
+
/* This will reset the tigon3 PHY if there is no valid
* link unless the FORCE argument is non-zero.
*/
@@ -987,6 +989,11 @@ static int tg3_phy_reset(struct tg3 *tp)
if (err != 0)
return -EBUSY;
+ if (netif_running(tp->dev) && netif_carrier_ok(tp->dev)) {
+ netif_carrier_off(tp->dev);
+ tg3_link_report(tp);
+ }
+
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703 ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704 ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) {
^ permalink raw reply related
* [PATCH 2/6] tg3: Add phy workaround
From: Michael Chan @ 2006-04-28 23:35 UTC (permalink / raw)
To: davem; +Cc: netdev
Add some PHY workaround code to reduce jitter on some PHYs.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index a28accb..a307340 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1030,6 +1030,12 @@ out:
tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x14e2);
tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0400);
}
+ else if (tp->tg3_flags2 & TG3_FLG2_PHY_JITTER_BUG) {
+ tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0c00);
+ tg3_writephy(tp, MII_TG3_DSP_ADDRESS, 0x000a);
+ tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x010b);
+ tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0400);
+ }
/* Set Extended packet length bit (bit 14) on all chips that */
/* support jumbo frames */
if ((tp->phy_id & PHY_ID_MASK) == PHY_ID_BCM5401) {
@@ -10360,10 +10366,13 @@ static int __devinit tg3_get_invariants(
if (tp->pci_chip_rev_id == CHIPREV_ID_5704_A0)
tp->tg3_flags2 |= TG3_FLG2_PHY_5704_A0_BUG;
- if ((tp->tg3_flags2 & TG3_FLG2_5705_PLUS) &&
- (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5755) &&
- (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5787))
- tp->tg3_flags2 |= TG3_FLG2_PHY_BER_BUG;
+ if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) {
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5755 ||
+ GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5787)
+ tp->tg3_flags2 |= TG3_FLG2_PHY_JITTER_BUG;
+ else
+ tp->tg3_flags2 |= TG3_FLG2_PHY_BER_BUG;
+ }
tp->coalesce_mode = 0;
if (GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5700_AX &&
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 8c8b987..0e29b88 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2215,6 +2215,7 @@ struct tg3 {
#define TG3_FLG2_HW_TSO_2 0x08000000
#define TG3_FLG2_HW_TSO (TG3_FLG2_HW_TSO_1 | TG3_FLG2_HW_TSO_2)
#define TG3_FLG2_1SHOT_MSI 0x10000000
+#define TG3_FLG2_PHY_JITTER_BUG 0x20000000
u32 split_mode_max_reqs;
#define SPLIT_MODE_5704_MAX_REQ 3
^ permalink raw reply related
* [PATCH 3/6] tg3: Reset chip when changing MAC address
From: Michael Chan @ 2006-04-28 23:35 UTC (permalink / raw)
To: davem; +Cc: netdev
Do the full chip reset when changing MAC address if ASF is enabled.
ASF sometimes uses a different MAC address than the driver. Without
the reset, the ASF MAC address may be overwritten when the driver's
MAC address is changed.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index a307340..0ccfb63 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -5732,9 +5732,23 @@ static int tg3_set_mac_addr(struct net_d
if (!netif_running(dev))
return 0;
- spin_lock_bh(&tp->lock);
- __tg3_set_mac_addr(tp);
- spin_unlock_bh(&tp->lock);
+ if (tp->tg3_flags & TG3_FLAG_ENABLE_ASF) {
+ /* Reset chip so that ASF can re-init any MAC addresses it
+ * needs.
+ */
+ tg3_netif_stop(tp);
+ tg3_full_lock(tp, 1);
+
+ tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
+ tg3_init_hw(tp);
+
+ tg3_netif_start(tp);
+ tg3_full_unlock(tp);
+ } else {
+ spin_lock_bh(&tp->lock);
+ __tg3_set_mac_addr(tp);
+ spin_unlock_bh(&tp->lock);
+ }
return 0;
}
^ permalink raw reply related
* [PATCH 4/6] tg3: Add reset_phy parameter to chip reset functions
From: Michael Chan @ 2006-04-28 23:36 UTC (permalink / raw)
To: davem; +Cc: netdev
Add a reset_phy parameter to tg3_reset_hw() and tg3_init_hw(). With
the full chip reset during MAC address change, the automatic PHY reset
during chip reset will cause a link down and bonding will not work
properly as a result. With this reset_phy parameter, we can do a chip
reset without link down when changing MAC address or MTU.
Signed-off-by: Gary Zambrano <zambrano@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0ccfb63..97e27d8 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3544,7 +3544,7 @@ static irqreturn_t tg3_test_isr(int irq,
return IRQ_RETVAL(0);
}
-static int tg3_init_hw(struct tg3 *);
+static int tg3_init_hw(struct tg3 *, int);
static int tg3_halt(struct tg3 *, int, int);
#ifdef CONFIG_NET_POLL_CONTROLLER
@@ -3580,7 +3580,7 @@ static void tg3_reset_task(void *_data)
tp->tg3_flags2 &= ~TG3_FLG2_RESTART_TIMER;
tg3_halt(tp, RESET_KIND_SHUTDOWN, 0);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
@@ -4055,7 +4055,7 @@ static int tg3_change_mtu(struct net_dev
tg3_set_mtu(dev, tp, new_mtu);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 0);
tg3_netif_start(tp);
@@ -5740,7 +5740,7 @@ static int tg3_set_mac_addr(struct net_d
tg3_full_lock(tp, 1);
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 0);
tg3_netif_start(tp);
tg3_full_unlock(tp);
@@ -5798,7 +5798,7 @@ static void __tg3_set_coalesce(struct tg
}
/* tp->lock is held. */
-static int tg3_reset_hw(struct tg3 *tp)
+static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
{
u32 val, rdmac_mode;
int i, err, limit;
@@ -5813,7 +5813,7 @@ static int tg3_reset_hw(struct tg3 *tp)
tg3_abort_hw(tp, 1);
}
- if (tp->tg3_flags2 & TG3_FLG2_MII_SERDES)
+ if ((tp->tg3_flags2 & TG3_FLG2_MII_SERDES) && reset_phy)
tg3_phy_reset(tp);
err = tg3_chip_reset(tp);
@@ -6354,7 +6354,7 @@ static int tg3_reset_hw(struct tg3 *tp)
tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl);
}
- err = tg3_setup_phy(tp, 1);
+ err = tg3_setup_phy(tp, reset_phy);
if (err)
return err;
@@ -6427,7 +6427,7 @@ static int tg3_reset_hw(struct tg3 *tp)
/* Called at device open time to get the chip ready for
* packet processing. Invoked with tp->lock held.
*/
-static int tg3_init_hw(struct tg3 *tp)
+static int tg3_init_hw(struct tg3 *tp, int reset_phy)
{
int err;
@@ -6440,7 +6440,7 @@ static int tg3_init_hw(struct tg3 *tp)
tw32(TG3PCI_MEM_WIN_BASE_ADDR, 0);
- err = tg3_reset_hw(tp);
+ err = tg3_reset_hw(tp, reset_phy);
out:
return err;
@@ -6710,7 +6710,7 @@ static int tg3_test_msi(struct tg3 *tp)
tg3_full_lock(tp, 1);
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- err = tg3_init_hw(tp);
+ err = tg3_init_hw(tp, 1);
tg3_full_unlock(tp);
@@ -6775,7 +6775,7 @@ static int tg3_open(struct net_device *d
tg3_full_lock(tp, 0);
- err = tg3_init_hw(tp);
+ err = tg3_init_hw(tp, 1);
if (err) {
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
tg3_free_rings(tp);
@@ -7866,7 +7866,7 @@ static int tg3_set_ringparam(struct net_
if (netif_running(dev)) {
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
}
@@ -7911,7 +7911,7 @@ static int tg3_set_pauseparam(struct net
if (netif_running(dev)) {
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
}
@@ -8549,7 +8549,7 @@ static int tg3_test_loopback(struct tg3
if (!netif_running(tp->dev))
return TG3_LOOPBACK_FAILED;
- tg3_reset_hw(tp);
+ tg3_reset_hw(tp, 1);
if (tg3_run_loopback(tp, TG3_MAC_LOOPBACK))
err |= TG3_MAC_LOOPBACK_FAILED;
@@ -8623,7 +8623,7 @@ static void tg3_self_test(struct net_dev
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
if (netif_running(dev)) {
tp->tg3_flags |= TG3_FLAG_INIT_COMPLETE;
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
}
@@ -11599,7 +11599,7 @@ static int tg3_suspend(struct pci_dev *p
tg3_full_lock(tp, 0);
tp->tg3_flags |= TG3_FLAG_INIT_COMPLETE;
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tp->timer.expires = jiffies + tp->timer_offset;
add_timer(&tp->timer);
@@ -11633,7 +11633,7 @@ static int tg3_resume(struct pci_dev *pd
tg3_full_lock(tp, 0);
tp->tg3_flags |= TG3_FLAG_INIT_COMPLETE;
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tp->timer.expires = jiffies + tp->timer_offset;
add_timer(&tp->timer);
^ permalink raw reply related
* [PATCH 5/6] tg3: Fix bug in nvram write
From: Michael Chan @ 2006-04-28 23:36 UTC (permalink / raw)
To: davem; +Cc: netdev
Fix bug in nvram write function. If the starting nvram address offset
happens to be the last dword of the page, the NVRAM_CMD_LAST bit will
not get set in the existing code. This patch fixes the bug by changing
the "else if" to "if" so that the last dword condition always gets
checked.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 97e27d8..0779544 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -9404,7 +9404,7 @@ static int tg3_nvram_write_block_buffere
if ((page_off == 0) || (i == 0))
nvram_cmd |= NVRAM_CMD_FIRST;
- else if (page_off == (tp->nvram_pagesize - 4))
+ if (page_off == (tp->nvram_pagesize - 4))
nvram_cmd |= NVRAM_CMD_LAST;
if (i == (len - 4))
^ permalink raw reply related
* [PATCH 6/6] tg3: Update version and reldate
From: Michael Chan @ 2006-04-28 23:36 UTC (permalink / raw)
To: davem; +Cc: netdev
Update version to 3.57.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0779544..beeb612 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -69,8 +69,8 @@
#define DRV_MODULE_NAME "tg3"
#define PFX DRV_MODULE_NAME ": "
-#define DRV_MODULE_VERSION "3.56"
-#define DRV_MODULE_RELDATE "Apr 1, 2006"
+#define DRV_MODULE_VERSION "3.57"
+#define DRV_MODULE_RELDATE "Apr 28, 2006"
#define TG3_DEF_MAC_MODE 0
#define TG3_DEF_RX_MODE 0
^ permalink raw reply related
* Re: [PATCH] PCI Error Recovery: e100 network device driver
From: Zhang, Yanmin @ 2006-04-29 2:48 UTC (permalink / raw)
To: Linas Vepstas
Cc: Jeff Garzik, netdev, linux-pci, LKML, linuxppc-dev, john.ronciak,
jesse.brandeburg, jeffrey.t.kirsher
In-Reply-To: <20060406222359.GA30037@austin.ibm.com>
On Fri, 2006-04-07 at 06:24, Linas Vepstas wrote:
> Please apply and forward upstream.
>
> --linas
>
> [PATCH] PCI Error Recovery: e100 network device driver
>
> Various PCI bus errors can be signaled by newer PCI controllers. This
> patch adds the PCI error recovery callbacks to the intel ethernet e100
> device driver. The patch has been tested, and appears to work well.
>
> Signed-off-by: Linas Vepstas <linas@linas.org>
> Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
I am enabling PCI-Express AER (Advanced Error Reporting) in kernel and
glad to see many drivers to support pci error handling.
>
> ----
>
> drivers/net/e100.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 65 insertions(+)
>
> Index: linux-2.6.17-rc1/drivers/net/e100.c
> ===================================================================
> --- linux-2.6.17-rc1.orig/drivers/net/e100.c 2006-04-05 09:56:06.000000000 -0500
> +++ linux-2.6.17-rc1/drivers/net/e100.c 2006-04-06 15:17:29.000000000 -0500
> @@ -2781,6 +2781,70 @@ static void e100_shutdown(struct pci_dev
> }
>
>
> +/* ------------------ PCI Error Recovery infrastructure -------------- */
> +/** e100_io_error_detected() is called when PCI error is detected */
> +static pci_ers_result_t e100_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state)
> +{
> + struct net_device *netdev = pci_get_drvdata(pdev);
> +
> + /* Same as calling e100_down(netdev_priv(netdev)), but generic */
> + netdev->stop(netdev);
e100 stop method e100_close calls e100_down which would do IO. Does it
violate the rule defined in Documentation/pci-error-recovery.txt that
error_detected shouldn't do any IO?
Suggest to create a new function, such like e100_close_noreset.
> +
> + /* Detach; put netif into state similar to hotplug unplug */
> + netif_poll_enable(netdev);
> + netif_device_detach(netdev);
> +
> + /* Request a slot reset. */
> + return PCI_ERS_RESULT_NEED_RESET;
> +}
> +
> +/** e100_io_slot_reset is called after the pci bus has been reset.
> + * Restart the card from scratch. */
> +static pci_ers_result_t e100_io_slot_reset(struct pci_dev *pdev)
> +{
> + struct net_device *netdev = pci_get_drvdata(pdev);
> + struct nic *nic = netdev_priv(netdev);
> +
> + if(pci_enable_device(pdev)) {
> + printk(KERN_ERR "e100: Cannot re-enable PCI device after reset.\n");
> + return PCI_ERS_RESULT_DISCONNECT;
> + }
> + pci_set_master(pdev);
> +
> + /* Only one device per card can do a reset */
> + if (0 != PCI_FUNC (pdev->devfn))
> + return PCI_ERS_RESULT_RECOVERED;
> + e100_hw_reset(nic);
> + e100_phy_init(nic);
Should pci_set_master be called after e100_hw_reset like in function
e100_probe?
> +
> + return PCI_ERS_RESULT_RECOVERED;
> +}
> +
> +/** e100_io_resume is called when the error recovery driver
> + * tells us that its OK to resume normal operation.
> + */
> +static void e100_io_resume(struct pci_dev *pdev)
> +{
> + struct net_device *netdev = pci_get_drvdata(pdev);
> + struct nic *nic = netdev_priv(netdev);
> +
> + /* ack any pending wake events, disable PME */
> + pci_enable_wake(pdev, 0, 0);
> +
> + netif_device_attach(netdev);
> + if(netif_running(netdev)) {
> + e100_open (netdev);
> + mod_timer(&nic->watchdog, jiffies);
e100_open calls e100_up which already sets watchdog timer. Why to set
it again?
> + }
> +}
> +
^ permalink raw reply
* RE: [PATCH] PCI Error Recovery: e1000 network device driver
From: Zhang, Yanmin @ 2006-04-29 3:26 UTC (permalink / raw)
To: Linas Vepstas, Greg KH
Cc: Jeff Garzik, Ronciak, John, Brandeburg, Jesse, Kirsher, Jeffrey T,
linux-kernel, netdev, linux-pci, linuxppc-dev, Linux NICS
>>-----Original Message-----
>>From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Linas Vepstas
>>Sent: 2006年3月25日 11:22
>>To: Greg KH
>>Cc: Jeff Garzik; Ronciak, John; Brandeburg, Jesse; Kirsher, Jeffrey T; linux-kernel@vger.kernel.org; netdev@vger.kernel.org;
>>linux-pci@atrey.karlin.mff.cuni.cz; linuxppc-dev@ozlabs.org; Linux NICS
>>Subject: Re: [PATCH] PCI Error Recovery: e1000 network device driver
>>
>>On Fri, Mar 24, 2006 at 06:22:06PM -0800, Greg KH wrote:
>>> ... a bit
>>> different from the traditional kernel coding style.
>>
>>Sorry, this is due to inattention on my part; I get cross-eyed
>>after staring at the same code for too long. The patch below should
>>fix things.
>>
>>--linas
>>
>>
>>[PATCH] PCI Error Recovery: e1000 network device driver
>>
>>Various PCI bus errors can be signaled by newer PCI controllers. This
>>patch adds the PCI error recovery callbacks to the intel gigabit
>>ethernet e1000 device driver. The patch has been tested, and appears
>>to work well.
>>
>>Signed-off-by: Linas Vepstas <linas@linas.org>
>>Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
>>
>>----
>>
>> drivers/net/e1000/e1000_main.c | 114 ++++++++++++++++++++++++++++++++++++++++-
>> 1 files changed, 113 insertions(+), 1 deletion(-)
>>
>>Index: linux-2.6.16-git6/drivers/net/e1000/e1000_main.c
>>===================================================================
>>--- linux-2.6.16-git6.orig/drivers/net/e1000/e1000_main.c 2006-03-23 15:48:01.000000000 -0600
>>+++ linux-2.6.16-git6/drivers/net/e1000/e1000_main.c 2006-03-24 15:14:40.431371705 -0600
>>@@ -226,6 +226,16 @@ static int e1000_resume(struct pci_dev *
>>+/**
>>+ * e1000_io_error_detected - called when PCI error is detected
>>+ * @pdev: Pointer to PCI device
>>+ * @state: The current pci conneection state
>>+ *
>>+ * This function is called after a PCI bus error affecting
>>+ * this device has been detected.
>>+ */
>>+static pci_ers_result_t e1000_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state)
>>+{
>>+ struct net_device *netdev = pci_get_drvdata(pdev);
>>+ struct e1000_adapter *adapter = netdev->priv;
>>+
>>+ netif_device_detach(netdev);
>>+
>>+ if (netif_running(netdev))
>>+ e1000_down(adapter);
[YM] e1000_down will do device IO. So it's not appropriate to do so here.
>>+
>>+ /* Request a slot slot reset. */
>>+ return PCI_ERS_RESULT_NEED_RESET;
>>+}
>>+
>>+/**
>>+ * e1000_io_slot_reset - called after the pci bus has been reset.
>>+ * @pdev: Pointer to PCI device
>>+ *
>>+ * Restart the card from scratch, as if from a cold-boot. Implementation
>>+ * resembles the first-half of the e1000_resume routine.
>>+ */
>>+static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev)
>>+{
>>+ struct net_device *netdev = pci_get_drvdata(pdev);
>>+ struct e1000_adapter *adapter = netdev->priv;
>>+
>>+ if (pci_enable_device(pdev)) {
>>+ printk(KERN_ERR "e1000: Cannot re-enable PCI device after reset.\n");
>>+ return PCI_ERS_RESULT_DISCONNECT;
>>+ }
>>+ pci_set_master(pdev);
>>+
>>+ pci_enable_wake(pdev, 3, 0);
>>+ pci_enable_wake(pdev, 4, 0); /* 4 == D3 cold */
[YM] Suggest using PCI_D3hot and PCI_D3cold instead of hard-coded numbers.
^ permalink raw reply
* Re: E1000 stopped transmitting in rc3.
From: Jim McCullough @ 2006-04-29 6:46 UTC (permalink / raw)
To: Auke Kok; +Cc: David S. Miller, davej, netdev
In-Reply-To: <39fa70c7844cbb7240b98446e0940de7@localhost>
>From what I have seen currently, the issue is resolved. Based on a
test across multiple systems on x86-64, i386, and ia64 builds.
On 4/28/06, Auke Kok <sofar@foo-projects.org> wrote:
>
>
> On Fri, 28 Apr 2006 00:14:40 -0700 (PDT), "David S. Miller" <davem@davemloft.net> wrote:
> > From: Auke Kok <sofar@foo-projects.org>
> > Date: Thu, 27 Apr 2006 18:54:28 -0700
> >
> >> Dave Jones wrote:
> >> > With 2.6.17-rc3, my E1000 won't get a dhcp lease.
> >> > Looking at tcpdump and ifconfig output, it's easy to see why.
> >> > It's recieving packets, but the packets transmitted field
> >> > of ifconfig never increases.
> >> >
> >> > The last version I have built that worked ok was 2.6.17rc2-git3
> >>
> >> *puzzled*
> >>
> >> the only patch between 2.6.17rc2 and 2.6.17rc3 contains an rx-path
> > patch, but
> >> nothing that affects tx. All the other patches sent earlier are queued
> > for
> >> 2.6.18 so they don't apply.
> >
> > If the rx path is corrupting the packets or providing bad
> > checksums, there will be nothing to transmit back.
> >
> > So RX changes could explain the behavior.
>
> Jim sent me a private message that his colleagues messed up the build, and that it is working correctly now, right Jim?
>
> Cheers,
>
> Auke
>
>
>
--
Jim McCullough
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-29 6:46 UTC (permalink / raw)
To: rusty; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <1146270160.8029.78.camel@localhost.localdomain>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Sat, 29 Apr 2006 10:22:40 +1000
> You're thinking the card would place the packet in the mmap'ed buffer,
> but the protocol handling would still be done (on that user-accessible
> buffer) in kernelspace?
Exactly.
> I hadn't considered that. Are the userspace-kernel interactions here
> are a lesser problem than telling userspace "you want direct access to
> the packets? Great, *you* handle the whole thing".
I've very much weary of putting a second TCP stack in userspace
for the same reasons most folks are weary of TOE.
And frankly we should only go towards that kind of duplication if it
shows a real performance gain.
Nevertheless I do highly encourage folks to experiment with that
as much as possible, I could be dead wrong on my hunch that it
won't help enough to justify allowing it.
^ permalink raw reply
* Re: [PATCH] rt2x00: Compile fix and kernel version cleanup
From: Ivo van Doorn @ 2006-04-29 9:26 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
In-Reply-To: <200604282052.44767.IvDoorn@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
On Friday 28 April 2006 20:52, Ivo van Doorn wrote:
> From: Ivo van Doorn <IvDoorn@gmail.com>
>
> During CVS merge I noticed several compilation errors have sneaked
> into the git version of rt2x00.
> - PRIO_ENTRIES define has been removed, TX_ENTRIES should be used
> - poll_delay module argument is of the type short
> - Remove LINUX_VERSION_CODE checks.
> - Fix missing byteordering type
> - Fix typo in usb_device
>
> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Please drop this patch, I'll resend a correct verion in a few minutes.
The LINUX_VERSION_CODE checks removal was obviously wrong.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH RESEND] rt2x00: Compile fix and kernel version cleanup
From: Ivo van Doorn @ 2006-04-29 9:36 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
In-Reply-To: <200604291126.56978.IvDoorn@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5791 bytes --]
From: Ivo van Doorn <IvDoorn@gmail.com>
During CVS merge I noticed several compilation errors have sneaked
into the git version of rt2x00.
- PRIO_ENTRIES define has been removed, TX_ENTRIES should be used
- poll_delay module argument is of the type short
- Remove LINUX_VERSION_CODE checks.
- Fix missing byteordering type
- Fix typo in usb_device
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-04-29 11:30:00.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-04-29 11:31:06.000000000 +0200
@@ -1239,7 +1239,7 @@ rt2400pci_allocate_rings(struct rt2x00_p
ATIM_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2400pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_PRIO], rt2400pci_txdone,
- PRIO_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
+ TX_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2400pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_BEACON], rt2400pci_beacondone,
BEACON_ENTRIES, MGMT_FRAME_SIZE, sizeof(struct txd))) {
@@ -2729,14 +2729,11 @@ MODULE_PARM_DESC(debug, "Set this parame
#endif /* CONFIG_RT2400PCI_DEBUG */
#ifdef CONFIG_RT2400PCI_BUTTON
-module_param_named(poll_delay, rt2x00_poll_delay, int, S_IRUGO);
+module_param_named(poll_delay, rt2x00_poll_delay, short, S_IRUGO);
MODULE_PARM_DESC(debug, "Delay between WiFi button pollings (in 100ms).");
#endif /* CONFIG_RT2400PCI_BUTTON */
static struct pci_driver rt2400pci_driver = {
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14)
- .owner = THIS_MODULE,
-#endif /* LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14) */
.name = DRV_NAME,
.id_table = rt2400pci_device_table,
.probe = rt2400pci_probe,
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-04-29 11:30:00.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-04-29 11:31:00.000000000 +0200
@@ -1328,7 +1328,7 @@ rt2500pci_allocate_rings(struct rt2x00_p
ATIM_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2500pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_PRIO], rt2500pci_txdone,
- PRIO_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
+ TX_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2500pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_BEACON], rt2500pci_beacondone,
BEACON_ENTRIES, MGMT_FRAME_SIZE, sizeof(struct txd))) {
@@ -3032,14 +3032,11 @@ MODULE_PARM_DESC(debug, "Set this parame
#endif /* CONFIG_RT2500PCI_DEBUG */
#ifdef CONFIG_RT2500PCI_BUTTON
-module_param_named(poll_delay, rt2x00_poll_delay, int, S_IRUGO);
+module_param_named(poll_delay, rt2x00_poll_delay, short, S_IRUGO);
MODULE_PARM_DESC(debug, "Delay between WiFi button pollings (in 100ms).");
#endif /* CONFIG_RT2500PCI_BUTTON */
static struct pci_driver rt2500pci_driver = {
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14)
- .owner = THIS_MODULE,
-#endif /* LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14) */
.name = DRV_NAME,
.id_table = rt2500pci_device_table,
.probe = rt2500pci_probe,
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.h wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.h 2006-04-29 11:29:58.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.h 2006-04-29 11:30:39.000000000 +0200
@@ -1005,7 +1005,7 @@ struct txd{
__le32 word1;
#define TXD_W1_BUFFER_ADDRESS FIELD32(0xffffffff)
- u32 word2;
+ __le32 word2;
#define TXD_W2_IV_OFFSET FIELD32(0x0000003f)
#define TXD_W2_AIFS FIELD32(0x000000c0)
#define TXD_W2_CWMIN FIELD32(0x00000f00)
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c 2006-04-29 11:30:00.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500usb.c 2006-04-29 11:30:54.000000000 +0200
@@ -1362,7 +1362,7 @@ rt2500usb_tx(struct net_device *net_dev,
struct sk_buff *skb, struct ieee80211_tx_control *control)
{
struct rt2x00_usb *rt2x00usb = ieee80211_dev_hw_data(net_dev);
- struct usb_devive *usb_dev =
+ struct usb_device *usb_dev =
interface_to_usbdev(rt2x00usb->usb_intf);
struct data_ring *ring;
struct data_entry *entry;
@@ -1844,7 +1844,7 @@ rt2500usb_beacon_update(struct net_devic
struct sk_buff *skb, struct ieee80211_tx_control *control)
{
struct rt2x00_usb *rt2x00usb = ieee80211_dev_hw_data(net_dev);
- struct usb_devive *usb_dev =
+ struct usb_device *usb_dev =
interface_to_usbdev(rt2x00usb->usb_intf);
struct data_entry *entry;
@@ -2074,7 +2074,7 @@ rt2500usb_init_hw_channels(struct rt2x00
channels[counter].val = vals[counter];
}
- /*
+ /*
* Set TX power, each EEPROM TXpower entry
* contains the TXpower value for 2 channels.
*/
@@ -2628,9 +2628,6 @@ MODULE_PARM_DESC(debug, "Set this parame
#endif /* CONFIG_RT2500USB_DEBUG */
static struct usb_driver rt2500usb_driver = {
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 15)
- .owner = THIS_MODULE,
-#endif /* LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 15) */
.name = DRV_NAME,
.id_table = rt2500usb_device_table,
.probe = rt2500usb_probe,
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 0/3] rt2x00 drivers
From: Ivo van Doorn @ 2006-04-29 9:47 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
[-- Attachment #1: Type: text/plain, Size: 266 bytes --]
Hi,
These patches are for the wireless-dev tree
and will add the rt61pci and rt73usb drivers
into the tree.
I have split them up into patches:
[PATCH 1/3] rt2x00 drivers: Makefile & CRC
[PATCH 2/3] rt2x00 drivers: rt61pci
[PATCH 3/3] rt2x00 drivers: rt73usb
IvD
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 1/3] rt2x00 drivers: Makefile & CRC
From: Ivo van Doorn @ 2006-04-29 9:47 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
[-- Attachment #1: Type: text/plain, Size: 7109 bytes --]
From: Ivo van Doorn <IvDoorn@gmail.com>
Change Makefile and KConfig file to add the rt61pci and rt73usb
drivers to the list.
The firmware needs to be validated by CRC, for this a crc header
has been added to the tree as well.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/Kconfig wireless-dev-rt2x00-drivers/drivers/net/wireless/d80211/rt2x00/Kconfig
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/Kconfig 2006-04-27 00:52:56.000000000 +0200
+++ wireless-dev-rt2x00-drivers/drivers/net/wireless/d80211/rt2x00/Kconfig 2006-04-29 11:42:17.000000000 +0200
@@ -5,7 +5,7 @@ config RT2X00
This will enable the experimental support for the Ralink drivers,
developed in the rt2x00 project <http://rt2x00.serialmonkey.com>.
- These drivers will make use of the DeviceScape ieee80211 stack.
+ These drivers will make use of the Devicescape ieee80211 stack.
config RT2400PCI
tristate "Ralink rt2400 pci/pcmcia support"
@@ -53,6 +53,29 @@ config RT2500PCI_DEBUG
---help---
Enable debugging output.
+config RT61PCI
+ tristate "Ralink rt61 pci/pcmcia support"
+ depends on RT2X00 && FW_LOADER && PCI
+ ---help---
+ This is an experimental driver for the Ralink rt61 wireless chip.
+
+ When compiled as a module, this driver will be called "rt61pci.ko".
+
+config RT2500PCI_BUTTON
+ bool "Ralink rt61 hardware button support"
+ depends on RT61PCI && X86
+ ---help---
+ In some notebooks the rt61 chipset is integrated in the machine,
+ with this option enabled the device will periodically poll the
+ the status of this button and will send and ACPI event when
+ the button has been pressed.
+
+config RT61PCI_DEBUG
+ bool "Ralink rt61 debug output"
+ depends on RT61PCI
+ ---help---
+ Enable debugging output.
+
config RT2500USB
tristate "Ralink rt2500 usb support"
depends on RT2X00 && USB
@@ -66,3 +89,17 @@ config RT2500USB_DEBUG
depends on RT2500USB
---help---
Enable debugging output.
+
+config RT73USB
+ tristate "Ralink rt73 usb support"
+ depends on RT2X00 && FW_LOADER && USB
+ ---help---
+ This is an experimental driver for the Ralink rt73 wireless chip.
+
+ When compiled as a module, this driver will be called "rt73usb.ko".
+
+config RT73USB_DEBUG
+ bool "Ralink rt73 debug output"
+ depends on RT73USB
+ ---help---
+ Enable debugging output.
\ No newline at end of file
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/Makefile wireless-dev-rt2x00-drivers/drivers/net/wireless/d80211/rt2x00/Makefile
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/Makefile 2006-04-27 00:52:56.000000000 +0200
+++ wireless-dev-rt2x00-drivers/drivers/net/wireless/d80211/rt2x00/Makefile 2006-04-29 11:41:21.000000000 +0200
@@ -1,3 +1,5 @@
obj-$(CONFIG_RT2400PCI) += rt2400pci.o
obj-$(CONFIG_RT2500PCI) += rt2500pci.o
-obj-$(CONFIG_RT2500USB) += rt2500usb.o
+obj-$(CONFIG_RT61PCI) += rt61pci.o
+obj-$(CONFIG_RT2500USB) += rt2500usb.o
+obj-$(CONFIG_RT73USB) += rt73usb.o
\ No newline at end of file
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00crc.h wireless-dev-rt2x00-drivers/drivers/net/wireless/d80211/rt2x00/rt2x00crc.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00crc.h 1970-01-01 01:00:00.000000000 +0100
+++ wireless-dev-rt2x00-drivers/drivers/net/wireless/d80211/rt2x00/rt2x00crc.h 2006-04-29 11:41:21.000000000 +0200
@@ -0,0 +1,82 @@
+/*
+ Copyright (C) 2004 - 2006 rt2x00 SourceForge Project
+ <http://rt2x00.serialmonkey.com>
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ 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
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/*
+ Module: rt2x00
+ Abstract: rt2x00 CRC implementation for firmware validation.
+ Supported chipsets: rt2561, rt2561s, rt2661 & rt2573
+ */
+
+#ifndef RT2X00CRC_H
+#define RT2X00CRC_H
+
+static const u16 rt2x00crc_table[256] = {
+ 0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7,
+ 0x8108, 0x9129, 0xa14a, 0xb16b, 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef,
+ 0x1231, 0x0210, 0x3273, 0x2252, 0x52b5, 0x4294, 0x72f7, 0x62d6,
+ 0x9339, 0x8318, 0xb37b, 0xa35a, 0xd3bd, 0xc39c, 0xf3ff, 0xe3de,
+ 0x2462, 0x3443, 0x0420, 0x1401, 0x64e6, 0x74c7, 0x44a4, 0x5485,
+ 0xa56a, 0xb54b, 0x8528, 0x9509, 0xe5ee, 0xf5cf, 0xc5ac, 0xd58d,
+ 0x3653, 0x2672, 0x1611, 0x0630, 0x76d7, 0x66f6, 0x5695, 0x46b4,
+ 0xb75b, 0xa77a, 0x9719, 0x8738, 0xf7df, 0xe7fe, 0xd79d, 0xc7bc,
+ 0x48c4, 0x58e5, 0x6886, 0x78a7, 0x0840, 0x1861, 0x2802, 0x3823,
+ 0xc9cc, 0xd9ed, 0xe98e, 0xf9af, 0x8948, 0x9969, 0xa90a, 0xb92b,
+ 0x5af5, 0x4ad4, 0x7ab7, 0x6a96, 0x1a71, 0x0a50, 0x3a33, 0x2a12,
+ 0xdbfd, 0xcbdc, 0xfbbf, 0xeb9e, 0x9b79, 0x8b58, 0xbb3b, 0xab1a,
+ 0x6ca6, 0x7c87, 0x4ce4, 0x5cc5, 0x2c22, 0x3c03, 0x0c60, 0x1c41,
+ 0xedae, 0xfd8f, 0xcdec, 0xddcd, 0xad2a, 0xbd0b, 0x8d68, 0x9d49,
+ 0x7e97, 0x6eb6, 0x5ed5, 0x4ef4, 0x3e13, 0x2e32, 0x1e51, 0x0e70,
+ 0xff9f, 0xefbe, 0xdfdd, 0xcffc, 0xbf1b, 0xaf3a, 0x9f59, 0x8f78,
+ 0x9188, 0x81a9, 0xb1ca, 0xa1eb, 0xd10c, 0xc12d, 0xf14e, 0xe16f,
+ 0x1080, 0x00a1, 0x30c2, 0x20e3, 0x5004, 0x4025, 0x7046, 0x6067,
+ 0x83b9, 0x9398, 0xa3fb, 0xb3da, 0xc33d, 0xd31c, 0xe37f, 0xf35e,
+ 0x02b1, 0x1290, 0x22f3, 0x32d2, 0x4235, 0x5214, 0x6277, 0x7256,
+ 0xb5ea, 0xa5cb, 0x95a8, 0x8589, 0xf56e, 0xe54f, 0xd52c, 0xc50d,
+ 0x34e2, 0x24c3, 0x14a0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
+ 0xa7db, 0xb7fa, 0x8799, 0x97b8, 0xe75f, 0xf77e, 0xc71d, 0xd73c,
+ 0x26d3, 0x36f2, 0x0691, 0x16b0, 0x6657, 0x7676, 0x4615, 0x5634,
+ 0xd94c, 0xc96d, 0xf90e, 0xe92f, 0x99c8, 0x89e9, 0xb98a, 0xa9ab,
+ 0x5844, 0x4865, 0x7806, 0x6827, 0x18c0, 0x08e1, 0x3882, 0x28a3,
+ 0xcb7d, 0xdb5c, 0xeb3f, 0xfb1e, 0x8bf9, 0x9bd8, 0xabbb, 0xbb9a,
+ 0x4a75, 0x5a54, 0x6a37, 0x7a16, 0x0af1, 0x1ad0, 0x2ab3, 0x3a92,
+ 0xfd2e, 0xed0f, 0xdd6c, 0xcd4d, 0xbdaa, 0xad8b, 0x9de8, 0x8dc9,
+ 0x7c26, 0x6c07, 0x5c64, 0x4c45, 0x3ca2, 0x2c83, 0x1ce0, 0x0cc1,
+ 0xef1f, 0xff3e, 0xcf5d, 0xdf7c, 0xaf9b, 0xbfba, 0x8fd9, 0x9ff8,
+ 0x6e17, 0x7e36, 0x4e55, 0x5e74, 0x2e93, 0x3eb2, 0x0ed1, 0x1ef0
+};
+
+static inline u16
+rt2x00crc_byte(u16 crc, const u8 data)
+{
+ return (crc << 8) ^ rt2x00crc_table[((crc >> 8) ^ data) & 0xff];
+}
+
+/*
+ * Compute the rt2x00 CRC for the data buffer
+ */
+static inline u16
+rt2x00crc(u16 crc, const u8 *buffer, size_t len)
+{
+ while (len--)
+ crc = rt2x00crc_byte(crc, *buffer++);
+ return crc;
+}
+
+#endif /* RT2X00CRC_H */
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 3/3] rt2x00 drivers: rt73usb
From: Ivo van Doorn @ 2006-04-29 9:47 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
[-- Attachment #1: Type: text/plain, Size: 203 bytes --]
From: Ivo van Doorn <IvDoorn@gmail.com>
This adds the rt73usb driver to the tree
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Available on server:
http://mendiosus.nl/rt2x00/rt73usb.diff
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 2/3] rt2x00 drivers: rt61pci
From: Ivo van Doorn @ 2006-04-29 9:47 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
[-- Attachment #1: Type: text/plain, Size: 203 bytes --]
From: Ivo van Doorn <IvDoorn@gmail.com>
This adds the rt61pci driver to the tree
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Available on server:
http://mendiosus.nl/rt2x00/rt61pci.diff
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: Pekka Enberg @ 2006-04-29 10:29 UTC (permalink / raw)
To: David Gómez; +Cc: David Vrabel, Francois Romieu, Linux-kernel, netdev
In-Reply-To: <Pine.LNX.4.58.0604281458110.19801@sbz-30.cs.Helsinki.FI>
On Fri, 28 Apr 2006, David Gómezz wrote:
> > Ok, i could take care of that, and it's a good way of getting my hands
> > dirty with kernel programming ;). David, if it's ok to you i'll do the
> > cleanup thing.
On Fri, 2006-04-28 at 14:59 +0300, Pekka J Enberg wrote:
> Here are some suggestions for coding style cleanups:
[snip]
I ended up doing most of them myself [1]. Sorry :-) Are the datasheets
public by the way?
Pekka
1. http://www.cs.helsinki.fi/u/penberg/linux/ip1000-driver.patch
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: Arjan van de Ven @ 2006-04-29 10:35 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Gómez, David Vrabel, Francois Romieu, Linux-kernel,
netdev
In-Reply-To: <1146306567.1642.3.camel@localhost>
On Sat, 2006-04-29 at 13:29 +0300, Pekka Enberg wrote:
> On Fri, 28 Apr 2006, David Gómezz wrote:
> > > Ok, i could take care of that, and it's a good way of getting my hands
> > > dirty with kernel programming ;). David, if it's ok to you i'll do the
> > > cleanup thing.
>
> On Fri, 2006-04-28 at 14:59 +0300, Pekka J Enberg wrote:
> > Here are some suggestions for coding style cleanups:
>
> [snip]
>
> I ended up doing most of them myself [1]. Sorry :-) Are the datasheets
> public by the way?
you want to nuke the ioctl btw and just use ethtool ioctl instead
^ permalink raw reply
* wireless-dev: warnings while removing bcm43xx-d80211
From: Johannes Berg @ 2006-04-29 11:00 UTC (permalink / raw)
To: netdev; +Cc: Broadcom Linux
[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]
This didn't look too good to me, maybe someone can investigate?
[24070.841580] Badness in remove_proc_entry at fs/proc/generic.c:732
[24070.841593] Call Trace:
[24070.841598] [E9A87C30] [C00081E8] show_stack+0x50/0x190 (unreliable)
[24070.841618] [E9A87C60] [C000E4EC] program_check_exception+0x454/0x5d0
[24070.841632] [E9A87CC0] [C000FA00] ret_from_except_full+0x0/0x4c
[24070.841643] --- Exception: 700 at remove_proc_entry+0x14c/0x1d0
[24070.841661] LR = remove_proc_entry+0x58/0x1d0
[24070.841667] [E9A87DC0] [F20BE214] ieee80211_proc_deinit_interface+0x38/0xe4 [80211]
[24070.841729] [E9A87DD0] [F20B17E0] ieee80211_unregister_hw+0xf4/0x1ac [80211]
[24070.841749] [E9A87DF0] [F24C2644] bcm43xx_remove_one+0x44/0xc0 [bcm43xx_d80211]
[24070.841789] [E9A87E10] [C0151670] pci_device_remove+0x38/0x60
[24070.841806] [E9A87E20] [C019F098] __device_release_driver+0x74/0xac
[24070.841822] [E9A87E40] [C019F5DC] driver_detach+0x110/0x140
[24070.841833] [E9A87E60] [C019E8C8] bus_remove_driver+0x8c/0xc8
[24070.841844] [E9A87E80] [C019F990] driver_unregister+0x18/0x34
[24070.841855] [E9A87EA0] [C0151524] pci_unregister_driver+0x20/0x8c
[24070.841866] [E9A87EC0] [F24D9954] bcm43xx_exit+0x18/0x376c [bcm43xx_d80211]
[24070.841886] [E9A87ED0] [C0047D30] sys_delete_module+0x19c/0x20c
[24070.841899] [E9A87F40] [C000F3A4] ret_from_syscall+0x0/0x38
[24070.841909] --- Exception: c01 at 0xff6e708
[24070.841918] LR = 0x1000103c
[24084.097041] Badness in remove_proc_entry at fs/proc/generic.c:732
[24084.097056] Call Trace:
[24084.097061] [E9BDBD20] [C00081E8] show_stack+0x50/0x190 (unreliable)
[24084.097081] [E9BDBD50] [C000E4EC] program_check_exception+0x454/0x5d0
[24084.097095] [E9BDBDB0] [C000FA00] ret_from_except_full+0x0/0x4c
[24084.097106] --- Exception: 700 at remove_proc_entry+0x14c/0x1d0
[24084.097124] LR = remove_proc_entry+0x58/0x1d0
[24084.097130] [E9BDBEB0] [F20BE37C] ieee80211_proc_deinit+0x38/0x48 [80211]
[24084.097174] [E9BDBEC0] [F20C7560] ieee80211_exit+0x14/0x3aec [80211]
[24084.097192] [E9BDBED0] [C0047D30] sys_delete_module+0x19c/0x20c
[24084.097206] [E9BDBF40] [C000F3A4] ret_from_syscall+0x0/0x38
[24084.097215] --- Exception: c01 at 0xff6e708
[24084.097224] LR = 0x1000103c
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: David Gómez @ 2006-04-29 12:21 UTC (permalink / raw)
To: Pekka Enberg; +Cc: David Vrabel, Francois Romieu, Linux-kernel, netdev
In-Reply-To: <1146306567.1642.3.camel@localhost>
Hi Pekka,
On Apr 29 at 01:29:26, Pekka Enberg wrote:
> I ended up doing most of them myself [1]. Sorry :-) Are the datasheets
> public by the way?
I already had it modified, just needed to create the patch... Anyway,
have you submitted it to netdev?
About the datasheets, i don't think so. The icplus web page seems broken
except for the driver section. But maybe if asked they'll made public
the datasheets.
cheers,
--
David Gómez Jabber ID: davidge@jabber.org
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: David Vrabel @ 2006-04-29 12:58 UTC (permalink / raw)
To: Pekka Enberg; +Cc: David Gómez, Francois Romieu, Linux-kernel, netdev
In-Reply-To: <1146306567.1642.3.camel@localhost>
Pekka Enberg wrote:
>
> I ended up doing most of them myself [1]. Sorry :-) Are the datasheets
> public by the way?
http://www.icplus.com.tw/Data/Datasheet/IP1000A-DS-R08-07052005.pdf
> 1. http://www.cs.helsinki.fi/u/penberg/linux/ip1000-driver.patch
^ permalink raw reply
* [TCP]: Fix sock_orphan dead lock
From: Herbert Xu @ 2006-04-29 13:13 UTC (permalink / raw)
To: Ingo Molnar; +Cc: David S. Miller, Arjan van de Ven, netdev
In-Reply-To: <20060429111507.GA3077@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]
On Sat, Apr 29, 2006 at 09:15:07PM +1000, herbert wrote:
>
> Unfortunately this is only true for TCP. All of the connectionless
> protocols use the callback lock without the socket lock so it does
> still serve a purpose.
>
> I'd be happy to see your patch included.
I've just changed my mind :) Instead of disabling BH on the read_lock
callers, we can instead move sock_orphan outside bh_lock_sock.
[TCP]: Fix sock_orphan dead lock
Calling sock_orphan inside bh_lock_sock in tcp_close can lead to dead
locks. For example, the inet_diag code holds sk_callback_lock without
disabling BH. If an inbound packet arrives during that admittedly tiny
window, it will cause a dead lock on bh_lock_sock. Another possible
path would be through sock_wfree if the network device driver frees the
tx skb in process context with BH enabled.
We can fix this by moving sock_orphan out of bh_lock_sock.
The tricky bit is to work out when we need to destroy the socket
ourselves and when it has already been destroyed by someone else.
By moving sock_orphan before the release_sock we can solve this
problem. This is because as long as we own the socket lock its
state cannot change.
So we simply record the socket state before the release_sock
and then check the state again after we regain the socket lock.
If the socket state has transitioned to TCP_CLOSE in the time being,
we know that the socket has been destroyed. Otherwise the socket is
still ours to keep.
Note that I've also moved the increment on the orphan count forward.
This may look like a problem as we're increasing it even if the socket
is just about to be destroyed where it'll be decreased again. However,
this simply enlarges a window that already exists. This also changes
the orphan count test by one.
Considering what the orphan count is meant to do this is no big deal.
This problem was discoverd by Ingo Molnar using his lock validator.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: tcp-sock-orphan.patch --]
[-- Type: text/plain, Size: 1337 bytes --]
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 87f68e7..e2b7b80 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1468,6 +1468,7 @@
{
struct sk_buff *skb;
int data_was_unread = 0;
+ int state;
lock_sock(sk);
sk->sk_shutdown = SHUTDOWN_MASK;
@@ -1544,6 +1545,11 @@
sk_stream_wait_close(sk, timeout);
adjudge_to_death:
+ state = sk->sk_state;
+ sock_hold(sk);
+ sock_orphan(sk);
+ atomic_inc(sk->sk_prot->orphan_count);
+
/* It is the last release_sock in its life. It will remove backlog. */
release_sock(sk);
@@ -1555,8 +1561,9 @@
bh_lock_sock(sk);
BUG_TRAP(!sock_owned_by_user(sk));
- sock_hold(sk);
- sock_orphan(sk);
+ /* Have we already been destroyed by a softirq or backlog? */
+ if (state != TCP_CLOSE && sk->sk_state == TCP_CLOSE)
+ goto out;
/* This is a (useful) BSD violating of the RFC. There is a
* problem with TCP as specified in that the other end could
@@ -1584,7 +1591,6 @@
if (tmo > TCP_TIMEWAIT_LEN) {
inet_csk_reset_keepalive_timer(sk, tcp_fin_time(sk));
} else {
- atomic_inc(sk->sk_prot->orphan_count);
tcp_time_wait(sk, TCP_FIN_WAIT2, tmo);
goto out;
}
@@ -1603,7 +1609,6 @@
NET_INC_STATS_BH(LINUX_MIB_TCPABORTONMEMORY);
}
}
- atomic_inc(sk->sk_prot->orphan_count);
if (sk->sk_state == TCP_CLOSE)
inet_csk_destroy_sock(sk);
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox