* Re: [RFC PATCH net-next] virtio_net: Support UDP Tunnel offloads.
From: Vlad Yasevich @ 2016-12-19 14:26 UTC (permalink / raw)
To: Or Gerlitz, Jarno Rajahalme
Cc: Linux Netdev List, james.zhangming,
Michael S. Tsirkin <mst@redhat.com> (mst@redhat.com), ailan
In-Reply-To: <CAJ3xEMh79catGjC4p7EsCqix_fmUgbcDtaz-1OUnR2xFpNq99g@mail.gmail.com>
On 12/15/2016 02:07 AM, Or Gerlitz wrote:
> On Fri, Nov 18, 2016 at 1:01 AM, Jarno Rajahalme <jarno@ovn.org> wrote:
>> This patch is a proof-of-concept I did a few months ago for UDP tunnel
>> offload support in virtio_net interface [..]
>
> What's the use case you were considering for a guest running a UDP based VTEP?
Two cases that I've been aware of are nested virt or simply a guest acting
as router/bridge with possible different tunnel devices.
-vlad
>
>> Real implementation needs to extend the virtio_net header rather than
>> piggy-backing on existing fields. Inner MAC length (or inner network
>> offset) also needs to be passed as a new field. Control plane (QEMU)
>> also needs to be updated.
>>
>> All testing was done using Geneve, but this should work for all UDP
>> tunnels the same.
^ permalink raw reply
* Re: [PATCH net v2] ipvlan: fix crash when master is set in loopback mode
From: Eric Dumazet @ 2016-12-19 14:37 UTC (permalink / raw)
To: Mahesh Bandewar; +Cc: netdev, Eric Dumazet, David Miller, Mahesh Bandewar
In-Reply-To: <1482087625-30366-1-git-send-email-mahesh@bandewar.net>
On Sun, 2016-12-18 at 11:00 -0800, Mahesh Bandewar wrote:
> 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.
>
> ------------[ cut here ]------------
> kernel BUG at include/linux/skbuff.h:1737!
> Call Trace:
> [<ffffffff921fbbc2>] dev_forward_skb+0x92/0xd0
> [<ffffffffc031ac65>] ipvlan_process_multicast+0x395/0x4c0 [ipvlan]
> [<ffffffffc031a9a7>] ? ipvlan_process_multicast+0xd7/0x4c0 [ipvlan]
> [<ffffffff91cdfea7>] ? process_one_work+0x147/0x660
> [<ffffffff91cdff09>] process_one_work+0x1a9/0x660
> [<ffffffff91cdfea7>] ? process_one_work+0x147/0x660
> [<ffffffff91ce086d>] worker_thread+0x11d/0x360
> [<ffffffff91ce0750>] ? rescuer_thread+0x350/0x350
> [<ffffffff91ce960b>] kthread+0xdb/0xe0
> [<ffffffff91c05c70>] ? _raw_spin_unlock_irq+0x30/0x50
> [<ffffffff91ce9530>] ? flush_kthread_worker+0xc0/0xc0
> [<ffffffff92348b7a>] ret_from_fork+0x9a/0xd0
> [<ffffffff91ce9530>] ? flush_kthread_worker+0xc0/0xc0
>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> ---
> v1->v2: commit log update
>
> drivers/net/ipvlan/ipvlan_core.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c
> index b4e990743e1d..4294fc1f5564 100644
> --- a/drivers/net/ipvlan/ipvlan_core.c
> +++ b/drivers/net/ipvlan/ipvlan_core.c
> @@ -660,6 +660,9 @@ rx_handler_result_t ipvlan_handle_frame(struct sk_buff **pskb)
> if (!port)
> return RX_HANDLER_PASS;
>
> + if (unlikely(!pskb_may_pull(skb, sizeof(struct ethhdr))))
> + goto out;
> +
> switch (port->mode) {
> case IPVLAN_MODE_L2:
> return ipvlan_handle_mode_l2(pskb, port);
> @@ -672,6 +675,8 @@ rx_handler_result_t ipvlan_handle_frame(struct sk_buff **pskb)
> /* Should not reach here */
> WARN_ONCE(true, "ipvlan_handle_frame() called for mode = [%hx]\n",
> port->mode);
> +
> +out:
> kfree_skb(skb);
> return RX_HANDLER_CONSUMED;
> }
There is something funky here.
When rx_handler() is called, we must have pulled Ethernet header
already.
Is this because RX_HANDLER_ANOTHER is returned in some cases, while it
should not ?
It looks like you added a pskb_may_pull() at a wrong place. Sure it
might fix the crash, but it looks weird here.
^ 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 14:38 UTC (permalink / raw)
To: Romain Perier, Volodymyr Bendiuga
Cc: 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: <20161219141610.30934-2-romain.perier@free-electrons.com>
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?
Please see:
https://www.spinics.net/lists/netdev/msg409156.html
It would be nicer to use Volodymyr, since it has been reviewed.
Volodymyr, what happened to your version 2? Did David accept it?
Andrew
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: marvell: Add ethernet switch definition for the EXPRESSObin
From: Andrew Lunn @ 2016-12-19 14:44 UTC (permalink / raw)
To: Romain Perier
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: <20161219141610.30934-5-romain.perier@free-electrons.com>
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + switch0phy0: switch0phy0@0 {
> + reg = <0x11>;
Since the reg is 0x11, this should be called switch0phy0@11. Please
follow the same scheme for the other phys.
Andrew
^ permalink raw reply
* Re: [PATCH 3/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
From: Andrew Lunn @ 2016-12-19 14:52 UTC (permalink / raw)
To: Romain Perier
Cc: 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: <20161219141610.30934-4-romain.perier@free-electrons.com>
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.
> --- 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.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH 2/4] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports
From: Andrew Lunn @ 2016-12-19 14:56 UTC (permalink / raw)
To: Romain Perier
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: <20161219141610.30934-3-romain.perier@free-electrons.com>
On Mon, Dec 19, 2016 at 03:16:07PM +0100, Romain Perier wrote:
> Some Marvell ethernet switches have internal ethernet transceivers with
> hardcoded phy addresses. These addresses can be grearer than the number
> of ports or its value might be different than the associated port number.
> This is for example the case for MV88E6341 that has 6 ports and internal
> Port 1 to Port4 PHYs mapped at SMI addresses from 0x11 to 0x14.
>
> This commits fixes the issue by removing the condition in MDIO callbacks.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
So it is not quite compatible with the 6352. Thanks Marvell :-(
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* 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
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