* Re: Many USB ethernet devices are broken over xhci
From: Sarah Sharp @ 2014-01-27 23:16 UTC (permalink / raw)
To: David Laight; +Cc: netdev@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D46624F@AcuExch.aculab.com>
David, you are overwhelming my capacity to handle patches right now. I
appreciate that you would like to clean up the driver, but the bug fixes
you're sending me are getting lost in the noise of random cleanup
patches.
Can you please limit the xHCI patches you send to bug fixes for now?
Also, can you resend all the patches you consider to be serious bug
fixes in one single patchset?
Thanks,
Sarah Sharp
On Mon, Jan 27, 2014 at 04:06:22PM +0000, David Laight wrote:
> Many of the net/usb ethernet drivers (including common ones like
> the smsc95xx) will fail to transmit all packet length properly
> when connected to a USB3 port (ie using the xhci driver).
>
> The underlying problem is that they assume the host controller
> will honour the URB_ZERO_PACKET flag - which usbnet sets because
> they specify FLAG_SEND_ZLP.
>
> However no one has ever added support for URB_ZERO_PACKET to
> the xhci driver - so packets that need padding (probably 512
> bytes after any header is added) will not be sent correctly
> and may have very adverse effects on the usb target.
>
> The ax179_178a driver avoids this by not setting FLAG_SEND_ZLP,
> modifying the packet header, and appending an extra zero byte.
> (Which has been responsible for its own set of panics.)
>
> I don't think this can be fixed by just clearing (or ignoring)
> FLAG_SEND_ZLP as the extra byte will also confuse things.
>
> It needs to be fixed in the xhci code.
>
> I wrote this patch a while ago - worked for me with the ax179_178a
> driver. http://www.spinics.net/lists/linux-usb/msg97370.html
>
> The patch is a bit difficult to read, the v1 version contained a copy of
> the new function. http://www.spinics.net/lists/linux-usb/msg97183.html
>
> I don't think anything significant has changed (in the main kernel
> sources) since I wrote the patch.
>
> David
>
>
>
>
^ permalink raw reply
* Re: [PATCH net-next 0/7] qlcnic: Refactoring and enhancements for all adapters.
From: David Miller @ 2014-01-27 23:24 UTC (permalink / raw)
To: zoltan.kiss; +Cc: himanshu.madhani, netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <52E6D7E1.90204@citrix.com>
From: Zoltan Kiss <zoltan.kiss@citrix.com>
Date: Mon, 27 Jan 2014 22:04:17 +0000
> On 24/01/14 00:14, David Miller wrote:
>> From: Himanshu Madhani <himanshu.madhani@qlogic.com>
>> Date: Thu, 23 Jan 2014 17:18:27 -0500
>>
>>> This patch series contains following patches.
>>>
>>> o Enhanced debug data collection when we are in Tx-timeout situation.
>>> o Enhanced MSI-x vector calculation for defualt load path as well
>>> as for TSS/RSS ring change path.
>>> o Refactored interrupt coalescing code for all adapters.
>>> o Refactored interrupt handling as well as cleanup of poll controller
>>> code patch for all adapters.
>>> o changed rx_mac_learn type to boolean.
>>>
>>> Please apply to net-next.
>>
>> Series applied, thanks.
>
> Not that I reject fame, but the commit message contains my name as
> sign-off, while I've never seen a bit of that code :)
Sorry about that. What happens is that I build the merge commit
messages from a template, and I used a template for a previous
serious with your signoff by accident :-/
^ permalink raw reply
* Re: Many USB ethernet devices are broken over xhci
From: Greg KH @ 2014-01-27 23:33 UTC (permalink / raw)
To: David Laight
Cc: netdev@vger.kernel.org, linux-usb@vger.kernel.org, Sarah Sharp
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D46624F@AcuExch.aculab.com>
On Mon, Jan 27, 2014 at 04:06:22PM +0000, David Laight wrote:
> Many of the net/usb ethernet drivers (including common ones like
> the smsc95xx) will fail to transmit all packet length properly
> when connected to a USB3 port (ie using the xhci driver).
That's odd, as I've never had a problem with my USB 3.0 ethernet device
(sorry, don't remember what driver it uses), and I stress it all the
time.
I've also run two different USB 2 ethernet devices on xhci with no
issues at all, so perhaps the "many" statement might not be true?
> The underlying problem is that they assume the host controller
> will honour the URB_ZERO_PACKET flag - which usbnet sets because
> they specify FLAG_SEND_ZLP.
>
> However no one has ever added support for URB_ZERO_PACKET to
> the xhci driver - so packets that need padding (probably 512
> bytes after any header is added) will not be sent correctly
> and may have very adverse effects on the usb target.
Really? How has things been working so well up to now without this
support? Doesn't the hardware automatically add this padding with no
explicit need for the xhci driver to do something?
> The ax179_178a driver avoids this by not setting FLAG_SEND_ZLP,
> modifying the packet header, and appending an extra zero byte.
> (Which has been responsible for its own set of panics.)
>
> I don't think this can be fixed by just clearing (or ignoring)
> FLAG_SEND_ZLP as the extra byte will also confuse things.
>
> It needs to be fixed in the xhci code.
>
> I wrote this patch a while ago - worked for me with the ax179_178a
> driver. http://www.spinics.net/lists/linux-usb/msg97370.html
Doing multiple things in a patch is generally considered bad-form, and
this is quite hard to follow.
> The patch is a bit difficult to read, the v1 version contained a copy of
> the new function. http://www.spinics.net/lists/linux-usb/msg97183.html
That's not helpful to the people having to review the v2 patch :)
> I don't think anything significant has changed (in the main kernel
> sources) since I wrote the patch.
Then resubmit it, don't post links to it on the web, there's nothing we
can do with them, sorry.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 3/3] net: via-rhine: add OF bus binding
From: Ben Hutchings @ 2014-01-27 23:40 UTC (permalink / raw)
To: Alexey Charkov
Cc: netdev, Tony Prisk, devicetree, Roger Luethi,
linux-kernel@vger.kernel.org
In-Reply-To: <CABjd4Yz2Kfed_qBfSAEXoAcVxfsmhTBA-83YJ9_iSwPZ+r1qYQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
On Mon, 2014-01-27 at 19:34 +0400, Alexey Charkov wrote:
> 2014/1/27 Ben Hutchings <ben@decadent.org.uk>:
> > On Mon, 2014-01-27 at 15:51 +0400, Alexey Charkov wrote:
> >> This should make the driver usable with VIA/WonderMedia ARM-based
> >> Systems-on-Chip integrated Rhine III adapters. Note that these
> >> are always in MMIO mode, and don't have any known EEPROM.
> > [...]
> >> --- a/drivers/net/ethernet/via/Kconfig
> >> +++ b/drivers/net/ethernet/via/Kconfig
> >> @@ -19,7 +19,7 @@ if NET_VENDOR_VIA
> >>
> >> config VIA_RHINE
> >> tristate "VIA Rhine support"
> >> - depends on PCI
> >> + depends on (PCI || USE_OF)
> >> select CRC32
> >> select MII
> >> ---help---
> >
> > This seems like the right thing to do, but it means you need to add
> > #ifdef CONFIG_PCI and #ifdef CONFIG_USE_OF around the driver structures
> > and related functions.
>
> Frankly, I would like to avoid that if possible (as pointed out in the
> cover email), as I believe we would get a cleaner driver without
> #ifdef. This is also the way it was done in via-velocity, and it works
> just fine.
OK, I'm surprised that all the PCI functions have dummy definitions.
> > You should compile-test in configurations that have just one of those
> > dependencies enabled.
>
> This has been compile-tested and runtime-tested in OF-only
> configuration on WM8950, and Roger also tested it in PCI-only
> configuration, so it seems to work fine.
[...]
Good, then I have no objection.
Ben.
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH 0/2] DT: net: davinci_emac: couple more properties actually optional
From: Sergei Shtylyov @ 2014-01-27 23:45 UTC (permalink / raw)
To: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree
Cc: linux-doc, davinci-linux-open-source
Hello.
Though described as required, couple more properties in the DaVinci EMAC
binding are actually optional, as the driver will happily function without them.
The patchset is against DaveM's 'net.git' tree this time.
[1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually optional
[2/2] DT: net: davinci_emac: "ti,davinci-no-bd-ram" property is actually optional
WBR, Sergei
^ permalink raw reply
* [PATCH 1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually optional
From: Sergei Shtylyov @ 2014-01-27 23:47 UTC (permalink / raw)
To: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree
Cc: linux-doc, davinci-linux-open-source
Though described as required, the "ti,davinci-rmii-en" property for the DaVinci
EMAC binding seems actually optional, as the driver should happily work without
it; the property is not specified either in the example device node or in the
actual EMAC device node for DA850 device tree, only AM3517 one.
While at it, document the property better...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Actually I think this property should have been boolean...
Documentation/devicetree/bindings/net/davinci_emac.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net/Documentation/devicetree/bindings/net/davinci_emac.txt
===================================================================
--- net.orig/Documentation/devicetree/bindings/net/davinci_emac.txt
+++ net/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -10,7 +10,6 @@ Required properties:
- ti,davinci-ctrl-mod-reg-offset: offset to control module register
- ti,davinci-ctrl-ram-offset: offset to control module ram
- ti,davinci-ctrl-ram-size: size of control module ram
-- ti,davinci-rmii-en: use RMII
- ti,davinci-no-bd-ram: has the emac controller BD RAM
- interrupts: interrupt mapping for the davinci emac interrupts sources:
4 sources: <Receive Threshold Interrupt
@@ -22,6 +21,7 @@ Optional properties:
- phy-handle: Contains a phandle to an Ethernet PHY.
If absent, davinci_emac driver defaults to 100/FULL.
- local-mac-address : 6 bytes, mac address
+- ti,davinci-rmii-en: 1 byte, 1 means use RMII
Example (enbw_cmc board):
eth0: emac@1e20000 {
^ permalink raw reply
* [PATCH 2/2] DT: net: davinci_emac: "ti,davinci-no-bd-ram" property is actually optional
From: Sergei Shtylyov @ 2014-01-27 23:49 UTC (permalink / raw)
To: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree
Cc: linux-doc, davinci-linux-open-source
The "ti,davinci-no-bd-ram" property for the DaVinci EMAC binding simply can't be
required one, as it's boolean (which means it's absent if false).
While at it, document the property better...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Documentation/devicetree/bindings/net/davinci_emac.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net/Documentation/devicetree/bindings/net/davinci_emac.txt
===================================================================
--- net.orig/Documentation/devicetree/bindings/net/davinci_emac.txt
+++ net/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -10,7 +10,6 @@ Required properties:
- ti,davinci-ctrl-mod-reg-offset: offset to control module register
- ti,davinci-ctrl-ram-offset: offset to control module ram
- ti,davinci-ctrl-ram-size: size of control module ram
-- ti,davinci-no-bd-ram: has the emac controller BD RAM
- interrupts: interrupt mapping for the davinci emac interrupts sources:
4 sources: <Receive Threshold Interrupt
Receive Interrupt
@@ -22,6 +21,7 @@ Optional properties:
If absent, davinci_emac driver defaults to 100/FULL.
- local-mac-address : 6 bytes, mac address
- ti,davinci-rmii-en: 1 byte, 1 means use RMII
+- ti,davinci-no-bd-ram: boolean, does EMAC has BD RAM?
Example (enbw_cmc board):
eth0: emac@1e20000 {
^ permalink raw reply
* Re: [PATCH 2/2] DT: net: davinci_emac: "ti,davinci-no-bd-ram" property is actually optional
From: Sergei Shtylyov @ 2014-01-27 23:59 UTC (permalink / raw)
To: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree
Cc: linux-doc, davinci-linux-open-source
In-Reply-To: <201401280249.40451.sergei.shtylyov@cogentembedded.com>
Hello.
On 01/28/2014 02:49 AM, Sergei Shtylyov wrote:
> The "ti,davinci-no-bd-ram" property for the DaVinci EMAC binding simply can't be
> required one, as it's boolean (which means it's absent if false).
> While at it, document the property better...
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> ---
> Documentation/devicetree/bindings/net/davinci_emac.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> Index: net/Documentation/devicetree/bindings/net/davinci_emac.txt
> ===================================================================
> --- net.orig/Documentation/devicetree/bindings/net/davinci_emac.txt
> +++ net/Documentation/devicetree/bindings/net/davinci_emac.txt
> @@ -10,7 +10,6 @@ Required properties:
> - ti,davinci-ctrl-mod-reg-offset: offset to control module register
> - ti,davinci-ctrl-ram-offset: offset to control module ram
> - ti,davinci-ctrl-ram-size: size of control module ram
> -- ti,davinci-no-bd-ram: has the emac controller BD RAM
> - interrupts: interrupt mapping for the davinci emac interrupts sources:
> 4 sources: <Receive Threshold Interrupt
> Receive Interrupt
> @@ -22,6 +21,7 @@ Optional properties:
> If absent, davinci_emac driver defaults to 100/FULL.
> - local-mac-address : 6 bytes, mac address
> - ti,davinci-rmii-en: 1 byte, 1 means use RMII
> +- ti,davinci-no-bd-ram: boolean, does EMAC has BD RAM?
Too hasty, s/has/have/. Do I need to resend or this could be fixed when
applying?
WBR, Sergei
^ permalink raw reply
* Re: [BUG PATCH] Memory leak on tcp_prot slab with TPROXY and TCP early demux
From: David Miller @ 2014-01-28 0:23 UTC (permalink / raw)
To: holger; +Cc: netdev, netfilter-devel, fw
In-Reply-To: <20140127093317.GU7176@imap.eitzenberger.org>
From: Holger Eitzenberger <holger@eitzenberger.org>
Date: Mon, 27 Jan 2014 10:33:18 +0100
> Please have a look, there could be smarter ways of fixing that.
Looks good, applied and queued up for -stable.
Thanks!
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Hannes Frederic Sowa @ 2014-01-28 0:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Florian Westphal, netdev
In-Reply-To: <1390846967.27806.75.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, Jan 27, 2014 at 10:22:47AM -0800, Eric Dumazet wrote:
> On Mon, 2014-01-27 at 09:22 +0100, Florian Westphal wrote:
>
> > +/* called if GSO skb needs to be fragmented on forward. */
> > +static int ip_forward_finish_gso(struct sk_buff *skb)
> > +{
> > + netdev_features_t features = netif_skb_features(skb);
netif_skb_features uses skb->dev for determination of offloading features but
we actually need rt->dst.dev, no?
> > + struct sk_buff *segs;
> > + int ret = 0;
> > +
> > + segs = skb_gso_segment(skb, features & ~NETIF_F_GSO_MASK);
> > + if (IS_ERR(segs)) {
> > + kfree_skb(skb);
> > + return -ENOMEM;
> > + }
> > +
> > + consume_skb(skb);
> > +
> > + do {
> > + struct sk_buff *nskb = segs->next;
> > + int err;
> > +
> > + segs->next = NULL;
> > + err = dst_output(segs);
> > +
> > + if (err && ret == 0)
> > + ret = err;
> > + segs = nskb;
> > + } while (segs);
> > +
> > + return ret;
> > +}
> > +
>
> Its still unclear if this is the best strategy.
>
> TCP stream not using DF flag are very unlikely to care if we adjust
> their MTU (lowering gso_size) at this point ?
UDP shouldn't be a problem, too.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH RFC v3 0/12] vti4: prepare namespace and interfamily support.
From: David Miller @ 2014-01-28 0:35 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev, christophe.gouault, saurabh.mohan
In-Reply-To: <1390818577-19589-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 27 Jan 2014 11:29:25 +0100
> This patchset prepares vti4 for proper namespace and interfamily
> support.
No major objections from me, this looks good.
^ permalink raw reply
* Re: [PATCH] sky2: initialize napi before registering device
From: David Miller @ 2014-01-28 0:40 UTC (permalink / raw)
To: stf_xl; +Cc: netdev, mlindner, stephen
In-Reply-To: <20140125103454.GA2490@localhost.localdomain>
From: Stanislaw Gruszka <stf_xl@wp.pl>
Date: Sat, 25 Jan 2014 11:34:54 +0100
> There is race condition when call netif_napi_add() after
> register_netdevice(), as ->open() can be called without napi initialized
> and trigger BUG_ON() on napi_enable(), like on below messages:
...
> To fix the problem patch changes the order of initialization.
>
> Bug report:
> https://bugzilla.kernel.org/show_bug.cgi?id=67151
>
> Reported-and-tested-by: ebrahim.azarisooreh@gmail.com
> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH net-next] hyperv: Add support for physically discontinuous receive buffer
From: David Miller @ 2014-01-28 0:41 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, jasowang, driverdev-devel, linux-kernel
In-Reply-To: <1390863822-3509-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Mon, 27 Jan 2014 15:03:42 -0800
> This will allow us to use bigger receive buffer, and prevent allocation failure
> due to fragmented memory.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Applied, thanks.
^ permalink raw reply
* Re: linux-next: manual merge of the bluetooth tree with the net/net-next trees
From: David Miller @ 2014-01-28 0:43 UTC (permalink / raw)
To: sfr; +Cc: gustavo, netdev, linux-next, linux-kernel, dborkman,
jukka.rissanen
In-Reply-To: <20140128095415.8382335c33545ad14d4be067@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 28 Jan 2014 09:54:15 +1100
> On Tue, 7 Jan 2014 12:54:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
...
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Tue, 7 Jan 2014 12:52:43 +1100
>> Subject: [PATCH] net: 6lowpan: fixup for code movement
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
...
> I think this fix patch got missed when bluetooth was merged ... so it
> should probably go into the net tree.
Good catch, applied, thanks Stephen!
^ permalink raw reply
* Re: [PATCH V2 0/4] misc: xgene: Add support for APM X-Gene SoC Queue Manager/Traffic Manager
From: Ravi Patel @ 2014-01-28 0:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg KH, Loc Ho, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Jon Masters, patches-qTEPVZfXA3Y@public.gmane.org, Keyur Chudgar
In-Reply-To: <201401141615.55820.arnd-r2nGTMty4D4@public.gmane.org>
On Tue, Jan 14, 2014 at 7:15 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> Now that I have a better understanding of what the driver is good for and
> how it's used, let's have a look at how we can make it fit into the Linux
> driver APIs and the DT bindings. We don't have anything exactly like this
> yet, but I think the "mailbox" framework is a close enough match that we
> can fit it in there, with some extensions. This framework is still in the
> process of being created (so far there is only a TI OMAP specific driver,
> and one for pl320), and I've not seen any mailboxes that support IRQ
> mitigation or multiple software interfaces per hardware mailbox, but those
> should be easy enough to add.
OK. We will put Queue Manager driver under drivers/mailbox directory along
with TI OMAP and pl320 drivers.
> For the DT binding, I would suggest using something along the lines of
> what we have for clocks, pinctrl and dmaengine. OMAP doesn't use this
> (yet), but now would be a good time to standardize it. The QMTM node
> should define a "#mailbox-cells" property that indicates how many
> 32-bit cells a qmtm needs to describe the connection between the
> controller and the slave. My best guess is that this would be hardcoded
> to <3>, using two cells for a 64-bit FIFO bus address, and a 32-bit cell
> for the slave-id signal number. All other parameters that you have in
> the big table in the qmtm driver at the moment can then get moved into
> the slave drivers, as they are constant per type of slave. This will
> simplify the QMTM driver.
>
> In the slave, you should have a "mailboxes" property with a phandle
> to the qmtm followed by the three cells to identify the actual
> queue. If it's possible that a device uses more than one rx and
> one tx queue, we also need a "mailbox-names" property to identify
> the individual queues.
We explored on DT bindings suggestion given by you. We have come
up with a sample DT binding for how it will look like. Herewith we have
provided the same. Would you please review and give us your
comments before we change our driver and DTS file to accomodate it?
Sample DTS node for QM:
qmlite: qmtm@17030000 {
compatible = "apm,xgene-qmtm-lite";
reg = <0x0 0x17030000 0x0 0x10000>,
<0x0 0x10000000 0x0 0x400000>;
interrupts = <0x0 0x40 0x4>,
<0x0 0x3c 0x4>;
status = "ok";
#clock-cells = <1>;
clocks = <&qmlclk 0>;
#mailbox-cells = <3>;
};
Sample DTS node for Ethernet:
menet: ethernet@17020000 {
compatible = "apm,xgene-enet";
status = "disabled";
reg = <0x0 0x17020000 0x0 0x30>,
<0x0 0x17020000 0x0 0x10000>,
<0x0 0x17020000 0x0 0x20>;
mailboxes = <&qmlite 0x0 0x1000002c 0x0000>,
<&qmlite 0x0 0x10000052 0x0020>,
<&qmlite 0x0 0x10000060 0x0f00>
mailbox-names = "mb-tx", "mb-fp", "mb-rx";
interrupts = <0x0 0x38 0x4>,
<0x0 0x39 0x4>,
<0x0 0x3a 0x4>;
#clock-cells = <1>;
clocks = <ð8clk 0>;
local-mac-address = <0x0 0x11 0x3a 0x8a 0x5a 0x78>;
max-frame-size = <0x233a>;
phyid = <3>;
phy-mode = "rgmii";
};
The mailbox node in DTS has following format:
mailbox = <&parent 'higher 32 bit bus address' 'lower 32 bit bus
address' 'signal id'>
Ethernet driver will call following function in platform_probe:
mailbox_get(dev, "mb-tx");
mailbox_get API will return the the context of allocated and configured mailbox.
For now, mailbox_get API will be implemented in xgene QMTM driver.
Eventually when mailbox framework in Linux will be standardized, we
will use it instead.
> For the in-kernel interfaces, we should probably start a conversation
> with the owners of the mailbox drivers to get a common API, for now
> I'd suggest you just leave it as it is, and only adapt for the new
> binding.
Sure. For now we will put our driver mostly as is in the
drivers/mailbox. Can you please help us identify the owners of the
mailbox drivers? As you suggested, we can start conversation with them
to define common in kernel APIs.
Ravi
On Tue, Jan 14, 2014 at 7:15 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Monday 13 January 2014, Ravi Patel wrote:
>> > Examples for local resource management (I had to think about this
>> > a long time, but probably some of these are wrong) would be
>> > * balancing between multiple non-busmaster devices connected to
>> > a dma-engine
>> > * distributing incoming ethernet data to the available CPUs based on
>> > a flow classifier in the MAC, e.g. by IOV MAC address, VLAN tag
>> > or even individual TCP connection depending on the NIC's capabilities.
>> > * 802.1p flow control for incoming ethernet data based on the amount
>> > of data queued up between the MAC and the driver
>> > * interrupt mitigation for both inbound data and outbound completion,
>> > by delaying the IRQ to the OS until multiple messages have arrived
>> > or a queue specific amount of time has passed.
>> > * controlling the amount of outbound buffer space per flow to minimize
>> > buffer-bloat between an ethernet driver and the NIC hardware.
>> > * reordering data from outbound flows based on priority.
>> >
>> > This is basically my current interpretation, I hope I got at least
>> > some of it right this time ;-)
>>
>> You have got them right. Although we have taken Ethernet examples here,
>> most of the local resource management apply to other slave devices also.
>
> I'm very suprised I got all those right, it seems it's a quite sophisticated
> piece of hardware then. I guess most other slave devices only use a subset
> of the capabilities that ethernet wants.
>
> Now that I have a better understanding of what the driver is good for and
> how it's used, let's have a look at how we can make it fit into the Linux
> driver APIs and the DT bindings. We don't have anything exactly like this
> yet, but I think the "mailbox" framework is a close enough match that we
> can fit it in there, with some extensions. This framework is still in the
> process of being created (so far there is only a TI OMAP specific driver,
> and one for pl320), and I've not seen any mailboxes that support IRQ
> mitigation or multiple software interfaces per hardware mailbox, but those
> should be easy enough to add.
>
> For the DT binding, I would suggest using something along the lines of
> what we have for clocks, pinctrl and dmaengine. OMAP doesn't use this
> (yet), but now would be a good time to standardize it. The QMTM node
> should define a "#mailbox-cells" property that indicates how many
> 32-bit cells a qmtm needs to describe the connection between the
> controller and the slave. My best guess is that this would be hardcoded
> to <3>, using two cells for a 64-bit FIFO bus address, and a 32-bit cell
> for the slave-id signal number. All other parameters that you have in
> the big table in the qmtm driver at the moment can then get moved into
> the slave drivers, as they are constant per type of slave. This will
> simplify the QMTM driver.
>
> In the slave, you should have a "mailboxes" property with a phandle
> to the qmtm followed by the three cells to identify the actual
> queue. If it's possible that a device uses more than one rx and
> one tx queue, we also need a "mailbox-names" property to identify
> the individual queues.
>
> For the in-kernel interfaces, we should probably start a conversation
> with the owners of the mailbox drivers to get a common API, for now
> I'd suggest you just leave it as it is, and only adapt for the new
> binding.
>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: Freescale FEC packet loss
From: Marek Vasut @ 2014-01-28 1:01 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev@vger.kernel.org, Frank Li, fugang.duan,
fabio.estevam@freescale.com, Hector Palacios, linux-arm-kernel,
Detlev Zundel, Eric Nelson, Matthew Garrett
In-Reply-To: <1390772013.2735.47.camel@deadeye.wl.decadent.org.uk>
On Sunday, January 26, 2014 at 10:33:33 PM, Ben Hutchings wrote:
> On Sun, 2014-01-26 at 20:12 +0100, Marek Vasut wrote:
> > On Sunday, January 26, 2014 at 07:56:30 PM, Ben Hutchings wrote:
> > > On Wed, 2014-01-22 at 22:55 +0100, Marek Vasut wrote:
> > > > Hi guys,
> > > >
> > > > I am running stock Linux 3.13 on i.MX6Q SabreLite board. The CPU is
> > > > i.MX6Q TO 1.0 .
> > > >
> > > > I am hitting a WARNING when I use the FEC ethernet to transfer data,
> > > > thus I started investigating this problem. TL;DR I am not able to
> > > > figure this problem out, so I am not attaching a patch :-(
> > > >
> > > > Steps to reproduce:
> > > > -------------------
> > > > 1) Boot stock Linux 3.13 on i.MX6Q SabreLite board
> > > > 2) Plug in an SD card into one of the SD slots (I use the full-size
> > > > one) 3) Plug in an USB stick into one of the USB ports (I use the
> > > > upper one) 4) Plug in an ethernet cable into the board
> > > >
> > > > -> Connect the other side into a gigabit-capable PC
> > >
> > > [...]
> > >
> > > I think there are known problems with 1000BASE-T on the Sabre Lite
> > > board.
> >
> > This is MX6-wide thing, not sabrelite specific actually.
> >
> > > Two possible workarounds are to limit the PHY to 100BASE-TX
> > > (should be doable with ethtool) or force it to be clock master for
> > > 1000BASE-T (requires a driver patch).
> >
> > Can you please elaborate on the later ? I don't quite understand that.
>
> 1000BASE-T uses all 4 pairs in both directions at the same time, which
> requires that both ends transmit symbols synchronously. As part of the
> autonegotiation protocol, they decide which is the clock master (using a
> local clock generator) and which is the clock slave (generating a clock
> from the received signal). A PHY can be configured to support only one
> of these roles.
I checked the patch you pointed me to. The patch basically messes with the
CTL1000 (0x9) register of the PHY, right ? I did the adjustments to the PHY
register manually , but the result is still the same (backtrace).
I did two different kinds of adjustment:
1) reg 0x9 |= 0x1800;
2) reg 0x9 |= 0x1000;
In both cases, the crash did happen. I verified the PHY register was configured
as necessary. The KSZ9021 PHY bit 12 configures the master/slave override, same
as the patch does. The bit 11 forces either master or slave mode for the PHY. In
both cases the crash was there.
I think this patch won't help in this case, sorry.
Best regards,
Marek Vasut
^ permalink raw reply
* Hi
From: a8kef58kbi @ 2014-01-28 1:25 UTC (permalink / raw)
To: a8kef58kbi
Diploma?
http://tiny.cc/2ww2cz4evf
^ permalink raw reply
* Re: [PATCH] AF_PACKET: Add documentation for queue mapping fanout mode
From: Neil Horman @ 2014-01-28 2:15 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev, David S. Miller, Daniel Borkmann
In-Reply-To: <87d2jdqepa.fsf@tassilo.jf.intel.com>
On Mon, Jan 27, 2014 at 01:48:01PM -0800, Andi Kleen wrote:
> Neil Horman <nhorman@tuxdriver.com> writes:
>
> > Recently I added a new AF_PACKET fanout operation mode in commit
> > 2d36097, but I forgot to document it. Add PACKET_FANOUT_QM as an available mode
> > in the af_packet documentation. Applies to net-next.
>
> Please also send a man page patch.
>
> -Andi
>
I'll take care of it in the am. Thanks for the reminder!
Neil
> --
> ak@linux.intel.com -- Speaking for myself only
>
^ permalink raw reply
* Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include <linux/init.h>
From: Benjamin Herrenschmidt @ 2014-01-28 3:13 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Stephen Rothwell, linux-arch, linux-mips, linux-m68k, rusty,
linux-ia64, kvm, linux-s390, netdev, x86, linux-kernel, torvalds,
gregkh, linux-alpha, sparclinux, akpm, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20140123003838.GA10182@windriver.com>
On Wed, 2014-01-22 at 19:38 -0500, Paul Gortmaker wrote:
> Thanks, it was a great help as it uncovered a few issues in fringe arch
> that I didn't have toolchains for, and I've fixed all of those up.
>
> I've noticed that powerpc has been un-buildable for a while now; I have
> used this hack patch locally so I could run the ppc defconfigs to check
> that I didn't break anything. Maybe useful for linux-next in the
> interim? It is a hack patch -- Not-Signed-off-by: Paul Gortmaker. :)
Can you and/or Aneesh submit that as a proper patch (with S-O-B
etc...) ?
Thanks !
Cheers,
Ben.
> Paul.
> --
>
> diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
> index d27960c89a71..d0f070a2b395 100644
> --- a/arch/powerpc/include/asm/pgtable-ppc64.h
> +++ b/arch/powerpc/include/asm/pgtable-ppc64.h
> @@ -560,9 +560,9 @@ extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
> pmd_t *pmdp);
>
> #define pmd_move_must_withdraw pmd_move_must_withdraw
> -typedef struct spinlock spinlock_t;
> -static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
> - spinlock_t *old_pmd_ptl)
> +struct spinlock;
> +static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
> + struct spinlock *old_pmd_ptl)
> {
> /*
> * Archs like ppc64 use pgtable to store per pmd
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [Xen-devel] [PATCH net-next v5] xen-netfront: clean up code in xennet_release_rx_bufs
From: annie li @ 2014-01-28 3:29 UTC (permalink / raw)
To: David Miller; +Cc: david.vrabel, wei.liu2, ian.campbell, netdev, xen-devel
In-Reply-To: <20140127.130921.7056971883805642.davem@davemloft.net>
On 2014/1/28 5:09, David Miller wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Mon, 27 Jan 2014 10:22:58 +0000
>
>> I think this should be applied to net (and tagged as a stable candidate)
>> rather than net-next as this fixes are very big resource leak.
> Then this subject line and commit message must be fixed to make it clear
> that this is a BUG fix, rather then just a "clean up".
>
I will post a new patch with correct subject and commit message.
Thanks
Annie
^ permalink raw reply
* [Xen-devel] [PATCH net v6] xen-netfront: fix resource leak in netfront
From: Annie Li @ 2014-01-28 3:35 UTC (permalink / raw)
To: xen-devel, netdev
Cc: konrad.wilk, ian.campbell, wei.liu2, david.vrabel, annie.li
From: Annie Li <annie.li@oracle.com>
This patch removes grant transfer releasing code from netfront, and uses
gnttab_end_foreign_access to end grant access since
gnttab_end_foreign_access_ref may fail when the grant entry is
currently used for reading or writing.
* clean up grant transfer code kept from old netfront(2.6.18) which grants
pages for access/map and transfer. But grant transfer is deprecated in current
netfront, so remove corresponding release code for transfer.
* fix resource leak, release grant access (through gnttab_end_foreign_access)
and skb for tx/rx path, use get_page to ensure page is released when grant
access is completed successfully.
Xen-blkfront/xen-tpmfront/xen-pcifront also have similar issue, but patches
for them will be created separately.
V6: Correct subject line and commit message.
V5: Remove unecessary change in xennet_end_access.
V4: Revert put_page in gnttab_end_foreign_access, and keep netfront change in
single patch.
V3: Changes as suggestion from David Vrabel, ensure pages are not freed untill
grant acess is ended.
V2: Improve patch comments.
Signed-off-by: Annie Li <annie.li@oracle.com>
---
drivers/net/xen-netfront.c | 88 +++++++++++++-------------------------------
1 files changed, 26 insertions(+), 62 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index d7bee8a..6ddf1e6 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -117,6 +117,7 @@ struct netfront_info {
} tx_skbs[NET_TX_RING_SIZE];
grant_ref_t gref_tx_head;
grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
+ struct page *grant_tx_page[NET_TX_RING_SIZE];
unsigned tx_skb_freelist;
spinlock_t rx_lock ____cacheline_aligned_in_smp;
@@ -396,6 +397,7 @@ static void xennet_tx_buf_gc(struct net_device *dev)
gnttab_release_grant_reference(
&np->gref_tx_head, np->grant_tx_ref[id]);
np->grant_tx_ref[id] = GRANT_INVALID_REF;
+ np->grant_tx_page[id] = NULL;
add_id_to_freelist(&np->tx_skb_freelist, np->tx_skbs, id);
dev_kfree_skb_irq(skb);
}
@@ -452,6 +454,7 @@ static void xennet_make_frags(struct sk_buff *skb, struct net_device *dev,
gnttab_grant_foreign_access_ref(ref, np->xbdev->otherend_id,
mfn, GNTMAP_readonly);
+ np->grant_tx_page[id] = virt_to_page(data);
tx->gref = np->grant_tx_ref[id] = ref;
tx->offset = offset;
tx->size = len;
@@ -497,6 +500,7 @@ static void xennet_make_frags(struct sk_buff *skb, struct net_device *dev,
np->xbdev->otherend_id,
mfn, GNTMAP_readonly);
+ np->grant_tx_page[id] = page;
tx->gref = np->grant_tx_ref[id] = ref;
tx->offset = offset;
tx->size = bytes;
@@ -596,6 +600,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
mfn = virt_to_mfn(data);
gnttab_grant_foreign_access_ref(
ref, np->xbdev->otherend_id, mfn, GNTMAP_readonly);
+ np->grant_tx_page[id] = virt_to_page(data);
tx->gref = np->grant_tx_ref[id] = ref;
tx->offset = offset;
tx->size = len;
@@ -1085,10 +1090,11 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
continue;
skb = np->tx_skbs[i].skb;
- gnttab_end_foreign_access_ref(np->grant_tx_ref[i],
- GNTMAP_readonly);
- gnttab_release_grant_reference(&np->gref_tx_head,
- np->grant_tx_ref[i]);
+ get_page(np->grant_tx_page[i]);
+ gnttab_end_foreign_access(np->grant_tx_ref[i],
+ GNTMAP_readonly,
+ (unsigned long)page_address(np->grant_tx_page[i]));
+ np->grant_tx_page[i] = NULL;
np->grant_tx_ref[i] = GRANT_INVALID_REF;
add_id_to_freelist(&np->tx_skb_freelist, np->tx_skbs, i);
dev_kfree_skb_irq(skb);
@@ -1097,78 +1103,35 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
static void xennet_release_rx_bufs(struct netfront_info *np)
{
- struct mmu_update *mmu = np->rx_mmu;
- struct multicall_entry *mcl = np->rx_mcl;
- struct sk_buff_head free_list;
- struct sk_buff *skb;
- unsigned long mfn;
- int xfer = 0, noxfer = 0, unused = 0;
int id, ref;
- dev_warn(&np->netdev->dev, "%s: fix me for copying receiver.\n",
- __func__);
- return;
-
- skb_queue_head_init(&free_list);
-
spin_lock_bh(&np->rx_lock);
for (id = 0; id < NET_RX_RING_SIZE; id++) {
- ref = np->grant_rx_ref[id];
- if (ref == GRANT_INVALID_REF) {
- unused++;
- continue;
- }
+ struct sk_buff *skb;
+ struct page *page;
skb = np->rx_skbs[id];
- mfn = gnttab_end_foreign_transfer_ref(ref);
- gnttab_release_grant_reference(&np->gref_rx_head, ref);
- np->grant_rx_ref[id] = GRANT_INVALID_REF;
-
- if (0 == mfn) {
- skb_shinfo(skb)->nr_frags = 0;
- dev_kfree_skb(skb);
- noxfer++;
+ if (!skb)
continue;
- }
- if (!xen_feature(XENFEAT_auto_translated_physmap)) {
- /* Remap the page. */
- const struct page *page =
- skb_frag_page(&skb_shinfo(skb)->frags[0]);
- unsigned long pfn = page_to_pfn(page);
- void *vaddr = page_address(page);
+ ref = np->grant_rx_ref[id];
+ if (ref == GRANT_INVALID_REF)
+ continue;
- MULTI_update_va_mapping(mcl, (unsigned long)vaddr,
- mfn_pte(mfn, PAGE_KERNEL),
- 0);
- mcl++;
- mmu->ptr = ((u64)mfn << PAGE_SHIFT)
- | MMU_MACHPHYS_UPDATE;
- mmu->val = pfn;
- mmu++;
+ page = skb_frag_page(&skb_shinfo(skb)->frags[0]);
- set_phys_to_machine(pfn, mfn);
- }
- __skb_queue_tail(&free_list, skb);
- xfer++;
- }
-
- dev_info(&np->netdev->dev, "%s: %d xfer, %d noxfer, %d unused\n",
- __func__, xfer, noxfer, unused);
+ /* gnttab_end_foreign_access() needs a page ref until
+ * foreign access is ended (which may be deferred).
+ */
+ get_page(page);
+ gnttab_end_foreign_access(ref, 0,
+ (unsigned long)page_address(page));
+ np->grant_rx_ref[id] = GRANT_INVALID_REF;
- if (xfer) {
- if (!xen_feature(XENFEAT_auto_translated_physmap)) {
- /* Do all the remapping work and M2P updates. */
- MULTI_mmu_update(mcl, np->rx_mmu, mmu - np->rx_mmu,
- NULL, DOMID_SELF);
- mcl++;
- HYPERVISOR_multicall(np->rx_mcl, mcl - np->rx_mcl);
- }
+ kfree_skb(skb);
}
- __skb_queue_purge(&free_list);
-
spin_unlock_bh(&np->rx_lock);
}
@@ -1339,6 +1302,7 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev)
for (i = 0; i < NET_RX_RING_SIZE; i++) {
np->rx_skbs[i] = NULL;
np->grant_rx_ref[i] = GRANT_INVALID_REF;
+ np->grant_tx_page[i] = NULL;
}
/* A grant for every tx ring slot */
--
1.7.3.4
^ permalink raw reply related
* Re: [Xen-devel] [PATCH net v6] xen-netfront: fix resource leak in netfront
From: David Miller @ 2014-01-28 3:49 UTC (permalink / raw)
To: Annie.li
Cc: xen-devel, netdev, konrad.wilk, ian.campbell, wei.liu2,
david.vrabel
In-Reply-To: <1390880142-4962-1-git-send-email-Annie.li@oracle.com>
From: Annie Li <Annie.li@oracle.com>
Date: Tue, 28 Jan 2014 11:35:42 +0800
> This patch removes grant transfer releasing code from netfront, and uses
> gnttab_end_foreign_access to end grant access since
> gnttab_end_foreign_access_ref may fail when the grant entry is
> currently used for reading or writing.
Applied and queued up for -stable, thanks.
^ permalink raw reply
* [PATCH net-next] bonding: fix locking in bond_loadbalance_arp_mon()
From: Ding Tianhong @ 2014-01-28 3:48 UTC (permalink / raw)
To: Jay Vosburgh, Veaceslav Falico, David S. Miller, Netdev,
Andy Gospodarek
The commit 1d3ee88ae0d605629bf369
(bonding: add netlink attributes to slave link dev)
has add rtmsg_ifinfo() in bond_set_active_slave() and
bond_set_backup_slave(), so the two function need to
called in RTNL lock, but bond_loadbalance_arp_mon()
only calling these functions in RCU, warning message
will occurs.
fix this by add a new function bond_slave_state_change(),
which will reset the slave's state after slave link check,
so remove the bond_set_xxx_slave() from the cycle and only
record the slave_state_changed, this will call the new
function to set all slaves to new state in RTNL later.
Cc: Jay Vosburgh <fubar@us.ibm.com>
Cc: Veaceslav Falico <vfalico@redhat.com>
Cc: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
drivers/net/bonding/bond_main.c | 29 +++++++++++++++++------------
drivers/net/bonding/bonding.h | 13 +++++++++++++
2 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index f9e0c8b..dd2dcc6 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2346,7 +2346,7 @@ static void bond_loadbalance_arp_mon(struct work_struct *work)
arp_work.work);
struct slave *slave, *oldcurrent;
struct list_head *iter;
- int do_failover = 0;
+ int do_failover = 0, slave_state_changed = 0;
if (!bond_has_slaves(bond))
goto re_arm;
@@ -2370,7 +2370,7 @@ static void bond_loadbalance_arp_mon(struct work_struct *work)
bond_time_in_interval(bond, slave->dev->last_rx, 1)) {
slave->link = BOND_LINK_UP;
- bond_set_active_slave(slave);
+ slave_state_changed = 1;
/* primary_slave has no meaning in round-robin
* mode. the window of a slave being up and
@@ -2399,7 +2399,7 @@ static void bond_loadbalance_arp_mon(struct work_struct *work)
!bond_time_in_interval(bond, slave->dev->last_rx, 2)) {
slave->link = BOND_LINK_DOWN;
- bond_set_backup_slave(slave);
+ slave_state_changed = 1;
if (slave->link_failure_count < UINT_MAX)
slave->link_failure_count++;
@@ -2426,19 +2426,24 @@ static void bond_loadbalance_arp_mon(struct work_struct *work)
rcu_read_unlock();
- if (do_failover) {
- /* the bond_select_active_slave must hold RTNL
- * and curr_slave_lock for write.
- */
+ if (do_failover || slave_state_changed) {
if (!rtnl_trylock())
goto re_arm;
- block_netpoll_tx();
- write_lock_bh(&bond->curr_slave_lock);
- bond_select_active_slave(bond);
+ if (slave_state_changed) {
+ bond_slave_state_change(bond);
+ } else if (do_failover) {
+ /* the bond_select_active_slave must hold RTNL
+ * and curr_slave_lock for write.
+ */
+ block_netpoll_tx();
+ write_lock_bh(&bond->curr_slave_lock);
- write_unlock_bh(&bond->curr_slave_lock);
- unblock_netpoll_tx();
+ bond_select_active_slave(bond);
+
+ write_unlock_bh(&bond->curr_slave_lock);
+ unblock_netpoll_tx();
+ }
rtnl_unlock();
}
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 1a9062f..86ccfb9 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -303,6 +303,19 @@ static inline void bond_set_backup_slave(struct slave *slave)
}
}
+static inline void bond_slave_state_change(struct bonding *bond)
+{
+ struct list_head *iter;
+ struct slave *tmp;
+
+ bond_for_each_slave(bond, tmp, iter) {
+ if (tmp->link == BOND_LINK_UP)
+ bond_set_active_slave(tmp);
+ else if (tmp->link == BOND_LINK_DOWN)
+ bond_set_backup_slave(tmp);
+ }
+}
+
static inline int bond_slave_state(struct slave *slave)
{
return slave->backup;
--
1.8.0
^ permalink raw reply related
* [PATCH v2] net: gre: use icmp_hdr() to get inner ip header
From: Duan Jiong @ 2014-01-28 3:49 UTC (permalink / raw)
To: David Miller; +Cc: Daniel Borkmann, netdev, Pravin Shelar
When dealing with icmp messages, the skb->data points the
ip header that triggered the sending of the icmp message.
In gre_cisco_err(), the parse_gre_header() is called, and the
iptunnel_pull_header() is called to pull the skb at the end of
the parse_gre_header(), so the skb->data doesn't point the
inner ip header.
Unfortunately, the ipgre_err still needs those ip addresses in
inner ip header to look up tunnel by ip_tunnel_lookup().
So just use icmp_hdr() to get inner ip header instead of skb->data.
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
v2: use icmp_hdr() instead of conditional pulling of headers
net/ipv4/ip_gre.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index e7a92fd..ec4f762 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -178,7 +178,7 @@ static int ipgre_err(struct sk_buff *skb, u32 info,
else
itn = net_generic(net, ipgre_net_id);
- iph = (const struct iphdr *)skb->data;
+ iph = (const struct iphdr *)(icmp_hdr(skb) + 1);
t = ip_tunnel_lookup(itn, skb->dev->ifindex, tpi->flags,
iph->daddr, iph->saddr, tpi->key);
--
1.8.3.1
^ permalink raw reply related
* i40e: Add missing braces to i40e_dcb_need_reconfig()
From: Dave Jones @ 2014-01-28 4:11 UTC (permalink / raw)
To: netdev; +Cc: Neerav.Parikh
Indentation mismatch spotted with Coverity.
Introduced in 4e3b35b044ea ("i40e: add DCB and DCBNL support")
Signed-off-by: Dave Jones <davej@fedoraproject.org>
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index a4b940862b83..b901371ca361 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -4440,9 +4440,10 @@ bool i40e_dcb_need_reconfig(struct i40e_pf *pf,
/* Check if APP Table has changed */
if (memcmp(&new_cfg->app,
&old_cfg->app,
- sizeof(new_cfg->app)))
+ sizeof(new_cfg->app))) {
need_reconfig = true;
dev_info(&pf->pdev->dev, "APP Table change detected.\n");
+ }
return need_reconfig;
}
^ 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