* Re: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Dhananjay Phadke @ 2009-11-20 17:30 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Jens Rosenboom, netdev@vger.kernel.org, Amit Salecha,
Ameen Rahman
In-Reply-To: <m1tywprvl4.fsf@fess.ebiederm.org>
> Weird. MSI's definitely weren't disabled. Looking a little farther at
> your quoted setup MSI work on your board. This is definitely
> something specific to the driver. Except for a few initialization
> races that are an issue for bonding I am running 2.6.31 just fine.
Jens,
Even if /proc/interrupt says PCI-MSI in both cases, single interrupt
case is msi vs. 4 vector case is msi-x. To confirm that msi-x doesn't
work with your card/machine, you can still stay on 2.6.31 and set
use_msi_x=0 in netxen_nic_main.c.
I had tried to make a available a module param to disable msi/msi-x for
platforms where msi-x doesn't work cleanly, but it was declined by David
Miller, et al.
Anyway, please note a few things -
Jens' has older generation (NX2031) of nic asic, so 4.0.xxx FW doesn't
apply:
NetXen XGb XFP Board S/N IF72MK0200 Chip rev 0x25
Eric has newer generation (NX3031) of nic asic:
NetXen Dual XGb SFP+ LP Board S/N SF86BK0008 Chip rev 0x41
Anyhow, what I learned here is Jens obtained firmware from IBM Japan.
Could you please describe the source of your device, you should involve
respective OEM (HP/IBM) for getting right revision of the firmware.
If it was purchased via direct channel, call QLogic support about
3.4.339 firmware. I can't imagine IBM Japan hosting firmware not
released for IBM branded NIC boards.
Thanks,
Dhananjay
^ permalink raw reply
* Re: [PATCH 4/7] via-velocity: Implement NAPI support
From: David Miller @ 2009-11-20 17:35 UTC (permalink / raw)
To: simon.kagstrom; +Cc: netdev, davej, shemminger, romieu
In-Reply-To: <20091120161223.10d01fd9@marrow.netinsight.se>
From: Simon Kagstrom <simon.kagstrom@netinsight.net>
Date: Fri, 20 Nov 2009 16:12:23 +0100
> This patch adds NAPI support for VIA velocity. The new velocity_poll
> function also pairs tx/rx handling twice which improves perforamance on
> some workloads (e.g., netperf UDP_STREAM) significantly (that part is
> from the VIA driver).
>
> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
With NAPI support present, your patch #3 should almost be not
necessary at all.
And if it is, make sure that you only use very low HW interrupt
mitigation settings.
^ permalink raw reply
* Re: [PATCH 1/7] via-velocity: Correct setting of skipped checksums
From: David Miller @ 2009-11-20 17:36 UTC (permalink / raw)
To: simon.kagstrom; +Cc: netdev, davej, shemminger, romieu
In-Reply-To: <20091120161205.6ddeb3ff@marrow.netinsight.se>
From: Simon Kagstrom <simon.kagstrom@netinsight.net>
Date: Fri, 20 Nov 2009 16:12:05 +0100
> (Taken from the VIA driver). Check that this is actually an UDP or TCP
> packet before claiming that the checksum is unnecessary.
>
> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
Why would the chip specifically say UDP or TCP checksum is OK
on a packet that is not of said protocol type?
Just wondering...
^ permalink raw reply
* Re: stmmac patches...
From: David Miller @ 2009-11-20 17:40 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <4B0642F2.7060308@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Fri, 20 Nov 2009 08:19:14 +0100
>> Please fix this up and resubmit both of your patches.
>
> I've just resent the second patch:
> [PATCH (RESENT)] stmmac: do not fail when the timer cannot be used.
> Let me know if I have to review something in my first patch as well.
I explicitly asked you to resubmit both patches, so that I would have
them in a group together to apply to my tree.
When changes are requested in some patches within a group, I mark
the entire group in patchwork with state 'changed requested' and
that's why I ask for the whole series to be resubmitted.
This means you should have resent the first patch even though I did
not ask you to make any changes to it.
^ permalink raw reply
* Re: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Eric W. Biederman @ 2009-11-20 17:43 UTC (permalink / raw)
To: Dhananjay Phadke
Cc: Jens Rosenboom, netdev@vger.kernel.org, Amit Salecha,
Ameen Rahman
In-Reply-To: <4B06D234.4060600@qlogic.com>
Dhananjay Phadke <dhananjay.phadke@qlogic.com> writes:
>> Weird. MSI's definitely weren't disabled. Looking a little farther at
>> your quoted setup MSI work on your board. This is definitely
>> something specific to the driver. Except for a few initialization
>> races that are an issue for bonding I am running 2.6.31 just fine.
>
>
> Jens,
>
> Even if /proc/interrupt says PCI-MSI in both cases, single interrupt case is msi
> vs. 4 vector case is msi-x. To confirm that msi-x doesn't work with your
> card/machine, you can still stay on 2.6.31 and set use_msi_x=0 in
> netxen_nic_main.c.
>
> I had tried to make a available a module param to disable msi/msi-x for
> platforms where msi-x doesn't work cleanly, but it was declined by David Miller,
> et al.
MSI-X uses the same messages on the wire is the same as MSI it is
only the programming interface that is different. So if MSI works and
MSI-X does not it is not a platform problem.
Eric
^ permalink raw reply
* Re: [PATCH 3/7] via-velocity: Enable support for adaptive interrupt supression
From: David Miller @ 2009-11-20 17:47 UTC (permalink / raw)
To: shemminger; +Cc: simon.kagstrom, netdev, davej, romieu
In-Reply-To: <20091120090505.0fa700e6@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 20 Nov 2009 09:05:05 -0800
> This should be done via ethtool irq coalescing settings not more module paramets.
Agreed.
^ permalink raw reply
* Re: Compile Error for TI Davinci
From: David Miller @ 2009-11-20 17:50 UTC (permalink / raw)
To: srk; +Cc: netdev, davinci-linux-open-source, chaithrika
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC35608702FA751A01@dbde02.ent.ti.com>
From: "Govindarajan, Sriramakrishnan" <srk@ti.com>
Date: Fri, 20 Nov 2009 17:36:38 +0530
> Patch for "TI DaVinci EMAC: Clear statistics register properly"(commit- 0fe7463a35aadfaf22d1ca58325ab3851b8d757c on net-next) has dependency on
> Patch "TI DaVinci EMAC: Minor macro related updates "(commit - 69ef9694099802f7feeb23182dfb869e7c5f76f0 on net-next).
>
> The first patch has been pushed upstream while the later still remains on
> Net-next. Due to the dependency between these two, we are seeing compilation
> Failure when we build for Davinci.
>
> Can you please push "TI DaVinci EMAC: Minor macro related updates" - 69ef9694099802f7feeb23182dfb869e7c5f76f0 up-stream .
This should not be happening, because yesterday I merged Linus's
tree into net-2.6 and afterwards I merged net-2.6 into net-next-2.6
Please verify that the problem still occurs.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/3] igb: add support for the 82580 phy
From: David Miller @ 2009-11-20 18:00 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20091119224108.29487.75458.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 19 Nov 2009 14:41:42 -0800
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This patch adds support for the phy included in the 82580 silicon family.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/3] igb: Add full support for 82580 devices
From: David Miller @ 2009-11-20 18:00 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20091119224220.29487.14972.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 19 Nov 2009 14:42:21 -0800
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This patch makes use of the 82580 PHY and MAC support added and adds a set
> of supported device IDs for said hardware.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH NEXT] netxen: remove PCI IDs of CNA device
From: David Miller @ 2009-11-20 18:00 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, dhananjay.phadke
In-Reply-To: <1258679292-26098-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Thu, 19 Nov 2009 17:08:12 -0800
> Remove PCI vendor and device IDs for QLE8240 and QLE8242
> CNA devices. CNA devices will have separate driver.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Dhananjay Phadke @ 2009-11-20 18:07 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Jens Rosenboom, netdev@vger.kernel.org, Amit Salecha,
Ameen Rahman
In-Reply-To: <m1d43drt0g.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> MSI-X uses the same messages on the wire is the same as MSI it is
> only the programming interface that is different. So if MSI works and
> MSI-X does not it is not a platform problem.
>
Sure, but firmware and driver see it differently. IMO, this points to
some firmware issue (which is why I asked him to get right version from
right source). All that driver did was tried to enable msi-x, from my
testing, I can tell that both msi and msix work on all revisions of the
nic asic, but firmware revision can make a difference. For chiprev 0x25,
3.4.339 is the right firmware version.
Thanks,
Dhananjay
^ permalink raw reply
* Re: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Eric W. Biederman @ 2009-11-20 18:21 UTC (permalink / raw)
To: Dhananjay Phadke
Cc: Jens Rosenboom, netdev@vger.kernel.org, Amit Salecha,
Ameen Rahman
In-Reply-To: <4B06DAF9.6080108@qlogic.com>
Dhananjay Phadke <dhananjay.phadke@qlogic.com> writes:
> Eric W. Biederman wrote:
>> MSI-X uses the same messages on the wire is the same as MSI it is
>> only the programming interface that is different. So if MSI works and
>> MSI-X does not it is not a platform problem.
>>
>
> Sure, but firmware and driver see it differently. IMO, this points to some
> firmware issue (which is why I asked him to get right version from right
> source). All that driver did was tried to enable msi-x, from my testing, I can
> tell that both msi and msix work on all revisions of the nic asic, but firmware
> revision can make a difference. For chiprev 0x25, 3.4.339 is the right firmware
> version.
Sorry I meant that only as a clarification, not to derail the conversation.
This does sound like a firmware mismatch issue to me as well.
Eric
^ permalink raw reply
* Re: [PATCH 1/2] rps: core implementation
From: Jarek Poplawski @ 2009-11-20 19:00 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev
In-Reply-To: <65634d660911200908l5acbf3d0v5fc9a2e1adb7c3a5@mail.gmail.com>
On Fri, Nov 20, 2009 at 09:08:10AM -0800, Tom Herbert wrote:
> > The description reads: "This solution queues packets early on in the
> > receive path on the backlog queues of other CPUs.", so I'm not sure
> > it's intended.
>
> That is precisely the intent. Getting packets quickly distributed to
> the target cpus maximizes parallelism and reduces latency.
Then precisely the intent is "the backlog queues of target CPUs".
"The backlog queues of other CPUs" may suggest that e.g. one cpu is
only doing distribution etc.
>
> Did you test it like this (and it was visibly worse)?:
> >
> > if (cpu < 0 || cpu == smp_processor_id())
> >
> >> + return __netif_receive_skb(skb);
> >> + else
> >> + return enqueue_to_backlog(skb, cpu);
> >> +}
> >> +
> This increases overall latency due to head of line blocking which will
> outweigh the benefits of optimizing for this one case.
The way I asked should suggest I "suspected" it's on purpose, and was
curious about "digits", but thanks for confirming this.
Jarek P.
^ permalink raw reply
* Re: [PATCH] ixgbe: move tc variable to CONFIG_IXGBE_DCB
From: David Miller @ 2009-11-20 19:13 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: jaswinder, yi.zou, peter.p.waskiewicz.jr, netdev, linux-kernel
In-Reply-To: <9929d2390911200624mf352c28u55a8b2aee8b52fa3@mail.gmail.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 20 Nov 2009 06:24:21 -0800
> On Fri, Nov 20, 2009 at 06:02, Jaswinder Singh Rajput
> <jaswinder@kernel.org> wrote:
>>
>> tc is required by CONFIG_IXGBE_DCB.
>> This also fixes compilation warning:
>>
>> drivers/net/ixgbe/ixgbe_main.c: In function ‘ixgbe_tx_is_paused’:
>> drivers/net/ixgbe/ixgbe_main.c:245: warning: unused variable ‘tc’
>>
>> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
...
> I just submitted a patch to fix this. So NAK.
But his is much cleaner that your's, less ifdefs. I think we
should therefore use Jasdinder's version.
^ permalink raw reply
* Re: [PATCH] ixgbe: move tc variable to CONFIG_IXGBE_DCB
From: Jeff Kirsher @ 2009-11-20 19:16 UTC (permalink / raw)
To: David Miller
Cc: jaswinder, yi.zou, peter.p.waskiewicz.jr, netdev, linux-kernel
In-Reply-To: <20091120.111355.141716974.davem@davemloft.net>
On Fri, Nov 20, 2009 at 11:13, David Miller <davem@davemloft.net> wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Fri, 20 Nov 2009 06:24:21 -0800
>
>> On Fri, Nov 20, 2009 at 06:02, Jaswinder Singh Rajput
>> <jaswinder@kernel.org> wrote:
>>>
>>> tc is required by CONFIG_IXGBE_DCB.
>>> This also fixes compilation warning:
>>>
>>> drivers/net/ixgbe/ixgbe_main.c: In function ‘ixgbe_tx_is_paused’:
>>> drivers/net/ixgbe/ixgbe_main.c:245: warning: unused variable ‘tc’
>>>
>>> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> ...
>> I just submitted a patch to fix this. So NAK.
>
> But his is much cleaner that your's, less ifdefs. I think we
> should therefore use Jasdinder's version.
>
>
:) That is fine. The end result is the same.
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
--
Cheers,
Jeff
^ permalink raw reply
* [PATCH] net: ETHOC should depend on HAS_DMA (was: Re: [PATCH] ETHOC: fix build breakage on s390)
From: Geert Uytterhoeven @ 2009-11-20 19:19 UTC (permalink / raw)
To: Heiko Carstens
Cc: David S. Miller, Thierry Reding, Martin Schwidefsky, netdev,
linux-kernel, linux-s390
On Mon, Mar 30, 2009 at 10:30, Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> From: Heiko Carstens <heiko.carstens@de.ibm.com>
>
> Let driver depend on HAS_IOMEM to avoid build breakage on s390:
>
> CC drivers/net/ethoc.o
> drivers/net/ethoc.c: In function 'ethoc_read':
> drivers/net/ethoc.c:221: error: implicit declaration of function 'ioread32'
> drivers/net/ethoc.c: In function 'ethoc_write':
> drivers/net/ethoc.c:226: error: implicit declaration of function 'iowrite32'
> drivers/net/ethoc.c: In function 'ethoc_rx':
> drivers/net/ethoc.c:405: error: implicit declaration of function 'memcpy_fromio'
> drivers/net/ethoc.c: In function 'ethoc_start_xmit':
> drivers/net/ethoc.c:828: error: implicit declaration of function 'memcpy_toio'
>
> Cc: Thierry Reding <thierry.reding@avionic-design.de>
> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
> ---
> drivers/net/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6/drivers/net/Kconfig
> ===================================================================
> --- linux-2.6.orig/drivers/net/Kconfig
> +++ linux-2.6/drivers/net/Kconfig
> @@ -974,7 +974,7 @@ config ENC28J60_WRITEVERIFY
>
> config ETHOC
> tristate "OpenCores 10/100 Mbps Ethernet MAC support"
> - depends on NET_ETHERNET
> + depends on NET_ETHERNET && HAS_IOMEM
This is not sufficient, it has to depend on HAS_DMA, too:
From cdb6fc81662e9afd6019221acc7f56d2d7dcd161 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Fri, 20 Nov 2009 20:07:09 +0100
Subject: [PATCH] net: ETHOC should depend on HAS_DMA
When building for Sun 3:
drivers/net/ethoc.c:1091: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `ethoc_probe':
drivers/net/ethoc.c:965: undefined reference to `dma_alloc_coherent'
drivers/net/ethoc.c:1063: undefined reference to `dma_free_coherent'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/net/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 8015ecc..9e7c76e 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -993,7 +993,7 @@ config ENC28J60_WRITEVERIFY
config ETHOC
tristate "OpenCores 10/100 Mbps Ethernet MAC support"
- depends on NET_ETHERNET && HAS_IOMEM
+ depends on NET_ETHERNET && HAS_IOMEM && HAS_DMA
select MII
select PHYLIB
select CRC32
--
1.6.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply related
* Re: [RFC] p54: software hot-swap eeprom image
From: Dan Williams @ 2009-11-20 19:53 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, netdev
In-Reply-To: <200911202027.13284.chunkeey@googlemail.com>
On Fri, 2009-11-20 at 20:27 +0100, Christian Lamparter wrote:
> This (aggregated) patch adds a new sysfs file "eeprom_overwrite"
> which can be used to upload an customized eeprom image to the
> driver during normal operation.
>
> The old wlanX device will quickly vanish. And if the new EEPROM
> image passes all sanity checks the device will reappear.
>
> Hopefully, this proves to be an adequate solution for everyone
> with a bad/missing EEPROM data/chip.
Honestly I wonder if this would be better done with ethtool. There's
already ethtool --eeprom-dump, would it be so hard to do an ethtool
--eeprom-load ?
I can see a number of devices doing this, so in my mind it makes sense
to have a generic facility for this sort of thing. But then again it's
not so common an operation and its fraught with danger :) Libertas
could potentially use this, but libertas has *two* EEPROM images that it
might need to update. So if ethtool did grow --eeprom-load we may want
to account for more than one eeprom image.
What do people think?
Dan
> ---
> there are plenty of bugs left!
>
> would be nice to hear from p54spi & p54pci folks!
>
> Regards,
> Chr
> ---
> diff --git a/drivers/net/wireless/p54/eeprom.c b/drivers/net/wireless/p54/eeprom.c
> index 8e3818f..e5c94d9 100644
> --- a/drivers/net/wireless/p54/eeprom.c
> +++ b/drivers/net/wireless/p54/eeprom.c
> @@ -121,25 +121,20 @@ static int p54_generate_band(struct ieee80211_hw *dev,
> enum ieee80211_band band)
> {
> struct p54_common *priv = dev->priv;
> - struct ieee80211_supported_band *tmp, *old;
> + struct ieee80211_supported_band *old_band, *new_band;
> + struct ieee80211_channel *tmp, *old_chan, *new_chan;
> unsigned int i, j;
> - int ret = -ENOMEM;
> + int old_chan_num, ret = 0;
>
> if ((!list->entries) || (!list->band_channel_num[band]))
> return -EINVAL;
>
> - tmp = kzalloc(sizeof(*tmp), GFP_KERNEL);
> - if (!tmp)
> - goto err_out;
> -
> - tmp->channels = kzalloc(sizeof(struct ieee80211_channel) *
> - list->band_channel_num[band], GFP_KERNEL);
> - if (!tmp->channels)
> - goto err_out;
> -
> - ret = p54_fill_band_bitrates(dev, tmp, band);
> - if (ret)
> - goto err_out;
> + tmp = kzalloc(sizeof(struct ieee80211_channel) *
> + list->band_channel_num[band], GFP_KERNEL);
> + if (!tmp) {
> + ret = -ENOMEM;
> + goto out;
> + }
>
> for (i = 0, j = 0; (j < list->band_channel_num[band]) &&
> (i < list->entries); i++) {
> @@ -161,8 +156,8 @@ static int p54_generate_band(struct ieee80211_hw *dev,
> continue;
> }
>
> - tmp->channels[j].band = list->channels[i].band;
> - tmp->channels[j].center_freq = list->channels[i].freq;
> + tmp[j].band = list->channels[i].band;
> + tmp[j].center_freq = list->channels[i].freq;
> j++;
> }
>
> @@ -172,25 +167,60 @@ static int p54_generate_band(struct ieee80211_hw *dev,
> "2 GHz" : "5 GHz");
>
> ret = -ENODATA;
> - goto err_out;
> + goto out;
> }
>
> - tmp->n_channels = j;
> - old = priv->band_table[band];
> - priv->band_table[band] = tmp;
> - if (old) {
> - kfree(old->channels);
> - kfree(old);
> + old_band = priv->band_table[band];
> + if (old_band) {
> + old_chan_num = old_band->n_channels;
> + old_chan = old_band->channels;
> + old_band->n_channels = 0;
> + old_band->n_bitrates = 0;
> + } else {
> + old_chan_num = 0;
> + old_chan = NULL;
> }
>
> - return 0;
> + if (j < old_chan_num) {
> + printk(KERN_ERR "%s: Channel list can only be extended.\n",
> + wiphy_name(dev->wiphy));
> + goto out;
> + }
> +
> + new_band = krealloc(old_band, sizeof(*new_band), GFP_KERNEL);
> + if (!new_band) {
> + printk(KERN_ERR "%s: Unable to modify band table.\n",
> + wiphy_name(dev->wiphy));
> +
> + goto out;
> + }
> +
> + new_band->band = band;
> + new_band->ht_cap.ht_supported = false;
>
> -err_out:
> - if (tmp) {
> - kfree(tmp->channels);
> - kfree(tmp);
> + new_chan = krealloc(old_chan, j * sizeof(struct ieee80211_channel),
> + GFP_KERNEL);
> +
> + if (!new_chan) {
> + printk(KERN_ERR "%s: Unable to modify band channel table.\n",
> + wiphy_name(dev->wiphy));
> +
> + goto out;
> }
>
> + memcpy(new_chan, tmp, j * sizeof(struct ieee80211_channel));
> +
> + new_band->channels = new_chan;
> + new_band->n_channels = j;
> +
> + ret = p54_fill_band_bitrates(dev, new_band, band);
> + if (ret)
> + goto out;
> +
> + priv->band_table[band] = new_band;
> +
> +out:
> + kfree(tmp);
> return ret;
> }
>
> @@ -533,7 +563,19 @@ static struct p54_cal_database *p54_convert_db(struct pda_custom_wrapper *src,
> return dst;
> }
>
> -int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len)
> +static void p54_reset_phydata(struct p54_common *priv)
> +{
> + memset(&priv->rssical_db, 0, sizeof(priv->rssical_db));
> + priv->iq_autocal_len = 0;
> + kfree(priv->output_limit);
> + kfree(priv->curve_data);
> + kfree(priv->iq_autocal);
> + priv->output_limit = NULL;
> + priv->curve_data = NULL;
> + priv->iq_autocal = NULL;
> +}
> +
> +int p54_parse_eeprom(struct ieee80211_hw *dev, const void *eeprom, int len)
> {
> struct p54_common *priv = dev->priv;
> struct eeprom_pda_wrap *wrap;
> @@ -543,10 +585,14 @@ int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len)
> int err;
> u8 *end = (u8 *)eeprom + len;
> u16 synth = 0;
> + bool has_rssical = false, has_mac = false, has_country = false;
>
> wrap = (struct eeprom_pda_wrap *) eeprom;
> entry = (void *)wrap->data + le16_to_cpu(wrap->len);
>
> + mutex_lock(&priv->conf_mutex);
> + p54_reset_phydata(priv);
> +
> /* verify that at least the entry length/code fits */
> while ((u8 *)entry <= end - sizeof(*entry)) {
> entry_len = le16_to_cpu(entry->len);
> @@ -558,21 +604,34 @@ int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len)
>
> switch (le16_to_cpu(entry->code)) {
> case PDR_MAC_ADDRESS:
> + if (has_mac)
> + break;
> +
> + has_mac = true;
> +
> if (data_len != ETH_ALEN)
> break;
> +
> SET_IEEE80211_PERM_ADDR(dev, entry->data);
> break;
> +
> case PDR_PRISM_PA_CAL_OUTPUT_POWER_LIMITS:
> if (priv->output_limit)
> break;
> +
> err = p54_convert_output_limits(dev, entry->data,
> data_len);
> if (err)
> goto err;
> break;
> +
> case PDR_PRISM_PA_CAL_CURVE_DATA: {
> struct pda_pa_curve_data *curve_data =
> (struct pda_pa_curve_data *)entry->data;
> +
> + if (priv->curve_data)
> + break;
> +
> if (data_len < sizeof(*curve_data)) {
> err = -EINVAL;
> goto err;
> @@ -597,7 +656,11 @@ int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len)
> goto err;
> }
> break;
> +
> case PDR_PRISM_ZIF_TX_IQ_CALIBRATION:
> + if (priv->iq_autocal)
> + break;
> +
> priv->iq_autocal = kmalloc(data_len, GFP_KERNEL);
> if (!priv->iq_autocal) {
> err = -ENOMEM;
> @@ -607,11 +670,22 @@ int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len)
> memcpy(priv->iq_autocal, entry->data, data_len);
> priv->iq_autocal_len = data_len / sizeof(struct pda_iq_autocal_entry);
> break;
> +
> case PDR_DEFAULT_COUNTRY:
> + if (has_country)
> + break;
> +
> + has_country = true;
> +
> p54_parse_default_country(dev, entry->data, data_len);
> break;
> +
> case PDR_INTERFACE_LIST:
> tmp = entry->data;
> +
> + if (synth)
> + break;
> +
> while ((u8 *)tmp < entry->data + data_len) {
> struct exp_if *exp_if = tmp;
> if (exp_if->if_id == cpu_to_le16(IF_ID_ISL39000))
> @@ -619,22 +693,38 @@ int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len)
> tmp += sizeof(*exp_if);
> }
> break;
> +
> case PDR_HARDWARE_PLATFORM_COMPONENT_ID:
> + if (priv->version)
> + break;
> +
> if (data_len < 2)
> break;
> priv->version = *(u8 *)(entry->data + 1);
> break;
> +
> case PDR_RSSI_LINEAR_APPROXIMATION:
> case PDR_RSSI_LINEAR_APPROXIMATION_DUAL_BAND:
> case PDR_RSSI_LINEAR_APPROXIMATION_EXTENDED:
> + if (has_rssical)
> + break;
> +
> + has_rssical = true;
> +
> p54_parse_rssical(dev, entry->data, data_len,
> le16_to_cpu(entry->code));
> break;
> +
> case PDR_RSSI_LINEAR_APPROXIMATION_CUSTOM: {
> __le16 *src = (void *) entry->data;
> s16 *dst = (void *) &priv->rssical_db;
> int i;
>
> + if (has_rssical)
> + break;
> +
> + has_rssical = true;
> +
> if (data_len != sizeof(priv->rssical_db)) {
> err = -EINVAL;
> goto err;
> @@ -644,24 +734,30 @@ int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len)
> *(dst++) = (s16) le16_to_cpu(*(src++));
> }
> break;
> +
> case PDR_PRISM_PA_CAL_OUTPUT_POWER_LIMITS_CUSTOM: {
> struct pda_custom_wrapper *pda = (void *) entry->data;
> if (priv->output_limit || data_len < sizeof(*pda))
> break;
> +
> priv->output_limit = p54_convert_db(pda, data_len);
> }
> break;
> +
> case PDR_PRISM_PA_CAL_CURVE_DATA_CUSTOM: {
> struct pda_custom_wrapper *pda = (void *) entry->data;
> if (priv->curve_data || data_len < sizeof(*pda))
> break;
> +
> priv->curve_data = p54_convert_db(pda, data_len);
> }
> break;
> +
> case PDR_END:
> /* make it overrun */
> entry_len = len;
> break;
> +
> default:
> break;
> }
> @@ -670,7 +766,11 @@ int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len)
> }
>
> if (!synth || !priv->iq_autocal || !priv->output_limit ||
> - !priv->curve_data) {
> + !priv->curve_data || !has_rssical) {
> + printk(KERN_INFO "%d %p %p %p %d\n",
> + synth, priv->iq_autocal, priv->output_limit,
> + priv->curve_data, has_rssical);
> +
> printk(KERN_ERR "%s: not all required entries found in eeprom!\n",
> wiphy_name(dev->wiphy));
> err = -EINVAL;
> @@ -708,18 +808,18 @@ int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len)
> wiphy_name(dev->wiphy), dev->wiphy->perm_addr, priv->version,
> p54_rf_chips[priv->rxhw]);
>
> + mutex_unlock(&priv->conf_mutex);
> +
> return 0;
>
> err:
> - kfree(priv->iq_autocal);
> - kfree(priv->output_limit);
> - kfree(priv->curve_data);
> - priv->iq_autocal = NULL;
> - priv->output_limit = NULL;
> - priv->curve_data = NULL;
> + p54_reset_phydata(priv);
>
> printk(KERN_ERR "%s: eeprom parse failed!\n",
> wiphy_name(dev->wiphy));
> +
> + mutex_unlock(&priv->conf_mutex);
> +
> return err;
> }
> EXPORT_SYMBOL_GPL(p54_parse_eeprom);
> @@ -753,8 +853,39 @@ int p54_read_eeprom(struct ieee80211_hw *dev)
> }
>
> ret = p54_parse_eeprom(dev, eeprom, offset);
> +
> free:
> kfree(eeprom);
> return ret;
> }
> EXPORT_SYMBOL_GPL(p54_read_eeprom);
> +
> +ssize_t p54_overwrite_eeprom(struct ieee80211_hw *dev,
> + const char *buf, size_t len)
> +{
> + struct p54_common *priv = dev->priv;
> + int err;
> +
> + if (len < 64 || len > 0x2020)
> + return -EINVAL;
> +
> + mutex_lock(&priv->sysfs_mutex);
> + p54_unregister_common(dev);
> +
> + err = p54_parse_eeprom(dev, buf, len);
> + if (err)
> + goto out;
> +
> + err = p54_register_common(dev, priv->pdev);
> + if (err)
> + goto out;
> +
> +out:
> +
> + if (err)
> + dev_err(priv->pdev, "failed to (re)-register device.\n");
> +
> + mutex_unlock(&priv->sysfs_mutex);
> + return (err) ? err : len;
> +}
> +EXPORT_SYMBOL_GPL(p54_overwrite_eeprom);
> diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
> index 18012db..e1395d4 100644
> --- a/drivers/net/wireless/p54/main.c
> +++ b/drivers/net/wireless/p54/main.c
> @@ -582,6 +582,7 @@ struct ieee80211_hw *p54_init_common(size_t priv_data_len)
> dev->wiphy->flags &= ~WIPHY_FLAG_PS_ON_BY_DEFAULT;
>
> mutex_init(&priv->conf_mutex);
> + mutex_init(&priv->sysfs_mutex);
> mutex_init(&priv->eeprom_mutex);
> init_completion(&priv->eeprom_comp);
> init_completion(&priv->beacon_comp);
> @@ -596,6 +597,9 @@ int p54_register_common(struct ieee80211_hw *dev, struct device *pdev)
> struct p54_common *priv = dev->priv;
> int err;
>
> + if (priv->registered)
> + return -EBUSY;
> +
> err = ieee80211_register_hw(dev);
> if (err) {
> dev_err(pdev, "Cannot register device (%d).\n", err);
> @@ -607,8 +611,9 @@ int p54_register_common(struct ieee80211_hw *dev, struct device *pdev)
> if (err)
> return err;
> #endif /* CONFIG_P54_LEDS */
> -
> + priv->pdev = pdev;
> dev_info(pdev, "is registered as '%s'\n", wiphy_name(dev->wiphy));
> + priv->registered = true;
> return 0;
> }
> EXPORT_SYMBOL_GPL(p54_register_common);
> @@ -618,6 +623,11 @@ void p54_free_common(struct ieee80211_hw *dev)
> struct p54_common *priv = dev->priv;
> unsigned int i;
>
> + BUG_ON(priv->registered);
> +
> + mutex_destroy(&priv->conf_mutex);
> + mutex_destroy(&priv->eeprom_mutex);
> +
> for (i = 0; i < IEEE80211_NUM_BANDS; i++)
> kfree(priv->band_table[i]);
>
> @@ -637,12 +647,14 @@ void p54_unregister_common(struct ieee80211_hw *dev)
> {
> struct p54_common *priv = dev->priv;
>
> + if (!priv->registered)
> + return ;
> +
> #ifdef CONFIG_P54_LEDS
> p54_unregister_leds(priv);
> #endif /* CONFIG_P54_LEDS */
>
> - ieee80211_unregister_hw(dev);
> - mutex_destroy(&priv->conf_mutex);
> - mutex_destroy(&priv->eeprom_mutex);
> + ieee80211_unregister_hw(priv->hw);
> + priv->registered = false;
> }
> EXPORT_SYMBOL_GPL(p54_unregister_common);
> diff --git a/drivers/net/wireless/p54/p54.h b/drivers/net/wireless/p54/p54.h
> index 1afc394..3e097e0 100644
> --- a/drivers/net/wireless/p54/p54.h
> +++ b/drivers/net/wireless/p54/p54.h
> @@ -159,6 +159,7 @@ struct p54_led_dev {
>
> struct p54_common {
> struct ieee80211_hw *hw;
> + struct device *pdev;
> struct ieee80211_vif *vif;
> void (*tx)(struct ieee80211_hw *dev, struct sk_buff *skb);
> int (*open)(struct ieee80211_hw *dev);
> @@ -166,6 +167,7 @@ struct p54_common {
> struct sk_buff_head tx_pending;
> struct sk_buff_head tx_queue;
> struct mutex conf_mutex;
> + bool registered;
>
> /* memory management (as seen by the firmware) */
> u32 rx_start;
> @@ -233,14 +235,17 @@ struct p54_common {
> void *eeprom;
> struct completion eeprom_comp;
> struct mutex eeprom_mutex;
> + struct mutex sysfs_mutex;
> };
>
> /* interfaces for the drivers */
> int p54_rx(struct ieee80211_hw *dev, struct sk_buff *skb);
> void p54_free_skb(struct ieee80211_hw *dev, struct sk_buff *skb);
> int p54_parse_firmware(struct ieee80211_hw *dev, const struct firmware *fw);
> -int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len);
> +int p54_parse_eeprom(struct ieee80211_hw *dev, const void *eeprom, int len);
> int p54_read_eeprom(struct ieee80211_hw *dev);
> +ssize_t p54_overwrite_eeprom(struct ieee80211_hw *dev,
> + const char *eeprom, size_t len);
>
> struct ieee80211_hw *p54_init_common(size_t priv_data_len);
> int p54_register_common(struct ieee80211_hw *dev, struct device *pdev);
> diff --git a/drivers/net/wireless/p54/p54pci.c b/drivers/net/wireless/p54/p54pci.c
> index e3a4c90..b8040e4 100644
> --- a/drivers/net/wireless/p54/p54pci.c
> +++ b/drivers/net/wireless/p54/p54pci.c
> @@ -466,6 +466,18 @@ static int p54p_open(struct ieee80211_hw *dev)
> return 0;
> }
>
> +static ssize_t p54p_sysfs_overwrite_eeprom(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct p54p_priv *priv = dev_get_drvdata(dev);
> +
> + return p54_overwrite_eeprom(priv->common.hw, buf, count);
> +}
> +
> +static DEVICE_ATTR(eeprom_overwrite, S_IWUSR,
> + NULL, p54p_sysfs_overwrite_eeprom);
> +
> static int __devinit p54p_probe(struct pci_dev *pdev,
> const struct pci_device_id *id)
> {
> @@ -561,6 +573,13 @@ static int __devinit p54p_probe(struct pci_dev *pdev,
> if (err)
> goto err_free_common;
>
> + err = device_create_file(&pdev->dev, &dev_attr_eeprom_overwrite);
> + if (err < 0) {
> + dev_err(&pdev->dev, "failed to create sysfs file "
> + "eeprom_overwrite.\n");
> + goto err_free_common;
> + }
> +
> return 0;
>
> err_free_common:
> @@ -591,6 +610,8 @@ static void __devexit p54p_remove(struct pci_dev *pdev)
> return;
>
> p54_unregister_common(dev);
> + device_remove_file(&pdev->dev, &dev_attr_eeprom_overwrite);
> +
> priv = dev->priv;
> release_firmware(priv->firmware);
> pci_free_consistent(pdev, sizeof(*priv->ring_control),
> diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
> index afd26bf..6fb0863 100644
> --- a/drivers/net/wireless/p54/p54spi.c
> +++ b/drivers/net/wireless/p54/p54spi.c
> @@ -592,6 +592,18 @@ static void p54spi_op_stop(struct ieee80211_hw *dev)
> mutex_unlock(&priv->mutex);
> }
>
> +static ssize_t p54s_sysfs_overwrite_eeprom(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct p54s_priv *priv = dev_get_drvdata(dev);
> +
> + return p54_overwrite_eeprom(priv->common.hw, buf, count);
> +}
> +
> +static DEVICE_ATTR(eeprom_overwrite, S_IWUSR,
> + NULL, p54s_sysfs_overwrite_eeprom);
> +
> static int __devinit p54spi_probe(struct spi_device *spi)
> {
> struct p54s_priv *priv = NULL;
> @@ -667,7 +679,9 @@ static int __devinit p54spi_probe(struct spi_device *spi)
> if (ret)
> goto err_free_common;
>
> - return 0;
> + ret = device_create_file(&spi->dev, &dev_attr_eeprom_overwrite);
> +
> + return ret;
>
> err_free_common:
> p54_free_common(priv->hw);
> @@ -680,6 +694,9 @@ static int __devexit p54spi_remove(struct spi_device *spi)
>
> p54_unregister_common(priv->hw);
>
> + device_remove_file(&spi->dev, &dev_attr_eeprom_overwrite);
> + dev_set_drvdata(&spi->dev, NULL);
> +
> free_irq(gpio_to_irq(p54spi_gpio_irq), spi);
>
> gpio_free(p54spi_gpio_power);
> diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
> index 92af9b9..be699d6 100644
> --- a/drivers/net/wireless/p54/p54usb.c
> +++ b/drivers/net/wireless/p54/p54usb.c
> @@ -874,6 +874,19 @@ static void p54u_stop(struct ieee80211_hw *dev)
> return;
> }
>
> +static ssize_t p54u_sysfs_overwrite_eeprom(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct ieee80211_hw *hw = (struct ieee80211_hw *)
> + usb_get_intfdata(to_usb_interface(dev));
> +
> + return p54_overwrite_eeprom(hw, buf, count);
> +}
> +
> +static DEVICE_ATTR(eeprom_overwrite, S_IWUSR,
> + NULL, p54u_sysfs_overwrite_eeprom);
> +
> static int __devinit p54u_probe(struct usb_interface *intf,
> const struct usb_device_id *id)
> {
> @@ -959,7 +972,9 @@ static int __devinit p54u_probe(struct usb_interface *intf,
> if (err)
> goto err_free_fw;
>
> - return 0;
> + err = device_create_file(&intf->dev, &dev_attr_eeprom_overwrite);
> +
> + return err;
>
> err_free_fw:
> release_firmware(priv->fw);
> @@ -982,6 +997,9 @@ static void __devexit p54u_disconnect(struct usb_interface *intf)
> p54_unregister_common(dev);
>
> priv = dev->priv;
> + device_remove_file(&intf->dev, &dev_attr_eeprom_overwrite);
> +
> + usb_set_intfdata(intf, NULL);
> usb_put_dev(interface_to_usbdev(intf));
> release_firmware(priv->fw);
> p54_free_common(dev);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: Compile Error for TI Davinci
From: Govindarajan, Sriramakrishnan @ 2009-11-20 19:56 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org,
davinci-linux-open-source@linux.davincidsp.com,
Subrahmanya, Chaithrika
In-Reply-To: <20091120.095000.265125164.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, November 20, 2009 11:20 PM
> To: Govindarajan, Sriramakrishnan
> Cc: netdev@vger.kernel.org; davinci-linux-open-
> source@linux.davincidsp.com; Subrahmanya, Chaithrika
> Subject: Re: Compile Error for TI Davinci
>
> From: "Govindarajan, Sriramakrishnan" <srk@ti.com>
> Date: Fri, 20 Nov 2009 17:36:38 +0530
>
> > Patch for "TI DaVinci EMAC: Clear statistics register properly"(commit-
> 0fe7463a35aadfaf22d1ca58325ab3851b8d757c on net-next) has dependency on
> > Patch "TI DaVinci EMAC: Minor macro related updates "(commit -
> 69ef9694099802f7feeb23182dfb869e7c5f76f0 on net-next).
> >
> > The first patch has been pushed upstream while the later still remains
> on
> > Net-next. Due to the dependency between these two, we are seeing
> compilation
> > Failure when we build for Davinci.
> >
> > Can you please push "TI DaVinci EMAC: Minor macro related updates" -
> 69ef9694099802f7feeb23182dfb869e7c5f76f0 up-stream .
>
> This should not be happening, because yesterday I merged Linus's
> tree into net-2.6 and afterwards I merged net-2.6 into net-next-2.6
>
> Please verify that the problem still occurs.
[Sriram] David the commit " TI DaVinci EMAC: Minor macro related updates" exists only on the net-next-2.6 git. As mentioned in my earlier email, subsequent patch " DaVinci EMAC: Clear statistics register properly" is dependent on this and is reflected in the net-2.6 and Linus's GIT. Hence compilation for Davinci would fail on both net-2.6 and Linus's GIT
I just verified the failure by building against the tip of Linus's GIT
Regards
Sriram
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: Jarek Poplawski @ 2009-11-20 20:04 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Tom Herbert, Linux Netdev List
In-Reply-To: <4B06AB96.8040805@gmail.com>
On Fri, Nov 20, 2009 at 03:45:42PM +0100, Eric Dumazet wrote:
> Jarek Poplawski a écrit :
> > On 20-11-2009 00:46, Eric Dumazet wrote:
> >> Here is first version of XPS.
> >>
> >> Goal of XPS is to free TX completed skbs by the cpu that submitted the transmit.
> >
> > But why?... OK, you write in another message about sock_wfree(). Then
> > how about users, who don't sock_wfree (routers)? Will there be any way
> > to disable it?
>
>
> This is open for discussion, but I saw no problem with routing workloads.
IMHO, it should depend on testing: if you can prove there is a
distinct gain in "common" use case (which isn't probably a numa box
used e.g. for google.com or even kernel.org yet), and no visible
slowdown for such a router, then we could probably forget about
disabling, and look more at optimizations of the fast path.
>
> sock_wfree() is not that expensive for tcp anyway.
> You also have a cost of kfreeing() two blocks of memory per skb, if allocation was done by another cpu.
>
> If this happens to be a problem, we can immediately free packet if it
> has no destructors :
>
> At xmit time, initialize skb->sending_cpu like that
>
> skb->sending_cpu = (skb->destructor) ? smp_processor_id() : 0xFFFF;
>
> to make sure we dont touch too many cache lines at tx completion time.
>
>
> >> +/*
> >> + * XPS : Xmit Packet Steering
> >> + *
> >> + * TX completion packet freeing is performed on cpu that sent packet.
> >> + */
> >> +#if defined(CONFIG_SMP)
> >
> > Shouldn't it be in the Makefile?
>
> It is in Makefile too, I let it in prelim code to make it clear this was CONFIG_SMP only.
Aha! Now it's clear why I made this mistake. ;-)
>
> >
> > ...
> >> +/*
> >> + * called at end of net_rx_action()
> >> + * preemption (and cpu migration/offline/online) disabled
> >> + */
> >> +void xps_flush(void)
> >> +{
> >> + int cpu, prevlen;
> >> + struct sk_buff_head *head = per_cpu_ptr(xps_array, smp_processor_id());
> >> + struct xps_pcpu_queue *q;
> >> + struct sk_buff *skb;
> >> +
> >> + for_each_cpu_mask_nr(cpu, __get_cpu_var(xps_cpus)) {
> >> + q = &per_cpu(xps_pcpu_queue, cpu);
> >> + if (cpu_online(cpu)) {
> >> + spin_lock(&q->list.lock);
> >
> > This lock probably needs irq disabling: let's say 2 cpus run this at
> > the same time and both are interrupted with these (previously
> > scheduled) IPIs?
>
> Repeat after me :
>
> lockdep is my friend, lockdep is my friend, lockdep is my friend... :)
Hmm... Actually, why did I have to do lockdep's job...
>
> Seriously, I must think again on this locking schem.
>
> >> +static void remote_free_skb_list(void *arg)
> >> +{
> >> + struct sk_buff *last;
> >> + struct softnet_data *sd;
> >> + struct xps_pcpu_queue *q = arg; /* &__get_cpu_var(xps_pcpu_queue); */
> >> +
> >> + spin_lock(&q->list.lock);
> >> +
> >> + last = q->list.prev;
> >
> > Is q->list handled in case this cpu goes down before this IPI is
> > triggered?
>
>
> [block migration] (how ? this is the question)
>
> if (cpu_online(cpu)) {
> give_work_to_cpu(cpu);
> trigger IPI
> } else {
> handle_work_ourself()
> }
>
> [unblock migration]
>
> General problem is : what guards cpu going off line between the if (cpu_online(cpu))
> and the IPI.
> I dont know yet, but it seems that disabling preemption is enough to get this
> guarantee. This seems strange.
>
> We can add a notifier (or better call a function from existing one : dev_cpu_callback()) to
> flush this queue when necessary.
Using dev_cpu_callback() looks quite obvious to me.
Jarek P.
^ permalink raw reply
* Re: [RFC] p54: software hot-swap eeprom image
From: Luis R. Rodriguez @ 2009-11-20 20:32 UTC (permalink / raw)
To: Dan Williams
Cc: Christian Lamparter, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1258746786.26965.83.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Fri, Nov 20, 2009 at 11:53 AM, Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Fri, 2009-11-20 at 20:27 +0100, Christian Lamparter wrote:
>> This (aggregated) patch adds a new sysfs file "eeprom_overwrite"
>> which can be used to upload an customized eeprom image to the
>> driver during normal operation.
>>
>> The old wlanX device will quickly vanish. And if the new EEPROM
>> image passes all sanity checks the device will reappear.
>>
>> Hopefully, this proves to be an adequate solution for everyone
>> with a bad/missing EEPROM data/chip.
>
> Honestly I wonder if this would be better done with ethtool. There's
> already ethtool --eeprom-dump, would it be so hard to do an ethtool
> --eeprom-load ?
>
> I can see a number of devices doing this, so in my mind it makes sense
> to have a generic facility for this sort of thing. But then again it's
> not so common an operation and its fraught with danger :) Libertas
> could potentially use this, but libertas has *two* EEPROM images that it
> might need to update. So if ethtool did grow --eeprom-load we may want
> to account for more than one eeprom image.
>
> What do people think?
Can't request_firmware() be generalized for this sort of stuff too?
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] p54: software hot-swap eeprom image
From: Kalle Valo @ 2009-11-20 20:32 UTC (permalink / raw)
To: Dan Williams; +Cc: Christian Lamparter, linux-wireless, netdev
In-Reply-To: <1258746786.26965.83.camel@localhost.localdomain>
Dan Williams <dcbw@redhat.com> writes:
> On Fri, 2009-11-20 at 20:27 +0100, Christian Lamparter wrote:
>> This (aggregated) patch adds a new sysfs file "eeprom_overwrite"
>> which can be used to upload an customized eeprom image to the
>> driver during normal operation.
[...]
> Honestly I wonder if this would be better done with ethtool. There's
> already ethtool --eeprom-dump, would it be so hard to do an ethtool
> --eeprom-load ?
>
> I can see a number of devices doing this, so in my mind it makes sense
> to have a generic facility for this sort of thing. But then again it's
> not so common an operation and its fraught with danger :)
I think that devices without eeprom at all (eg. stlc4550, most wl1251
and all wl1271 chips) request_firmware() and a udev script is the best
way to go, as they will need the eeprom data from user space during
every boot. This was discussed few months back, but unfortunately I
have yet to seen an implementation of this :) Hopefully I find some
time to try this soon.
But for devices with eeprom, having support in ethtool sounds good to
me.
> Libertas could potentially use this, but libertas has *two* EEPROM
> images that it might need to update. So if ethtool did grow
> --eeprom-load we may want to account for more than one eeprom image.
Makes sense to mee.
--
Kalle Valo
^ permalink raw reply
* A generic kernel compatibilty code
From: Luis R. Rodriguez @ 2009-11-20 20:45 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-wireless, netdev
Everyone and their mother reinvents the wheel when it comes to
backporting kernel modules. It a painful job and it seems to me an
alternative is possible. If we can write generic compatibilty code for
a new routine introduced on the next kernel how about just merging it
to the kernel under some generic compat module. This would be
completey ignored by everyone using the stable kernel but can be
copied by anyone doing backport work.
So I'm thinking something as simple as a generic compat/comat.ko with
compat-2.6.32.[ch] files.
We've already backported everything needed for wireless drivers under
compat-wireless under this format down to even 2.6.25. I volunteer to
be the sucker for this if this is reasonable and given the shot to try
it.
If you would like a better idea of what I mean please check out this
git tree and check out the files under compat/*.[ch]
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6.git
Things which *cannot* be backported through new defines or exported
symbols are handled manually through patches (check compat/patches/)
but no need for something like that upstream it seems.
Please let me know what you think.
Luis
^ permalink raw reply
* Re: [net-next-2.6 PATCH v7 2/7 RFC] TCPCT part 1b: generate Responder Cookie secret
From: Andi Kleen @ 2009-11-20 20:47 UTC (permalink / raw)
To: David Miller; +Cc: william.allen.simpson, netdev
In-Reply-To: <20091120.092228.216274668.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: William Allen Simpson <william.allen.simpson@gmail.com>
> Date: Fri, 20 Nov 2009 09:23:21 -0500
>
>> +static DEFINE_SPINLOCK(tcp_secret_locker);
>
> So connection creation scalability will be limited now because
> we'll always have to go through this centralized spinlock even
> for independent listening sockets, right?
I was about to complain about the same thing in a earlier version
of this patch kit, but then I noticed the spin lock aquiring
is guarded by
if (unlikely(time_after_eq(jiffy, tcp_secret_generating->expires))) {
which presumably makes it rare enough?
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
From: Andi Kleen @ 2009-11-20 20:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Tom Herbert, Linux Netdev List
In-Reply-To: <4B05D8DC.7020907@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> Here is first version of XPS.
>
> Goal of XPS is to free TX completed skbs by the cpu that submitted the transmit.
>
> Because I chose to union skb->iif with skb->sending_cpu, I chose
> to introduce a new xps_consume_skb(skb), and not generalize consume_skb() itself.
>
> This means that selected drivers must use new function to benefit from XPS
>
> Preliminary tests are quite good, especially on NUMA machines.
>
> Only NAPI drivers can use this new infrastructure (xps_consume_skb() cannot
> be called from hardirq context, only from softirq)
>
> I converted tg3 and pktgen for my tests
Do you have numbers on this? It seems like a lot of effort to avoid transfering
a few cache lines.
-Andi (who is a bit sceptical and would rather see generic work for this in slab)
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v7 2/7 RFC] TCPCT part 1b: generate Responder Cookie secret
From: David Miller @ 2009-11-20 20:51 UTC (permalink / raw)
To: andi; +Cc: william.allen.simpson, netdev
In-Reply-To: <87eins53fu.fsf@basil.nowhere.org>
From: Andi Kleen <andi@firstfloor.org>
Date: Fri, 20 Nov 2009 21:47:17 +0100
> David Miller <davem@davemloft.net> writes:
>
>> From: William Allen Simpson <william.allen.simpson@gmail.com>
>> Date: Fri, 20 Nov 2009 09:23:21 -0500
>>
>>> +static DEFINE_SPINLOCK(tcp_secret_locker);
>>
>> So connection creation scalability will be limited now because
>> we'll always have to go through this centralized spinlock even
>> for independent listening sockets, right?
>
> I was about to complain about the same thing in a earlier version
> of this patch kit, but then I noticed the spin lock aquiring
> is guarded by
>
> if (unlikely(time_after_eq(jiffy, tcp_secret_generating->expires))) {
>
> which presumably makes it rare enough?
Works for me.
^ permalink raw reply
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