* [PATCH] net: atheros: atl1: use offset_in_page() macro
From: Geliang Tang @ 2017-04-22 1:21 UTC (permalink / raw)
To: Jay Cliburn, Chris Snook, David S. Miller, Eric Dumazet
Cc: Geliang Tang, netdev, linux-kernel
In-Reply-To: <4dbc77ccaaed98b183cf4dba58a4fa325fd65048.1492758503.git.geliangtang@gmail.com>
Use offset_in_page() macro instead of open-coding.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
drivers/net/ethernet/atheros/atlx/atl1.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c b/drivers/net/ethernet/atheros/atlx/atl1.c
index 022772e..83d2db2 100644
--- a/drivers/net/ethernet/atheros/atlx/atl1.c
+++ b/drivers/net/ethernet/atheros/atlx/atl1.c
@@ -1886,7 +1886,7 @@ static u16 atl1_alloc_rx_buffers(struct atl1_adapter *adapter)
buffer_info->skb = skb;
buffer_info->length = (u16) adapter->rx_buffer_len;
page = virt_to_page(skb->data);
- offset = (unsigned long)skb->data & ~PAGE_MASK;
+ offset = offset_in_page(skb->data);
buffer_info->dma = pci_map_page(pdev, page, offset,
adapter->rx_buffer_len,
PCI_DMA_FROMDEVICE);
@@ -2230,7 +2230,7 @@ static void atl1_tx_map(struct atl1_adapter *adapter, struct sk_buff *skb,
hdr_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
buffer_info->length = hdr_len;
page = virt_to_page(skb->data);
- offset = (unsigned long)skb->data & ~PAGE_MASK;
+ offset = offset_in_page(skb->data);
buffer_info->dma = pci_map_page(adapter->pdev, page,
offset, hdr_len,
PCI_DMA_TODEVICE);
@@ -2254,9 +2254,8 @@ static void atl1_tx_map(struct atl1_adapter *adapter, struct sk_buff *skb,
data_len -= buffer_info->length;
page = virt_to_page(skb->data +
(hdr_len + i * ATL1_MAX_TX_BUF_LEN));
- offset = (unsigned long)(skb->data +
- (hdr_len + i * ATL1_MAX_TX_BUF_LEN)) &
- ~PAGE_MASK;
+ offset = offset_in_page(skb->data +
+ (hdr_len + i * ATL1_MAX_TX_BUF_LEN));
buffer_info->dma = pci_map_page(adapter->pdev,
page, offset, buffer_info->length,
PCI_DMA_TODEVICE);
@@ -2268,7 +2267,7 @@ static void atl1_tx_map(struct atl1_adapter *adapter, struct sk_buff *skb,
/* not TSO */
buffer_info->length = buf_len;
page = virt_to_page(skb->data);
- offset = (unsigned long)skb->data & ~PAGE_MASK;
+ offset = offset_in_page(skb->data);
buffer_info->dma = pci_map_page(adapter->pdev, page,
offset, buf_len, PCI_DMA_TODEVICE);
if (++next_to_use == tpd_ring->count)
--
2.9.3
^ permalink raw reply related
* Re: [PATCH RFC] sparc64: eBPF JIT
From: David Miller @ 2017-04-22 1:19 UTC (permalink / raw)
To: alexei.starovoitov; +Cc: sparclinux, netdev, ast, daniel
In-Reply-To: <20170418225707.GA65449@ast-mbp.thefacebook.com>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Tue, 18 Apr 2017 15:57:09 -0700
> Alternative idea: can the above
> 'add FP, STACK_BIAS, one_of_local_regs' be done once in prologue
> and that register used as substitue for R10 ?
After much consideration I think this is what I'm going to end up
doing, I should have listened to you from the beginning :-)
It will simplify the JIT significantly.
Now I will just have to completely trust that the verifier has audited
all the FP accesses properly. :-)
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: add binding for RTL8211E Ethernet PHY
From: icenowy-h8G6r0blFSE @ 2017-04-22 1:12 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Rob Herring, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <c7aa9d7a-5e97-0e7f-2b1c-584a4de00837-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
在 2017-04-22 08:22，Florian Fainelli 写道：
> On 04/21/2017 04:24 PM, Icenowy Zheng wrote:
>> From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>
>> Some RTL8211E Ethernet PHY have an issue that needs a workaround
>> indicated with device tree.
>>
>> Add the binding for a property that indicates this workaround.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>> ---
>> .../devicetree/bindings/net/realtek,rtl8211e.txt | 22
>> ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>> b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>> new file mode 100644
>> index 000000000000..c1913301bfe8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>> @@ -0,0 +1,22 @@
>> +Realtek RTL8211E Ethernet PHY
>> +
>> +One batch of RTL8211E is slight broken, that needs some special (and
>> +full of magic numbers) tweaking in order to make GbE to operate
>> properly.
>> +The only well-known board that used the broken batch is Pine64+.
>> +Configure it through an Ethernet OF device node.
>> +
>> +Optional properties:
>> +
>> +- realtek,disable-rx-delay:
>> + If set, RX delay will be completely disabled (according to
>> Realtek). This
>> + will affect the performance on non-broken boards.
>> + default: do not disable RX delay.
>
> Please don't introduce custom properties to do that, instead correct
> specify the "phy-mode" such that it is e.g: "rgmii-txid" which
> indicates
> that there should be no RX internal delay, but a TX internal delay
> added
> by the PHY.
According to Realtek and Pine64 people, set that register is equal to
hardwire RDDLY line to low.
Is it the standard definition of RGMII-TXID?
(P.S. as it's only provided as a workaround, there's no implementation
known for RGMII-RXID and RGMII-ID)
Thanks,
Icenowy
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH net-next 0/3] mlx5: fix warnings
From: David Miller @ 2017-04-22 1:07 UTC (permalink / raw)
To: stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ
Cc: saeedm-VPRAkNaXOzVWk0Htik3J/w, matanb-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, sthemmin-0li6OtcxBFHby3iVrkZq2A
In-Reply-To: <20170421181558.5414-1-sthemmin-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
From: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Date: Fri, 21 Apr 2017 11:15:55 -0700
> While looking for sparse and warning output in another driver,
> I saw several trivial warnings from MLX5 driver. This patch
> series fixes them.
Saeed, please merge the patches you are OK with into your tree.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] change the default Kconfig value of mlx5_en
From: Saeed Mahameed @ 2017-04-22 1:07 UTC (permalink / raw)
To: Ian Kumlien, Leon Romanovsky, Matan Barak
Cc: David Miller, Saeed Mahameed, Linux Kernel Network Developers
In-Reply-To: <CAA85sZsUjOSZ9Ax6=YFVQfykexCUCRH8+qVxUHRHwt0cBtSqmQ@mail.gmail.com>
On Sat, Apr 22, 2017 at 3:47 AM, Ian Kumlien <ian.kumlien@gmail.com> wrote:
> On Sat, Apr 22, 2017 at 2:34 AM, Saeed Mahameed
> <saeedm@dev.mellanox.co.il> wrote:
>> On Sat, Apr 22, 2017 at 2:10 AM, Ian Kumlien <ian.kumlien@gmail.com> wrote:
>>> Sorry,
>>>
>>> Back again, fighting cold, hot whiskey has been consumed...
>>>
>>> Something like this would perhaps be a better solution:
>>>
>>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
>>> b/drivers/net/ethernet/mellanox/mlx5/core/main.c
>>> index 60154a175bd3..fe192e247601 100644
>>> --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
>>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
>>> @@ -1139,6 +1139,10 @@ static int mlx5_load_one(struct mlx5_core_dev
>>> *dev, struct mlx5_priv *priv,
>>>
>>> #ifdef CONFIG_MLX5_CORE_EN
>>> mlx5_eswitch_attach(dev->priv.eswitch);
>>> +#else
>>> + if (MLX5_CAP_GEN(dev, port_type) == MLX5_CAP_PORT_TYPE_ETH) {
>>> + dev_info(&pdev->dev, "Ethernet device discovered but
>>> support not enabled in kernel.");
>>> + }
>>> #endif
>>>
>>
>> Currently both MLX5_CORE=n and MLX5_CORE_EN=n as a default, the issue
>> you are seeing can occur only if you explicitly set MLX5_CORE=y and
>> MLX5_CORE=n, Why would someone do this if he knows he wants Ethernet
>> support as well ? IMHO this print is redundant .
>
> Well, I'm running a prebuilt kernel - which was configured this way,
> and since there
> is no mlx5_en module and it does state that the link is "Ethernet", it
> just looks like the
> driver is broken or in some kind of really weird state.
>
>> Anyway, Are you looking for RDMA support over ethernet (RoCE) ? and
>> you are not interested to have ethernet netdev support ?
>
> ? RDMA is something we'll look at in the future, right now, having the
> nics actually
> work as nics is a priority ;)
>
I see, i just wanted to understand your situation :)
>> if yes, I think this is something that can be achieved, but the
>> question is do we really need this ?
>
> It's really weird to see the driver load, to see everything register
> and have no feedback.
>
So, in your case you have mlx5 core support without MLX5_CORE_EN which
provides the eswitch and netdev functionality in ethernet.
But you will still have mlx5_ib register an RDMA interface and
theoretically it should work, the only thing you won't see is a
netdevice.
The weird thing is that you don't see a link up on the RDMA interface,
Leon/Matan can you please look into this ? do we really need a netdev
to have a functioning RDMA logical link in ethernet ?
> Including no network devices, but if you run the Infiniband commands,
> they tell you that
> you are connected to Ethernet but that the device is down and disabled.
>
> To me, down and disabled is not the same as in "Ethernet support is
> not included" =)
>
> Basically, i would hate for someone else to end up in the same
> situation since you only
> get guides on how to enable infiniband/RDMA but what you really want
> to do at that point
> is to disable it and see if that gives you your network devices back =)
>
Yes this is misleading, Maybe your kernel log warning is not so bad
after all, but let me dig more into this.
I will get back to you next week.
> I have had similar issues with some connectx3 devices while playing at
> home but i suspect
> that it's just a limitation of OFED packages available for the dist I'm running.
^ permalink raw reply
* Re: [PATCH net-next 3/3] mlx5: fix space waste from ethtool descriptions
From: Saeed Mahameed @ 2017-04-22 0:49 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David S. Miller, Saeed Mahameed, Matan Barak, Leon Romanovsky,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Linux Netdev List,
Stephen Hemminger
In-Reply-To: <20170421181558.5414-4-sthemmin-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
On Fri, Apr 21, 2017 at 9:15 PM, Stephen Hemminger
<stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org> wrote:
> The ethtool statistics descriptions were declared as static in
> en_stats.h but that file is included indirectly in multiple places
> causing multiple unused redundant copies. This is reported by building
> with W=1.
>
> The solution is to move the description out of en_stats.h into
> the one file that uses them en_ethtool.c
Hi Stephen,
Thanks for the patches,
I really like patches #1 and #2, But i would like to keep this patch
out of this series for now.
I have some guys working now on adding and refactoring the stats
reporting mechanism in mlx5e and I also would like to keep the stats
descriptions outside of en_ethtool.c logic.
I totally agree with you and I will keep the wasted space issue in
mind and will ask the guys to fix it in their patches.
Deal ?
Thanks
Saeed.
>
> Signed-off-by: Stephen Hemminger <sthemmin-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
> ---
> .../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 208 +++++++++++++++++++++
> drivers/net/ethernet/mellanox/mlx5/core/en_stats.h | 206 +-------------------
> 2 files changed, 209 insertions(+), 205 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
> index ce7b09d72ff6..b1d9518b2719 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
> @@ -31,6 +31,214 @@
> */
>
> #include "en.h"
> +#include "en_stats.h"
> +
> +
> +static const struct counter_desc sw_stats_desc[] = {
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_packets) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_bytes) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_packets) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_bytes) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_tso_packets) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_tso_bytes) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_tso_inner_packets) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_tso_inner_bytes) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_lro_packets) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_lro_bytes) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_csum_unnecessary) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_csum_none) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_csum_complete) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_csum_unnecessary_inner) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_xdp_drop) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_xdp_tx) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_xdp_tx_full) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_csum_partial) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_csum_partial_inner) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_queue_stopped) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_queue_wake) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_queue_dropped) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_xmit_more) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_wqe_err) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_mpwqe_filler) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_buff_alloc_err) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_cqe_compress_blks) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_cqe_compress_pkts) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_cache_reuse) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_cache_full) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_cache_empty) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_cache_busy) },
> + { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, link_down_events_phy) },
> +};
> +
> +static const struct counter_desc q_stats_desc[] = {
> + { MLX5E_DECLARE_STAT(struct mlx5e_qcounter_stats, rx_out_of_buffer) },
> +};
> +
> +static const struct counter_desc vport_stats_desc[] = {
> + { "rx_vport_unicast_packets",
> + VPORT_COUNTER_OFF(received_eth_unicast.packets) },
> + { "rx_vport_unicast_bytes",
> + VPORT_COUNTER_OFF(received_eth_unicast.octets) },
> + { "tx_vport_unicast_packets",
> + VPORT_COUNTER_OFF(transmitted_eth_unicast.packets) },
> + { "tx_vport_unicast_bytes",
> + VPORT_COUNTER_OFF(transmitted_eth_unicast.octets) },
> + { "rx_vport_multicast_packets",
> + VPORT_COUNTER_OFF(received_eth_multicast.packets) },
> + { "rx_vport_multicast_bytes",
> + VPORT_COUNTER_OFF(received_eth_multicast.octets) },
> + { "tx_vport_multicast_packets",
> + VPORT_COUNTER_OFF(transmitted_eth_multicast.packets) },
> + { "tx_vport_multicast_bytes",
> + VPORT_COUNTER_OFF(transmitted_eth_multicast.octets) },
> + { "rx_vport_broadcast_packets",
> + VPORT_COUNTER_OFF(received_eth_broadcast.packets) },
> + { "rx_vport_broadcast_bytes",
> + VPORT_COUNTER_OFF(received_eth_broadcast.octets) },
> + { "tx_vport_broadcast_packets",
> + VPORT_COUNTER_OFF(transmitted_eth_broadcast.packets) },
> + { "tx_vport_broadcast_bytes",
> + VPORT_COUNTER_OFF(transmitted_eth_broadcast.octets) },
> + { "rx_vport_rdma_unicast_packets",
> + VPORT_COUNTER_OFF(received_ib_unicast.packets) },
> + { "rx_vport_rdma_unicast_bytes",
> + VPORT_COUNTER_OFF(received_ib_unicast.octets) },
> + { "tx_vport_rdma_unicast_packets",
> + VPORT_COUNTER_OFF(transmitted_ib_unicast.packets) },
> + { "tx_vport_rdma_unicast_bytes",
> + VPORT_COUNTER_OFF(transmitted_ib_unicast.octets) },
> + { "rx_vport_rdma_multicast_packets",
> + VPORT_COUNTER_OFF(received_ib_multicast.packets) },
> + { "rx_vport_rdma_multicast_bytes",
> + VPORT_COUNTER_OFF(received_ib_multicast.octets) },
> + { "tx_vport_rdma_multicast_packets",
> + VPORT_COUNTER_OFF(transmitted_ib_multicast.packets) },
> + { "tx_vport_rdma_multicast_bytes",
> + VPORT_COUNTER_OFF(transmitted_ib_multicast.octets) },
> +};
> +static const struct counter_desc pport_802_3_stats_desc[] = {
> + { "tx_packets_phy", PPORT_802_3_OFF(a_frames_transmitted_ok) },
> + { "rx_packets_phy", PPORT_802_3_OFF(a_frames_received_ok) },
> + { "rx_crc_errors_phy", PPORT_802_3_OFF(a_frame_check_sequence_errors) },
> + { "tx_bytes_phy", PPORT_802_3_OFF(a_octets_transmitted_ok) },
> + { "rx_bytes_phy", PPORT_802_3_OFF(a_octets_received_ok) },
> + { "tx_multicast_phy", PPORT_802_3_OFF(a_multicast_frames_xmitted_ok) },
> + { "tx_broadcast_phy", PPORT_802_3_OFF(a_broadcast_frames_xmitted_ok) },
> + { "rx_multicast_phy", PPORT_802_3_OFF(a_multicast_frames_received_ok) },
> + { "rx_broadcast_phy", PPORT_802_3_OFF(a_broadcast_frames_received_ok) },
> + { "rx_in_range_len_errors_phy", PPORT_802_3_OFF(a_in_range_length_errors) },
> + { "rx_out_of_range_len_phy", PPORT_802_3_OFF(a_out_of_range_length_field) },
> + { "rx_oversize_pkts_phy", PPORT_802_3_OFF(a_frame_too_long_errors) },
> + { "rx_symbol_err_phy", PPORT_802_3_OFF(a_symbol_error_during_carrier) },
> + { "tx_mac_control_phy", PPORT_802_3_OFF(a_mac_control_frames_transmitted) },
> + { "rx_mac_control_phy", PPORT_802_3_OFF(a_mac_control_frames_received) },
> + { "rx_unsupported_op_phy", PPORT_802_3_OFF(a_unsupported_opcodes_received) },
> + { "rx_pause_ctrl_phy", PPORT_802_3_OFF(a_pause_mac_ctrl_frames_received) },
> + { "tx_pause_ctrl_phy", PPORT_802_3_OFF(a_pause_mac_ctrl_frames_transmitted) },
> +};
> +
> +static const struct counter_desc pport_2863_stats_desc[] = {
> + { "rx_discards_phy", PPORT_2863_OFF(if_in_discards) },
> + { "tx_discards_phy", PPORT_2863_OFF(if_out_discards) },
> + { "tx_errors_phy", PPORT_2863_OFF(if_out_errors) },
> +};
> +
> +static const struct counter_desc pport_2819_stats_desc[] = {
> + { "rx_undersize_pkts_phy", PPORT_2819_OFF(ether_stats_undersize_pkts) },
> + { "rx_fragments_phy", PPORT_2819_OFF(ether_stats_fragments) },
> + { "rx_jabbers_phy", PPORT_2819_OFF(ether_stats_jabbers) },
> + { "rx_64_bytes_phy", PPORT_2819_OFF(ether_stats_pkts64octets) },
> + { "rx_65_to_127_bytes_phy", PPORT_2819_OFF(ether_stats_pkts65to127octets) },
> + { "rx_128_to_255_bytes_phy", PPORT_2819_OFF(ether_stats_pkts128to255octets) },
> + { "rx_256_to_511_bytes_phy", PPORT_2819_OFF(ether_stats_pkts256to511octets) },
> + { "rx_512_to_1023_bytes_phy", PPORT_2819_OFF(ether_stats_pkts512to1023octets) },
> + { "rx_1024_to_1518_bytes_phy", PPORT_2819_OFF(ether_stats_pkts1024to1518octets) },
> + { "rx_1519_to_2047_bytes_phy", PPORT_2819_OFF(ether_stats_pkts1519to2047octets) },
> + { "rx_2048_to_4095_bytes_phy", PPORT_2819_OFF(ether_stats_pkts2048to4095octets) },
> + { "rx_4096_to_8191_bytes_phy", PPORT_2819_OFF(ether_stats_pkts4096to8191octets) },
> + { "rx_8192_to_10239_bytes_phy", PPORT_2819_OFF(ether_stats_pkts8192to10239octets) },
> +};
> +
> +static const struct counter_desc pport_phy_statistical_stats_desc[] = {
> + { "rx_symbol_errors_phy", PPORT_PHY_STATISTICAL_OFF(phy_symbol_errors) },
> + { "rx_corrected_bits_phy", PPORT_PHY_STATISTICAL_OFF(phy_corrected_bits) },
> +};
> +
> +static const struct counter_desc pport_per_prio_traffic_stats_desc[] = {
> + { "rx_prio%d_bytes", PPORT_PER_PRIO_OFF(rx_octets) },
> + { "rx_prio%d_packets", PPORT_PER_PRIO_OFF(rx_frames) },
> + { "tx_prio%d_bytes", PPORT_PER_PRIO_OFF(tx_octets) },
> + { "tx_prio%d_packets", PPORT_PER_PRIO_OFF(tx_frames) },
> +};
> +
> +static const struct counter_desc pport_per_prio_pfc_stats_desc[] = {
> + /* %s is "global" or "prio{i}" */
> + { "rx_%s_pause", PPORT_PER_PRIO_OFF(rx_pause) },
> + { "rx_%s_pause_duration", PPORT_PER_PRIO_OFF(rx_pause_duration) },
> + { "tx_%s_pause", PPORT_PER_PRIO_OFF(tx_pause) },
> + { "tx_%s_pause_duration", PPORT_PER_PRIO_OFF(tx_pause_duration) },
> + { "rx_%s_pause_transition", PPORT_PER_PRIO_OFF(rx_pause_transition) },
> +};
> +
> +static const struct counter_desc pcie_perf_stats_desc[] = {
> + { "rx_pci_signal_integrity", PCIE_PERF_OFF(rx_errors) },
> + { "tx_pci_signal_integrity", PCIE_PERF_OFF(tx_errors) },
> +};
> +
> +static const struct counter_desc rq_stats_desc[] = {
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, packets) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, bytes) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, csum_complete) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, csum_unnecessary_inner) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, csum_none) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, xdp_drop) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, xdp_tx) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, xdp_tx_full) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, lro_packets) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, lro_bytes) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, wqe_err) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, mpwqe_filler) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, buff_alloc_err) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, cqe_compress_blks) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, cqe_compress_pkts) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, cache_reuse) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, cache_full) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, cache_empty) },
> + { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, cache_busy) },
> +};
> +
> +static const struct counter_desc sq_stats_desc[] = {
> + { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, packets) },
> + { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, bytes) },
> + { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, tso_packets) },
> + { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, tso_bytes) },
> + { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, tso_inner_packets) },
> + { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, tso_inner_bytes) },
> + { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, csum_partial_inner) },
> + { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, nop) },
> + { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, csum_none) },
> + { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, stopped) },
> + { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, wake) },
> + { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, dropped) },
> + { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, xmit_more) },
> +};
> +
> +static const struct counter_desc mlx5e_pme_status_desc[] = {
> + { "module_plug", 0 },
> + { "module_unplug", 8 },
> +};
> +
> +static const struct counter_desc mlx5e_pme_error_desc[] = {
> + { "module_pwr_budget_exd", 0 }, /* power budget exceed */
> + { "module_long_range", 8 }, /* long range for non MLNX cable */
> + { "module_bus_stuck", 16 }, /* bus stuck (I2C or data shorted) */
> + { "module_no_eeprom", 24 }, /* no eeprom/retry time out */
> + { "module_enforce_part", 32 }, /* enforce part number list */
> + { "module_unknown_id", 40 }, /* unknown identifier */
> + { "module_high_temp", 48 }, /* high temperature */
> + { "module_bad_shorted", 56 }, /* bad or shorted cable/module */
> + { "module_unknown_status", 64 },
> +};
>
> static void mlx5e_get_drvinfo(struct net_device *dev,
> struct ethtool_drvinfo *drvinfo)
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h b/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h
> index 53e4992d6511..1c867ee973f2 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h
> @@ -47,7 +47,7 @@
>
> struct counter_desc {
> char format[ETH_GSTRING_LEN];
> - int offset; /* Byte offset */
> + size_t offset; /* Byte offset */
> };
>
> struct mlx5e_sw_stats {
> @@ -88,49 +88,10 @@ struct mlx5e_sw_stats {
> u64 link_down_events_phy;
> };
>
> -static const struct counter_desc sw_stats_desc[] = {
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_packets) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_bytes) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_packets) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_bytes) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_tso_packets) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_tso_bytes) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_tso_inner_packets) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_tso_inner_bytes) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_lro_packets) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_lro_bytes) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_csum_unnecessary) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_csum_none) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_csum_complete) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_csum_unnecessary_inner) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_xdp_drop) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_xdp_tx) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_xdp_tx_full) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_csum_partial) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_csum_partial_inner) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_queue_stopped) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_queue_wake) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_queue_dropped) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_xmit_more) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_wqe_err) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_mpwqe_filler) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_buff_alloc_err) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_cqe_compress_blks) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_cqe_compress_pkts) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_cache_reuse) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_cache_full) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_cache_empty) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_cache_busy) },
> - { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, link_down_events_phy) },
> -};
> -
> struct mlx5e_qcounter_stats {
> u32 rx_out_of_buffer;
> };
>
> -static const struct counter_desc q_stats_desc[] = {
> - { MLX5E_DECLARE_STAT(struct mlx5e_qcounter_stats, rx_out_of_buffer) },
> -};
>
> #define VPORT_COUNTER_OFF(c) MLX5_BYTE_OFF(query_vport_counter_out, c)
> #define VPORT_COUNTER_GET(vstats, c) MLX5_GET64(query_vport_counter_out, \
> @@ -140,48 +101,6 @@ struct mlx5e_vport_stats {
> __be64 query_vport_out[MLX5_ST_SZ_QW(query_vport_counter_out)];
> };
>
> -static const struct counter_desc vport_stats_desc[] = {
> - { "rx_vport_unicast_packets",
> - VPORT_COUNTER_OFF(received_eth_unicast.packets) },
> - { "rx_vport_unicast_bytes",
> - VPORT_COUNTER_OFF(received_eth_unicast.octets) },
> - { "tx_vport_unicast_packets",
> - VPORT_COUNTER_OFF(transmitted_eth_unicast.packets) },
> - { "tx_vport_unicast_bytes",
> - VPORT_COUNTER_OFF(transmitted_eth_unicast.octets) },
> - { "rx_vport_multicast_packets",
> - VPORT_COUNTER_OFF(received_eth_multicast.packets) },
> - { "rx_vport_multicast_bytes",
> - VPORT_COUNTER_OFF(received_eth_multicast.octets) },
> - { "tx_vport_multicast_packets",
> - VPORT_COUNTER_OFF(transmitted_eth_multicast.packets) },
> - { "tx_vport_multicast_bytes",
> - VPORT_COUNTER_OFF(transmitted_eth_multicast.octets) },
> - { "rx_vport_broadcast_packets",
> - VPORT_COUNTER_OFF(received_eth_broadcast.packets) },
> - { "rx_vport_broadcast_bytes",
> - VPORT_COUNTER_OFF(received_eth_broadcast.octets) },
> - { "tx_vport_broadcast_packets",
> - VPORT_COUNTER_OFF(transmitted_eth_broadcast.packets) },
> - { "tx_vport_broadcast_bytes",
> - VPORT_COUNTER_OFF(transmitted_eth_broadcast.octets) },
> - { "rx_vport_rdma_unicast_packets",
> - VPORT_COUNTER_OFF(received_ib_unicast.packets) },
> - { "rx_vport_rdma_unicast_bytes",
> - VPORT_COUNTER_OFF(received_ib_unicast.octets) },
> - { "tx_vport_rdma_unicast_packets",
> - VPORT_COUNTER_OFF(transmitted_ib_unicast.packets) },
> - { "tx_vport_rdma_unicast_bytes",
> - VPORT_COUNTER_OFF(transmitted_ib_unicast.octets) },
> - { "rx_vport_rdma_multicast_packets",
> - VPORT_COUNTER_OFF(received_ib_multicast.packets) },
> - { "rx_vport_rdma_multicast_bytes",
> - VPORT_COUNTER_OFF(received_ib_multicast.octets) },
> - { "tx_vport_rdma_multicast_packets",
> - VPORT_COUNTER_OFF(transmitted_ib_multicast.packets) },
> - { "tx_vport_rdma_multicast_bytes",
> - VPORT_COUNTER_OFF(transmitted_ib_multicast.octets) },
> -};
>
> #define PPORT_802_3_OFF(c) \
> MLX5_BYTE_OFF(ppcnt_reg, \
> @@ -224,69 +143,6 @@ struct mlx5e_pport_stats {
> __be64 phy_statistical_counters[MLX5_ST_SZ_QW(ppcnt_reg)];
> };
>
> -static const struct counter_desc pport_802_3_stats_desc[] = {
> - { "tx_packets_phy", PPORT_802_3_OFF(a_frames_transmitted_ok) },
> - { "rx_packets_phy", PPORT_802_3_OFF(a_frames_received_ok) },
> - { "rx_crc_errors_phy", PPORT_802_3_OFF(a_frame_check_sequence_errors) },
> - { "tx_bytes_phy", PPORT_802_3_OFF(a_octets_transmitted_ok) },
> - { "rx_bytes_phy", PPORT_802_3_OFF(a_octets_received_ok) },
> - { "tx_multicast_phy", PPORT_802_3_OFF(a_multicast_frames_xmitted_ok) },
> - { "tx_broadcast_phy", PPORT_802_3_OFF(a_broadcast_frames_xmitted_ok) },
> - { "rx_multicast_phy", PPORT_802_3_OFF(a_multicast_frames_received_ok) },
> - { "rx_broadcast_phy", PPORT_802_3_OFF(a_broadcast_frames_received_ok) },
> - { "rx_in_range_len_errors_phy", PPORT_802_3_OFF(a_in_range_length_errors) },
> - { "rx_out_of_range_len_phy", PPORT_802_3_OFF(a_out_of_range_length_field) },
> - { "rx_oversize_pkts_phy", PPORT_802_3_OFF(a_frame_too_long_errors) },
> - { "rx_symbol_err_phy", PPORT_802_3_OFF(a_symbol_error_during_carrier) },
> - { "tx_mac_control_phy", PPORT_802_3_OFF(a_mac_control_frames_transmitted) },
> - { "rx_mac_control_phy", PPORT_802_3_OFF(a_mac_control_frames_received) },
> - { "rx_unsupported_op_phy", PPORT_802_3_OFF(a_unsupported_opcodes_received) },
> - { "rx_pause_ctrl_phy", PPORT_802_3_OFF(a_pause_mac_ctrl_frames_received) },
> - { "tx_pause_ctrl_phy", PPORT_802_3_OFF(a_pause_mac_ctrl_frames_transmitted) },
> -};
> -
> -static const struct counter_desc pport_2863_stats_desc[] = {
> - { "rx_discards_phy", PPORT_2863_OFF(if_in_discards) },
> - { "tx_discards_phy", PPORT_2863_OFF(if_out_discards) },
> - { "tx_errors_phy", PPORT_2863_OFF(if_out_errors) },
> -};
> -
> -static const struct counter_desc pport_2819_stats_desc[] = {
> - { "rx_undersize_pkts_phy", PPORT_2819_OFF(ether_stats_undersize_pkts) },
> - { "rx_fragments_phy", PPORT_2819_OFF(ether_stats_fragments) },
> - { "rx_jabbers_phy", PPORT_2819_OFF(ether_stats_jabbers) },
> - { "rx_64_bytes_phy", PPORT_2819_OFF(ether_stats_pkts64octets) },
> - { "rx_65_to_127_bytes_phy", PPORT_2819_OFF(ether_stats_pkts65to127octets) },
> - { "rx_128_to_255_bytes_phy", PPORT_2819_OFF(ether_stats_pkts128to255octets) },
> - { "rx_256_to_511_bytes_phy", PPORT_2819_OFF(ether_stats_pkts256to511octets) },
> - { "rx_512_to_1023_bytes_phy", PPORT_2819_OFF(ether_stats_pkts512to1023octets) },
> - { "rx_1024_to_1518_bytes_phy", PPORT_2819_OFF(ether_stats_pkts1024to1518octets) },
> - { "rx_1519_to_2047_bytes_phy", PPORT_2819_OFF(ether_stats_pkts1519to2047octets) },
> - { "rx_2048_to_4095_bytes_phy", PPORT_2819_OFF(ether_stats_pkts2048to4095octets) },
> - { "rx_4096_to_8191_bytes_phy", PPORT_2819_OFF(ether_stats_pkts4096to8191octets) },
> - { "rx_8192_to_10239_bytes_phy", PPORT_2819_OFF(ether_stats_pkts8192to10239octets) },
> -};
> -
> -static const struct counter_desc pport_phy_statistical_stats_desc[] = {
> - { "rx_symbol_errors_phy", PPORT_PHY_STATISTICAL_OFF(phy_symbol_errors) },
> - { "rx_corrected_bits_phy", PPORT_PHY_STATISTICAL_OFF(phy_corrected_bits) },
> -};
> -
> -static const struct counter_desc pport_per_prio_traffic_stats_desc[] = {
> - { "rx_prio%d_bytes", PPORT_PER_PRIO_OFF(rx_octets) },
> - { "rx_prio%d_packets", PPORT_PER_PRIO_OFF(rx_frames) },
> - { "tx_prio%d_bytes", PPORT_PER_PRIO_OFF(tx_octets) },
> - { "tx_prio%d_packets", PPORT_PER_PRIO_OFF(tx_frames) },
> -};
> -
> -static const struct counter_desc pport_per_prio_pfc_stats_desc[] = {
> - /* %s is "global" or "prio{i}" */
> - { "rx_%s_pause", PPORT_PER_PRIO_OFF(rx_pause) },
> - { "rx_%s_pause_duration", PPORT_PER_PRIO_OFF(rx_pause_duration) },
> - { "tx_%s_pause", PPORT_PER_PRIO_OFF(tx_pause) },
> - { "tx_%s_pause_duration", PPORT_PER_PRIO_OFF(tx_pause_duration) },
> - { "rx_%s_pause_transition", PPORT_PER_PRIO_OFF(rx_pause_transition) },
> -};
>
> #define PCIE_PERF_OFF(c) \
> MLX5_BYTE_OFF(mpcnt_reg, counter_set.pcie_perf_cntrs_grp_data_layout.c)
> @@ -298,11 +154,6 @@ struct mlx5e_pcie_stats {
> __be64 pcie_perf_counters[MLX5_ST_SZ_QW(mpcnt_reg)];
> };
>
> -static const struct counter_desc pcie_perf_stats_desc[] = {
> - { "rx_pci_signal_integrity", PCIE_PERF_OFF(rx_errors) },
> - { "tx_pci_signal_integrity", PCIE_PERF_OFF(tx_errors) },
> -};
> -
> struct mlx5e_rq_stats {
> u64 packets;
> u64 bytes;
> @@ -325,28 +176,6 @@ struct mlx5e_rq_stats {
> u64 cache_busy;
> };
>
> -static const struct counter_desc rq_stats_desc[] = {
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, packets) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, bytes) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, csum_complete) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, csum_unnecessary_inner) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, csum_none) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, xdp_drop) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, xdp_tx) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, xdp_tx_full) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, lro_packets) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, lro_bytes) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, wqe_err) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, mpwqe_filler) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, buff_alloc_err) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, cqe_compress_blks) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, cqe_compress_pkts) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, cache_reuse) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, cache_full) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, cache_empty) },
> - { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, cache_busy) },
> -};
> -
> struct mlx5e_sq_stats {
> /* commonly accessed in data path */
> u64 packets;
> @@ -365,22 +194,6 @@ struct mlx5e_sq_stats {
> u64 dropped;
> };
>
> -static const struct counter_desc sq_stats_desc[] = {
> - { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, packets) },
> - { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, bytes) },
> - { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, tso_packets) },
> - { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, tso_bytes) },
> - { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, tso_inner_packets) },
> - { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, tso_inner_bytes) },
> - { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, csum_partial_inner) },
> - { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, nop) },
> - { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, csum_none) },
> - { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, stopped) },
> - { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, wake) },
> - { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, dropped) },
> - { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, xmit_more) },
> -};
> -
> #define NUM_SW_COUNTERS ARRAY_SIZE(sw_stats_desc)
> #define NUM_Q_COUNTERS ARRAY_SIZE(q_stats_desc)
> #define NUM_VPORT_COUNTERS ARRAY_SIZE(vport_stats_desc)
> @@ -416,21 +229,4 @@ struct mlx5e_stats {
> struct mlx5e_pcie_stats pcie;
> };
>
> -static const struct counter_desc mlx5e_pme_status_desc[] = {
> - { "module_plug", 0 },
> - { "module_unplug", 8 },
> -};
> -
> -static const struct counter_desc mlx5e_pme_error_desc[] = {
> - { "module_pwr_budget_exd", 0 }, /* power budget exceed */
> - { "module_long_range", 8 }, /* long range for non MLNX cable */
> - { "module_bus_stuck", 16 }, /* bus stuck (I2C or data shorted) */
> - { "module_no_eeprom", 24 }, /* no eeprom/retry time out */
> - { "module_enforce_part", 32 }, /* enforce part number list */
> - { "module_unknown_id", 40 }, /* unknown identifier */
> - { "module_high_temp", 48 }, /* high temperature */
> - { "module_bad_shorted", 56 }, /* bad or shorted cable/module */
> - { "module_unknown_status", 64 },
> -};
> -
> #endif /* __MLX5_EN_STATS_H__ */
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] change the default Kconfig value of mlx5_en
From: Ian Kumlien @ 2017-04-22 0:47 UTC (permalink / raw)
To: Saeed Mahameed
Cc: David Miller, Saeed Mahameed, Linux Kernel Network Developers
In-Reply-To: <CALzJLG9cLY8qqjFHGx6i=Gi-TH5EZ2Mq+TQOusX7=EoRDvx1tw@mail.gmail.com>
On Sat, Apr 22, 2017 at 2:34 AM, Saeed Mahameed
<saeedm@dev.mellanox.co.il> wrote:
> On Sat, Apr 22, 2017 at 2:10 AM, Ian Kumlien <ian.kumlien@gmail.com> wrote:
>> Sorry,
>>
>> Back again, fighting cold, hot whiskey has been consumed...
>>
>> Something like this would perhaps be a better solution:
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
>> b/drivers/net/ethernet/mellanox/mlx5/core/main.c
>> index 60154a175bd3..fe192e247601 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
>> @@ -1139,6 +1139,10 @@ static int mlx5_load_one(struct mlx5_core_dev
>> *dev, struct mlx5_priv *priv,
>>
>> #ifdef CONFIG_MLX5_CORE_EN
>> mlx5_eswitch_attach(dev->priv.eswitch);
>> +#else
>> + if (MLX5_CAP_GEN(dev, port_type) == MLX5_CAP_PORT_TYPE_ETH) {
>> + dev_info(&pdev->dev, "Ethernet device discovered but
>> support not enabled in kernel.");
>> + }
>> #endif
>>
>
> Currently both MLX5_CORE=n and MLX5_CORE_EN=n as a default, the issue
> you are seeing can occur only if you explicitly set MLX5_CORE=y and
> MLX5_CORE=n, Why would someone do this if he knows he wants Ethernet
> support as well ? IMHO this print is redundant .
Well, I'm running a prebuilt kernel - which was configured this way,
and since there
is no mlx5_en module and it does state that the link is "Ethernet", it
just looks like the
driver is broken or in some kind of really weird state.
> Anyway, Are you looking for RDMA support over ethernet (RoCE) ? and
> you are not interested to have ethernet netdev support ?
? RDMA is something we'll look at in the future, right now, having the
nics actually
work as nics is a priority ;)
> if yes, I think this is something that can be achieved, but the
> question is do we really need this ?
It's really weird to see the driver load, to see everything register
and have no feedback.
Including no network devices, but if you run the Infiniband commands,
they tell you that
you are connected to Ethernet but that the device is down and disabled.
To me, down and disabled is not the same as in "Ethernet support is
not included" =)
Basically, i would hate for someone else to end up in the same
situation since you only
get guides on how to enable infiniband/RDMA but what you really want
to do at that point
is to disable it and see if that gives you your network devices back =)
I have had similar issues with some connectx3 devices while playing at
home but i suspect
that it's just a limitation of OFED packages available for the dist I'm running.
^ permalink raw reply
* Re: [PATCH net-next v2 1/5] nfp: make use of the DMA_ATTR_SKIP_CPU_SYNC attribute
From: Jakub Kicinski @ 2017-04-22 0:36 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Jakub Kicinski
In-Reply-To: <20170421192310.193875-2-jakub.kicinski@netronome.com>
On Fri, 21 Apr 2017 12:23:06 -0700, Jakub Kicinski wrote:
> DMA unmap may destroy changes CPU made to the buffer. To make XDP
> run correctly on non-x86 platforms we should use the
> DMA_ATTR_SKIP_CPU_SYNC attribute.
>
> Thanks to using the attribute we can now push the sync operation to the
> common code path from XDP handler.
>
> A little bit of variable name reshuffling is required to bring the
> code back to readable state.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
I think I need to add the sync for device after XDP DROP as well.
Please drop this series, I'll send v3, sorry.
^ permalink raw reply
* Re: [PATCH 3/4] net: phy: realtek: add disable RX delay hack for RTL8211E
From: Florian Fainelli @ 2017-04-22 0:35 UTC (permalink / raw)
To: Icenowy Zheng, Andrew Lunn, Rob Herring
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170421232436.10924-4-icenowy-h8G6r0blFSE@public.gmane.org>
On 04/21/2017 04:24 PM, Icenowy Zheng wrote:
> From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>
> Some RTL8211E chips have broken GbE function, which needs a hack to
> fix. It's said that this fix will affect the performance on not-buggy
> PHYs, so it should only be enabled on boards with the broken PHY.
> Currently only some Pine64+ boards are known to have this issue.
>
> This hack is said to disable RX relay for RTL8211E according to Realtek.
>
> Enable this hack when a certain device tree property is set.
>
> As this hack is not documented on the datasheet at all, it contains
> magic numbers, and could not be revealed. These magic numbers are
> received from Realtek via Pine64.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
> drivers/net/phy/realtek.c | 36 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> index d820d00addf6..880022160cd2 100644
> --- a/drivers/net/phy/realtek.c
> +++ b/drivers/net/phy/realtek.c
> @@ -13,6 +13,7 @@
> * option) any later version.
> *
> */
> +#include <linux/of.h>
> #include <linux/phy.h>
> #include <linux/module.h>
>
> @@ -26,6 +27,8 @@
> #define RTL8211_PAGE_SELECT 0x1f
>
> #define RTL8211E_INER_LINK_STATUS 0x400
> +#define RTL8211E_EXT_PAGE_SELECT 0x1e
> +#define RTL8211E_EXT_PAGE 0x7
>
> #define RTL8211F_INER_LINK_STATUS 0x0010
> #define RTL8211F_INSR 0x1d
> @@ -121,6 +124,38 @@ static int rtl8211f_config_init(struct phy_device *phydev)
> return 0;
> }
>
> +static int rtl8211e_config_init(struct phy_device *phydev)
> +{
> + struct device *dev = &phydev->mdio.dev;
> + struct device_node *of_node = dev->of_node;
> + int ret;
> +
> + ret = genphy_config_init(phydev);
> + if (ret < 0)
> + return ret;
> +
> + if (of_node &&
> + of_property_read_bool(of_node, "realtek,disable-rx-delay")) {
> + /* All these magic numbers are retrieved from Pine64, and
> + * they're said to be originated from Realtek.
> + *
> + * The datasheet of RTL8211E didn't cover this ext page.
> + *
> + * Select extension page 0xa4 here.
> + */
> + phy_write(phydev, RTL8211_PAGE_SELECT, RTL8211E_EXT_PAGE)
> + phy_write(phydev, RTL8211E_EXT_PAGE_SELECT, 0xa4);
> +
> + /* Write the magic number */
> + phy_write(phydev, 0x1c, 0xb591);
> +
> + /* Restore to default page 0 */
> + phy_write(phydev, RTL8211_PAGE_SELECT, 0);
> + }
The code itself is probably fine, but the way you are checking whether
the RX delay should be disabled is not. As mentioned in patch 2, using
the correct "phy-mode" property would translate in the proper
phydev->interface value here (presumably PHY_INTERFACE_MODE_RGMII_TXID)
is that you want here that would allow you to check whether the RX delay
should, or should not be disabled.
Thank you
--
Florian
^ permalink raw reply
* Re: [RFC] change the default Kconfig value of mlx5_en
From: Saeed Mahameed @ 2017-04-22 0:34 UTC (permalink / raw)
To: Ian Kumlien; +Cc: David Miller, Saeed Mahameed, Linux Kernel Network Developers
In-Reply-To: <CAA85sZtr3N3Y8=R5qZHDTMgquV35ddw0x45qy8Kkf_tiVdu8ag@mail.gmail.com>
On Sat, Apr 22, 2017 at 2:10 AM, Ian Kumlien <ian.kumlien@gmail.com> wrote:
> Sorry,
>
> Back again, fighting cold, hot whiskey has been consumed...
>
> Something like this would perhaps be a better solution:
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> index 60154a175bd3..fe192e247601 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> @@ -1139,6 +1139,10 @@ static int mlx5_load_one(struct mlx5_core_dev
> *dev, struct mlx5_priv *priv,
>
> #ifdef CONFIG_MLX5_CORE_EN
> mlx5_eswitch_attach(dev->priv.eswitch);
> +#else
> + if (MLX5_CAP_GEN(dev, port_type) == MLX5_CAP_PORT_TYPE_ETH) {
> + dev_info(&pdev->dev, "Ethernet device discovered but
> support not enabled in kernel.");
> + }
> #endif
>
Currently both MLX5_CORE=n and MLX5_CORE_EN=n as a default, the issue
you are seeing can occur only if you explicitly set MLX5_CORE=y and
MLX5_CORE=n, Why would someone do this if he knows he wants Ethernet
support as well ? IMHO this print is redundant .
Anyway, Are you looking for RDMA support over ethernet (RoCE) ? and
you are not interested to have ethernet netdev support ?
if yes, I think this is something that can be achieved, but the
question is do we really need this ?
^ permalink raw reply
* Re: [PATCH net v3] net/mlx5e: Fix race in mlx5e_sw_stats and mlx5e_vport_stats
From: Saeed Mahameed @ 2017-04-22 0:24 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Linux Netdev List, Saeed Mahameed, Eric Dumazet, Kernel Team
In-Reply-To: <20170421044012.1955130-1-kafai@fb.com>
On Fri, Apr 21, 2017 at 7:40 AM, Martin KaFai Lau <kafai@fb.com> wrote:
> We have observed a sudden spike in rx/tx_packets and rx/tx_bytes
> reported under /proc/net/dev. There is a race in mlx5e_update_stats()
> and some of the get-stats functions (the one that we hit is the
> mlx5e_get_stats() which is called by ndo_get_stats64()).
>
> In particular, the very first thing mlx5e_update_sw_counters()
> does is 'memset(s, 0, sizeof(*s))'. For example, if mlx5e_get_stats()
> is unlucky at one point, rx_bytes and rx_packets could be 0. One second
> later, a normal (and much bigger than 0) value will be reported.
>
> This patch is to use a 'struct mlx5e_sw_stats temp' to avoid
> a direct memset zero on priv->stats.sw.
>
> mlx5e_update_vport_counters() has a similar race. Hence, addressed
> together. However, memset zero is removed instead because
> it is not needed.
>
> I am lucky enough to catch this 0-reset in rx multicast:
> eth0: 41457665 76804 70 0 0 70 0 47085 15586634 87502 3 0 0 0 3 0
> eth0: 41459860 76815 70 0 0 70 0 47094 15588376 87516 3 0 0 0 3 0
> eth0: 41460577 76822 70 0 0 70 0 0 15589083 87521 3 0 0 0 3 0
> eth0: 41463293 76838 70 0 0 70 0 47108 15595872 87538 3 0 0 0 3 0
> eth0: 41463379 76839 70 0 0 70 0 47116 15596138 87539 3 0 0 0 3 0
>
> v2: Remove memset zero from mlx5e_update_vport_counters()
> v1: Use temp and memcpy
>
> Fixes: 9218b44dcc05 ("net/mlx5e: Statistics handling refactoring")
> Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
> Suggested-by: Saeed Mahameed <saeedm@mellanox.com>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> ---
Thank you Martin and Eric for the fix, we will follow up with the
spinlock fix soon.
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: add binding for RTL8211E Ethernet PHY
From: Florian Fainelli @ 2017-04-22 0:22 UTC (permalink / raw)
To: Icenowy Zheng, Andrew Lunn, Rob Herring
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170421232436.10924-3-icenowy-h8G6r0blFSE@public.gmane.org>
On 04/21/2017 04:24 PM, Icenowy Zheng wrote:
> From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>
> Some RTL8211E Ethernet PHY have an issue that needs a workaround
> indicated with device tree.
>
> Add the binding for a property that indicates this workaround.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
> .../devicetree/bindings/net/realtek,rtl8211e.txt | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>
> diff --git a/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
> new file mode 100644
> index 000000000000..c1913301bfe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
> @@ -0,0 +1,22 @@
> +Realtek RTL8211E Ethernet PHY
> +
> +One batch of RTL8211E is slight broken, that needs some special (and
> +full of magic numbers) tweaking in order to make GbE to operate properly.
> +The only well-known board that used the broken batch is Pine64+.
> +Configure it through an Ethernet OF device node.
> +
> +Optional properties:
> +
> +- realtek,disable-rx-delay:
> + If set, RX delay will be completely disabled (according to Realtek). This
> + will affect the performance on non-broken boards.
> + default: do not disable RX delay.
Please don't introduce custom properties to do that, instead correct
specify the "phy-mode" such that it is e.g: "rgmii-txid" which indicates
that there should be no RX internal delay, but a TX internal delay added
by the PHY.
--
Florian
^ permalink raw reply
* [PATCH 2/2] drivers:net:ethernet:3com:3c512: array char instead of char pointer
From: Karim Eshapa @ 2017-04-22 0:17 UTC (permalink / raw)
To: davem; +Cc: jarod, felipe.balbi, a, fw, tglx, netdev, linux-kernel,
Karim Eshapa
char pointer creates two variables static string and pointer to it
according to Jeff Garzik janitors TODO
Signed-off-by: Karim Eshapa <karim.eshapa@gmail.com>
---
drivers/net/ethernet/3com/3c515.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/3com/3c515.c b/drivers/net/ethernet/3com/3c515.c
index e7b1fa5..29b8ddd 100644
--- a/drivers/net/ethernet/3com/3c515.c
+++ b/drivers/net/ethernet/3com/3c515.c
@@ -26,7 +26,7 @@
#define DRV_VERSION "0.99t-ac"
#define DRV_RELDATE "28-Oct-2002"
-static char *version =
+static char version[] =
DRV_NAME ".c:v" DRV_VERSION " " DRV_RELDATE " becker@scyld.com and others\n";
#define CORKSCREW 1
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 5/5] bnxt_en: Restrict a PF in Multi-Host mode from changing port PHY configuration
From: Michael Chan @ 2017-04-22 0:11 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1492819886-19625-1-git-send-email-michael.chan@broadcom.com>
From: Deepak Khungar <deepak.khungar@broadcom.com>
This change restricts the PF in multi-host mode from setting any port
level PHY configuration. The settings are controlled by firmware in
Multi-Host mode.
Signed-off-by: Deepak Khungar <deepak.khungar@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 13 +++++++++----
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 4 +++-
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 9130628..b3ba660 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -4482,10 +4482,15 @@ static int bnxt_hwrm_func_qcfg(struct bnxt *bp)
vf->vlan = le16_to_cpu(resp->vlan) & VLAN_VID_MASK;
}
#endif
- if (BNXT_PF(bp) && (le16_to_cpu(resp->flags) &
- (FUNC_QCFG_RESP_FLAGS_FW_DCBX_AGENT_ENABLED |
- FUNC_QCFG_RESP_FLAGS_FW_LLDP_AGENT_ENABLED)))
- bp->flags |= BNXT_FLAG_FW_LLDP_AGENT;
+ if (BNXT_PF(bp)) {
+ u16 flags = le16_to_cpu(resp->flags);
+
+ if (flags & (FUNC_QCFG_RESP_FLAGS_FW_DCBX_AGENT_ENABLED |
+ FUNC_QCFG_RESP_FLAGS_FW_LLDP_AGENT_ENABLED))
+ bp->flags |= BNXT_FLAG_FW_LLDP_AGENT;
+ if (flags & FUNC_QCFG_RESP_FLAGS_MULTI_HOST)
+ bp->flags |= BNXT_FLAG_MULTI_HOST;
+ }
switch (resp->port_partition_type) {
case FUNC_QCFG_RESP_PORT_PARTITION_TYPE_NPAR1_0:
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index 25fef61..3ef42db 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -1005,6 +1005,7 @@ struct bnxt {
#define BNXT_FLAG_NO_AGG_RINGS 0x20000
#define BNXT_FLAG_RX_PAGE_MODE 0x40000
#define BNXT_FLAG_FW_LLDP_AGENT 0x80000
+ #define BNXT_FLAG_MULTI_HOST 0x100000
#define BNXT_FLAG_CHIP_NITRO_A0 0x1000000
#define BNXT_FLAG_ALL_CONFIG_FEATS (BNXT_FLAG_TPA | \
@@ -1014,7 +1015,8 @@ struct bnxt {
#define BNXT_PF(bp) (!((bp)->flags & BNXT_FLAG_VF))
#define BNXT_VF(bp) ((bp)->flags & BNXT_FLAG_VF)
#define BNXT_NPAR(bp) ((bp)->port_partition_type)
-#define BNXT_SINGLE_PF(bp) (BNXT_PF(bp) && !BNXT_NPAR(bp))
+#define BNXT_MH(bp) ((bp)->flags & BNXT_FLAG_MULTI_HOST)
+#define BNXT_SINGLE_PF(bp) (BNXT_PF(bp) && !BNXT_NPAR(bp) && !BNXT_MH(bp))
#define BNXT_CHIP_TYPE_NITRO_A0(bp) ((bp)->flags & BNXT_FLAG_CHIP_NITRO_A0)
#define BNXT_RX_PAGE_MODE(bp) ((bp)->flags & BNXT_FLAG_RX_PAGE_MODE)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 4/5] bnxt_en: Check the FW_LLDP_AGENT flag before allowing DCBX host agent.
From: Michael Chan @ 2017-04-22 0:11 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1492819886-19625-1-git-send-email-michael.chan@broadcom.com>
Check the additional flag in bnxt_hwrm_func_qcfg() before allowing
DCBX to be done in host mode.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 447ee3d..9130628 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -4483,7 +4483,8 @@ static int bnxt_hwrm_func_qcfg(struct bnxt *bp)
}
#endif
if (BNXT_PF(bp) && (le16_to_cpu(resp->flags) &
- FUNC_QCFG_RESP_FLAGS_FW_DCBX_AGENT_ENABLED))
+ (FUNC_QCFG_RESP_FLAGS_FW_DCBX_AGENT_ENABLED |
+ FUNC_QCFG_RESP_FLAGS_FW_LLDP_AGENT_ENABLED)))
bp->flags |= BNXT_FLAG_FW_LLDP_AGENT;
switch (resp->port_partition_type) {
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 3/5] bnxt_en: Add 100G link speed reporting for BCM57454 ASIC in ethtool
From: Michael Chan @ 2017-04-22 0:11 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1492819886-19625-1-git-send-email-michael.chan@broadcom.com>
From: Deepak Khungar <deepak.khungar@broadcom.com>
Added support for 100G link speed reporting for Broadcom BCM57454
ASIC in ethtool command.
Signed-off-by: Deepak Khungar <deepak.khungar@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 5 +++--
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 2 ++
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 14 +++++++++++++-
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 129b810..447ee3d 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -5471,7 +5471,8 @@ static void bnxt_report_link(struct bnxt *bp)
if (bp->link_info.link_up) {
const char *duplex;
const char *flow_ctrl;
- u16 speed, fec;
+ u32 speed;
+ u16 fec;
netif_carrier_on(bp->dev);
if (bp->link_info.duplex == BNXT_LINK_DUPLEX_FULL)
@@ -5487,7 +5488,7 @@ static void bnxt_report_link(struct bnxt *bp)
else
flow_ctrl = "none";
speed = bnxt_fw_to_ethtool_speed(bp->link_info.link_speed);
- netdev_info(bp->dev, "NIC Link is Up, %d Mbps %s duplex, Flow control: %s\n",
+ netdev_info(bp->dev, "NIC Link is Up, %u Mbps %s duplex, Flow control: %s\n",
speed, duplex, flow_ctrl);
if (bp->flags & BNXT_FLAG_EEE_CAP)
netdev_info(bp->dev, "EEE is %s\n",
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index c9a1688..25fef61 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -851,6 +851,7 @@ struct bnxt_link_info {
#define BNXT_LINK_SPEED_25GB PORT_PHY_QCFG_RESP_LINK_SPEED_25GB
#define BNXT_LINK_SPEED_40GB PORT_PHY_QCFG_RESP_LINK_SPEED_40GB
#define BNXT_LINK_SPEED_50GB PORT_PHY_QCFG_RESP_LINK_SPEED_50GB
+#define BNXT_LINK_SPEED_100GB PORT_PHY_QCFG_RESP_LINK_SPEED_100GB
u16 support_speeds;
u16 auto_link_speeds; /* fw adv setting */
#define BNXT_LINK_SPEED_MSK_100MB PORT_PHY_QCFG_RESP_SUPPORT_SPEEDS_100MB
@@ -862,6 +863,7 @@ struct bnxt_link_info {
#define BNXT_LINK_SPEED_MSK_25GB PORT_PHY_QCFG_RESP_SUPPORT_SPEEDS_25GB
#define BNXT_LINK_SPEED_MSK_40GB PORT_PHY_QCFG_RESP_SUPPORT_SPEEDS_40GB
#define BNXT_LINK_SPEED_MSK_50GB PORT_PHY_QCFG_RESP_SUPPORT_SPEEDS_50GB
+#define BNXT_LINK_SPEED_MSK_100GB PORT_PHY_QCFG_RESP_SUPPORT_SPEEDS_100GB
u16 support_auto_speeds;
u16 lp_auto_link_speeds;
u16 force_link_speed;
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
index 848ecf2..11ddf0a 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
@@ -929,6 +929,9 @@ u32 _bnxt_fw_to_ethtool_adv_spds(u16 fw_speeds, u8 fw_pause)
if ((fw_speeds) & BNXT_LINK_SPEED_MSK_50GB) \
ethtool_link_ksettings_add_link_mode(lk_ksettings, name,\
50000baseCR2_Full);\
+ if ((fw_speeds) & BNXT_LINK_SPEED_MSK_100GB) \
+ ethtool_link_ksettings_add_link_mode(lk_ksettings, name,\
+ 100000baseCR4_Full);\
if ((fw_pause) & BNXT_LINK_PAUSE_RX) { \
ethtool_link_ksettings_add_link_mode(lk_ksettings, name,\
Pause); \
@@ -965,6 +968,9 @@ u32 _bnxt_fw_to_ethtool_adv_spds(u16 fw_speeds, u8 fw_pause)
if (ethtool_link_ksettings_test_link_mode(lk_ksettings, name, \
50000baseCR2_Full)) \
(fw_speeds) |= BNXT_LINK_SPEED_MSK_50GB; \
+ if (ethtool_link_ksettings_test_link_mode(lk_ksettings, name, \
+ 100000baseCR4_Full)) \
+ (fw_speeds) |= BNXT_LINK_SPEED_MSK_100GB; \
}
static void bnxt_fw_to_ethtool_advertised_spds(struct bnxt_link_info *link_info,
@@ -1027,6 +1033,8 @@ u32 bnxt_fw_to_ethtool_speed(u16 fw_link_speed)
return SPEED_40000;
case BNXT_LINK_SPEED_50GB:
return SPEED_50000;
+ case BNXT_LINK_SPEED_100GB:
+ return SPEED_100000;
default:
return SPEED_UNKNOWN;
}
@@ -1092,7 +1100,7 @@ static int bnxt_get_link_ksettings(struct net_device *dev,
return 0;
}
-static u32 bnxt_get_fw_speed(struct net_device *dev, u16 ethtool_speed)
+static u32 bnxt_get_fw_speed(struct net_device *dev, u32 ethtool_speed)
{
struct bnxt *bp = netdev_priv(dev);
struct bnxt_link_info *link_info = &bp->link_info;
@@ -1132,6 +1140,10 @@ static u32 bnxt_get_fw_speed(struct net_device *dev, u16 ethtool_speed)
if (support_spds & BNXT_LINK_SPEED_MSK_50GB)
fw_speed = PORT_PHY_CFG_REQ_AUTO_LINK_SPEED_50GB;
break;
+ case SPEED_100000:
+ if (support_spds & BNXT_LINK_SPEED_MSK_100GB)
+ fw_speed = PORT_PHY_CFG_REQ_AUTO_LINK_SPEED_100GB;
+ break;
default:
netdev_err(dev, "unsupported speed!\n");
break;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 2/5] bnxt_en: Fix VF attributes reporting.
From: Michael Chan @ 2017-04-22 0:11 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1492819886-19625-1-git-send-email-michael.chan@broadcom.com>
The .ndo_get_vf_config() is returning the wrong qos attribute. Fix
the code that checks and reports the qos and spoofchk attributes. The
BNXT_VF_QOS and BNXT_VF_LINK_UP flags should not be set by default
during init. time.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
index f893531..b8e7248 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
@@ -138,8 +138,11 @@ int bnxt_get_vf_config(struct net_device *dev, int vf_id,
ivi->max_tx_rate = vf->max_tx_rate;
ivi->min_tx_rate = vf->min_tx_rate;
ivi->vlan = vf->vlan;
- ivi->qos = vf->flags & BNXT_VF_QOS;
- ivi->spoofchk = vf->flags & BNXT_VF_SPOOFCHK;
+ if (vf->flags & BNXT_VF_QOS)
+ ivi->qos = vf->vlan >> VLAN_PRIO_SHIFT;
+ else
+ ivi->qos = 0;
+ ivi->spoofchk = !!(vf->flags & BNXT_VF_SPOOFCHK);
if (!(vf->flags & BNXT_VF_LINK_FORCED))
ivi->linkstate = IFLA_VF_LINK_STATE_AUTO;
else if (vf->flags & BNXT_VF_LINK_UP)
@@ -304,7 +307,6 @@ static int bnxt_set_vf_attr(struct bnxt *bp, int num_vfs)
for (i = 0; i < num_vfs; i++) {
vf = &bp->pf.vf[i];
memset(vf, 0, sizeof(*vf));
- vf->flags = BNXT_VF_QOS | BNXT_VF_LINK_UP;
}
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 1/5] bnxt_en: Pass DCB RoCE app priority to firmware.
From: Michael Chan @ 2017-04-22 0:11 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1492819886-19625-1-git-send-email-michael.chan@broadcom.com>
When the driver gets the RoCE app priority set/delete call through DCBNL,
the driver will send the information to the firmware to set up the
priority VLAN tag for RDMA traffic.
[ New version using the common ETH_P_IBOE constant in if_ether.h ]
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 108 +++++++++++++++++++++++++-
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h | 1 +
2 files changed, 108 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
index 03532061..46de2f8 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
@@ -1,6 +1,7 @@
/* Broadcom NetXtreme-C/E network driver.
*
* Copyright (c) 2014-2016 Broadcom Corporation
+ * Copyright (c) 2016-2017 Broadcom Limited
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -14,6 +15,7 @@
#include <linux/interrupt.h>
#include <linux/pci.h>
#include <linux/etherdevice.h>
+#include <rdma/ib_verbs.h>
#include "bnxt_hsi.h"
#include "bnxt.h"
#include "bnxt_dcb.h"
@@ -241,6 +243,92 @@ static int bnxt_hwrm_queue_pfc_qcfg(struct bnxt *bp, struct ieee_pfc *pfc)
return 0;
}
+static int bnxt_hwrm_set_dcbx_app(struct bnxt *bp, struct dcb_app *app,
+ bool add)
+{
+ struct hwrm_fw_set_structured_data_input set = {0};
+ struct hwrm_fw_get_structured_data_input get = {0};
+ struct hwrm_struct_data_dcbx_app *fw_app;
+ struct hwrm_struct_hdr *data;
+ dma_addr_t mapping;
+ size_t data_len;
+ int rc, n, i;
+
+ if (bp->hwrm_spec_code < 0x10601)
+ return 0;
+
+ n = IEEE_8021QAZ_MAX_TCS;
+ data_len = sizeof(*data) + sizeof(*fw_app) * n;
+ data = dma_alloc_coherent(&bp->pdev->dev, data_len, &mapping,
+ GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ memset(data, 0, data_len);
+ bnxt_hwrm_cmd_hdr_init(bp, &get, HWRM_FW_GET_STRUCTURED_DATA, -1, -1);
+ get.dest_data_addr = cpu_to_le64(mapping);
+ get.structure_id = cpu_to_le16(STRUCT_HDR_STRUCT_ID_DCBX_APP);
+ get.subtype = cpu_to_le16(HWRM_STRUCT_DATA_SUBTYPE_HOST_OPERATIONAL);
+ get.count = 0;
+ rc = hwrm_send_message(bp, &get, sizeof(get), HWRM_CMD_TIMEOUT);
+ if (rc)
+ goto set_app_exit;
+
+ fw_app = (struct hwrm_struct_data_dcbx_app *)(data + 1);
+
+ if (data->struct_id != cpu_to_le16(STRUCT_HDR_STRUCT_ID_DCBX_APP)) {
+ rc = -ENODEV;
+ goto set_app_exit;
+ }
+
+ n = data->count;
+ for (i = 0; i < n; i++, fw_app++) {
+ if (fw_app->protocol_id == cpu_to_be16(app->protocol) &&
+ fw_app->protocol_selector == app->selector &&
+ fw_app->priority == app->priority) {
+ if (add)
+ goto set_app_exit;
+ else
+ break;
+ }
+ }
+ if (add) {
+ /* append */
+ n++;
+ fw_app->protocol_id = cpu_to_be16(app->protocol);
+ fw_app->protocol_selector = app->selector;
+ fw_app->priority = app->priority;
+ fw_app->valid = 1;
+ } else {
+ size_t len = 0;
+
+ /* not found, nothing to delete */
+ if (n == i)
+ goto set_app_exit;
+
+ len = (n - 1 - i) * sizeof(*fw_app);
+ if (len)
+ memmove(fw_app, fw_app + 1, len);
+ n--;
+ memset(fw_app + n, 0, sizeof(*fw_app));
+ }
+ data->count = n;
+ data->len = cpu_to_le16(sizeof(*fw_app) * n);
+ data->subtype = cpu_to_le16(HWRM_STRUCT_DATA_SUBTYPE_HOST_OPERATIONAL);
+
+ bnxt_hwrm_cmd_hdr_init(bp, &set, HWRM_FW_SET_STRUCTURED_DATA, -1, -1);
+ set.src_data_addr = cpu_to_le64(mapping);
+ set.data_len = cpu_to_le16(sizeof(*data) + sizeof(*fw_app) * n);
+ set.hdr_cnt = 1;
+ rc = hwrm_send_message(bp, &set, sizeof(set), HWRM_CMD_TIMEOUT);
+ if (rc)
+ rc = -EIO;
+
+set_app_exit:
+ dma_free_coherent(&bp->pdev->dev, data_len, data, mapping);
+ return rc;
+}
+
static int bnxt_ets_validate(struct bnxt *bp, struct ieee_ets *ets, u8 *tc)
{
int total_ets_bw = 0;
@@ -417,6 +505,15 @@ static int bnxt_dcbnl_ieee_setapp(struct net_device *dev, struct dcb_app *app)
return -EINVAL;
rc = dcb_ieee_setapp(dev, app);
+ if (rc)
+ return rc;
+
+ if ((app->selector == IEEE_8021QAZ_APP_SEL_ETHERTYPE &&
+ app->protocol == ETH_P_IBOE) ||
+ (app->selector == IEEE_8021QAZ_APP_SEL_DGRAM &&
+ app->protocol == ROCE_V2_UDP_DPORT))
+ rc = bnxt_hwrm_set_dcbx_app(bp, app, true);
+
return rc;
}
@@ -425,10 +522,19 @@ static int bnxt_dcbnl_ieee_delapp(struct net_device *dev, struct dcb_app *app)
struct bnxt *bp = netdev_priv(dev);
int rc;
- if (!(bp->dcbx_cap & DCB_CAP_DCBX_VER_IEEE))
+ if (!(bp->dcbx_cap & DCB_CAP_DCBX_VER_IEEE) ||
+ !(bp->dcbx_cap & DCB_CAP_DCBX_HOST))
return -EINVAL;
rc = dcb_ieee_delapp(dev, app);
+ if (rc)
+ return rc;
+ if ((app->selector == IEEE_8021QAZ_APP_SEL_ETHERTYPE &&
+ app->protocol == ETH_P_IBOE) ||
+ (app->selector == IEEE_8021QAZ_APP_SEL_DGRAM &&
+ app->protocol == ROCE_V2_UDP_DPORT))
+ rc = bnxt_hwrm_set_dcbx_app(bp, app, false);
+
return rc;
}
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h
index 35a0d28..ecd0a5e 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h
@@ -1,6 +1,7 @@
/* Broadcom NetXtreme-C/E network driver.
*
* Copyright (c) 2014-2016 Broadcom Corporation
+ * Copyright (c) 2016-2017 Broadcom Limited
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 0/5] bnxt_en: Updates for net-next.
From: Michael Chan @ 2017-04-22 0:11 UTC (permalink / raw)
To: davem; +Cc: netdev
Miscellaneous updates include passing DCBX RoCE VLAN priority to firmware,
checking one more new firmware flag before allowing DCBX to run on the host,
adding 100Gbps speed support, adding check to disallow speed settings on
Multi-host NICs, and a minor fix for reporting VF attributes.
Deepak Khungar (2):
bnxt_en: Add 100G link speed reporting for BCM57454 ASIC in ethtool
bnxt_en: Restrict a PF in Multi-Host mode from changing port PHY
configuration
Michael Chan (3):
bnxt_en: Pass DCB RoCE app priority to firmware.
bnxt_en: Fix VF attributes reporting.
bnxt_en: Check the FW_LLDP_AGENT flag before allowing DCBX host agent.
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 17 +++-
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 2 +
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 108 +++++++++++++++++++++-
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h | 1 +
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 14 ++-
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 8 +-
6 files changed, 140 insertions(+), 10 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH 2/2] openvswitch: Add eventmask support to CT action.
From: Jarno Rajahalme @ 2017-04-21 23:49 UTC (permalink / raw)
To: Joe Stringer; +Cc: netdev
In-Reply-To: <CAPWQB7E6d-Czev+ya9GAzYkCumS16OMAXCiwxGC_RosA=igg_Q@mail.gmail.com>
Thanks Joe, I’ll issue a v2 with the comment fix and retain the acks, so it should be good to go.
Jarno
> On Apr 20, 2017, at 11:53 AM, Joe Stringer <joe@ovn.org> wrote:
>
> On 19 April 2017 at 18:49, Jarno Rajahalme <jarno@ovn.org> wrote:
>> Add a new optional conntrack action attribute OVS_CT_ATTR_EVENTMASK,
>> which can be used in conjunction with the commit flag
>> (OVS_CT_ATTR_COMMIT) to set the mask of bits specifying which
>> conntrack events (IPCT_*) should be delivered via the Netfilter
>> netlink multicast groups. Default behavior depends on the system
>> configuration, but typically a lot of events are delivered. This can be
>> very chatty for the NFNLGRP_CONNTRACK_UPDATE group, even if only some
>> types of events are of interest.
>>
>> Netfilter core init_conntrack() adds the event cache extension, so we
>> only need to set the ctmask value. However, if the system is
>> configured without support for events, the setting will be skipped due
>> to extension not being found.
>>
>> Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
>> ---
>
> Thanks Jarno, looks good overall. Minor nit in the API description below.
>
> Acked-by: Joe Stringer <joe@ovn.org>
>
>> include/uapi/linux/openvswitch.h | 12 ++++++++++++
>> net/openvswitch/conntrack.c | 27 +++++++++++++++++++++++++++
>> 2 files changed, 39 insertions(+)
>>
>> diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
>> index 66d1c3c..38ae95d 100644
>> --- a/include/uapi/linux/openvswitch.h
>> +++ b/include/uapi/linux/openvswitch.h
>> @@ -693,6 +693,17 @@ struct ovs_action_hash {
>> * nothing if the connection is already committed will check that the current
>> * packet is in conntrack entry's original direction. If directionality does
>> * not match, will delete the existing conntrack entry and commit a new one.
>> + * @OVS_CT_ATTR_EVENTMASK: Mask of bits indicating which conntrack event types
>> + * (enum ip_conntrack_events IPCT_*) should be reported. For any bit set to
>> + * zero, the corresponding event type is not generated. Default behavior
>> + * depends on system configuration, but typically all event types are
>> + * generated, hence listening on UPDATE events may get a lot of events.
>
> s/UPDATE/NFNLGRP_CONNTRACK_UPDATE/
>
>> + * Explicitly passing this attribute allows limiting the updates received to
>> + * the events of interest. The bit 1 << IPCT_NEW, 1 << IPCT_RELATED, and
>> + * 1 << IPCT_DESTROY must be set to ones for those events to be received on
>> + * NFNLGRP_CONNTRACK_NEW and NFNLGRP_CONNTRACK_DESTROY groups, respectively.
>> + * Remaining bits control the changes for which an event is delivered on the
>> + * NFNLGRP_CONNTRACK_UPDATE group.
>> */
>> enum ovs_ct_attr {
>> OVS_CT_ATTR_UNSPEC,
>> @@ -704,6 +715,7 @@ enum ovs_ct_attr {
>> related connections. */
>> OVS_CT_ATTR_NAT, /* Nested OVS_NAT_ATTR_* */
>> OVS_CT_ATTR_FORCE_COMMIT, /* No argument */
>> + OVS_CT_ATTR_EVENTMASK, /* u32 mask of IPCT_* events. */
>> __OVS_CT_ATTR_MAX
>> };
>>
>> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
>> index 58de4c2..4f7c3b5 100644
>> --- a/net/openvswitch/conntrack.c
>> +++ b/net/openvswitch/conntrack.c
>> @@ -66,7 +66,9 @@ struct ovs_conntrack_info {
>> u8 commit : 1;
>> u8 nat : 3; /* enum ovs_ct_nat */
>> u8 force : 1;
>> + u8 have_eventmask : 1;
>> u16 family;
>> + u32 eventmask; /* Mask of 1 << IPCT_*. */
>> struct md_mark mark;
>> struct md_labels labels;
>> #ifdef CONFIG_NF_NAT_NEEDED
>> @@ -1007,6 +1009,20 @@ static int ovs_ct_commit(struct net *net, struct sw_flow_key *key,
>> if (!ct)
>> return 0;
>>
>> + /* Set the conntrack event mask if given. NEW and DELETE events have
>> + * their own groups, but the NFNLGRP_CONNTRACK_UPDATE group listener
>> + * typically would receive many kinds of updates. Setting the event
>> + * mask allows those events to be filtered. The set event mask will
>> + * remain in effect for the lifetime of the connection unless changed
>> + * by a further CT action with both the commit flag and the eventmask
>> + * option. */
>> + if (info->have_eventmask) {
>> + struct nf_conntrack_ecache *cache = nf_ct_ecache_find(ct);
>> +
>> + if (cache)
>> + cache->ctmask = info->eventmask;
>> + }
>> +
>> /* Apply changes before confirming the connection so that the initial
>> * conntrack NEW netlink event carries the values given in the CT
>> * action.
>> @@ -1238,6 +1254,8 @@ static const struct ovs_ct_len_tbl ovs_ct_attr_lens[OVS_CT_ATTR_MAX + 1] = {
>> /* NAT length is checked when parsing the nested attributes. */
>> [OVS_CT_ATTR_NAT] = { .minlen = 0, .maxlen = INT_MAX },
>> #endif
>> + [OVS_CT_ATTR_EVENTMASK] = { .minlen = sizeof(u32),
>> + .maxlen = sizeof(u32) },
>> };
>>
>> static int parse_ct(const struct nlattr *attr, struct ovs_conntrack_info *info,
>> @@ -1316,6 +1334,11 @@ static int parse_ct(const struct nlattr *attr, struct ovs_conntrack_info *info,
>> break;
>> }
>> #endif
>> + case OVS_CT_ATTR_EVENTMASK:
>> + info->have_eventmask = true;
>> + info->eventmask = nla_get_u32(a);
>> + break;
>> +
>> default:
>> OVS_NLERR(log, "Unknown conntrack attr (%d)",
>> type);
>> @@ -1515,6 +1538,10 @@ int ovs_ct_action_to_attr(const struct ovs_conntrack_info *ct_info,
>> ct_info->helper->name))
>> return -EMSGSIZE;
>> }
>> + if (ct_info->have_eventmask &&
>> + nla_put_u32(skb, OVS_CT_ATTR_EVENTMASK, ct_info->eventmask))
>> + return -EMSGSIZE;
>> +
>> #ifdef CONFIG_NF_NAT_NEEDED
>> if (ct_info->nat && !ovs_ct_nat_to_attr(ct_info, skb))
>> return -EMSGSIZE;
>> --
>> 2.1.4
^ permalink raw reply
* [PATCH net-next v2 2/2] openvswitch: Add eventmask support to CT action.
From: Jarno Rajahalme @ 2017-04-21 23:48 UTC (permalink / raw)
To: netdev; +Cc: jarno
In-Reply-To: <1492818486-57292-1-git-send-email-jarno@ovn.org>
Add a new optional conntrack action attribute OVS_CT_ATTR_EVENTMASK,
which can be used in conjunction with the commit flag
(OVS_CT_ATTR_COMMIT) to set the mask of bits specifying which
conntrack events (IPCT_*) should be delivered via the Netfilter
netlink multicast groups. Default behavior depends on the system
configuration, but typically a lot of events are delivered. This can be
very chatty for the NFNLGRP_CONNTRACK_UPDATE group, even if only some
types of events are of interest.
Netfilter core init_conntrack() adds the event cache extension, so we
only need to set the ctmask value. However, if the system is
configured without support for events, the setting will be skipped due
to extension not being found.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Reviewed-by: Greg Rose <gvrose8192@gmail.com>
Acked-by: Joe Stringer <joe@ovn.org>
---
include/uapi/linux/openvswitch.h | 12 ++++++++++++
net/openvswitch/conntrack.c | 27 +++++++++++++++++++++++++++
2 files changed, 39 insertions(+)
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 66d1c3c..61b7d36 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -693,6 +693,17 @@ struct ovs_action_hash {
* nothing if the connection is already committed will check that the current
* packet is in conntrack entry's original direction. If directionality does
* not match, will delete the existing conntrack entry and commit a new one.
+ * @OVS_CT_ATTR_EVENTMASK: Mask of bits indicating which conntrack event types
+ * (enum ip_conntrack_events IPCT_*) should be reported. For any bit set to
+ * zero, the corresponding event type is not generated. Default behavior
+ * depends on system configuration, but typically all event types are
+ * generated, hence listening on NFNLGRP_CONNTRACK_UPDATE events may get a lot
+ * of events. Explicitly passing this attribute allows limiting the updates
+ * received to the events of interest. The bit 1 << IPCT_NEW, 1 <<
+ * IPCT_RELATED, and 1 << IPCT_DESTROY must be set to ones for those events to
+ * be received on NFNLGRP_CONNTRACK_NEW and NFNLGRP_CONNTRACK_DESTROY groups,
+ * respectively. Remaining bits control the changes for which an event is
+ * delivered on the NFNLGRP_CONNTRACK_UPDATE group.
*/
enum ovs_ct_attr {
OVS_CT_ATTR_UNSPEC,
@@ -704,6 +715,7 @@ enum ovs_ct_attr {
related connections. */
OVS_CT_ATTR_NAT, /* Nested OVS_NAT_ATTR_* */
OVS_CT_ATTR_FORCE_COMMIT, /* No argument */
+ OVS_CT_ATTR_EVENTMASK, /* u32 mask of IPCT_* events. */
__OVS_CT_ATTR_MAX
};
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 58de4c2..4f7c3b5 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -66,7 +66,9 @@ struct ovs_conntrack_info {
u8 commit : 1;
u8 nat : 3; /* enum ovs_ct_nat */
u8 force : 1;
+ u8 have_eventmask : 1;
u16 family;
+ u32 eventmask; /* Mask of 1 << IPCT_*. */
struct md_mark mark;
struct md_labels labels;
#ifdef CONFIG_NF_NAT_NEEDED
@@ -1007,6 +1009,20 @@ static int ovs_ct_commit(struct net *net, struct sw_flow_key *key,
if (!ct)
return 0;
+ /* Set the conntrack event mask if given. NEW and DELETE events have
+ * their own groups, but the NFNLGRP_CONNTRACK_UPDATE group listener
+ * typically would receive many kinds of updates. Setting the event
+ * mask allows those events to be filtered. The set event mask will
+ * remain in effect for the lifetime of the connection unless changed
+ * by a further CT action with both the commit flag and the eventmask
+ * option. */
+ if (info->have_eventmask) {
+ struct nf_conntrack_ecache *cache = nf_ct_ecache_find(ct);
+
+ if (cache)
+ cache->ctmask = info->eventmask;
+ }
+
/* Apply changes before confirming the connection so that the initial
* conntrack NEW netlink event carries the values given in the CT
* action.
@@ -1238,6 +1254,8 @@ static const struct ovs_ct_len_tbl ovs_ct_attr_lens[OVS_CT_ATTR_MAX + 1] = {
/* NAT length is checked when parsing the nested attributes. */
[OVS_CT_ATTR_NAT] = { .minlen = 0, .maxlen = INT_MAX },
#endif
+ [OVS_CT_ATTR_EVENTMASK] = { .minlen = sizeof(u32),
+ .maxlen = sizeof(u32) },
};
static int parse_ct(const struct nlattr *attr, struct ovs_conntrack_info *info,
@@ -1316,6 +1334,11 @@ static int parse_ct(const struct nlattr *attr, struct ovs_conntrack_info *info,
break;
}
#endif
+ case OVS_CT_ATTR_EVENTMASK:
+ info->have_eventmask = true;
+ info->eventmask = nla_get_u32(a);
+ break;
+
default:
OVS_NLERR(log, "Unknown conntrack attr (%d)",
type);
@@ -1515,6 +1538,10 @@ int ovs_ct_action_to_attr(const struct ovs_conntrack_info *ct_info,
ct_info->helper->name))
return -EMSGSIZE;
}
+ if (ct_info->have_eventmask &&
+ nla_put_u32(skb, OVS_CT_ATTR_EVENTMASK, ct_info->eventmask))
+ return -EMSGSIZE;
+
#ifdef CONFIG_NF_NAT_NEEDED
if (ct_info->nat && !ovs_ct_nat_to_attr(ct_info, skb))
return -EMSGSIZE;
--
2.1.4
^ permalink raw reply related
* [PATCH net-next v2 1/2] openvswitch: Typo fix.
From: Jarno Rajahalme @ 2017-04-21 23:48 UTC (permalink / raw)
To: netdev; +Cc: jarno
Fix typo in a comment.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Greg Rose <gvrose8192@gmail.com>
---
net/openvswitch/conntrack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 7b2c2fc..58de4c2 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -373,7 +373,7 @@ static int ovs_ct_init_labels(struct nf_conn *ct, struct sw_flow_key *key,
}
/* Labels are included in the IPCTNL_MSG_CT_NEW event only if the
- * IPCT_LABEL bit it set in the event cache.
+ * IPCT_LABEL bit is set in the event cache.
*/
nf_conntrack_event_cache(IPCT_LABEL, ct);
--
2.1.4
^ permalink raw reply related
* [PATCH net] net: ipv6: regenerate host route if moved to gc list
From: David Ahern @ 2017-04-21 23:40 UTC (permalink / raw)
To: netdev; +Cc: dvyukov, andreyknvl, mmanning, David Ahern
Taking down the loopback device wreaks havoc on IPv6 routes. By
extension, taking a VRF device wreaks havoc on its table.
Dmitry and Andrey both reported heap out-of-bounds reports in the IPv6
FIB code while running syzkaller fuzzer. The root cause is a dead dst
that is on the garbage list gets reinserted into the IPv6 FIB. While on
the gc (or perhaps when it gets added to the gc list) the dst->next is
set to an IPv4 dst. A subsequent walk of the ipv6 tables causes the
out-of-bounds access.
Andrey's reproducer was the key to getting to the bottom of this.
With IPv6, host routes for an address have the dst->dev set to the
loopback device. When the 'lo' device is taken down, rt6_ifdown initiates
a walk of the fib evicting routes with the 'lo' device which means all
host routes are removed. That process moves the dst which is attached to
an inet6_ifaddr to the gc list and marks it as dead.
The recent change to keep global IPv6 addresses added a new function
fixup_permanent_addr that is called on admin up. That function restarts
dad for an inet6_ifaddr and when it completes the host route attached
to it is inserted into the fib. Since the route was marked dead and
moved to the gc list, we get the reported out-of-bounds accesses. If
the device with the address is taken down or the address is removed, the
WARN_ON in fib6_del is triggered.
All of those faults are fixed by regenerating the host route of the
existing one has been moved to the gc list, something that can be
determined by checking if the rt6i_ref counter is 0.
The update of the route on the ifp is done using cmpxchg as suggested
by Li RongQing in a patch a year ago.
Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
net/ipv6/addrconf.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 08f9e8ea7a81..93555528a45b 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3303,14 +3303,16 @@ static void addrconf_gre_config(struct net_device *dev)
static int fixup_permanent_addr(struct inet6_dev *idev,
struct inet6_ifaddr *ifp)
{
- if (!ifp->rt) {
- struct rt6_info *rt;
+ if (!ifp->rt || !atomic_read(&ifp->rt->rt6i_ref)) {
+ struct rt6_info *rt, *prev;
rt = addrconf_dst_alloc(idev, &ifp->addr, false);
if (unlikely(IS_ERR(rt)))
return PTR_ERR(rt);
- ifp->rt = rt;
+ prev = cmpxchg(&ifp->rt, ifp->rt, rt);
+ if (prev)
+ ip6_rt_put(prev);
}
if (!(ifp->flags & IFA_F_NOPREFIXROUTE)) {
--
2.1.4
^ permalink raw reply related
* (unknown),
From: Mr.Jerry Smith @ 2017-04-21 17:15 UTC (permalink / raw)
We Give Out Loans At 3% Interest Rate And We Offer Loans From $5,000 To $50,000,000.00, Are You Looking To Buy A House Car Or Company Or Start Up A Truck Company or Buy A Truck Or Personal Loans Or Business Loan, Email Us At jerryfunds11@inbox.lv With Amount Needed And Phone Number.
^ permalink raw reply
* [PATCH 4/4] [DO NOT MERGE] arm64: allwinner: a64: enable RTL8211E PHY workaround
From: Icenowy Zheng @ 2017-04-21 23:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Rob Herring
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170421232436.10924-1-icenowy-h8G6r0blFSE@public.gmane.org>
From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
Some Pine64+ boards are said to have broken RTL8211E PHY.
Enable the workaround in Pine64+ device tree file.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
index 790d14daaa6a..1f59ee4f8b45 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -48,3 +48,7 @@
/* TODO: Camera, Ethernet PHY, touchscreen, etc. */
};
+
+&ext_phy {
+ realtek,disable-rx-delay;
+};
--
2.12.2
^ 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