* Re: [PATCH v2 net-next 0/9] ipv6: fib6: socket dst_entry improvments and cleanups
From: David Miller @ 2014-09-26 16:46 UTC (permalink / raw)
To: hannes; +Cc: netdev, eric.dumazet, hideaki, vyasevich, nicolas.dichtel, kafai
In-Reply-To: <1411718323.1731596.171980125.03C65719@webmail.messagingengine.com>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Fri, 26 Sep 2014 09:58:43 +0200
> On Fri, Sep 26, 2014, at 06:28, David Miller wrote:
>> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
>> Date: Sun, 21 Sep 2014 16:11:44 +0200
>>
>> > Eric Dumazet noticed that rt6_nodes wich are neither RTF_NONEXTHOP nor
>> > RTF_GATEWAY but DST_HOST ones cause major routing lookup churn because
>> > their rt6_genid is never renewed, thus ip6_dst_check always considers
>> > them outdated. This is a major problem, because these kind of routes
>> > are normally used to in input handling.
>>
>> This series is a disappointment for me from the perspective of the
>> fact that we have a regression in mainline and this is too complex
>> of a set of changes for there.
>>
>> If we relookup the thing every TCP input packet, we might as well
>> not do the input route caching in the socket.
>
> I can understand.
>
> Toss this series, I'll try to do better tomorrow and send changes for
> net and submit net-next cleanups when your queue is a bit smaller.
BTW, don't get me wrong, I like the new code and for 'net-next' it's
good.
But for 'net' we have to come up with something simpler meanwhile.
^ permalink raw reply
* Regarding bug 82471
From: Laurent CARON @ 2014-09-26 16:35 UTC (permalink / raw)
To: netdev
Hi,
I've been biten by : https://bugzilla.kernel.org/show_bug.cgi?id=82471
today.
I tried various kernels from 3.2.0 to 3.16.3
The last unaffected kernel according to my tests is 3.14 (didn't yet try
3.15).
Please see logs when (on 3.16.2)
1/ using iptables
2/ having some traffic (even light) going through
http://pastebin.com/JWkFu2w2
My network config is the following:
a bond interface consisting of 2 10Gb ports (intel ixgbe / X520-SR2) on
top of which I use 2 vlans.
Thanks for your help,
Laurent
^ permalink raw reply
* Re: [PATCH][V2] Freescale Frame Manager Device Tree binding document
From: Bob Cochran @ 2014-09-26 16:37 UTC (permalink / raw)
To: Igal.Liberman, devicetree, linuxppc-dev, netdev; +Cc: scottwood, Emilian.Medve
In-Reply-To: <1410952110-32733-1-git-send-email-igal.liberman@freescale.com>
On 09/17/2014 07:08 AM, Igal.Liberman wrote:
> From: Igal Liberman <Igal.Liberman@freescale.com>
>
> The Frame Manager (FMan) combines the Ethernet network interfaces with packet
> distribution logic to provide intelligent distribution and queuing decisions
> for incoming traffic at line rate.
>
> This binding document describes Freescale's Frame Manager hardware attributes
> that are used by the Frame Manager driver for its basic initialization and
> configuration.
>
> Difference between [V1] and [V2]:
> Addressed all comments recieved from Scott in [V1]
>
> Signed-off-by: Igal Liberman <Igal.Liberman@freescale.com>
Is there a reference (FMAN) dts file I can compare this against? I was
reviewing this against my (combined) dts file for my t1040rdb built with
either FSL's SDK1.6 or Yocto Project meta-fsl-ppc master branch, and I'm
not finding a good match between the nodes / properties in my dts file
and what you have here.
For example, I don't find the required "clocks" or
"fsl,qman-channel-range" properties under my <fman0: fman@400000 ...>
node.
I'm wondering if this document is trailing or leading the source in the
latest published FSL SDK (1.6).
And a minor nit pick: twice you write "bellow" where you should have "below"
Thanks
Bob
> ---
> .../devicetree/bindings/powerpc/fsl/fman.txt | 529 ++++++++++++++++++++
> 1 file changed, 529 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/fman.txt
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> new file mode 100644
> index 0000000..da8e5f2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> @@ -0,0 +1,529 @@
> +=============================================================================
> +Freescale Frame Manager Device Bindings
> +
> +CONTENTS
> + - FMan Node
> + - FMan Port Node
> + - FMan MURAM Node
> + - FMan dTSEC/XGEC/mEMAC Node
> + - FMan IEEE 1588 Node
> + - Example
> +
> +=============================================================================
> +FMan Node
> +
> +DESCRIPTION
> +
> +Due to the fact that the FMan is an aggregation of sub-engines (ports, MACs,
> +etc.) the FMan node will have child nodes for each of them.
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: Must include "fsl,fman"
> + FMan version can be determined via FM_IP_REV_1 register in the
> + FMan block. The offset is 0xc4 from the beginning of the
> + Frame Processing Manager memory map (0xc3000 from the
> + beginning of the FMan node).
> +
> +- cell-index
> + Usage: required
> + Value type: <u32>
> + Definition: Specifies the index of the FMan unit.
> +
> + The cell-index value may be used by the SoC, to identify the
> + FMan unit in the SoC memory map. In the table bellow,
> + there's a description of the cell-index use in each SoC:
> +
> + - P1023:
> + register[bit] FMan unit cell-index
> + ============================================================
> + DEVDISR[1] 1 0
> +
> + - P2041, P3041, P4080 P5020, P5040:
> + register[bit] FMan unit cell-index
> + ============================================================
> + DCFG_DEVDISR2[6] 1 0
> + DCFG_DEVDISR2[14] 2 1
> + (Second FM available only in P4080 and P5040)
> +
> + - B4860, T1040, T2080, T4240:
> + register[bit] FMan unit cell-index
> + ============================================================
> + DCFG_CCSR_DEVDISR2[24] 1 0
> + DCFG_CCSR_DEVDISR2[25] 2 1
> + (Second FM available only in T4240)
> +
> + DEVDISR, DCFG_DEVDISR2 and DCFG_CCSR_DEVDISR2 are located in
> + the specific SoC "Device Configuration/Pin Control" Memory
> + Map.
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property. Specifies the offset of the
> + following configuration registers:
> + - BMI configuration registers.
> + - QMI configuration registers.
> + - DMA configuration registers.
> + - FPM configuration registers.
> + - FMan controller configuration registers.
> +
> +- ranges
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property.
> +
> +- clocks
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: phandle for fman clock.
> +
> +- clock-names
> + usage: optional
> + Value type: <stringlist>
> + Definition: A standard property
> +
> +- interrupts
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A pair of IRQs are specified in this property.
> + The first element is associated with the event interrupts and
> + the second element is associated with the error interrupts.
> +
> +- fsl,qman-channel-range
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Specifies the range of the available dedicated
> + channels in the FMan. The first cell specifies the beginning
> + of the range and the second cell specifies the number of
> + channels.
> + Further information available at:
> + "Work Queue (WQ) Channel Assignments in the QMan" section
> + in DPAA Reference Manual.
> +
> +=============================================================================
> +FMan MURAM Node
> +
> +DESCRIPTION
> +
> +FMan Internal memory - shared between all the FMan modules.
> +It contains data structures that are common and written to or read by
> +the modules.
> +FMan internal memory is split into the following parts:
> + Packet buffering (Tx/Rx FIFOs)
> + Frames internal context
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: Must include "fsl,fman-muram"
> +
> +- ranges
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property.
> + Specifies the multi-user memory offset and the size within
> + the FMan.
> +
> +EXAMPLE
> +
> +muram@0 {
> + compatible = "fsl,fman-muram";
> + ranges = <0 0x000000 0x28000>;
> +};
> +
> +=============================================================================
> +FMan Port Node
> +
> +DESCRIPTION
> +
> +The Frame Manager (FMan) supports several types of hardware ports:
> + Ethernet receiver (RX)
> + Ethernet transmitter (TX)
> + Offline/Host command (O/H)
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: A standard property.
> + Must include one of the following:
> + - "fsl,fman-v2-port-oh" for FManV2 OH ports
> + - "fsl,fman-v2-port-rx" for FManV2 RX ports
> + - "fsl,fman-v2-port-tx" for FManV2 TX ports
> + - "fsl,fman-v3-port-oh" for FManV3 OH ports
> + - "fsl,fman-v3-port-rx" for FManV3 RX ports
> + - "fsl,fman-v3-port-tx" for FManV3 TX ports
> +
> +- cell-index
> + Usage: required
> + Value type: <u32>
> + Definition: Specifies the hardware port id.
> + Each hardware port on the FMan has its own hardware PortID.
> + Super set of all hardware Port IDs available at FMan Reference
> + Manual under "FMan Hardware Ports in Freescale Devices" table.
> +
> + Each hardware port is assigned a 4KB, port-specific page in
> + the FMan hardware port memory region (which is part of the
> + FMan memory map). The first 4 KB in the FMan hardware ports
> + memory region is used for what are called common registers.
> + The subsequent 63 4KB pages are allocated to the hardware
> + ports.
> + The page of a specific port is determined by the cell-index.
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: There is one reg region describing the port
> + configuration registers.
> +
> +EXAMPLE
> +
> +port@a8000 {
> + cell-index = <0x28>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xa8000 0x1000>;
> +};
> +
> +port@88000 {
> + cell-index = <0x8>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x88000 0x1000>;
> +};
> +
> +port@81000 {
> + cell-index = <0x1>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x81000 0x1000>;
> +};
> +
> +=============================================================================
> +FMan dTSEC/XGEC/mEMAC Node
> +
> +DESCRIPTION
> +
> +mEMAC/dTSEC/XGEC are the Ethernet network interfaces
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: A standard property.
> + Must include one of the following:
> + - "fsl,fman-dtsec" for dTSEC MAC
> + - "fsl,fman-xgec" for XGEC MAC
> + - "fsl,fman-memac for mEMAC MAC
> +
> +- cell-index
> + Usage: required
> + Value type: <u32>
> + Definition: Specifies the MAC id.
> +
> + The cell-index value may be used by the FMan or the SoC, to
> + identify the MAC unit in the FMan (or SoC) memory map.
> + In the tables bellow there's a description of the cell-index
> + use, there are two tables, one describes the use of cell-index
> + by the FMan, the second describes the use by the SoC:
> +
> + 1. FMan Registers
> +
> + FManV2:
> + register[bit] MAC cell-index
> + ============================================================
> + FM_EPI[16] XGEC 8
> + FM_EPI[16+n] dTSECn n-1
> + FM_NPI[11+n] dTSECn n-1
> + n = 1,..,5
> +
> + FManV3:
> + register[bit] MAC cell-index
> + ============================================================
> + FM_EPI[16+n] mEMACn n-1
> + FM_EPI[25] mEMAC10 9
> +
> + FM_NPI[11+n] mEMACn n-1
> + FM_NPI[10] mEMAC10 9
> + FM_NPI[11] mEMAC9 8
> + n = 1,..8
> +
> + FM_EPI and FM_NPI are located in the FMan memory map.
> +
> + 2. SoC registers:
> +
> + - P2041, P3041, P4080 P5020, P5040:
> + register[bit] FMan MAC cell
> + Unit index
> + ============================================================
> + DCFG_DEVDISR2[7] 1 XGEC 8
> + DCFG_DEVDISR2[7+n] 1 dTSECn n-1
> + DCFG_DEVDISR2[15] 2 XGEC 8
> + DCFG_DEVDISR2[15+n] 2 dTSECn n-1
> + n = 1,..5
> +
> + - T1040, T2080, T4240, B4860:
> + register[bit] FMan MAC cell
> + Unit index
> + ============================================================
> + DCFG_CCSR_DEVDISR2[n-1] 1 mEMACn n-1
> + DCFG_CCSR_DEVDISR2[11+n] 2 mEMACn n-1
> + n = 1,..6,9,10
> +
> + EVDISR, DCFG_DEVDISR2 and DCFG_CCSR_DEVDISR2 are located in
> + the specific SoC "Device Configuration/Pin Control" Memory
> + Map.
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property.
> +
> +- fsl,fman-ports
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: An array of two phandles - the first references is
> + the FMan RX port and the second is the TX port used by this
> + MAC.
> +
> +- ptp-timer
> + Usage required
> + Value type: <phandle>
> + Definition: A phandle for 1EEE1588 timer.
> +
> +EXAMPLE
> +
> +fman1_tx28: port@a8000 {
> + cell-index = <0x28>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xa8000 0x1000>;
> +};
> +
> +fman1_rx8: port@88000 {
> + cell-index = <0x8>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x88000 0x1000>;
> +};
> +
> +ptp-timer: ptp_timer@fe000 {
> + compatible = "fsl,fman-ptp-timer";
> + reg = <0xfe000 0x1000>;
> +};
> +
> +ethernet@e0000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <0>;
> + reg = <0xe0000 0x1000>;
> + fsl,fman-ports = <&fman1_rx8 &fman1_tx28>;
> + ptp-timer = <&ptp-timer>;
> +};
> +
> +============================================================================
> +FMan IEEE 1588 Node
> +
> +DESCRIPTION
> +
> +The FMan interface to support IEEE 1588
> +
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: A standard property.
> + Must include "fsl,fman-ptp-timer".
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property.
> +
> +EXAMPLE
> +
> +ptp-timer@fe000 {
> + compatible = "fsl,fman-ptp-timer";
> + reg = <0xfe000 0x1000>;
> +};
> +
> +=============================================================================
> +Example
> +
> +fman@400000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + cell-index = <1>;
> + compatible = "fsl,fman"
> + ranges = <0 0x400000 0x100000>;
> + reg = <0x400000 0x100000>;
> + clocks = <&fman_clk>;
> + clock-names = "fmanclk";
> + interrupts = <
> + 96 2 0 0
> + 16 2 1 1>;
> + fsl,qman-channel-range = <0x40 0xc>;
> +
> + muram@0 {
> + compatible = "fsl,fman-muram";
> + reg = <0x0 0x28000>;
> + };
> +
> + port@81000 {
> + cell-index = <1>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x81000 0x1000>;
> + };
> +
> + port@82000 {
> + cell-index = <2>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x82000 0x1000>;
> + };
> +
> + port@83000 {
> + cell-index = <3>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x83000 0x1000>;
> + };
> +
> + port@84000 {
> + cell-index = <4>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x84000 0x1000>;
> + };
> +
> + port@85000 {
> + cell-index = <5>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x85000 0x1000>;
> + };
> +
> + port@86000 {
> + cell-index = <6>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x86000 0x1000>;
> + };
> +
> + fman1_rx_0x8: port@88000 {
> + cell-index = <0x8>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x88000 0x1000>;
> + };
> +
> + fman1_rx_0x9: port@89000 {
> + cell-index = <0x9>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x89000 0x1000>;
> + };
> +
> + fman1_rx_0xa: port@8a000 {
> + cell-index = <0xa>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x8a000 0x1000>;
> + };
> +
> + fman1_rx_0xb: port@8b000 {
> + cell-index = <0xb>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x8b000 0x1000>;
> + };
> +
> + fman1_rx_0xc: port@8c000 {
> + cell-index = <0xc>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x8c000 0x1000>;
> + };
> +
> + fman1_rx_0x10: port@90000 {
> + cell-index = <0x10>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x90000 0x1000>;
> + };
> +
> + fman1_tx_0x28: port@a8000 {
> + cell-index = <0x28>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xa8000 0x1000>;
> + };
> +
> + fman1_tx_0x29: port@a9000 {
> + cell-index = <0x29>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xa9000 0x1000>;
> + };
> +
> + fman1_tx_0x2a: port@aa000 {
> + cell-index = <0x2a>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xaa000 0x1000>;
> + };
> +
> + fman1_tx_0x2b: port@ab000 {
> + cell-index = <0x2b>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xab000 0x1000>;
> + };
> +
> + fman1_tx_0x2c: port@ac0000 {
> + cell-index = <0x2c>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xac000 0x1000>;
> + };
> +
> + fman1_tx_0x30: port@b0000 {
> + cell-index = <0x30>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xb0000 0x1000>;
> + };
> +
> + ethernet@e0000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <0>;
> + reg = <0xe0000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0x8 &fman1_tx_0x28>;
> + };
> +
> + ethernet@e2000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <1>;
> + reg = <0xe2000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0x9 &fman1_tx_0x29>;
> + };
> +
> + ethernet@e4000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <2>;
> + reg = <0xe4000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0xa &fman1_tx_0x2a>;
> + };
> +
> + ethernet@e6000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <3>;
> + reg = <0xe6000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0xb &fman1_tx_0x2b>;
> + };
> +
> + ethernet@e8000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <4>;
> + reg = <0xf0000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0xc &fman1_tx_0x2c>;
> +
> + ethernet@f0000 {
> + cell-index = <8>;
> + compatible = "fsl,fman-xgec";
> + reg = <0xf0000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0x10 &fman1_tx_0x30>;
> + };
> +
> + ptp-timer@fe000 {
> + compatible = "fsl,fman-ptp-timer";
> + reg = <0xfe000 0x1000>;
> + };
> +};
>
^ permalink raw reply
* [PATCH] xen/xenbus: Use 'void' instead of 'int' for the return of xenbus_switch_state()
From: Chen Gang @ 2014-09-26 16:36 UTC (permalink / raw)
To: David Vrabel, konrad.wilk, ian.campbell, wei.liu2,
boris.ostrovsky, bhelgaas, jgross, yongjun_wei, mukesh.rathor
Cc: xen-devel, netdev@vger.kernel.org, linux-pci, linux-scsi,
linux-kernel@vger.kernel.org
When xenbus_switch_state() fails, it will call xenbus_switch_fatal()
internally, so need not return any status value, then use 'void' instead
of 'int' for xenbus_switch_state() and __xenbus_switch_state().
Also need be sure that all callers which check the return value must let
'err' be 0.
And also need change the related comments for xenbus_switch_state().
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
drivers/block/xen-blkback/xenbus.c | 9 ++-------
drivers/net/xen-netback/xenbus.c | 5 +----
drivers/pci/xen-pcifront.c | 15 ++++++---------
drivers/xen/xen-pciback/xenbus.c | 21 ++++-----------------
drivers/xen/xen-scsiback.c | 5 +----
drivers/xen/xenbus/xenbus_client.c | 16 ++++++++--------
include/xen/xenbus.h | 3 ++-
7 files changed, 24 insertions(+), 50 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 3a8b810..fdcc584 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -587,9 +587,7 @@ static int xen_blkbk_probe(struct xenbus_device *dev,
if (err)
goto fail;
- err = xenbus_switch_state(dev, XenbusStateInitWait);
- if (err)
- goto fail;
+ xenbus_switch_state(dev, XenbusStateInitWait);
return 0;
@@ -837,10 +835,7 @@ again:
if (err)
xenbus_dev_fatal(dev, err, "ending transaction");
- err = xenbus_switch_state(dev, XenbusStateConnected);
- if (err)
- xenbus_dev_fatal(dev, err, "%s: switching to Connected state",
- dev->nodename);
+ xenbus_switch_state(dev, XenbusStateConnected);
return;
abort:
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 9c47b89..b5c3d47 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -337,10 +337,7 @@ static int netback_probe(struct xenbus_device *dev,
if (err)
pr_debug("Error writing multi-queue-max-queues\n");
- err = xenbus_switch_state(dev, XenbusStateInitWait);
- if (err)
- goto fail;
-
+ xenbus_switch_state(dev, XenbusStateInitWait);
be->state = XenbusStateInitWait;
/* This kicks hotplug scripts, so do it immediately. */
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 53df39a..c1d73b7 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -901,18 +901,16 @@ static int pcifront_try_connect(struct pcifront_device *pdev)
}
}
- err = xenbus_switch_state(pdev->xdev, XenbusStateConnected);
-
+ xenbus_switch_state(pdev->xdev, XenbusStateConnected);
+ return 0;
out:
return err;
}
static int pcifront_try_disconnect(struct pcifront_device *pdev)
{
- int err = 0;
enum xenbus_state prev_state;
-
prev_state = xenbus_read_driver_state(pdev->xdev->nodename);
if (prev_state >= XenbusStateClosing)
@@ -923,11 +921,10 @@ static int pcifront_try_disconnect(struct pcifront_device *pdev)
pcifront_disconnect(pdev);
}
- err = xenbus_switch_state(pdev->xdev, XenbusStateClosed);
+ xenbus_switch_state(pdev->xdev, XenbusStateClosed);
out:
-
- return err;
+ return 0;
}
static int pcifront_attach_devices(struct pcifront_device *pdev)
@@ -1060,8 +1057,8 @@ static int pcifront_detach_devices(struct pcifront_device *pdev)
domain, bus, slot, func);
}
- err = xenbus_switch_state(pdev->xdev, XenbusStateReconfiguring);
-
+ xenbus_switch_state(pdev->xdev, XenbusStateReconfiguring);
+ return 0;
out:
return err;
}
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index c214daa..630a215 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -184,10 +184,7 @@ static int xen_pcibk_attach(struct xen_pcibk_device *pdev)
dev_dbg(&pdev->xdev->dev, "Connecting...\n");
- err = xenbus_switch_state(pdev->xdev, XenbusStateConnected);
- if (err)
- xenbus_dev_fatal(pdev->xdev, err,
- "Error switching to connected state!");
+ xenbus_switch_state(pdev->xdev, XenbusStateConnected);
dev_dbg(&pdev->xdev->dev, "Connected? %d\n", err);
out:
@@ -500,12 +497,7 @@ static int xen_pcibk_reconfigure(struct xen_pcibk_device *pdev)
}
}
- err = xenbus_switch_state(pdev->xdev, XenbusStateReconfigured);
- if (err) {
- xenbus_dev_fatal(pdev->xdev, err,
- "Error switching to reconfigured state!");
- goto out;
- }
+ xenbus_switch_state(pdev->xdev, XenbusStateReconfigured);
out:
mutex_unlock(&pdev->dev_lock);
@@ -640,10 +632,7 @@ static int xen_pcibk_setup_backend(struct xen_pcibk_device *pdev)
goto out;
}
- err = xenbus_switch_state(pdev->xdev, XenbusStateInitialised);
- if (err)
- xenbus_dev_fatal(pdev->xdev, err,
- "Error switching to initialised state!");
+ xenbus_switch_state(pdev->xdev, XenbusStateInitialised);
out:
mutex_unlock(&pdev->dev_lock);
@@ -683,9 +672,7 @@ static int xen_pcibk_xenbus_probe(struct xenbus_device *dev,
}
/* wait for xend to configure us */
- err = xenbus_switch_state(dev, XenbusStateInitWait);
- if (err)
- goto out;
+ xenbus_switch_state(dev, XenbusStateInitWait);
/* watch the backend node for backend configuration information */
err = xenbus_watch_path(dev, dev->nodename, &pdev->be_watch,
diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index ad11258..847bc9c 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -1225,10 +1225,7 @@ static int scsiback_probe(struct xenbus_device *dev,
if (err)
xenbus_dev_error(dev, err, "writing feature-sg-grant");
- err = xenbus_switch_state(dev, XenbusStateInitWait);
- if (err)
- goto fail;
-
+ xenbus_switch_state(dev, XenbusStateInitWait);
return 0;
fail:
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index ca74410..e2bcd1d 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -166,7 +166,7 @@ EXPORT_SYMBOL_GPL(xenbus_watch_pathfmt);
static void xenbus_switch_fatal(struct xenbus_device *, int, int,
const char *, ...);
-static int
+static void
__xenbus_switch_state(struct xenbus_device *dev,
enum xenbus_state state, int depth)
{
@@ -188,7 +188,7 @@ __xenbus_switch_state(struct xenbus_device *dev,
int err, abort;
if (state == dev->state)
- return 0;
+ return;
again:
abort = 1;
@@ -196,7 +196,7 @@ again:
err = xenbus_transaction_start(&xbt);
if (err) {
xenbus_switch_fatal(dev, depth, err, "starting transaction");
- return 0;
+ return;
}
err = xenbus_scanf(xbt, dev->nodename, "state", "%d", ¤t_state);
@@ -219,7 +219,7 @@ abort:
} else
dev->state = state;
- return 0;
+ return;
}
/**
@@ -228,12 +228,12 @@ abort:
* @state: new state
*
* Advertise in the store a change of the given driver to the given new_state.
- * Return 0 on success, or -errno on error. On error, the device will switch
- * to XenbusStateClosing, and the error will be saved in the store.
+ * When failure occurs, it will call xenbus_switch_fatal() internally, so need
+ * not return value to notify upper caller.
*/
-int xenbus_switch_state(struct xenbus_device *dev, enum xenbus_state state)
+void xenbus_switch_state(struct xenbus_device *dev, enum xenbus_state state)
{
- return __xenbus_switch_state(dev, state, 0);
+ __xenbus_switch_state(dev, state, 0);
}
EXPORT_SYMBOL_GPL(xenbus_switch_state);
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index 0324c6d..587c53d 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -195,7 +195,8 @@ int xenbus_watch_pathfmt(struct xenbus_device *dev, struct xenbus_watch *watch,
const char **, unsigned int),
const char *pathfmt, ...);
-int xenbus_switch_state(struct xenbus_device *dev, enum xenbus_state new_state);
+void xenbus_switch_state(struct xenbus_device *dev,
+ enum xenbus_state new_state);
int xenbus_grant_ring(struct xenbus_device *dev, unsigned long ring_mfn);
int xenbus_map_ring_valloc(struct xenbus_device *dev,
int gnt_ref, void **vaddr);
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 5/5] vxlan: Set inner protocol before transmit
From: Tom Herbert @ 2014-09-26 16:22 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1411748554-7346-1-git-send-email-therbert@google.com>
Call skb_set_inner_protocol to set inner Ethernet protocol to
ETH_P_TEB before transmit. This is needed for GSO with UDP tunnels.
Signed-off-by: Tom Herbert <therbert@google.com>
---
drivers/net/vxlan.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 34e102e..2af795d 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1610,6 +1610,8 @@ static int vxlan6_xmit_skb(struct vxlan_sock *vs,
vxh->vx_flags = htonl(VXLAN_FLAGS);
vxh->vx_vni = vni;
+ skb_set_inner_protocol(skb, htons(ETH_P_TEB));
+
udp_tunnel6_xmit_skb(vs->sock, dst, skb, dev, saddr, daddr, prio,
ttl, src_port, dst_port);
return 0;
@@ -1652,6 +1654,8 @@ int vxlan_xmit_skb(struct vxlan_sock *vs,
vxh->vx_flags = htonl(VXLAN_FLAGS);
vxh->vx_vni = vni;
+ skb_set_inner_protocol(skb, htons(ETH_P_TEB));
+
return udp_tunnel_xmit_skb(vs->sock, rt, skb, src, dst, tos,
ttl, df, src_port, dst_port, xnet);
}
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 4/5] gre: Set inner protocol in v4 and v6 GRE transmit
From: Tom Herbert @ 2014-09-26 16:22 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1411748554-7346-1-git-send-email-therbert@google.com>
Call skb_set_inner_protocol to set inner Ethernet protocol to
protocol being encapsulation by GRE before tunnel_xmit. This is
needed for GSO if UDP encapsulation (fou) is being done.
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv4/ip_gre.c | 2 ++
net/ipv6/ip6_gre.c | 8 ++++++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 829aff8b..0485ef1 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -241,6 +241,8 @@ static void __gre_xmit(struct sk_buff *skb, struct net_device *dev,
/* Push GRE header. */
gre_build_header(skb, &tpi, tunnel->tun_hlen);
+ skb_set_inner_protocol(skb, tpi.proto);
+
ip_tunnel_xmit(skb, dev, tnl_params, tnl_params->protocol);
}
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 5f19dfb..9a0a1aa 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -616,6 +616,7 @@ static netdev_tx_t ip6gre_xmit2(struct sk_buff *skb,
int err = -1;
u8 proto;
struct sk_buff *new_skb;
+ __be16 protocol;
if (dev->type == ARPHRD_ETHER)
IPCB(skb)->flags = 0;
@@ -732,8 +733,9 @@ static netdev_tx_t ip6gre_xmit2(struct sk_buff *skb,
ipv6h->daddr = fl6->daddr;
((__be16 *)(ipv6h + 1))[0] = tunnel->parms.o_flags;
- ((__be16 *)(ipv6h + 1))[1] = (dev->type == ARPHRD_ETHER) ?
- htons(ETH_P_TEB) : skb->protocol;
+ protocol = (dev->type == ARPHRD_ETHER) ?
+ htons(ETH_P_TEB) : skb->protocol;
+ ((__be16 *)(ipv6h + 1))[1] = protocol;
if (tunnel->parms.o_flags&(GRE_KEY|GRE_CSUM|GRE_SEQ)) {
__be32 *ptr = (__be32 *)(((u8 *)ipv6h) + tunnel->hlen - 4);
@@ -754,6 +756,8 @@ static netdev_tx_t ip6gre_xmit2(struct sk_buff *skb,
}
}
+ skb_set_inner_protocol(skb, protocol);
+
ip6tunnel_xmit(skb, dev);
if (ndst)
ip6_tnl_dst_store(tunnel, ndst);
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 3/5] ipip: Set inner IP protocol in ipip
From: Tom Herbert @ 2014-09-26 16:22 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1411748554-7346-1-git-send-email-therbert@google.com>
Call skb_set_inner_ipproto to set inner IP protocol to IPPROTO_IPV4
before tunnel_xmit. This is needed if UDP encapsulation (fou) is
being done.
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv4/ipip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index bfec31d..ea88ab3 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -224,6 +224,8 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
if (IS_ERR(skb))
goto out;
+ skb_set_inner_ipproto(skb, IPPROTO_IPIP);
+
ip_tunnel_xmit(skb, dev, tiph, tiph->protocol);
return NETDEV_TX_OK;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 2/5] sit: Set inner IP protocol in sit
From: Tom Herbert @ 2014-09-26 16:22 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1411748554-7346-1-git-send-email-therbert@google.com>
Call skb_set_inner_ipproto to set inner IP protocol to IPPROTO_IPV6
before tunnel_xmit. This is needed if UDP encapsulation (fou) is
being done.
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv6/sit.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index db75809..0d4e274 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -982,6 +982,8 @@ static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb,
goto tx_error;
}
+ skb_set_inner_ipproto(skb, IPPROTO_IPV6);
+
err = iptunnel_xmit(skb->sk, rt, skb, fl4.saddr, fl4.daddr,
protocol, tos, ttl, df,
!net_eq(tunnel->net, dev_net(dev)));
@@ -1006,6 +1008,8 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
if (IS_ERR(skb))
goto out;
+ skb_set_inner_ipproto(skb, IPPROTO_IPIP);
+
ip_tunnel_xmit(skb, dev, tiph, IPPROTO_IPIP);
return NETDEV_TX_OK;
out:
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 1/5] udp: Generalize skb_udp_segment
From: Tom Herbert @ 2014-09-26 16:22 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1411748554-7346-1-git-send-email-therbert@google.com>
skb_udp_segment is the function called from udp4_ufo_fragment to
segment a UDP tunnel packet. This function currently assumes
segmentation is transparent Ethernet bridging (i.e. VXLAN
encapsulation). This patch generalizes the function to
operate on either Ethertype or IP protocol.
The inner_protocol field must be set to the protocol of the inner
header. This can now be either an Ethertype or an IP protocol
(in a union). A new flag in the skbuff indicates which type is
effective. skb_set_inner_protocol and skb_set_inner_ipproto
helper functions were added to set the inner_protocol. These
functions are called from the point where the tunnel encapsulation
is occuring.
When skb_udp_tunnel_segment is called, the function to segment the
inner packet is selected based on the inner IP or Ethertype. In the
case of an IP protocol encapsulation, the function is derived from
inet[6]_offloads. In the case of Ethertype, skb->protocol is
set to the inner_protocol and skb_mac_gso_segment is called. (GRE
currently does this, but it might be possible to lookup the protocol
in offload_base and call the appropriate segmenation function
directly).
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/skbuff.h | 26 +++++++++++++++++++++++--
include/net/udp.h | 3 ++-
net/core/skbuff.c | 1 +
net/ipv4/udp_offload.c | 51 +++++++++++++++++++++++++++++++++++++++++++++-----
net/ipv6/udp_offload.c | 2 +-
5 files changed, 74 insertions(+), 9 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index f1bfa37..7973fcb 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -628,10 +628,15 @@ struct sk_buff {
kmemcheck_bitfield_begin(flags3);
__u8 csum_level:2;
__u8 csum_bad:1;
- /* 13 bit hole */
+ __u8 inner_protocol_type:1;
+ /* 12 bit hole */
kmemcheck_bitfield_end(flags3);
- __be16 inner_protocol;
+ union {
+ __be16 inner_protocol;
+ __u8 inner_ipproto;
+ };
+
__u16 inner_transport_header;
__u16 inner_network_header;
__u16 inner_mac_header;
@@ -1716,6 +1721,23 @@ static inline void skb_reserve(struct sk_buff *skb, int len)
skb->tail += len;
}
+#define ENCAP_TYPE_ETHER 0
+#define ENCAP_TYPE_IPPROTO 1
+
+static inline void skb_set_inner_protocol(struct sk_buff *skb,
+ __be16 protocol)
+{
+ skb->inner_protocol = protocol;
+ skb->inner_protocol_type = ENCAP_TYPE_ETHER;
+}
+
+static inline void skb_set_inner_ipproto(struct sk_buff *skb,
+ __u8 ipproto)
+{
+ skb->inner_ipproto = ipproto;
+ skb->inner_protocol_type = ENCAP_TYPE_IPPROTO;
+}
+
static inline void skb_reset_inner_headers(struct sk_buff *skb)
{
skb->inner_mac_header = skb->mac_header;
diff --git a/include/net/udp.h b/include/net/udp.h
index 16f4e80..07f9b70 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -239,7 +239,8 @@ int udp_ioctl(struct sock *sk, int cmd, unsigned long arg);
int udp_disconnect(struct sock *sk, int flags);
unsigned int udp_poll(struct file *file, struct socket *sock, poll_table *wait);
struct sk_buff *skb_udp_tunnel_segment(struct sk_buff *skb,
- netdev_features_t features);
+ netdev_features_t features,
+ bool is_ipv6);
int udp_lib_getsockopt(struct sock *sk, int level, int optname,
char __user *optval, int __user *optlen);
int udp_lib_setsockopt(struct sock *sk, int level, int optname,
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 06a8feb..f26e63b 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -682,6 +682,7 @@ static void __copy_skb_header(struct sk_buff *new, const struct sk_buff *old)
new->network_header = old->network_header;
new->mac_header = old->mac_header;
new->inner_protocol = old->inner_protocol;
+ new->inner_protocol_type = old->inner_protocol_type;
new->inner_transport_header = old->inner_transport_header;
new->inner_network_header = old->inner_network_header;
new->inner_mac_header = old->inner_mac_header;
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 19ebe6a..8c35f2c 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -25,8 +25,11 @@ struct udp_offload_priv {
struct udp_offload_priv __rcu *next;
};
-struct sk_buff *skb_udp_tunnel_segment(struct sk_buff *skb,
- netdev_features_t features)
+static struct sk_buff *__skb_udp_tunnel_segment(struct sk_buff *skb,
+ netdev_features_t features,
+ struct sk_buff *(*gso_inner_segment)(struct sk_buff *skb,
+ netdev_features_t features),
+ __be16 new_protocol)
{
struct sk_buff *segs = ERR_PTR(-EINVAL);
u16 mac_offset = skb->mac_header;
@@ -48,7 +51,7 @@ struct sk_buff *skb_udp_tunnel_segment(struct sk_buff *skb,
skb_reset_mac_header(skb);
skb_set_network_header(skb, skb_inner_network_offset(skb));
skb->mac_len = skb_inner_network_offset(skb);
- skb->protocol = htons(ETH_P_TEB);
+ skb->protocol = new_protocol;
need_csum = !!(skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM);
if (need_csum)
@@ -56,7 +59,7 @@ struct sk_buff *skb_udp_tunnel_segment(struct sk_buff *skb,
/* segment inner packet. */
enc_features = skb->dev->hw_enc_features & netif_skb_features(skb);
- segs = skb_mac_gso_segment(skb, enc_features);
+ segs = gso_inner_segment(skb, enc_features);
if (IS_ERR_OR_NULL(segs)) {
skb_gso_error_unwind(skb, protocol, tnl_hlen, mac_offset,
mac_len);
@@ -101,6 +104,44 @@ out:
return segs;
}
+struct sk_buff *skb_udp_tunnel_segment(struct sk_buff *skb,
+ netdev_features_t features,
+ bool is_ipv6)
+{
+ __be16 protocol = skb->protocol;
+ const struct net_offload **offloads;
+ const struct net_offload *ops;
+ struct sk_buff *segs = ERR_PTR(-EINVAL);
+ struct sk_buff *(*gso_inner_segment)(struct sk_buff *skb,
+ netdev_features_t features);
+
+ rcu_read_lock();
+
+ switch (skb->inner_protocol_type) {
+ case ENCAP_TYPE_ETHER:
+ protocol = skb->inner_protocol;
+ gso_inner_segment = skb_mac_gso_segment;
+ break;
+ case ENCAP_TYPE_IPPROTO:
+ offloads = is_ipv6 ? inet6_offloads : inet_offloads;
+ ops = rcu_dereference(offloads[skb->inner_ipproto]);
+ if (!ops || !ops->callbacks.gso_segment)
+ goto out_unlock;
+ gso_inner_segment = ops->callbacks.gso_segment;
+ break;
+ default:
+ goto out_unlock;
+ }
+
+ segs = __skb_udp_tunnel_segment(skb, features, gso_inner_segment,
+ protocol);
+
+out_unlock:
+ rcu_read_unlock();
+
+ return segs;
+}
+
static struct sk_buff *udp4_ufo_fragment(struct sk_buff *skb,
netdev_features_t features)
{
@@ -113,7 +154,7 @@ static struct sk_buff *udp4_ufo_fragment(struct sk_buff *skb,
if (skb->encapsulation &&
(skb_shinfo(skb)->gso_type &
(SKB_GSO_UDP_TUNNEL|SKB_GSO_UDP_TUNNEL_CSUM))) {
- segs = skb_udp_tunnel_segment(skb, features);
+ segs = skb_udp_tunnel_segment(skb, features, false);
goto out;
}
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index 212ebfc..8f96988 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -58,7 +58,7 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
if (skb->encapsulation && skb_shinfo(skb)->gso_type &
(SKB_GSO_UDP_TUNNEL|SKB_GSO_UDP_TUNNEL_CSUM))
- segs = skb_udp_tunnel_segment(skb, features);
+ segs = skb_udp_tunnel_segment(skb, features, true);
else {
const struct ipv6hdr *ipv6h;
struct udphdr *uh;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 0/5] udp: Generalize GSO for UDP tunnels
From: Tom Herbert @ 2014-09-26 16:22 UTC (permalink / raw)
To: davem, netdev
This patch set generalizes the UDP tunnel segmentation functions so
that they can work with various protocol encapsulations. The primary
change is to set the inner_protocol field in the skbuff when creating
the encapsulated packet, and then in skb_udp_tunnel_segment this data
is used to determine the function for segmenting the encapsulated
packet. The inner_protocol field is overloaded to take either an
Ethertype or IP protocol.
The inner_protocol is set on transmit using skb_set_inner_ipproto or
skb_set_inner_protocol functions. VXLAN and IP tunnels (for fou GSO)
were modified to call these.
Notes:
- GSO for GRE/UDP where GRE checksum is enabled does not work.
Handling this will require some special case code.
- Software GSO now supports many varieties of encapsulation with
SKB_GSO_UDP_TUNNEL{_CSUM}. We still need a mechanism to query
for device support of particular combinations (I intend to
add ndo_gso_check for that).
- MPLS seems to be the only previous user of inner_protocol. I don't
believe these patches can affect that. For supporting GSO with
MPLS over UDP, the inner_protocol should be set using the
helper functions in this patch.
- GSO for L2TP/UDP should also be straightforward now.
Tested GRE, IPIP, and SIT over fou as well as VLXAN. This was
done using 200 TCP_STREAMs in netperf.
GRE
IPv4, FOU, UDP checksum enabled
TCP_STREAM TSO enabled on tun interface
14.04% TX CPU utilization
13.17% RX CPU utilization
9211 Mbps
TCP_STREAM TSO disabled on tun interface
27.82% TX CPU utilization
25.41% RX CPU utilization
9336 Mbps
IPv4, FOU, UDP checksum disabled
TCP_STREAM TSO enabled on tun interface
13.14% TX CPU utilization
23.18% RX CPU utilization
9277 Mbps
TCP_STREAM TSO disabled on tun interface
30.00% TX CPU utilization
31.28% RX CPU utilization
9327 Mbps
IPIP
FOU, UDP checksum enabled
TCP_STREAM TSO enabled on tun interface
15.28% TX CPU utilization
13.92% RX CPU utilization
9342 Mbps
TCP_STREAM TSO disabled on tun interface
27.82% TX CPU utilization
25.41% RX CPU utilization
9336 Mbps
FOU, UDP checksum disabled
TCP_STREAM TSO enabled on tun interface
15.08% TX CPU utilization
24.64% RX CPU utilization
9226 Mbps
TCP_STREAM TSO disabled on tun interface
30.00% TX CPU utilization
31.28% RX CPU utilization
9327 Mbps
SIT
FOU, UDP checksum enabled
TCP_STREAM TSO enabled on tun interface
14.47% TX CPU utilization
14.58% RX CPU utilization
9106 Mbps
TCP_STREAM TSO disabled on tun interface
31.82% TX CPU utilization
30.82% RX CPU utilization
9204 Mbps
FOU, UDP checksum disabled
TCP_STREAM TSO enabled on tun interface
15.70% TX CPU utilization
27.93% RX CPU utilization
9097 Mbps
TCP_STREAM TSO disabled on tun interface
33.48% TX CPU utilization
37.36% RX CPU utilization
9197 Mbps
VXLAN
TCP_STREAM TSO enabled on tun interface
16.42% TX CPU utilization
23.66% RX CPU utilization
9081 Mbps
TCP_STREAM TSO disabled on tun interface
30.32% TX CPU utilization
30.55% RX CPU utilization
9185 Mbps
Baseline (no encp, TSO and LRO enabled)
TCP_STREAM
11.85% TX CPU utilization
15.13% RX CPU utilization
9452 Mbps
Tom Herbert (5):
udp: Generalize skb_udp_segment
sit: Set inner IP protocol in sit
ipip: Set inner IP protocol in ipip
gre: Set inner protocol in v4 and v6 GRE transmit
vxlan: Set inner protocol before transmit
drivers/net/vxlan.c | 4 ++++
include/linux/skbuff.h | 26 +++++++++++++++++++++++--
include/net/udp.h | 3 ++-
net/core/skbuff.c | 1 +
net/ipv4/ip_gre.c | 2 ++
net/ipv4/ipip.c | 2 ++
net/ipv4/udp_offload.c | 51 +++++++++++++++++++++++++++++++++++++++++++++-----
net/ipv6/ip6_gre.c | 8 ++++++--
net/ipv6/sit.c | 4 ++++
net/ipv6/udp_offload.c | 2 +-
10 files changed, 92 insertions(+), 11 deletions(-)
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply
* Re: [RFC PATCH net-next] net: pktgen: packet bursting via skb->xmit_more
From: Eric Dumazet @ 2014-09-26 16:06 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Jesper Dangaard Brouer, Eric Dumazet,
John Fastabend, Network Development
In-Reply-To: <CAMEtUuxduBWxRggN8b9yxQPb-0zVkpM5HhRYGh1Bdp6nm7c2eQ@mail.gmail.com>
On Fri, 2014-09-26 at 08:59 -0700, Alexei Starovoitov wrote:
>
> oh. thanks for testing! That makes sense.
> I don't think I can find bnx2x around to double check this.
> Do you mind applying this fix and resubmitting with two sob?
> This one was rfc anyway :)
Yes, I'll also provide the bnx2x patch to support skb->xmit_more.
Thanks
^ permalink raw reply
* Re: [RFC PATCH net-next] net: pktgen: packet bursting via skb->xmit_more
From: Alexei Starovoitov @ 2014-09-26 15:59 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Jesper Dangaard Brouer, Eric Dumazet,
John Fastabend, Network Development
In-Reply-To: <1411746270.16953.130.camel@edumazet-glaptop2.roam.corp.google.com>
On Fri, Sep 26, 2014 at 8:44 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2014-09-26 at 00:42 -0700, Eric Dumazet wrote:
>> On Thu, 2014-09-25 at 18:20 -0700, Eric Dumazet wrote:
>> > On Thu, 2014-09-25 at 17:46 -0700, Alexei Starovoitov wrote:
>> > > This patch demonstrates the effect of delaying update of HW tailptr.
>> > > (based on earlier patch by Jesper)
>> > >
>> > > burst=1 is a default. It sends one packet with xmit_more=false
>> > > burst=2 sends one packet with xmit_more=true and
>> > > 2nd copy of the same packet with xmit_more=false
>> > > burst=3 sends two copies of the same packet with xmit_more=true and
>> > > 3rd copy with xmit_more=false
>> >
>> > >
>> > > Cc: Jesper Dangaard Brouer <brouer@redhat.com>
>> > > Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
>> > > ---
>> >
>> > Perfect, this is what I had in mind, thanks !
>> >
>> > Acked-by: Eric Dumazet <edumazet@google.com>
>> >
>>
>> By the way with this patch, I now reach 10 Mpps on mlx4
>
> On the other hand, bnx2x is not that happy
>
> [ 381.424736] bnx2x: [bnx2x_start_xmit:3772(eth0)]BUG! Tx ring full
> when queue awake!
> [ 381.432660] bnx2x: [bnx2x_start_xmit:3772(eth0)]BUG! Tx ring full
> when queue awake!
> [ 381.440337] bnx2x: [bnx2x_start_xmit:3772(eth0)]BUG! Tx ring full
> when queue awake!
> [ 381.448255] bnx2x: [bnx2x_start_xmit:3772(eth0)]BUG! Tx ring full
> when queue awake!
>
> When TX_BUSY is replied, and/or netif_tx_stop_queue(txq) was done by
> the driver, the 'burst' loop should stop
>
> So your :
>
> if (more)
> goto xmit_more;
>
> Should instead be :
>
> if (more && !netif_xmit_frozen_or_drv_stopped(txq))
> goto xmit_more;
>
oh. thanks for testing! That makes sense.
I don't think I can find bnx2x around to double check this.
Do you mind applying this fix and resubmitting with two sob?
This one was rfc anyway :)
^ permalink raw reply
* Re: [RFC PATCH net-next] net: pktgen: packet bursting via skb->xmit_more
From: Eric Dumazet @ 2014-09-26 15:44 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Jesper Dangaard Brouer, Eric Dumazet,
John Fastabend, netdev
In-Reply-To: <1411717322.16953.99.camel@edumazet-glaptop2.roam.corp.google.com>
On Fri, 2014-09-26 at 00:42 -0700, Eric Dumazet wrote:
> On Thu, 2014-09-25 at 18:20 -0700, Eric Dumazet wrote:
> > On Thu, 2014-09-25 at 17:46 -0700, Alexei Starovoitov wrote:
> > > This patch demonstrates the effect of delaying update of HW tailptr.
> > > (based on earlier patch by Jesper)
> > >
> > > burst=1 is a default. It sends one packet with xmit_more=false
> > > burst=2 sends one packet with xmit_more=true and
> > > 2nd copy of the same packet with xmit_more=false
> > > burst=3 sends two copies of the same packet with xmit_more=true and
> > > 3rd copy with xmit_more=false
> >
> > >
> > > Cc: Jesper Dangaard Brouer <brouer@redhat.com>
> > > Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
> > > ---
> >
> > Perfect, this is what I had in mind, thanks !
> >
> > Acked-by: Eric Dumazet <edumazet@google.com>
> >
>
> By the way with this patch, I now reach 10 Mpps on mlx4
On the other hand, bnx2x is not that happy
[ 381.424736] bnx2x: [bnx2x_start_xmit:3772(eth0)]BUG! Tx ring full
when queue awake!
[ 381.432660] bnx2x: [bnx2x_start_xmit:3772(eth0)]BUG! Tx ring full
when queue awake!
[ 381.440337] bnx2x: [bnx2x_start_xmit:3772(eth0)]BUG! Tx ring full
when queue awake!
[ 381.448255] bnx2x: [bnx2x_start_xmit:3772(eth0)]BUG! Tx ring full
when queue awake!
When TX_BUSY is replied, and/or netif_tx_stop_queue(txq) was done by
the driver, the 'burst' loop should stop
So your :
if (more)
goto xmit_more;
Should instead be :
if (more && !netif_xmit_frozen_or_drv_stopped(txq))
goto xmit_more;
^ permalink raw reply
* Re: [PATCH net-next v2] bonding: make global bonding stats more reliable
From: Andy Gospodarek @ 2014-09-26 15:35 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, j.vosburgh, vfalico
In-Reply-To: <54257B50.20709@redhat.com>
On Fri, Sep 26, 2014 at 04:42:24PM +0200, Nikolay Aleksandrov wrote:
> On 26/09/14 00:37, Andy Gospodarek wrote:
> >As the code stands today, bonding stats are based simply on the stats
> >from the member interfaces. If a member was to be removed from a bond,
> >the stats would instantly drop. This would be confusing to an admin
> >would would suddonly see interface stats drop while traffic is still
> >flowing.
> >
> >In addition to preventing the stats drops mentioned above, new members
> >will now be added to the bond and only traffic received after the member
> >was added to the bond will be counted as part of bonding stats.
> >
> >v2: Changes suggested by Nik to properly allocate/free stats memory.
> >
> >Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com>
> >---
> > drivers/net/bonding/bond_main.c | 85 +++++++++++++++++++++++++++--------------
> > drivers/net/bonding/bonding.h | 3 ++
> > 2 files changed, 60 insertions(+), 28 deletions(-)
> >
> <<<<snip>>>>
> >@@ -3857,6 +3874,8 @@ static void bond_uninit(struct net_device *bond_dev)
> > __bond_release_one(bond_dev, slave->dev, true);
> > netdev_info(bond_dev, "Released all slaves\n");
> >
> >+ kfree(bond->bond_stats);
> >+
> > list_del(&bond->bond_list);
> >
> > bond_debug_unregister(bond);
> >@@ -4243,7 +4262,13 @@ static int bond_init(struct net_device *bond_dev)
> >
> > bond->wq = create_singlethread_workqueue(bond_dev->name);
> > if (!bond->wq)
> >- return -ENOMEM;
> >+ goto bond_wq_fail;
> >+
> >+ /* initialize persistent stats for the bond */
> >+ bond->bond_stats = kzalloc(sizeof(struct rtnl_link_stats64),
> >+ GFP_KERNEL);
> >+ if (!bond->bond_stats)
> >+ goto bond_stats_fail;
> >
> > bond_set_lockdep_class(bond_dev);
> >
> >@@ -4259,6 +4284,10 @@ static int bond_init(struct net_device *bond_dev)
> > eth_hw_addr_random(bond_dev);
> >
> > return 0;
> >+bond_stats_fail:
> >+ kfree(bond->wq);
> ^^^^^^^^^^
> I think you should use destroy_workqueue() to properly get rid of the wq.
I'm beginning to think I should have gone with my first approach and
placed the rtnl_link_stats64 structs inside struct slave and struct
bonding rather than creating pointers....
>
>
> >+bond_wq_fail:
> >+ return -ENOMEM;
> > }
> >
> > unsigned int bond_get_num_tx_queues(void)
> >diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
> >index 6140bf0..fe25265 100644
> >--- a/drivers/net/bonding/bonding.h
> >+++ b/drivers/net/bonding/bonding.h
> >@@ -24,6 +24,7 @@
> > #include <linux/inetdevice.h>
> > #include <linux/etherdevice.h>
> > #include <linux/reciprocal_div.h>
> >+#include <linux/if_link.h>
> >
> > #include "bond_3ad.h"
> > #include "bond_alb.h"
> >@@ -175,6 +176,7 @@ struct slave {
> > struct netpoll *np;
> > #endif
> > struct kobject kobj;
> >+ struct rtnl_link_stats64 *slave_stats;
> > };
> >
> > /*
> >@@ -224,6 +226,7 @@ struct bonding {
> > /* debugging support via debugfs */
> > struct dentry *debug_dir;
> > #endif /* CONFIG_DEBUG_FS */
> >+ struct rtnl_link_stats64 *bond_stats;
> > };
> >
> > #define bond_slave_get_rcu(dev) \
> >
>
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Michael Tokarev @ 2014-09-26 15:20 UTC (permalink / raw)
To: Arend van Spriel
Cc: Seth Forshee, brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <54257B69.3070607-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
26.09.2014 18:42, Arend van Spriel wrote:
> Being bold here, but would you be willing to send that non-working part of hardware to me. I seem to have 4313 cards over here that just work and it would help greatly investigating the issue. I guess you do not care that much anymore, but might be others do (myself included).
Please note that this is 2nd card of the same model which I
come across in different laptops (one lenovo which I bought
last December, and later in a HP Envy which I borrowed from
my friend because my lenovo didn't work anymore). Both shows
exactly the same sympthoms, on several different WiFi networks.
The sympthoms are rehashed here several times -- sporaric stalls
of different frequence of occurences, which can be cured by
re-loading the driver.
I can send it your way, -- guess it will be quite a bit costly,
but I don't have any use for it anyway (short of throwing it
away), and since I already spent significantly more money due
to all this (whole thinkpad plus ssds and several wifi adaptors),
this additional cost is just a small noize. But since that's
2nd card in a row, maybe there's something else in there, the
prob is not in the card?
I mentioned several times that here, both of these cards worked
for long periods of time and for many gigabytes transfers (I
used wget in a loop overnight), -- and worked very well. Just
that these "working periods" changes into "non-working periods"
without any clear cause, sporadically. And these working
periods can be rather long, too.
Maybe this is some uninitialized field somewhere, I dunno -
at least that'd explain the "mystery" and inability to reproduce
any of the two kinds of "periods". Ofcourse it's rather difficult
to debug, but it might not be card-specific.
I also noticed that quite often it does not work after rebooing
the laptop from windows. But not always. I thought maybe win
switches it into some mode which linux driver fails to notice,
but no, the fact that it sometimes works after windows tells
me that I'm not right.
And note please that the closed-source wl driver always worked
with both of these cards, at least when I was able to compile
it (the prob is always the same - no support for more recent
kernels; and I don't really like to use recent kernels (I myself
currently stay with 3.10.x stable line), but both laptops actually
requires recent kernels to work properly (either because of
great energy saving support in latest intel cpus, or because of
support of gpu in latest intel celerons) -- that's why I really
prefer in-kernel driver).
That to say - the fact that wl always works may tell that the
hw is fine and the prob is elsewhere.
Thanks,
/mjt
--
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
* Payment
From: Finance Department @ 2014-09-26 14:58 UTC (permalink / raw)
Dear Recipient,
You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds.
Gloria Peter
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Arend van Spriel @ 2014-09-26 14:42 UTC (permalink / raw)
To: Michael Tokarev; +Cc: Seth Forshee, brcm80211-dev-list, linux-wireless, netdev
In-Reply-To: <54257779.8010903@msgid.tls.msk.ru>
On 09/26/14 16:26, Michael Tokarev wrote:
> Okay, so finally, today, without any updates from your side,
> I opened up the laptop again and inserted a newly bought
> Intel 6235ANHMW card instead of this creaky brcm4313. This
> card works right out of the box - plug it in and set up,
> both wifi and bluetooth (I had numerous probs with bluetooth
> too with brcm card), and it works on both 2.4GHz and 5GHz
> bands. Connection is very good and stable, I wasn't able
> to trigger a single glitch no matter how hard I tried.
Good for you.
> My only sorry is a lot of wasted time, efforts and money -
> all that have much better value than trying to deal with
> non-working drivers. And my only wish is so vendors stop
> using non-working parts in their hardware.. But oh well.
Being bold here, but would you be willing to send that non-working part
of hardware to me. I seem to have 4313 cards over here that just work
and it would help greatly investigating the issue. I guess you do not
care that much anymore, but might be others do (myself included).
Regards,
Arend
^ permalink raw reply
* Re: [PATCH net-next v2] bonding: make global bonding stats more reliable
From: Nikolay Aleksandrov @ 2014-09-26 14:42 UTC (permalink / raw)
To: Andy Gospodarek, netdev; +Cc: j.vosburgh, vfalico
In-Reply-To: <1411684631-7509-1-git-send-email-gospo@cumulusnetworks.com>
On 26/09/14 00:37, Andy Gospodarek wrote:
> As the code stands today, bonding stats are based simply on the stats
> from the member interfaces. If a member was to be removed from a bond,
> the stats would instantly drop. This would be confusing to an admin
> would would suddonly see interface stats drop while traffic is still
> flowing.
>
> In addition to preventing the stats drops mentioned above, new members
> will now be added to the bond and only traffic received after the member
> was added to the bond will be counted as part of bonding stats.
>
> v2: Changes suggested by Nik to properly allocate/free stats memory.
>
> Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com>
> ---
> drivers/net/bonding/bond_main.c | 85 +++++++++++++++++++++++++++--------------
> drivers/net/bonding/bonding.h | 3 ++
> 2 files changed, 60 insertions(+), 28 deletions(-)
>
<<<<snip>>>>
> @@ -3857,6 +3874,8 @@ static void bond_uninit(struct net_device *bond_dev)
> __bond_release_one(bond_dev, slave->dev, true);
> netdev_info(bond_dev, "Released all slaves\n");
>
> + kfree(bond->bond_stats);
> +
> list_del(&bond->bond_list);
>
> bond_debug_unregister(bond);
> @@ -4243,7 +4262,13 @@ static int bond_init(struct net_device *bond_dev)
>
> bond->wq = create_singlethread_workqueue(bond_dev->name);
> if (!bond->wq)
> - return -ENOMEM;
> + goto bond_wq_fail;
> +
> + /* initialize persistent stats for the bond */
> + bond->bond_stats = kzalloc(sizeof(struct rtnl_link_stats64),
> + GFP_KERNEL);
> + if (!bond->bond_stats)
> + goto bond_stats_fail;
>
> bond_set_lockdep_class(bond_dev);
>
> @@ -4259,6 +4284,10 @@ static int bond_init(struct net_device *bond_dev)
> eth_hw_addr_random(bond_dev);
>
> return 0;
> +bond_stats_fail:
> + kfree(bond->wq);
^^^^^^^^^^
I think you should use destroy_workqueue() to properly get rid of the wq.
> +bond_wq_fail:
> + return -ENOMEM;
> }
>
> unsigned int bond_get_num_tx_queues(void)
> diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
> index 6140bf0..fe25265 100644
> --- a/drivers/net/bonding/bonding.h
> +++ b/drivers/net/bonding/bonding.h
> @@ -24,6 +24,7 @@
> #include <linux/inetdevice.h>
> #include <linux/etherdevice.h>
> #include <linux/reciprocal_div.h>
> +#include <linux/if_link.h>
>
> #include "bond_3ad.h"
> #include "bond_alb.h"
> @@ -175,6 +176,7 @@ struct slave {
> struct netpoll *np;
> #endif
> struct kobject kobj;
> + struct rtnl_link_stats64 *slave_stats;
> };
>
> /*
> @@ -224,6 +226,7 @@ struct bonding {
> /* debugging support via debugfs */
> struct dentry *debug_dir;
> #endif /* CONFIG_DEBUG_FS */
> + struct rtnl_link_stats64 *bond_stats;
> };
>
> #define bond_slave_get_rcu(dev) \
>
^ permalink raw reply
* Re: [PATCH v6 00/10] ARM: Berlin: Ethernet support
From: Antoine Tenart @ 2014-09-26 14:37 UTC (permalink / raw)
To: sebastian.hesselbarth
Cc: Antoine Tenart, alexandre.belloni, thomas.petazzoni, zmxu,
jszhang, netdev, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <1411742036-23520-1-git-send-email-antoine.tenart@free-electrons.com>
On Fri, Sep 26, 2014 at 04:33:46PM +0200, Antoine Tenart wrote:
> Hi all,
>
> This series introduce support for the Ethernet controller on Berlin SoCs,
> using the existing pxa168 Ethernet driver. In order to do this, DT
> support is added to the driver alongside some other modifications and
> fixes.
>
> This has been tested on a Berlin BG2Q DMP board.
>
> Changes since v4:
> - removed the phy-addr property and added a phy subnode
> - added COMPILE_TEST for the pxa168_eth driver
>
> Changes since v3:
> - moved the addition of pxa168_eth_get_mac_address() to the patch
> using it first
>
> Changes since v2:
> - reworked how the MAC address is configured
> - made the clock anonymous
>
> Changes since v1:
> - removed custom Berlin Ethernet driver
> - used the pxa168 Ethernet driver instead
> - made modifications to the pxa168 driver (DT support, fixes)
>
That's really the cover letter for the v5, not v6, I made a typo in the
subject...
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* (unknown),
From: Oscar Salvador @ 2014-09-26 14:34 UTC (permalink / raw)
To: netdev
subscribe netdev
^ permalink raw reply
* [PATCH v5 06/10] net: pxa168_eth: rework the MAC address setup
From: Antoine Tenart @ 2014-09-26 14:33 UTC (permalink / raw)
To: sebastian.hesselbarth
Cc: Antoine Tenart, alexandre.belloni, thomas.petazzoni, zmxu,
jszhang, netdev, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <1411742036-23520-1-git-send-email-antoine.tenart@free-electrons.com>
This patch rework the way the MAC address is retrieved. The MAC address
can now, in addition to being random, be set in the device tree or
retrieved from the Ethernet controller MAC address registers. The
probing function will try to get a MAC address in the following order:
- From the device tree.
- From the Ethernet controller MAC address registers.
- Generate a random one.
This patch also adds a function to read the MAC address from the
Ethernet Controller registers.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/marvell/pxa168_eth.c | 32 +++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c b/drivers/net/ethernet/marvell/pxa168_eth.c
index 34f17dde1cb0..3da8c5af15de 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -35,6 +35,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_net.h>
#include <linux/phy.h>
#include <linux/platform_device.h>
#include <linux/pxa168_eth.h>
@@ -606,6 +607,21 @@ static void pxa168_eth_set_rx_mode(struct net_device *dev)
update_hash_table_mac_address(pep, NULL, ha->addr);
}
+static void pxa168_eth_get_mac_address(struct net_device *dev,
+ unsigned char *addr)
+{
+ struct pxa168_eth_private *pep = netdev_priv(dev);
+ unsigned int mac_h = rdl(pep, MAC_ADDR_HIGH);
+ unsigned int mac_l = rdl(pep, MAC_ADDR_LOW);
+
+ addr[0] = (mac_h >> 24) & 0xff;
+ addr[1] = (mac_h >> 16) & 0xff;
+ addr[2] = (mac_h >> 8) & 0xff;
+ addr[3] = mac_h & 0xff;
+ addr[4] = (mac_l >> 8) & 0xff;
+ addr[5] = mac_l & 0xff;
+}
+
static int pxa168_eth_set_mac_address(struct net_device *dev, void *addr)
{
struct sockaddr *sa = addr;
@@ -1467,6 +1483,7 @@ static int pxa168_eth_probe(struct platform_device *pdev)
struct resource *res;
struct clk *clk;
struct device_node *np;
+ const unsigned char *mac_addr = NULL;
int err;
printk(KERN_NOTICE "PXA168 10/100 Ethernet Driver\n");
@@ -1508,8 +1525,19 @@ static int pxa168_eth_probe(struct platform_device *pdev)
INIT_WORK(&pep->tx_timeout_task, pxa168_eth_tx_timeout_task);
- dev_info(&pdev->dev, "Using random mac address\n");
- eth_hw_addr_random(dev);
+ if (pdev->dev.of_node)
+ mac_addr = of_get_mac_address(pdev->dev.of_node);
+
+ if (mac_addr && is_valid_ether_addr(mac_addr)) {
+ ether_addr_copy(dev->dev_addr, mac_addr);
+ } else {
+ /* try reading the mac address, if set by the bootloader */
+ pxa168_eth_get_mac_address(dev, dev->dev_addr);
+ if (!is_valid_ether_addr(dev->dev_addr)) {
+ dev_info(&pdev->dev, "Using random mac address\n");
+ eth_hw_addr_random(dev);
+ }
+ }
pep->rx_ring_size = NUM_RX_DESCS;
pep->tx_ring_size = NUM_TX_DESCS;
--
1.9.1
^ permalink raw reply related
* [PATCH v6 00/10] ARM: Berlin: Ethernet support
From: Antoine Tenart @ 2014-09-26 14:33 UTC (permalink / raw)
To: sebastian.hesselbarth
Cc: Antoine Tenart, alexandre.belloni, thomas.petazzoni, zmxu,
jszhang, netdev, linux-arm-kernel, devicetree, linux-kernel
Hi all,
This series introduce support for the Ethernet controller on Berlin SoCs,
using the existing pxa168 Ethernet driver. In order to do this, DT
support is added to the driver alongside some other modifications and
fixes.
This has been tested on a Berlin BG2Q DMP board.
Changes since v4:
- removed the phy-addr property and added a phy subnode
- added COMPILE_TEST for the pxa168_eth driver
Changes since v3:
- moved the addition of pxa168_eth_get_mac_address() to the patch
using it first
Changes since v2:
- reworked how the MAC address is configured
- made the clock anonymous
Changes since v1:
- removed custom Berlin Ethernet driver
- used the pxa168 Ethernet driver instead
- made modifications to the pxa168 driver (DT support, fixes)
Antoine Tenart (10):
net: pxa168_eth: clean up
net: pxa168_eth: add device tree support
Documentation: bindings: net: add the Marvell PXA168 Ethernet
controller
net: pxa168_eth: fix Ethernet flow control status
net: pxa168_eth: set the mac address on the Ethernet controller
net: pxa168_eth: rework the MAC address setup
net: pxa168_eth: allow Berlin SoCs to use the pxa168_eth driver
net: pxa168_eth: allow to compile the pxa168_eth driver for tests
ARM: dts: berlin: add the Ethernet node
ARM: dts: berlin: enable the Ethernet port on the BG2Q DMP
.../devicetree/bindings/net/marvell-pxa168.txt | 36 ++++
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 4 +
arch/arm/boot/dts/berlin2q.dtsi | 17 ++
drivers/net/ethernet/marvell/Kconfig | 2 +-
drivers/net/ethernet/marvell/pxa168_eth.c | 219 +++++++++++++--------
5 files changed, 199 insertions(+), 79 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/marvell-pxa168.txt
--
1.9.1
^ permalink raw reply
* [PATCH v5 10/10] ARM: dts: berlin: enable the Ethernet port on the BG2Q DMP
From: Antoine Tenart @ 2014-09-26 14:33 UTC (permalink / raw)
To: sebastian.hesselbarth
Cc: thomas.petazzoni, zmxu, devicetree, netdev, Antoine Tenart,
linux-kernel, alexandre.belloni, jszhang, linux-arm-kernel
In-Reply-To: <1411742036-23520-1-git-send-email-antoine.tenart@free-electrons.com>
This patch enables the Ethernet port on the Marvell Berlin2Q DMP board.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index a357ce02a64e..ea1f99b8eed6 100644
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
@@ -45,3 +45,7 @@
&uart0 {
status = "okay";
};
+
+ð0 {
+ status = "okay";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v5 09/10] ARM: dts: berlin: add the Ethernet node
From: Antoine Tenart @ 2014-09-26 14:33 UTC (permalink / raw)
To: sebastian.hesselbarth
Cc: Antoine Tenart, alexandre.belloni, thomas.petazzoni, zmxu,
jszhang, netdev, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <1411742036-23520-1-git-send-email-antoine.tenart@free-electrons.com>
This patch adds the Ethernet node, enabling the network unit on Berlin
BG2Q SoCs.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/berlin2q.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 902eddb19cd8..d442b22fd1ea 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -114,6 +114,23 @@
#interrupt-cells = <3>;
};
+ eth0: ethernet@b90000 {
+ compatible = "marvell,pxa168-eth";
+ reg = <0xb90000 0x10000>;
+ clocks = <&chip CLKID_GETH0>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+ /* set by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy-handle = <ðphy0>;
+ status = "disabled";
+
+ ethphy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+
cpu-ctrl@dd0000 {
compatible = "marvell,berlin-cpu-ctrl";
reg = <0xdd0000 0x10000>;
--
1.9.1
^ permalink raw reply related
* [PATCH v5 08/10] net: pxa168_eth: allow to compile the pxa168_eth driver for tests
From: Antoine Tenart @ 2014-09-26 14:33 UTC (permalink / raw)
To: sebastian.hesselbarth
Cc: thomas.petazzoni, zmxu, devicetree, netdev, Antoine Tenart,
linux-kernel, alexandre.belloni, jszhang, linux-arm-kernel
In-Reply-To: <1411742036-23520-1-git-send-email-antoine.tenart@free-electrons.com>
Add a dependency to COMPILE_TEST so that the driver can be compiled for
test purposes.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/marvell/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig
index 48b9466d1781..bed8fbb3edc5 100644
--- a/drivers/net/ethernet/marvell/Kconfig
+++ b/drivers/net/ethernet/marvell/Kconfig
@@ -64,7 +64,7 @@ config MVPP2
config PXA168_ETH
tristate "Marvell pxa168 ethernet support"
- depends on CPU_PXA168 || ARCH_BERLIN
+ depends on CPU_PXA168 || ARCH_BERLIN || COMPILE_TEST
select PHYLIB
---help---
This driver supports the pxa168 Ethernet ports.
--
1.9.1
^ 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