* Re: [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Romain Perier @ 2016-12-19 14:56 UTC (permalink / raw)
To: Andrew Lunn, Volodymyr Bendiuga
Cc: Mark Rutland, devicetree, Florian Fainelli, Jason Cooper,
Pawel Moll, Vivien Didelot, netdev, Ian Campbell, Nadav Haklai,
Rob Herring, Kumar Gala, Gregory Clement, Thomas Petazzoni,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20161219143848.GA10048@lunn.ch>
Hi Andrew,
Le 19/12/2016 à 15:38, Andrew Lunn a écrit :
> On Mon, Dec 19, 2016 at 03:16:06PM +0100, Romain Perier wrote:
>> Currently, the function mv88e6xxx_smi_init() returns -EINVAL if the bit
>> zero of sw_addr is 0x1. However, on some platforms, ethernet switches
>> are configured in Multi chip addressing mode and available at MDIO
>> address 0x1.
>
> Hi Romain
>
> What branch is this against? net-next?
Until last friday it was based onto next-20161216, I rebased onto the
torvalds's tree this morning (so ~4.10-pre-rc1).
>
> Please see:
>
> https://www.spinics.net/lists/netdev/msg409156.html
Oh, it's already fixed, good. I did not see this patch :)
>
> It would be nicer to use Volodymyr, since it has been reviewed.
As the fix is already there, I will use it, sure.
Thanks,
Romain
^ permalink raw reply
* Re: [PATCH 3/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
From: Romain Perier @ 2016-12-19 14:58 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Rutland, devicetree, Florian Fainelli, Jason Cooper,
Pawel Moll, Vivien Didelot, netdev, Ian Campbell, Nadav Haklai,
Rob Herring, Kumar Gala, Gregory Clement, Thomas Petazzoni,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20161219145227.GC10048@lunn.ch>
Hi Andrew,
Le 19/12/2016 à 15:52, Andrew Lunn a écrit :
> Hi Romain
>
>> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
>> index 76d944e..72ba24b 100644
>> --- a/drivers/net/dsa/mv88e6xxx/chip.c
>> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
>> @@ -4086,6 +4086,20 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
>> .ops = &mv88e6321_ops,
>> },
>>
>> + [MV88E6341] = {
>> + .prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
>> + .family = MV88E6XXX_FAMILY_6352,
>> + .name = "Marvell 88E6341",
>> + .num_databases = 4096,
>> + .num_ports = 6,
>> + .port_base_addr = 0x10,
>> + .global1_addr = 0x1b,
>> + .age_time_coeff = 15000,
>> + .tag_protocol = DSA_TAG_PROTO_EDSA,
>> + .flags = MV88E6XXX_FLAGS_FAMILY_6352,
>> + .ops = &mv88e6352_ops,
>
> Even if it i 100% compatible with the 6532, you should still add an
> ops structure for it. All chips have their own, even when the are
> exactly the same as other in the family.
Ack, I will fix this.
>
>> --- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
>> +++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
>> @@ -86,6 +86,7 @@
>> #define PORT_SWITCH_ID_PROD_NUM_6097 0x099
>> #define PORT_SWITCH_ID_PROD_NUM_6131 0x106
>> #define PORT_SWITCH_ID_PROD_NUM_6320 0x115
>> +#define PORT_SWITCH_ID_PROD_NUM_6341 0x340
>> #define PORT_SWITCH_ID_PROD_NUM_6123 0x121
>> #define PORT_SWITCH_ID_PROD_NUM_6161 0x161
>
> Ah, err..
>
> These should be in numerical order of the macro.
> PORT_SWITCH_ID_PROD_NUM_6320 is however in the wrong place. Please
> put the 6341 after the 6321.
good catch, ok.
Thanks,
Romain
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: marvell: Add ethernet switch definition for the EXPRESSObin
From: Thomas Petazzoni @ 2016-12-19 14:58 UTC (permalink / raw)
To: Romain Perier
Cc: Mark Rutland, Andrew Lunn, Florian Fainelli, Jason Cooper,
Pawel Moll, Vivien Didelot, netdev, Ian Campbell, Nadav Haklai,
devicetree, Rob Herring, Kumar Gala, Gregory Clement,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20161219141610.30934-5-romain.perier@free-electrons.com>
Hello,
On Mon, 19 Dec 2016 15:16:09 +0100, Romain Perier wrote:
> This defines and enables the Marvell ethernet switch MVE886341 on the
> Marvell EXPRESSObin board.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
I didn't want to make this (silly) comment but since you got another
comment that will let you send a new iteration, here is my silly
comment: the name of the board is EspressoBin, not ExpressoBin.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Andrew Lunn @ 2016-12-19 15:00 UTC (permalink / raw)
To: Romain Perier
Cc: Volodymyr Bendiuga, Vivien Didelot, Florian Fainelli,
Jason Cooper, Sebastian Hesselbarth, Gregory Clement, netdev,
devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, linux-arm-kernel, Thomas Petazzoni, Nadav Haklai
In-Reply-To: <292d4f15-c58b-3565-26ec-98a025b6adb3@free-electrons.com>
On Mon, Dec 19, 2016 at 03:56:34PM +0100, Romain Perier wrote:
> Hi Andrew,
>
> Le 19/12/2016 à 15:38, Andrew Lunn a écrit :
> >On Mon, Dec 19, 2016 at 03:16:06PM +0100, Romain Perier wrote:
> >>Currently, the function mv88e6xxx_smi_init() returns -EINVAL if the bit
> >>zero of sw_addr is 0x1. However, on some platforms, ethernet switches
> >>are configured in Multi chip addressing mode and available at MDIO
> >>address 0x1.
> >
> >Hi Romain
> >
> >What branch is this against? net-next?
>
> Until last friday it was based onto next-20161216, I rebased onto
> the torvalds's tree this morning (so ~4.10-pre-rc1).
This patchset is 80% networking. So please see:
Documentation/networking/netdev-FAQ.txt
> Oh, it's already fixed, good. I did not see this patch :)
>
> >
> >It would be nicer to use Volodymyr, since it has been reviewed.
>
>
> As the fix is already there, I will use it, sure.
Im not sure what happened to it. It might of fallen through the
cracks. Lets see what Volodymyr says. It might need resubmitting once
netdev reopens.
Andrew
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: marvell: Add ethernet switch definition for the EXPRESSObin
From: Romain Perier @ 2016-12-19 15:03 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Mark Rutland, Andrew Lunn, Florian Fainelli, Jason Cooper,
Pawel Moll, Vivien Didelot, netdev, Ian Campbell, Nadav Haklai,
devicetree, Rob Herring, Kumar Gala, Gregory Clement,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20161219155819.4cdf0f40@free-electrons.com>
Hi,
Le 19/12/2016 à 15:58, Thomas Petazzoni a écrit :
> Hello,
>
> On Mon, 19 Dec 2016 15:16:09 +0100, Romain Perier wrote:
>> This defines and enables the Marvell ethernet switch MVE886341 on the
>> Marvell EXPRESSObin board.
>>
>> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
>
> I didn't want to make this (silly) comment but since you got another
> comment that will let you send a new iteration, here is my silly
> comment: the name of the board is EspressoBin, not ExpressoBin.
>
> Thanks!
>
> Thomas
>
Ack for the two feedback (I don't know why I have replaced "es" by "ex"
:/, anyway...)
Thanks,
Romain
^ permalink raw reply
* [PATCH net 0/3] Fix integration of eee-broken-modes
From: Jerome Brunet @ 2016-12-19 15:05 UTC (permalink / raw)
To: netdev, devicetree, Florian Fainelli
Cc: Andrew Lunn, Neil Armstrong, Martin Blumenstingl, Kevin Hilman,
linux-kernel, Yegor Yefremov, Julia Lawall, Andre Roth,
Carlo Caione, linux-amlogic, Andreas Färber,
linux-arm-kernel, Jerome Brunet
The purpose of this series is to fix the integration of the ethernet phy
property "eee-broken-modes" [0]
The v3 of this series has been merged, missing a fix (error reported by
kbuild robot) available in the v4 [1]
More importantly, Florian opposed adding a DT property mapping a device
register this directly [2]. The concern was that the property could be
abused to implement platform configuration policy. After discussing it,
I think we agreed that such information about the HW (defect) should appear
in the platform DT. However, the preferred way is to add a boolean property
for each EEE broken mode.
[0]: http://lkml.kernel.org/r/1480326409-25419-1-git-send-email-jbrunet@baylibre.com
[1]: http://lkml.kernel.org/r/1480348229-25672-1-git-send-email-jbrunet@baylibre.com
[2]: http://lkml.kernel.org/r/e14a3b0c-dc34-be14-48b3-518a0ad0c080@gmail.com
Jerome Brunet (3):
net: phy: fix sign type error in genphy_config_eee_advert
net: phy: use boolean dt properties for eee broken modes
dt: bindings: net: use boolean dt properties for eee broken modes
Documentation/devicetree/bindings/net/phy.txt | 10 ++++++++--
drivers/net/phy/phy_device.c | 22 +++++++++++++++++-----
include/dt-bindings/net/mdio.h | 19 -------------------
3 files changed, 25 insertions(+), 26 deletions(-)
delete mode 100644 include/dt-bindings/net/mdio.h
--
2.7.4
^ permalink raw reply
* [PATCH net 2/3] net: phy: use boolean dt properties for eee broken modes
From: Jerome Brunet @ 2016-12-19 15:05 UTC (permalink / raw)
To: netdev, devicetree, Florian Fainelli
Cc: Jerome Brunet, Carlo Caione, Kevin Hilman, Martin Blumenstingl,
Andre Roth, Andrew Lunn, Neil Armstrong, linux-amlogic,
linux-arm-kernel, linux-kernel, Yegor Yefremov,
Andreas Färber
In-Reply-To: <1482159938-13239-1-git-send-email-jbrunet@baylibre.com>
The patches regarding eee-broken-modes was merged before all people
involved could find an agreement on the best way to move forward.
While we agreed on having a DT property to mark particular modes as broken,
the value used for eee-broken-modes mapped the phy register in very direct
way. Because of this, the concern is that it could be used to implement
configuration policies instead of describing a broken HW.
In the end, having a boolean property for each mode seems to be preferred
over one bit field value mapping the register (too) directly.
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/net/phy/phy_device.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index ee5ebadb1463..92b08383cafa 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1665,7 +1665,7 @@ static void of_set_phy_supported(struct phy_device *phydev)
static void of_set_phy_eee_broken(struct phy_device *phydev)
{
struct device_node *node = phydev->mdio.dev.of_node;
- u32 broken;
+ u32 broken = 0;
if (!IS_ENABLED(CONFIG_OF_MDIO))
return;
@@ -1673,8 +1673,20 @@ static void of_set_phy_eee_broken(struct phy_device *phydev)
if (!node)
return;
- if (!of_property_read_u32(node, "eee-broken-modes", &broken))
- phydev->eee_broken_modes = broken;
+ if (of_property_read_bool(node, "eee-broken-100tx"))
+ broken |= MDIO_EEE_100TX;
+ if (of_property_read_bool(node, "eee-broken-1000t"))
+ broken |= MDIO_EEE_1000T;
+ if (of_property_read_bool(node, "eee-broken-10gt"))
+ broken |= MDIO_EEE_10GT;
+ if (of_property_read_bool(node, "eee-broken-1000kx"))
+ broken |= MDIO_EEE_1000KX;
+ if (of_property_read_bool(node, "eee-broken-10gkx4"))
+ broken |= MDIO_EEE_10GKX4;
+ if (of_property_read_bool(node, "eee-broken-10gkr"))
+ broken |= MDIO_EEE_10GKR;
+
+ phydev->eee_broken_modes = broken;
}
/**
--
2.7.4
^ permalink raw reply related
* [PATCH net 3/3] dt: bindings: net: use boolean dt properties for eee broken modes
From: Jerome Brunet @ 2016-12-19 15:05 UTC (permalink / raw)
To: netdev, devicetree, Florian Fainelli
Cc: Jerome Brunet, Carlo Caione, Kevin Hilman, Martin Blumenstingl,
Andre Roth, Andrew Lunn, Neil Armstrong, linux-amlogic,
linux-arm-kernel, linux-kernel, Yegor Yefremov,
Andreas Färber
In-Reply-To: <1482159938-13239-1-git-send-email-jbrunet@baylibre.com>
The patches regarding eee-broken-modes was merged before all people
involved could find an agreement on the best way to move forward.
While we agreed on having a DT property to mark particular modes as broken,
the value used for eee-broken-modes mapped the phy register in very direct
way. Because of this, the concern is that it could be used to implement
configuration policies instead of describing a broken HW.
In the end, having a boolean property for each mode seems to be preferred
over one bit field value mapping the register (too) directly.
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
Documentation/devicetree/bindings/net/phy.txt | 10 ++++++++--
include/dt-bindings/net/mdio.h | 19 -------------------
2 files changed, 8 insertions(+), 21 deletions(-)
delete mode 100644 include/dt-bindings/net/mdio.h
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index 54749b60a466..ff1bc4b1bb3b 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -38,8 +38,14 @@ Optional Properties:
- enet-phy-lane-swap: If set, indicates the PHY will swap the TX/RX lanes to
compensate for the board being designed with the lanes swapped.
-- eee-broken-modes: Bits to clear in the MDIO_AN_EEE_ADV register to
- disable EEE broken modes.
+- eee-broken-100tx:
+- eee-broken-1000t:
+- eee-broken-10gt:
+- eee-broken-1000kx:
+- eee-broken-10gkx4:
+- eee-broken-10gkr:
+ Mark the corresponding energy efficient ethernet mode as broken and
+ request the ethernet to stop advertising it.
Example:
diff --git a/include/dt-bindings/net/mdio.h b/include/dt-bindings/net/mdio.h
deleted file mode 100644
index 99c6d903d439..000000000000
--- a/include/dt-bindings/net/mdio.h
+++ /dev/null
@@ -1,19 +0,0 @@
-/*
- * This header provides generic constants for ethernet MDIO bindings
- */
-
-#ifndef _DT_BINDINGS_NET_MDIO_H
-#define _DT_BINDINGS_NET_MDIO_H
-
-/*
- * EEE capability Advertisement
- */
-
-#define MDIO_EEE_100TX 0x0002 /* 100TX EEE cap */
-#define MDIO_EEE_1000T 0x0004 /* 1000T EEE cap */
-#define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
-#define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap */
-#define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap */
-#define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap */
-
-#endif
--
2.7.4
^ permalink raw reply related
* [PATCH net 1/3] net: phy: fix sign type error in genphy_config_eee_advert
From: Jerome Brunet @ 2016-12-19 15:05 UTC (permalink / raw)
To: netdev, devicetree, Florian Fainelli
Cc: Jerome Brunet, Carlo Caione, Kevin Hilman, Martin Blumenstingl,
Andre Roth, Andrew Lunn, Neil Armstrong, linux-amlogic,
linux-arm-kernel, linux-kernel, Julia Lawall, Yegor Yefremov,
Andreas Färber
In-Reply-To: <1482159938-13239-1-git-send-email-jbrunet@baylibre.com>
In genphy_config_eee_advert, the return value of phy_read_mmd_indirect is
checked to know if the register could be accessed but the result is
assigned to a 'u32'.
Changing to 'int' to correctly get errors from phy_read_mmd_indirect.
Fixes: d853d145ea3e ("net: phy: add an option to disable EEE advertisement")
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/net/phy/phy_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 9c06f8028f0c..ee5ebadb1463 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1187,8 +1187,8 @@ static int genphy_config_advert(struct phy_device *phydev)
*/
static int genphy_config_eee_advert(struct phy_device *phydev)
{
- u32 broken = phydev->eee_broken_modes;
- u32 old_adv, adv;
+ int broken = phydev->eee_broken_modes;
+ int old_adv, adv;
/* Nothing to disable */
if (!broken)
--
2.7.4
^ permalink raw reply related
* [PATCH net] virtio_net: reject XDP programs using header adjustment
From: Jakub Kicinski @ 2016-12-19 15:05 UTC (permalink / raw)
To: netdev
Cc: john.fastabend, kafai, daniel, alexei.starovoitov, mst,
Jakub Kicinski
commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog")
added a new XDP helper to prepend and remove data from a frame.
Make virtio_net reject programs making use of this helper until
proper support is added.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/virtio_net.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 08327e005ccc..db761f37783e 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1677,6 +1677,11 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
u16 xdp_qp = 0, curr_qp;
int i, err;
+ if (prog && prog->xdp_adjust_head) {
+ netdev_warn(dev, "Does not support bpf_xdp_adjust_head()\n");
+ return -EOPNOTSUPP;
+ }
+
if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO4) ||
virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO6)) {
netdev_warn(dev, "can't set XDP while host is implementing LRO, disable LRO first\n");
--
2.11.0
^ permalink raw reply related
* Re: Linux support for 802.1AS-Rev.
From: Richard Cochran @ 2016-12-19 15:06 UTC (permalink / raw)
To: Praveen Bajantri; +Cc: netdev
In-Reply-To: <CA+tSgV+DWJHJ4LBHTyX4bzwLyCq+3=4nOF+eLjWwFPyYfP6FsQ@mail.gmail.com>
On Mon, Dec 19, 2016 at 03:50:08PM +0530, Praveen Bajantri wrote:
> I am new to Linux networking and had doubt related to support for
> 802.1AS-Rev. Please point me to appropriate forum/mailing list If this
> is not a right place.
This list is for kernel related issues. The mailing lists for the
user space gPTP stack are at:
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
> Does Linux support 802.1AS-Rev ? Is there any application which can be
> used to test this feature ?
Looking at
http://www.ieee802.org/1/pages/802.1AS-rev.html
this standard hasn't even been published, and the drafts are locked
away for committee's eyes only.
So how on earth do you expect us to support it?
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Andrew Lunn @ 2016-12-19 15:07 UTC (permalink / raw)
To: Volodymyr Bendiuga
Cc: Romain Perier, Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement, netdev, devicetree,
Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel, Thomas Petazzoni, Nadav Haklai
In-Reply-To: <CABHmqqDqhJa6N=Ayu-GFNyp4g90dXzTje6o8qfCEP2DacCFWdQ@mail.gmail.com>
On Mon, Dec 19, 2016 at 04:04:32PM +0100, Volodymyr Bendiuga wrote:
> Hi Andrew,
>
> No, it did not get accepted. Or at least I did not see
> David accepting it. Let me know if I should resubmit it.
Hi Volodymyr
Please do resend it. Probably netdev will reopen sometime after the
25th.
Don't forget to include the reviewed-by i gave.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH] stmmac: fix memory barriers
From: Niklas Cassel @ 2016-12-19 15:08 UTC (permalink / raw)
To: Pavel Machek, LinoSanfilippo, peppe.cavallaro, alexandre.torgue,
davem, linux-kernel, netdev, Joao.Pinto
In-Reply-To: <20161218203812.GA1012@amd>
Tested-by: Niklas Cassel <niklas.cassel@axis.com>
On 12/18/2016 09:38 PM, Pavel Machek wrote:
> Fix up memory barriers in stmmac driver. They are meant to protect
> against DMA engine, so smp_ variants are certainly wrong, and dma_
> variants are preferable.
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> index a340fc8..8816515 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> @@ -334,7 +334,7 @@ static void dwmac4_rd_prepare_tx_desc(struct dma_desc *p, int is_fs, int len,
> * descriptors for the same frame has to be set before, to
> * avoid race condition.
> */
> - wmb();
> + dma_wmb();
>
> p->des3 = cpu_to_le32(tdes3);
> }
> @@ -377,7 +377,7 @@ static void dwmac4_rd_prepare_tso_tx_desc(struct dma_desc *p, int is_fs,
> * descriptors for the same frame has to be set before, to
> * avoid race condition.
> */
> - wmb();
> + dma_wmb();
>
> p->des3 = cpu_to_le32(tdes3);
> }
> diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> index ce97e52..f0d8632 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> @@ -350,7 +350,7 @@ static void enh_desc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len,
> * descriptors for the same frame has to be set before, to
> * avoid race condition.
> */
> - wmb();
> + dma_wmb();
>
> p->des0 = cpu_to_le32(tdes0);
> }
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 3e40578..bb40382 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2125,7 +2125,7 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
> * descriptor and then barrier is needed to make sure that
> * all is coherent before granting the DMA engine.
> */
> - smp_wmb();
> + dma_wmb();
>
> if (netif_msg_pktdata(priv)) {
> pr_info("%s: curr=%d dirty=%d f=%d, e=%d, f_p=%p, nfrags %d\n",
> @@ -2338,7 +2338,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
> * descriptor and then barrier is needed to make sure that
> * all is coherent before granting the DMA engine.
> */
> - smp_wmb();
> + dma_wmb();
> }
>
> netdev_sent_queue(dev, skb->len);
> @@ -2443,14 +2443,14 @@ static inline void stmmac_rx_refill(struct stmmac_priv *priv)
> netif_dbg(priv, rx_status, priv->dev,
> "refill entry #%d\n", entry);
> }
> - wmb();
> + dma_wmb();
>
> if (unlikely(priv->synopsys_id >= DWMAC_CORE_4_00))
> priv->hw->desc->init_rx_desc(p, priv->use_riwt, 0, 0);
> else
> priv->hw->desc->set_rx_owner(p);
>
> - wmb();
> + dma_wmb();
>
> entry = STMMAC_GET_ENTRY(entry, DMA_RX_SIZE);
> }
>
^ permalink raw reply
* Re: [PATCH net-next v4 2/4] dt-bindings: net: add EEE capability constants
From: Jerome Brunet @ 2016-12-19 15:16 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Florian Fainelli, Alexandre TORGUE, Andrew Lunn,
Martin Blumenstingl, netdev, Neil Armstrong, linux-kernel,
Yegor Yefremov, Julia Lawall, Andre Roth, Kevin Hilman,
Carlo Caione, Giuseppe Cavallaro, linux-amlogic,
Andreas Färber, linux-arm-kernel
In-Reply-To: <20161205143942.f3w6nmp3jvmrk5es@rob-hp-laptop>
Hi Rob,
First, Thx for this information and sorry for this late reply
As you may have seen yourself, there was little bit of confusion while
discussing this patch series.
The point is the v3 was applied before your reply (patches 2 and 3 not
combined unfortunately).
Because of this confusion, the series needed a few fixes witch removes
the previously added bindings [0].
This time, I made sure to modify (remove) the bindings along with the
documentation.
[0]: http://lkml.kernel.org/r/1482159938-13239-1-git-send-email-jbrunet
@baylibre.com
Cheers
Jerome
On Mon, 2016-12-05 at 08:39 -0600, Rob Herring wrote:
> On Mon, Nov 28, 2016 at 04:50:26PM +0100, Jerome Brunet wrote:
> >
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
> > Tested-by: Andreas Färber <afaerber@suse.de>
> > Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> > ---
> > include/dt-bindings/net/mdio.h | 19 +++++++++++++++++++
> > 1 file changed, 19 insertions(+)
> > create mode 100644 include/dt-bindings/net/mdio.h
>
> Seems changes are wanted on this, but patches 2 and 3 should be
> combined. The header is part of the binding doc.
>
> Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH net] virtio_net: reject XDP programs using header adjustment
From: Mintz, Yuval @ 2016-12-19 15:23 UTC (permalink / raw)
To: Jakub Kicinski, netdev@vger.kernel.org
Cc: john.fastabend@gmail.com, kafai@fb.com, daniel@iogearbox.net,
alexei.starovoitov@gmail.com, mst@redhat.com
In-Reply-To: <20161219150500.2600-1-jakub.kicinski@netronome.com>
> commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog")
> added a new XDP helper to prepend and remove data from a frame.
> Make virtio_net reject programs making use of this helper until proper
> support is added.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Is that how it goes until we'll add the proper infrastructure?
Am I expected to provide the same for qede?
I was under the impression that so long as this is being [early] developed
and there's no way to communicate what is and isn't supported by
a given implementation, it would simply be the user's responsibility
to make sure what he's trying is supported.
^ permalink raw reply
* Re: [PATCH] stmmac: fix memory barriers
From: Giuseppe CAVALLARO @ 2016-12-19 15:36 UTC (permalink / raw)
To: Pavel Machek, LinoSanfilippo, alexandre.torgue, davem,
linux-kernel, netdev, niklas.cassel, Joao.Pinto
In-Reply-To: <20161218203812.GA1012@amd>
On 12/18/2016 9:38 PM, Pavel Machek wrote:
>
> Fix up memory barriers in stmmac driver. They are meant to protect
> against DMA engine, so smp_ variants are certainly wrong, and dma_
> variants are preferable.
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> index a340fc8..8816515 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> @@ -334,7 +334,7 @@ static void dwmac4_rd_prepare_tx_desc(struct dma_desc *p, int is_fs, int len,
> * descriptors for the same frame has to be set before, to
> * avoid race condition.
> */
> - wmb();
> + dma_wmb();
>
> p->des3 = cpu_to_le32(tdes3);
> }
> @@ -377,7 +377,7 @@ static void dwmac4_rd_prepare_tso_tx_desc(struct dma_desc *p, int is_fs,
> * descriptors for the same frame has to be set before, to
> * avoid race condition.
> */
> - wmb();
> + dma_wmb();
>
> p->des3 = cpu_to_le32(tdes3);
> }
> diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> index ce97e52..f0d8632 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> @@ -350,7 +350,7 @@ static void enh_desc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len,
> * descriptors for the same frame has to be set before, to
> * avoid race condition.
> */
> - wmb();
> + dma_wmb();
>
> p->des0 = cpu_to_le32(tdes0);
> }
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 3e40578..bb40382 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2125,7 +2125,7 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
> * descriptor and then barrier is needed to make sure that
> * all is coherent before granting the DMA engine.
> */
> - smp_wmb();
> + dma_wmb();
>
> if (netif_msg_pktdata(priv)) {
> pr_info("%s: curr=%d dirty=%d f=%d, e=%d, f_p=%p, nfrags %d\n",
> @@ -2338,7 +2338,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
> * descriptor and then barrier is needed to make sure that
> * all is coherent before granting the DMA engine.
> */
> - smp_wmb();
> + dma_wmb();
> }
>
> netdev_sent_queue(dev, skb->len);
> @@ -2443,14 +2443,14 @@ static inline void stmmac_rx_refill(struct stmmac_priv *priv)
> netif_dbg(priv, rx_status, priv->dev,
> "refill entry #%d\n", entry);
> }
> - wmb();
> + dma_wmb();
>
> if (unlikely(priv->synopsys_id >= DWMAC_CORE_4_00))
> priv->hw->desc->init_rx_desc(p, priv->use_riwt, 0, 0);
> else
> priv->hw->desc->set_rx_owner(p);
>
> - wmb();
> + dma_wmb();
>
> entry = STMMAC_GET_ENTRY(entry, DMA_RX_SIZE);
> }
>
^ permalink raw reply
* Re: [PATCH net v2 2/5] powerpc: remove fsl,fman from of_device_ids[]
From: David Miller @ 2016-12-19 15:37 UTC (permalink / raw)
To: madalin.bucur; +Cc: netdev, linuxppc-dev, linux-kernel, scott.wood, mpe
In-Reply-To: <1482139343-8975-3-git-send-email-madalin.bucur@nxp.com>
From: Madalin Bucur <madalin.bucur@nxp.com>
Date: Mon, 19 Dec 2016 11:22:20 +0200
> The fsl/fman drivers will use of_platform_populate() on all
> supported platforms.
>
> Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
It seems that this creates a failure point between patches #2 and
#3. If the cases handled by this "fsl,fman" entry are only afterwards
covered by the of_platform_populate() code added in patch #3 then you
cannot split these two changes up like this.
The two changes must be done at the same time, otherwise probing will
fail for some people between patches #2 and #3.
^ permalink raw reply
* Re: [PATCH net] virtio_net: reject XDP programs using header adjustment
From: Jakub Kicinski @ 2016-12-19 15:42 UTC (permalink / raw)
To: Mintz, Yuval
Cc: netdev@vger.kernel.org, john.fastabend@gmail.com, kafai@fb.com,
daniel@iogearbox.net, alexei.starovoitov@gmail.com,
mst@redhat.com
In-Reply-To: <BL2PR07MB2306FB78FBB5F2D17681699D8D910@BL2PR07MB2306.namprd07.prod.outlook.com>
On Mon, Dec 19, 2016 at 3:23 PM, Mintz, Yuval <Yuval.Mintz@cavium.com> wrote:
>> commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog")
>> added a new XDP helper to prepend and remove data from a frame.
>> Make virtio_net reject programs making use of this helper until proper
>> support is added.
>>
>> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>
> Is that how it goes until we'll add the proper infrastructure?
> Am I expected to provide the same for qede?
I asked Martin to fix the existing drivers like qede but virtio's XDP
was not merged at that point.
> I was under the impression that so long as this is being [early] developed
> and there's no way to communicate what is and isn't supported by
> a given implementation, it would simply be the user's responsibility
> to make sure what he's trying is supported.
IMHO the less user has to guess the better if we're hoping for wide adoption.
^ permalink raw reply
* Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string
From: Rob Herring @ 2016-12-19 16:04 UTC (permalink / raw)
To: Dongpo Li
Cc: David Miller, Mark Rutland, Michael Turquette, Stephen Boyd,
Russell King, Zhangfei Gao, Yisen Zhuang, salil.mehta,
Arnd Bergmann, Andrew Lunn, Jiancheng Xue, benjamin.chenhao,
caizhiyong, netdev, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <585796D6.1080407@hisilicon.com>
On Mon, Dec 19, 2016 at 2:14 AM, Dongpo Li <lidongpo@hisilicon.com> wrote:
> Hi Rob and David,
>
> On 2016/12/12 22:21, Rob Herring wrote:
>> On Mon, Dec 12, 2016 at 5:16 AM, Dongpo Li <lidongpo@hisilicon.com> wrote:
>>> Hi Rob,
>>>
>>> On 2016/12/10 6:35, Rob Herring wrote:
>>>> On Mon, Dec 05, 2016 at 09:27:58PM +0800, Dongpo Li wrote:
[...]
>>>>> @@ -20,7 +25,7 @@ Required properties:
>>>>>
>>>>> Example:
>>>>> gmac0: ethernet@f9840000 {
>>>>> - compatible = "hisilicon,hix5hd2-gmac";
>>>>> + compatible = "hisilicon,hix5hd2-gemac", "hisilicon,hisi-gemac-v1";
>>>>
>>>> You can't just change compatible strings.
>>>>
>>> Okay, maybe I should name all the compatible string with the suffix "-gmac" instead of
>>> "-gemac". This can keep the compatible strings with the same suffix. Is this okay?
>>> Can I just add the generic compatible string without changing the SoCs compatible string?
>>> Like following:
>>> gmac0: ethernet@f9840000 {
>>> - compatible = "hisilicon,hix5hd2-gmac";
>>> + compatible = "hisilicon,hix5hd2-gmac", "hisilicon,hisi-gmac-v1";
>>
>> Yes, this is fine.
>
> As the patch series have been applied to net-next branch,
> in which way should I commit this compatible fix?
> Should I send a new patch fixing this compatible string error with "Fixes: xxx"?
> Looking forward to your reply!
Yes to both.
Rob
^ permalink raw reply
* Re: [v3] net: ethernet: cavium: octeon: octeon_mgmt: Handle return NULL error from devm_ioremap
From: David Miller @ 2016-12-19 16:04 UTC (permalink / raw)
To: arvind.yadav.cs
Cc: peter.chen, fw, david.daney, f.fainelli, netdev, linux-kernel
In-Reply-To: <1481742210-5609-1-git-send-email-arvind.yadav.cs@gmail.com>
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date: Thu, 15 Dec 2016 00:33:30 +0530
> Here, If devm_ioremap will fail. It will return NULL.
> Kernel can run into a NULL-pointer dereference.
> This error check will avoid NULL pointer dereference.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Since ioremap() is in fact designed to possibly fail, we do
need to always check it's return value. So this change is
correct and I have applied it to the 'net' tree.
Thanks.
^ permalink raw reply
* Re: Synopsys Ethernet QoS
From: Niklas Cassel @ 2016-12-19 16:05 UTC (permalink / raw)
To: Joao Pinto, Lars Persson
Cc: Florian Fainelli, Andy Shevchenko, David Miller,
Giuseppe CAVALLARO, Rabin Vincent, netdev,
CARLOS.PALMINHA@synopsys.com, Jie.Deng1@synopsys.com,
Stephen Warren, pavel@ucw.cz
In-Reply-To: <c6eb5745-20b3-daac-33b4-b20c568344b8@synopsys.com>
On 12/13/2016 01:56 PM, Joao Pinto wrote:
> Às 12:50 PM de 12/13/2016, Lars Persson escreveu:
>>> 13 dec. 2016 kl. 13:31 skrev Niklas Cassel <Niklas.Cassel@axis.com>:
>>>
>>>
>>>
>>>> On 12/13/2016 12:49 PM, Joao Pinto wrote:
>>>> Hi Niklas,
>>>>
>>>> Às 4:25 PM de 12/12/2016, Niklas Cassel escreveu:
>>>>>> On 12/12/2016 11:19 AM, Joao Pinto wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Às 1:44 AM de 12/10/2016, Florian Fainelli escreveu:
>>>>>>>> Le 12/09/16 à 16:16, Andy Shevchenko a écrit :
>>>>>>>> On Sat, Dec 10, 2016 at 12:52 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>> (snip...)
>>>>
>>>>
>>>>>> @Rabin Vincent: Hi Rabin. Since Axis is more familiar with the synopsys/*qos*
>>>>>> driver would it be possible for you to make an initial analysis of what has to
>>>>>> be merged into Stmmac? This way the development would speed-up.
>>>>> I can answer that question.
>>>>>
>>>>> I've sent out 12 patches to the stmmac driver
>>>>> (all patches are included in the current net-next tree),
>>>>> with these patches the stmmac driver works properly on Axis hardware
>>>>> (we use Synopsys GMAC 4.10a synthesized with multiple TX queues).
>>>>> stmmac's DT binding has also been extended with properties that
>>>>> existed in DWC EQoS's DT binding, such as no-pbl-x8, txpbl, rxpbl.
>>>>>
>>>>> Since we have no problem updating the DTB together with the kernel,
>>>>> we will simply move to using the start using the stmmac driver,
>>>>> with stmmac's DT binding.
>>>>>
>>>>> However, I've noticed that NVIDIA has extended the DWC EQoS DT binding,
>>>>> I don't how easy it would be for them to switch to stmmac's DT binding.
>>>>> (Adding Stephen Warren to CC.)
>>>>>
>>>>> The reset sequence that Lars Persson was worried about is not an issue
>>>>> with the stmmac driver.
>>>> Great! So you saying that stmmac works great with AXIS hardware and no need to
>>>> merge specific code from AXIS' *qos* driver?
>>> Yes. From Axis point of view, we are done.
>>> stmmac works and we will move to that driver + DT binding.
>>>
>>> However, it seems like Stephen Warren will NAK if you try to remove
>>> synopsys/dwc_eth_qos.c before
>>> Documentation/devicetree/bindings/net/stmmac.txt
>>> is compatible with
>>> Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
>>>
>>> You might want to sync with him. I have no idea, but perhaps they are
>>> only using a subset of all the available properties. Perhaps,
>>> only implementing what they are using might be enough, I don't know.
>>> I couldn't find their DTS in arch/arm/dts.
>>> I guess you might want to know David Miller's opinion,
>>> since he's the one who decides in the end.
>> I will also NACK removal of dwc_eth_qos.c until the binding is implemented elsewhere.
> Totally agree.
> @Niklas: David Miller is informed of what we are planning to do. Can you
> estimate the effort of merging the axis driver device tree bindings? If there
> was anyone from axis to do the merge would be better since you are familiar with
> it. What do you think?
Since stmmac supports glue layers, the best thing is probably
to create a new glue layer
(see for example drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
with matching Documentation/devicetree/bindings/net/meson-dwmac.txt).
That way we don't have to "contaminate" the generic code in
stmmac_platform.c and dwmac-generic.c.
The only code needed in the glue driver would be the code to parse the
devicetree properties specific to dwc_eth_qos.c.
Hence, the amount of code you will have to write will be very limited.
Writing the code will probably be quick, but since you will have to
fix review comments etc., I would estimate it to be around 1-2 days work.
Since we have already moved to stmmac's DT binding,
we don't really care about the old binding, but I will gladly
help you by performing code reviews if you would like.
>
>>
>>>>>
>>>>>
>>>>> There are some performance problems with the stmmac driver though:
>>>>>
>>>>> When running iperf3 with 3 streams:
>>>>> iperf3 -c 192.168.0.90 -P 3 -t 30
>>>>> iperf3 -c 192.168.0.90 -P 3 -t 30 -R
>>>>>
>>>>> I get really bad fairness between the streams.
>>>>>
>>>>> This appears to be an issue with how TX IRQ coalescing is implemented in stmmac.
>>>>> Disabling TX IRQ coalescing in the stmmac driver makes the problem go away.
>>>>> We have a local patch that implements TX IRQ coalescing in the dwceqos driver,
>>>>> and we don't see the same problem.
>>>>>
>>>>> Also netperf TCP_RR and UDP_RR gives really bad results compared to the
>>>>> dwceqos driver (without IRQ coalescing).
>>>>> 2000 transactions/sec vs 9000 transactions/sec.
>>>>> Turning TX IRQ coalescing off and RX interrupt watchdog off in stmmac
>>>>> gives the same performance. I guess it's a trade off, low CPU usage
>>>>> vs low latency, so I don't know how important TCP_RR/UDP_RR really is.
>>>>>
>>>>> The best thing would be to get a good working TX IRQ coalesce
>>>>> implementation with HR timers in stmmac.
>>>>> Perhaps it should also be investigated if the RX interrupt watchdog
>>>>> timeout should have a lower default value.
>>>>>
>>>>>
>>>>>
>>>>>> Thanks to all.
>>>>>>
>>>>>> Joao
^ permalink raw reply
* Re: [PATCH] stmmac: fix memory barriers
From: David Miller @ 2016-12-19 16:06 UTC (permalink / raw)
To: pavel
Cc: LinoSanfilippo, peppe.cavallaro, alexandre.torgue, linux-kernel,
netdev, niklas.cassel, Joao.Pinto
In-Reply-To: <20161218203812.GA1012@amd>
From: Pavel Machek <pavel@ucw.cz>
Date: Sun, 18 Dec 2016 21:38:12 +0100
> Fix up memory barriers in stmmac driver. They are meant to protect
> against DMA engine, so smp_ variants are certainly wrong, and dma_
> variants are preferable.
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
Applied.
^ permalink raw reply
* RE: [PATCH net v2 2/5] powerpc: remove fsl,fman from of_device_ids[]
From: Madalin-Cristian Bucur @ 2016-12-19 16:07 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Scott Wood
In-Reply-To: <20161219.103712.1578523196484939315.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, December 19, 2016 5:37 PM
>
> From: Madalin Bucur <madalin.bucur@nxp.com>
> Date: Mon, 19 Dec 2016 11:22:20 +0200
>
> > The fsl/fman drivers will use of_platform_populate() on all
> > supported platforms.
> >
> > Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
>
> It seems that this creates a failure point between patches #2 and
> #3. If the cases handled by this "fsl,fman" entry are only afterwards
> covered by the of_platform_populate() code added in patch #3 then you
> cannot split these two changes up like this.
>
> The two changes must be done at the same time, otherwise probing will
> fail for some people between patches #2 and #3.
You are right, that will happen. I was not convinced these need to be
merged due to the different places they touch. I'll send a v3.
^ permalink raw reply
* Re: [PATCH net v2] ipvlan: fix crash when master is set in loopback mode
From: David Miller @ 2016-12-19 16:11 UTC (permalink / raw)
To: mahesh; +Cc: netdev, edumazet, maheshb
In-Reply-To: <1482087625-30366-1-git-send-email-mahesh@bandewar.net>
From: Mahesh Bandewar <mahesh@bandewar.net>
Date: Sun, 18 Dec 2016 11:00:25 -0800
> From: Mahesh Bandewar <maheshb@google.com>
>
> In an IPvlan setup when master is set in loopback mode e.g.
>
> ethtool -K eth0 set loopback on
>
> where eth0 is master device for IPvlan setup.
>
> The failure actually happens while processing mulitcast packets
> but that's a result of unconditionally queueing packets without
> ensuring ether-header is part of the linear part of skb.
>
> This patch forces this check at the reception and drops packets
> which fail this check before queuing them.
...
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> ---
> v1->v2: commit log update
Like Eric, I still do not like this change nor the explanation.
Whether in loopback mode or not, your explanation makes no sense at
all.
If the packet comes from the ethernet device, the freakin' ethernet
header is there in the linear SKB area. No pulling should be needed
whatsoever.
Something creates this bad situation where the ethernet header is not
there, but you have not explained that sufficiently yet.
Thank you.
^ permalink raw reply
* [PATCH net v3 0/4] fsl/fman: fixes for ARM
From: Madalin Bucur @ 2016-12-19 16:13 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem, scott.wood, mpe
The patch set fixes advertised speeds for QSGMII interfaces, disables
A007273 erratum workaround on non-PowerPC platforms where it does not
apply, enables compilation on ARM64 and addresses a probing issue on
non PPC platforms.
Changes from v2: merged fsl/fman changes to avoid a point of failure
Changes from v1: unifying probing on all supported platforms
Madalin Bucur (4):
fsl/fman: fix 1G support for QSGMII interfaces
powerpc: fsl/fman: remove fsl,fman from of_device_ids[]
fsl/fman: A007273 only applies to PPC SoCs
fsl/fman: enable compilation on ARM64
arch/powerpc/platforms/85xx/corenet_generic.c | 3 ---
drivers/net/ethernet/freescale/fman/Kconfig | 2 +-
drivers/net/ethernet/freescale/fman/fman.c | 16 ++++++++++++++++
drivers/net/ethernet/freescale/fman/mac.c | 1 +
4 files changed, 18 insertions(+), 4 deletions(-)
--
2.1.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox