* Re: [PATCH] sky2: override for PCI legacy power management
From: Jonathan Nieder @ 2012-05-06 22:26 UTC (permalink / raw)
To: Knut Petersen
Cc: Bjorn Helgaas, Stephen Hemminger, David S. Miller, Linus Torvalds,
arekm, Jared, dilieto, linux-kernel, netdev
In-Reply-To: <4F6BA960.6020003@t-online.de>
Knut Petersen wrote, a few months ago:
> It´s easy to dmi_match() known broken systems - I have dmidecode
> outputs of four systems that definitely need the patch.
>
> Two ASUSTek P5* mainboards with AMI BIOSes, two AOpen i915G*
> mainboards with Award/Phoenix BIOSes.
Yes, please. Could you attach those to [1]?
Thanks,
Jonathan
[1] https://bugzilla.kernel.org/show_bug.cgi?id=19492
^ permalink raw reply
* RE: [PATCH net-next 1/3] Add capability to retrieve plug-in module EEPROM
From: Ben Hutchings @ 2012-05-06 22:05 UTC (permalink / raw)
To: Yaniv Rosner
Cc: smhodgson@solarflare.com, netdev@vger.kernel.org,
bruce.w.allan@intel.com, decot@google.com,
alexander.h.duyck@intel.com, linux-kernel@vger.kernel.org,
David Miller
In-Reply-To: <A6AA2EF896BED345B0F23520D832A4B106AD8E@SJEXCHMB05.corp.ad.broadcom.com>
On Sun, 2012-05-06 at 08:02 +0000, Yaniv Rosner wrote:
> > On Mon, 2012-04-23 at 17:28 -0400, David Miller wrote:
> > > You can't just submit three seperate patches each with the same exact
> > > Subject line.
> > >
> > > Otherwise someone scanning the commit headers can't figure out what
> > > is different in each of these changes.
> > >
> > > There also is no signoff from Ben for patches #2 or #3, did he review
> > > them? If so, why didn't he ACK or sign off on it? If not, why not?
> >
> > Sorry, I've been busy with another project. I'll reply to Stuart's
> > patches faster next round.
> >
> > Ben.
>
> Hi Stuart,
> It's been 3 weeks since you sent the initial patch series which were not
> accepted. Please reply if you're going to resubmit fixed patches soon,
> otherwise I'll take over, and complete this task from where you left it.
I'll be making a pull request including Stuart's patches in the next few
days.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [GIT PULL net-next v2] IPVS
From: Pablo Neira Ayuso @ 2012-05-06 21:56 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Hans Schillstrom, Jesper Dangaard Brouer
In-Reply-To: <1335939762-1912-1-git-send-email-horms@verge.net.au>
Hi Simon,
On Wed, May 02, 2012 at 03:22:24PM +0900, Simon Horman wrote:
> Hi Pablo,
>
> please consider the following 18 changes for 3.5.
>
> This replaces a 17 patch pull request that I sent earlier today by adding a
> patch from Hans patch to the head of the request. You should be able to
> just pull again if you have already pulled the original series and not
> applied anything else on top.
>
> Please note that there will be a conflict with the following when merged
> with net-next due to the following change which is already present in
> David's tree. It should be a trivial merge but please let me know if you
> want to handle this another way.
>
> 4a17fd5 sock: Introduce named constants for sk_reuse
>
> The following changes since commit c3dc836d807a9b9855eefe535fdcbcf7cbb7a574:
>
> netfilter: bridge: optionally set indev to vlan (2012-04-24 01:22:44 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git master
Pulled, thanks.
I have fixed some minor glitches, see below.
> for you to fetch changes up to 3de4b8ca4ffa3dafaeef985fabe152a1717a8ea0:
>
> export sysctl symbols needed by ip_vs_sync (2012-05-02 14:48:55 +0900)
>
> ----------------------------------------------------------------
> H Hartley Sweeten (2):
> IPVS: ip_vs_ftp.c: local functions should not be exposed globally
> IPVS: ip_vs_proto.c: local functions should not be exposed globally
^^^^
Please, use consistent tagging across patches (sometimes this is in
uppercase, sometimes lowercase).
I think using the same tagging is good for grepping for changes.
I have also removed the CC tag to David Miller in those two patches
above from H. Hartely, they are not useful anymore.
> Hans Schillstrom (1):
> export sysctl symbols needed by ip_vs_sync
^^^
This one missed "net: " or "sock: " tag in the beginnging. I added
"net: " here.
I have manually fixed this, but you'll have to rebase your tree, sorry.
^ permalink raw reply
* Re: [PATCH 18/18] export sysctl symbols needed by ip_vs_sync
From: David Miller @ 2012-05-06 21:19 UTC (permalink / raw)
To: pablo
Cc: horms, lvs-devel, netdev, netfilter-devel, wensong, ja,
hans.schillstrom, brouer
In-Reply-To: <20120506205412.GA22406@1984>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Sun, 6 May 2012 22:54:12 +0200
> Hi David,
>
> The IPVS people needs this patch for net-next to allow to tune the
> socket buffer for ipvs_sync (the state synchronization that they do
> from kernel-space). This exports sysctl_wmem_max and sysctl_rmem_max
> living in net/core/sock.c. So far, they've been using global socket
> tuning to make them bigger (this avoids overruning the socket under
> high peak of state-change synchronization).
>
> I think this is out of my scope (since it's out of the netfilter
> tree).
>
> Would you acknowledge it, please?
Feel free to merge it via your tree:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 18/18] export sysctl symbols needed by ip_vs_sync
From: Pablo Neira Ayuso @ 2012-05-06 20:54 UTC (permalink / raw)
To: davem
Cc: Simon Horman, lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Hans Schillstrom, Jesper Dangaard Brouer
In-Reply-To: <1335939762-1912-19-git-send-email-horms@verge.net.au>
Hi David,
The IPVS people needs this patch for net-next to allow to tune the
socket buffer for ipvs_sync (the state synchronization that they do
from kernel-space). This exports sysctl_wmem_max and sysctl_rmem_max
living in net/core/sock.c. So far, they've been using global socket
tuning to make them bigger (this avoids overruning the socket under
high peak of state-change synchronization).
I think this is out of my scope (since it's out of the netfilter
tree).
Would you acknowledge it, please?
On Wed, May 02, 2012 at 03:22:42PM +0900, Simon Horman wrote:
> From: Hans Schillstrom <hans.schillstrom@ericsson.com>
>
> To build ip_vs as a module sysctl_rmem_max and sysctl_wmem_max
> needs to be exported.
> The dependency was added by "ipvs: wakeup master thread" patch
>
> Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
> ---
> net/core/sock.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index c7e60ea..ac3131a 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -258,7 +258,9 @@ static struct lock_class_key af_callback_keys[AF_MAX];
>
> /* Run time adjustable parameters. */
> __u32 sysctl_wmem_max __read_mostly = SK_WMEM_MAX;
> +EXPORT_SYMBOL(sysctl_wmem_max);
> __u32 sysctl_rmem_max __read_mostly = SK_RMEM_MAX;
> +EXPORT_SYMBOL(sysctl_rmem_max);
> __u32 sysctl_wmem_default __read_mostly = SK_WMEM_MAX;
> __u32 sysctl_rmem_default __read_mostly = SK_RMEM_MAX;
>
> --
> 1.7.10
>
^ permalink raw reply
* Re: [PATCH 01/13 v4] usb/net: rndis: inline the cpu_to_le32() macro
From: Jussi Kivilinna @ 2012-05-06 18:23 UTC (permalink / raw)
To: Linus Walleij
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, David S. Miller, Felipe Balbi, Haiyang Zhang,
Wei Yongjun, Ben Hutchings
In-Reply-To: <CACRpkdY0t2UvU9vX4kPxV+BPOaerOWw4UKzTe_RjLOpYr2akDg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Quoting Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
> On Wed, May 2, 2012 at 5:29 PM, Jussi Kivilinna
> <jussi.kivilinna-E01nCVcF24I@public.gmane.org> wrote:
>
>> Quoting Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>>
>>> The header file <linux/usb/rndis_host.h> used a number of #defines
>>> that included the cpu_to_le32() macro to assure the result will be
>>> in LE endianness. Inlining this into the code instead of using it
>>> in the code definitions yields consolidation opportunities later
>>> on as you will see in the following patches. The individual
>>> drivers also used local defines - all are switched over to the
>>> pattern of doing the conversion at the call sites instead.
>>>
>>
>> After this patch, endianness checks with sparse output:
> (...)
>> Patch fixing this attached.
>
> Thanks! Folded this into patch 1 and added your Signed-off-by.
>
>> Patch-set to clean-up ugliness caused by this patch at:
>> http://koti.mbnet.fi/axh/kernel/rndis_wlan/
>
> This seems like a good middle-ground as compared to the
> other suggestion to force all defines to be cpu_to_le32().
>
> Do you want me to rebase this on top of my series (there was
> a number of conflicts later in the series) and carry it as part
> of this patch set?
Please, do.
>
> Yours,
> Linus Walleij
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: [PATCH 7/9] net: add skb_orphan_frags to copy aside frags with destructors
From: Michael S. Tsirkin @ 2012-05-06 17:01 UTC (permalink / raw)
To: David Miller; +Cc: ian.campbell, netdev, eric.dumazet
In-Reply-To: <20120504.025433.1474691040952890731.davem@davemloft.net>
On Fri, May 04, 2012 at 02:54:33AM -0400, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@redhat.com>
> Date: Fri, 4 May 2012 00:10:24 +0300
>
> > Hmm we orphan skbs when we loop them back so how about reusing the
> > skb->destructor for this?
>
> That's one possibility.
>
> But I fear we're about to toss Ian into yet another rabbit hole. :-)
>
> Let's try to converge on something quickly as I think integration of
> his work has been delayed enough as-is.
OK I tried doing this and I recalled why we
do the copy with ubufs before clone:
the problem is that shinfo is shared between skbs,
so modifying frags like skb_orphan_frags does is racy.
Stuck for now.
So I have a question: how about reusing the TX_DEV_ZEROCOPY
machinery for this, instead of frag destructors?
Thanks,
--
MST
^ permalink raw reply
* Re: [net-next 0/4][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-05-06 17:25 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1336221493-913-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 5 May 2012 05:38:09 -0700
> This series of patches contains updates for e1000e and ixgbe.
>
> NOTE- The ixgbe patch can and probably should be applied to
> David Miller's net tree as well.
>
> The following are changes since commit bd14b1b2e29bd6812597f896dde06eaf7c6d2f24:
> tcp: be more strict before accepting ECN negociation
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
No new changes there?
[davem@drr net-next]$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
>From git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next
* branch master -> FETCH_HEAD
Already up-to-date.
^ permalink raw reply
* Re: [PATCH 3/3] skb: Add inline helper for getting the skb end offset from head
From: David Miller @ 2012-05-06 17:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: alexander.h.duyck, netdev, jeffrey.t.kirsher
In-Reply-To: <1336196361.3752.485.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 05 May 2012 07:39:21 +0200
> On Fri, 2012-05-04 at 17:26 -0700, Alexander Duyck wrote:
>> With the recent changes for how we compute the skb truesize it occurs to me
>> we are probably going to have a lot of calls to skb_end_pointer -
>> skb->head. Instead of running all over the place doing that it would make
>> more sense to just make it a separate inline skb_end_offset(skb) that way
>> we can return the correct value without having gcc having to do all the
>> optimization to cancel out skb->head - skb->head.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
...
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] skb: Drop "fastpath" variable for skb_cloned check in pskb_expand_head
From: David Miller @ 2012-05-06 17:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: alexander.h.duyck, netdev, jeffrey.t.kirsher
In-Reply-To: <1336196244.3752.484.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 05 May 2012 07:37:24 +0200
> On Fri, 2012-05-04 at 17:26 -0700, Alexander Duyck wrote:
>> Since there is now only one spot that actually uses "fastpath" there isn't
>> much point in carrying it. Instead we can just use a check for skb_cloned
>> to verify if we can perform the fast-path free for the head or not.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
...
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] skb: Drop bad code from pskb_expand_head
From: David Miller @ 2012-05-06 17:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: alexander.h.duyck, netdev, jeffrey.t.kirsher
In-Reply-To: <1336196130.3752.483.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 05 May 2012 07:35:30 +0200
> On Fri, 2012-05-04 at 17:26 -0700, Alexander Duyck wrote:
>> The fast-path for pskb_expand_head contains a check where the size plus the
>> unaligned size of skb_shared_info is compared against the size of the data
>> buffer. This code path has two issues. First is the fact that after the
>> recent changes by Eric Dumazet to __alloc_skb and build_skb the shared info
>> is always placed in the optimal spot for a buffer size making this check
>> unnecessary. The second issue is the fact that the check doesn't take into
>> account the aligned size of shared info. As a result the code burns cycles
>> doing a memcpy with nothing actually being shifted.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
...
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net v2] cdc_ether: Ignore bogus union descriptor for RNDIS devices
From: David Miller @ 2012-05-06 17:12 UTC (permalink / raw)
To: markus-cHz7HMenPf4hFhg+JK9F0w
Cc: linux-201011-TzK+PxyQ8t4hFhg+JK9F0w, bjorn-yOkvZcmFvRU,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
shaola-r/HQZD9NxM9g9hUCZPvPmw, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
oliver-GvhC2dPhHPQdnm+yROfE0A, 655387-61a8vm9lEZVf4u+23C9RwQ,
stable-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4FA64ECC.7030005-cHz7HMenPf4hFhg+JK9F0w@public.gmane.org>
From: Markus Kolb <markus-cHz7HMenPf4hFhg+JK9F0w@public.gmane.org>
Date: Sun, 06 May 2012 12:13:32 +0200
> David Miller wrote on 03.05.2012 07:11:
>> From: Markus Kolb<linux-201011-TzK+PxyQ8t4hFhg+JK9F0w@public.gmane.org>
>> Date: Thu, 03 May 2012 06:57:39 +0200
>>
>>> I'll build it during next rainy day and will report its success
>>> after some usage ;-)
>>
>> Thank you.
>
> Works without any problem for me.
> So maybe this patch will be included in the official kernels before
> I'll buy a new mobile phone?! ;-)
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: [PATCH net v3] bnx2x: bug fix when loading after SAN boot
From: David Miller @ 2012-05-06 17:11 UTC (permalink / raw)
To: eilong; +Cc: ariele, netdev
In-Reply-To: <1336323957.12363.23.camel@lb-tlvb-eilong.il.broadcom.com>
From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Sun, 6 May 2012 20:05:57 +0300
> From: Ariel Elior <ariele@broadcom.com>
>
> This is a bug fix for an "interface fails to load" issue.
> The issue occurs when bnx2x driver loads after UNDI driver was previously
> loaded over the chip. In such a scenario the UNDI driver is loaded and operates
> in the pre-boot kernel, within its own specific host memory address range.
> When the pre-boot stage is complete, the real kernel is loaded, in a new and
> distinct host memory address range. The transition from pre-boot stage to boot
> is asynchronous from UNDI point of view.
>
> A race condition occurs when UNDI driver triggers a DMAE transaction to valid
> host addresses in the pre-boot stage, when control is diverted to the real
> kernel. This results in access to illegal addresses by our HW as the addresses
> which were valid in the preboot stage are no longer considered valid.
> Specifically, the 'was_error' bit in the pci glue of our device is set. This
> causes all following pci transactions from chip to host to timeout (in
> accordance to the pci spec).
>
> Signed-off-by: Ariel Elior <ariele@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bnx2x: bug fix when loading after SAN boot
From: Eilon Greenstein @ 2012-05-06 17:06 UTC (permalink / raw)
To: David Miller; +Cc: ariele, netdev
In-Reply-To: <20120506.123834.956789615986300329.davem@davemloft.net>
On Sun, 2012-05-06 at 12:38 -0400, David Miller wrote:
> From: "Eilon Greenstein" <eilong@broadcom.com>
> Date: Fri, 4 May 2012 22:15:40 +0300
>
> > On Fri, 2012-05-04 at 11:57 -0400, David Miller wrote:
> >> From: "Ariel Elior" <ariele@broadcom.com>
> >> Date: Thu, 3 May 2012 11:22:00 +0300
> >>
> >> > + /* clear hw from errors which mnay have resulted from an interrupted
> >> > + * dmae transaction.
> >> > + */
> >>
> >> Please fix the typos in this comment.
> >>
> >
> > Sure - thanks for pointing that out:
> >
> > Subject: [PATCH net v2] bnx2x: bug fix when loading after SAN boot
>
> Don't reply to a discussion with a patch you intend me to apply.
>
> When you do that, I have to edit all of this other crap in the
> thread out of the commit message. That makes more work for me.
>
> Always post new patches as fresh patch postings to the list.
Done.
^ permalink raw reply
* [PATCH net v3] bnx2x: bug fix when loading after SAN boot
From: Eilon Greenstein @ 2012-05-06 17:05 UTC (permalink / raw)
To: David Miller; +Cc: ariele, netdev
From: Ariel Elior <ariele@broadcom.com>
This is a bug fix for an "interface fails to load" issue.
The issue occurs when bnx2x driver loads after UNDI driver was previously
loaded over the chip. In such a scenario the UNDI driver is loaded and operates
in the pre-boot kernel, within its own specific host memory address range.
When the pre-boot stage is complete, the real kernel is loaded, in a new and
distinct host memory address range. The transition from pre-boot stage to boot
is asynchronous from UNDI point of view.
A race condition occurs when UNDI driver triggers a DMAE transaction to valid
host addresses in the pre-boot stage, when control is diverted to the real
kernel. This results in access to illegal addresses by our HW as the addresses
which were valid in the preboot stage are no longer considered valid.
Specifically, the 'was_error' bit in the pci glue of our device is set. This
causes all following pci transactions from chip to host to timeout (in
accordance to the pci spec).
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 23 +++++++++++++++++++++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index e077d25..795fc49 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -9122,13 +9122,34 @@ static int __devinit bnx2x_prev_unload_common(struct bnx2x *bp)
return bnx2x_prev_mcp_done(bp);
}
+/* previous driver DMAE transaction may have occurred when pre-boot stage ended
+ * and boot began, or when kdump kernel was loaded. Either case would invalidate
+ * the addresses of the transaction, resulting in was-error bit set in the pci
+ * causing all hw-to-host pcie transactions to timeout. If this happened we want
+ * to clear the interrupt which detected this from the pglueb and the was done
+ * bit
+ */
+static void __devinit bnx2x_prev_interrupted_dmae(struct bnx2x *bp)
+{
+ u32 val = REG_RD(bp, PGLUE_B_REG_PGLUE_B_INT_STS);
+ if (val & PGLUE_B_PGLUE_B_INT_STS_REG_WAS_ERROR_ATTN) {
+ BNX2X_ERR("was error bit was found to be set in pglueb upon startup. Clearing");
+ REG_WR(bp, PGLUE_B_REG_WAS_ERROR_PF_7_0_CLR, 1 << BP_FUNC(bp));
+ }
+}
+
static int __devinit bnx2x_prev_unload(struct bnx2x *bp)
{
int time_counter = 10;
u32 rc, fw, hw_lock_reg, hw_lock_val;
BNX2X_DEV_INFO("Entering Previous Unload Flow\n");
- /* Release previously held locks */
+ /* clear hw from errors which may have resulted from an interrupted
+ * dmae transaction.
+ */
+ bnx2x_prev_interrupted_dmae(bp);
+
+ /* Release previously held locks */
hw_lock_reg = (BP_FUNC(bp) <= 5) ?
(MISC_REG_DRIVER_CONTROL_1 + BP_FUNC(bp) * 8) :
(MISC_REG_DRIVER_CONTROL_7 + (BP_FUNC(bp) - 6) * 8);
^ permalink raw reply related
* Re: [PATCH resend] [IPV6] remove sysctl accept_source_route
From: David Miller @ 2012-05-06 16:41 UTC (permalink / raw)
To: eldad; +Cc: kuznet, jmorris, yoshfuji, kaber, linux-kernel, netdev
In-Reply-To: <1336249737-26661-1-git-send-email-eldad@fogrefinery.com>
Why are you resending this?
Your patch is sitting in patchwork waiting to be reviewed and applied.
When you needlessly resend a patch it makes more work for me, so do
not do this. Check the queue at:
http://patchwork.ozlabs.org/project/netdev/list/
first.
^ permalink raw reply
* Re: [PATCH] bnx2x: bug fix when loading after SAN boot
From: David Miller @ 2012-05-06 16:38 UTC (permalink / raw)
To: eilong; +Cc: ariele, netdev
In-Reply-To: <1336158940.12363.19.camel@lb-tlvb-eilong.il.broadcom.com>
From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Fri, 4 May 2012 22:15:40 +0300
> On Fri, 2012-05-04 at 11:57 -0400, David Miller wrote:
>> From: "Ariel Elior" <ariele@broadcom.com>
>> Date: Thu, 3 May 2012 11:22:00 +0300
>>
>> > + /* clear hw from errors which mnay have resulted from an interrupted
>> > + * dmae transaction.
>> > + */
>>
>> Please fix the typos in this comment.
>>
>
> Sure - thanks for pointing that out:
>
> Subject: [PATCH net v2] bnx2x: bug fix when loading after SAN boot
Don't reply to a discussion with a patch you intend me to apply.
When you do that, I have to edit all of this other crap in the
thread out of the commit message. That makes more work for me.
Always post new patches as fresh patch postings to the list.
^ permalink raw reply
* Re: Implementing RFCs from IETF
From: Rémi Denis-Courmont @ 2012-05-06 14:28 UTC (permalink / raw)
To: netdev
In-Reply-To: <1336313708.11610.11.camel@oc4748611672.ibm.com>
Le dimanche 6 mai 2012 17:15:08 Onkar, vous avez écrit :
> > But the copyright license does prevent example code from being copied
> > into the kernel (or any other GPL piece), in many cases.
>
> If the RFC proposes some solution to existing problem and this solution
> is proposed by some guys , at say CISCO or IBM , then does that solution
> have some kind of copyright which prevents people form other companies
> from implementing the RFC in the Linux kernel ?
Please refer to the copyright statements found in the RFC. netdev is not the
right place for lawyering.
> > Also some RFC have IPR separate claims.
>
> If possible , can you please give me one example on this as a reference.
You can find them on the IETF website.
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Re: Implementing RFCs from IETF
From: Onkar @ 2012-05-06 14:15 UTC (permalink / raw)
To: Rémi Denis-Courmont; +Cc: netdev
In-Reply-To: <201205061707.50204.remi@remlab.net>
On Sun, 2012-05-06 at 17:07 +0300, Rémi Denis-Courmont wrote:
> Le dimanche 6 mai 2012 16:59:34 Onkar, vous avez écrit :
> > Do RFCs on IETF contain some kind of copyright with the
> > authors (and their respective companies )who have written the RFC which
> > prohibits the RFC from being implemented in the Linux kernel.
>
> Of course not.
>
Thanks for your reply Remi.
> But the copyright license does prevent example code from being copied into the
> kernel (or any other GPL piece), in many cases.
If the RFC proposes some solution to existing problem and this solution
is proposed by some guys , at say CISCO or IBM , then does that solution
have some kind of copyright which prevents people form other companies
from implementing the RFC in the Linux kernel ?
> Also some RFC have IPR separate claims.
>
If possible , can you please give me one example on this as a reference.
Thank you very much.
- Onnm
^ permalink raw reply
* Re: Implementing RFCs from IETF
From: Rémi Denis-Courmont @ 2012-05-06 14:07 UTC (permalink / raw)
To: netdev
In-Reply-To: <1336312774.11610.7.camel@oc4748611672.ibm.com>
Le dimanche 6 mai 2012 16:59:34 Onkar, vous avez écrit :
> Do RFCs on IETF contain some kind of copyright with the
> authors (and their respective companies )who have written the RFC which
> prohibits the RFC from being implemented in the Linux kernel.
Of course not.
But the copyright license does prevent example code from being copied into the
kernel (or any other GPL piece), in many cases.
Also some RFC have IPR separate claims.
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Automated Response
From: Barr. Daniels @ 2012-05-06 12:58 UTC (permalink / raw)
To: mycontacts
Dear
My email address have been changed to <bbd2012motive@ua.fm> due to so much of
spam mails...... Please update your contact address with my new email and get
back to me....
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Implementing RFCs from IETF
From: Onkar @ 2012-05-06 13:59 UTC (permalink / raw)
To: netdev
Do RFCs on IETF contain some kind of copyright with the
authors (and their respective companies )who have written the RFC which
prohibits the RFC from being implemented in the Linux kernel.
Regards,
onnm
^ permalink raw reply
* Re: [PATCH 7/9] net: add skb_orphan_frags to copy aside frags with destructors
From: Michael S. Tsirkin @ 2012-05-06 13:54 UTC (permalink / raw)
To: Ian Campbell; +Cc: netdev, David Miller, Eric Dumazet
In-Reply-To: <1336056971-7839-7-git-send-email-ian.campbell@citrix.com>
On Thu, May 03, 2012 at 03:56:09PM +0100, Ian Campbell wrote:
> This should be used by drivers which need to hold on to an skb for an extended
> (perhaps unbounded) period of time. e.g. the tun driver which relies on
> userspace consuming the skb.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: mst@redhat.com
> ---
> drivers/net/tun.c | 1 +
> include/linux/skbuff.h | 11 ++++++++
> net/core/skbuff.c | 68 ++++++++++++++++++++++++++++++++++-------------
> 3 files changed, 61 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index bb8c72c..b53e04e 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -415,6 +415,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
> /* Orphan the skb - required as we might hang on to it
> * for indefinite time. */
> skb_orphan(skb);
> + skb_orphan_frags(skb, GFP_KERNEL);
>
> /* Enqueue packet */
> skb_queue_tail(&tun->socket.sk->sk_receive_queue, skb);
BTW, didn't notice at the moment but there seem to be
a couple of other problems:
1. this is using GFP_KERNEL on xmit path.
2. And it's not just a question of passing in GFP_ATOMIC:
return status needs to be checked.
3. Scanning all frags just in case one of them has
a descructor also won't help performace :(
--
MST
^ permalink raw reply
* Re: ipctl - new tool for efficient read/write of net related sysctl
From: Oskar Berggren @ 2012-05-06 12:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <9241f146-d0f7-415b-a652-acd1bf34e95a@tahiti.vyatta.com>
2012/5/6 Stephen Hemminger <stephen.hemminger@vyatta.com>:
>
>>
>> In a project of mine I need to read (and possibly set) many of the
>> properties
>> found under /proc/sys/net/ipv4/conf/. This is simple enough, except
>> that
>> when you have hundreds of interfaces, it is really slow. In my tests
>> it takes
>> about 4 seconds to read a single variable for 700 interfaces. For a
>> while I
>> worked around this using the binary sysctl() interface, but this is
>> deprecated.
>>
>
> What about exposing these as NETLINK attributes? That would be faster
> and you could do bulk updates.
This is my first attempt at using NETLINK, so could you please elaborate?
Below is the generic netlink interface I implemented so far. Any pointers
on how I should do this differently?
#ifndef IPCTL_NL_H_INCLUDED
#define IPCTL_NL_H_INCLUDED
/* Copyright (C) 2012 Oskar Berggren <oskar.berggren@gmail.com
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/* NETLINK attributes */
enum {
IPCTL_ATTR_UNSPEC,
IPCTL_ATTR_PROPERTY, /* Use IPCTL_PROPERTY_* */
IPCTL_ATTR_IFINDEX,
IPCTL_ATTR_VALUE,
__IPCTL_ATTR_MAX,
};
#define IPCTL_ATTR_MAX (__IPCTL_ATTR_MAX - 1)
/* attribute policy */
static struct nla_policy ipctl_genl_policy[IPCTL_ATTR_MAX + 1] = {
[IPCTL_ATTR_PROPERTY] = { .type = NLA_U32 },
[IPCTL_ATTR_IFINDEX] = { .type = NLA_U32 },
[IPCTL_ATTR_VALUE] = { .type = NLA_U8 },
};
/* NETLINK commands */
enum {
IPCTL_CMD_UNSPEC,
IPCTL_CMD_SET,
IPCTL_CMD_GET,
__IPCTL_CMD_MAX,
};
#define IPCTL_CMD_MAX (__IPCTL_CMD_MAX - 1)
/* Values for IPCTL_ATTR_PROPERTY. */
enum {
IPCTL_PROPERTY_PROXYARP,
};
/* ipctl use the generic netlink facility. */
#define IPCTL_GENL_NAME "ipctl"
#define IPCTL_GENL_VERSION 1
#endif
^ permalink raw reply
* Re: [PATCH net v2] cdc_ether: Ignore bogus union descriptor for RNDIS devices
From: Markus Kolb @ 2012-05-06 10:13 UTC (permalink / raw)
To: David Miller
Cc: linux-201011-TzK+PxyQ8t4hFhg+JK9F0w, bjorn-yOkvZcmFvRU,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
shaola-r/HQZD9NxM9g9hUCZPvPmw, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
oliver-GvhC2dPhHPQdnm+yROfE0A, 655387-61a8vm9lEZVf4u+23C9RwQ,
stable-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120503.011129.639700793389264897.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller wrote on 03.05.2012 07:11:
> From: Markus Kolb<linux-201011-TzK+PxyQ8t4hFhg+JK9F0w@public.gmane.org>
> Date: Thu, 03 May 2012 06:57:39 +0200
>
>> I'll build it during next rainy day and will report its success
>> after some usage ;-)
>
> Thank you.
Works without any problem for me.
So maybe this patch will be included in the official kernels before I'll
buy a new mobile phone?! ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
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