* Re: [PATCH v2 7/7] net: phy: realtek: configure RTL8211E LEDs
From: Matthias Kaehlcke @ 2019-07-03 20:45 UTC (permalink / raw)
To: Heiner Kallweit
Cc: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <189ec367-2085-056b-61a9-90f0044b55ba@gmail.com>
On Wed, Jul 03, 2019 at 10:28:17PM +0200, Heiner Kallweit wrote:
> On 03.07.2019 21:37, Matthias Kaehlcke wrote:
> > Configure the RTL8211E LEDs behavior when the device tree property
> > 'realtek,led-modes' is specified.
> >
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> > Changes in v2:
> > - patch added to the series
> > ---
> > drivers/net/phy/realtek.c | 63 +++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 61 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> > index 45fee4612031..559aec547738 100644
> > --- a/drivers/net/phy/realtek.c
> > +++ b/drivers/net/phy/realtek.c
> > @@ -9,6 +9,7 @@
> > * Copyright (c) 2004 Freescale Semiconductor, Inc.
> > */
> > #include <linux/bitops.h>
> > +#include <linux/bits.h>
> > #include <linux/device.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > @@ -35,6 +36,15 @@
> > #define RTL8211E_EEE_LED_MODE1 0x05
> > #define RTL8211E_EEE_LED_MODE2 0x06
> >
> > +/* RTL8211E extension page 44 */
> > +#define RTL8211E_LACR 0x1a
> > +#define RLT8211E_LACR_LEDACTCTRL_SHIFT 4
> > +#define RLT8211E_LACR_LEDACTCTRL_MASK GENMASK(6, 4)
> > +#define RTL8211E_LCR 0x1c
> > +#define RTL8211E_LCR_LEDCTRL_MASK (GENMASK(2, 0) | \
> > + GENMASK(6, 4) | \
> > + GENMASK(10, 8))
> > +
> > /* RTL8211E extension page 160 */
> > #define RTL8211E_SCR 0x1a
> > #define RTL8211E_SCR_DISABLE_RXC_SSC BIT(2)
> > @@ -124,6 +134,56 @@ static int rtl8211e_disable_eee_led_mode(struct phy_device *phydev)
> > return phy_restore_page(phydev, oldpage, ret);
> > }
> >
> > +static int rtl8211e_config_leds(struct phy_device *phydev)
> > +{
> > + struct device *dev = &phydev->mdio.dev;
> > + int count, i, oldpage, ret;
> > + u16 lacr_bits = 0, lcr_bits = 0;
> > +
> > + if (!dev->of_node)
> > + return 0;
> > +
> > + if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
> > + rtl8211e_disable_eee_led_mode(phydev);
> > +
> > + count = of_property_count_elems_of_size(dev->of_node,
> > + "realtek,led-modes",
> > + sizeof(u32));
> > + if (count < 0 || count > 3)
> > + return -EINVAL;
> > +
> > + for (i = 0; i < count; i++) {
> > + u32 val;
> > +
> > + of_property_read_u32_index(dev->of_node,
> > + "realtek,led-modes", i, &val);
> > + lacr_bits |= (u16)(val >> 16) <<
> > + (RLT8211E_LACR_LEDACTCTRL_SHIFT + i);
>
> This may be done in an easier to read way:
>
> if (val & RTL8211E_LINK_ACTIVITY)
> lacr_bits |= BIT(RLT8211E_LACR_LEDACTCTRL_SHIFT + i);
indeed, that's more readable, thanks for the suggestion!
> > + lcr_bits |= (u16)(val & 0xf) << (i * 4);
> > + }
> > +
> > + oldpage = rtl8211e_select_ext_page(phydev, 44);
> > + if (oldpage < 0) {
> > + dev_err(dev, "failed to select extended page: %d\n", oldpage);
>
> In a PHY driver it may be more appropriate to use phydev_err() et al,
> even though effectively it's the same.
sounds good, I'll change it to the phydev_err() et al.
Thanks for the reviews!
Matthias
^ permalink raw reply
* Re: [PATCH net-next 0/2] Mellanox, mlx5 devlink versions query
From: David Miller @ 2019-07-03 20:47 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20190702235442.1925-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Tue, 2 Jul 2019 23:55:07 +0000
> This humble 2 patch series from Shay adds the support for devlink fw
> versions query to mlx5 driver.
>
> In the first patch we implement the needed fw commands to support this
> feature.
> In the 2nd patch we implement the devlink callbacks themselves.
>
> I am not sending this as a pull request since i am not sure when my next
> pull request is going to be ready, and these two patches are straight
> forward net-next patches.
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] Mellanox, mlx5 devlink versions query
From: David Miller @ 2019-07-03 20:49 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20190703.134700.1755482990570068688.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 03 Jul 2019 13:47:00 -0700 (PDT)
> From: Saeed Mahameed <saeedm@mellanox.com>
> Date: Tue, 2 Jul 2019 23:55:07 +0000
>
>> This humble 2 patch series from Shay adds the support for devlink fw
>> versions query to mlx5 driver.
>>
>> In the first patch we implement the needed fw commands to support this
>> feature.
>> In the 2nd patch we implement the devlink callbacks themselves.
>>
>> I am not sending this as a pull request since i am not sure when my next
>> pull request is going to be ready, and these two patches are straight
>> forward net-next patches.
>
> Series applied to net-next, thanks.
This doesn't build, there is some dependency...
[davem@localhost net-next]$ make -s -j14
In file included from ./include/linux/mlx5/driver.h:51,
from drivers/net/ethernet/mellanox/mlx5/core/fw.c:33:
drivers/net/ethernet/mellanox/mlx5/core/fw.c: In function ‘mlx5_reg_mcqi_query’:
./include/linux/mlx5/device.h:68:36: error: invalid application of ‘sizeof’ to incomplete type ‘union mlx5_ifc_mcqi_reg_data_bits’
#define MLX5_UN_SZ_DW(typ) (sizeof(union mlx5_ifc_##typ##_bits) / 32)
^~~~~
^ permalink raw reply
* [PATCH bpf-next] selftests/bpf: make verifier loop tests arch independent
From: Stanislav Fomichev @ 2019-07-03 20:51 UTC (permalink / raw)
To: netdev, bpf; +Cc: davem, ast, daniel, Stanislav Fomichev
Take the first x bytes of pt_regs for scalability tests, there is
no real reason we need x86 specific rax.
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
tools/testing/selftests/bpf/progs/loop1.c | 3 ++-
tools/testing/selftests/bpf/progs/loop2.c | 3 ++-
tools/testing/selftests/bpf/progs/loop3.c | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/bpf/progs/loop1.c b/tools/testing/selftests/bpf/progs/loop1.c
index dea395af9ea9..d530c61d2517 100644
--- a/tools/testing/selftests/bpf/progs/loop1.c
+++ b/tools/testing/selftests/bpf/progs/loop1.c
@@ -14,11 +14,12 @@ SEC("raw_tracepoint/kfree_skb")
int nested_loops(volatile struct pt_regs* ctx)
{
int i, j, sum = 0, m;
+ volatile int *any_reg = (volatile int *)ctx;
for (j = 0; j < 300; j++)
for (i = 0; i < j; i++) {
if (j & 1)
- m = ctx->rax;
+ m = *any_reg;
else
m = j;
sum += i * m;
diff --git a/tools/testing/selftests/bpf/progs/loop2.c b/tools/testing/selftests/bpf/progs/loop2.c
index 0637bd8e8bcf..91bb89d901e3 100644
--- a/tools/testing/selftests/bpf/progs/loop2.c
+++ b/tools/testing/selftests/bpf/progs/loop2.c
@@ -14,9 +14,10 @@ SEC("raw_tracepoint/consume_skb")
int while_true(volatile struct pt_regs* ctx)
{
int i = 0;
+ volatile int *any_reg = (volatile int *)ctx;
while (true) {
- if (ctx->rax & 1)
+ if (*any_reg & 1)
i += 3;
else
i += 7;
diff --git a/tools/testing/selftests/bpf/progs/loop3.c b/tools/testing/selftests/bpf/progs/loop3.c
index 30a0f6cba080..3a7f12d7186c 100644
--- a/tools/testing/selftests/bpf/progs/loop3.c
+++ b/tools/testing/selftests/bpf/progs/loop3.c
@@ -14,9 +14,10 @@ SEC("raw_tracepoint/consume_skb")
int while_true(volatile struct pt_regs* ctx)
{
__u64 i = 0, sum = 0;
+ volatile __u64 *any_reg = (volatile __u64 *)ctx;
do {
i++;
- sum += ctx->rax;
+ sum += *any_reg;
} while (i < 0x100000000ULL);
return sum;
}
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* Re: [PATCH net-next v2 0/5] net: use ICW for sk_proto->{send,recv}msg
From: David Miller @ 2019-07-03 20:52 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: pabeni, netdev
In-Reply-To: <CAF=yD-+z8-rq5bcrm3NdMv4kHp1HvoucxVBG3kLHxV9NS35EBw@mail.gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Wed, 3 Jul 2019 10:45:13 -0400
> On Wed, Jul 3, 2019 at 10:07 AM Paolo Abeni <pabeni@redhat.com> wrote:
>>
>> This series extends ICW usage to one of the few remaining spots in fast-path
>> still hitting per packet retpoline overhead, namely the sk_proto->{send,recv}msg
>> calls.
>>
>> The first 3 patches in this series refactor the existing code so that applying
>> the ICW macros is straight-forward: we demux inet_{recv,send}msg in ipv4 and
>> ipv6 variants so that each of them can easily select the appropriate TCP or UDP
>> direct call. While at it, a new helper is created to avoid excessive code
>> duplication, and the current ICWs for inet_{recv,send}msg are adjusted
>> accordingly.
>>
>> The last 2 patches really introduce the new ICW use-case, respectively for the
>> ipv6 and the ipv4 code path.
>>
>> This gives up to 5% performance improvement under UDP flood, and smaller but
>> measurable gains for TCP RR workloads.
>>
>> v1 -> v2:
>> - drop inet6_{recv,send}msg declaration from header file,
>> prefer ICW macro instead
>> - avoid unneeded reclaration for udp_sendmsg, as suggested by Willem
>>
>> Paolo Abeni (5):
>> inet: factor out inet_send_prepare()
>> ipv6: provide and use ipv6 specific version for {recv,send}msg
>> net: adjust socket level ICW to cope with ipv6 variant of
>> {recv,send}msg
>> ipv6: use indirect call wrappers for {tcp,udpv6}_{recv,send}msg()
>> ipv4: use indirect call wrappers for {tcp,udp}_{recv,send}msg()
>
> Acked-by: Willem de Bruijn <willemb@google.com>
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH][next] gve: fix -ENOMEM null check on a page allocation
From: David Miller @ 2019-07-03 20:53 UTC (permalink / raw)
To: colin.king
Cc: csully, sagis, jonolson, willemb, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20190703165037.3041-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Wed, 3 Jul 2019 17:50:37 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently the check to see if a page is allocated is incorrect
> and is checking if the pointer page is null, not *page as
> intended. Fix this.
>
> Addresses-Coverity: ("Dereference before null check")
> Fixes: f5cedc84a30d ("gve: Add transmit and receive support")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 4/7] net: phy: realtek: Enable accessing RTL8211E extension pages
From: Heiner Kallweit @ 2019-07-03 21:01 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <20190703203650.GF250418@google.com>
On 03.07.2019 22:36, Matthias Kaehlcke wrote:
> On Wed, Jul 03, 2019 at 10:12:12PM +0200, Heiner Kallweit wrote:
>> On 03.07.2019 21:37, Matthias Kaehlcke wrote:
>>> The RTL8211E has extension pages, which can be accessed after
>>> selecting a page through a custom method. Add a function to
>>> modify bits in a register of an extension page and a helper for
>>> selecting an ext page.
>>>
>>> rtl8211e_modify_ext_paged() is inspired by its counterpart
>>> phy_modify_paged().
>>>
>>> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
>>> ---
>>> Changes in v2:
>>> - assign .read/write_page handlers for RTL8211E
>>
>> Maybe this was planned, but it's not part of the patch.
>
> Oops, it was definitely there when I tested ... I guess this got
> somehow lost when changing the patch order and resolving minor
> conflicts, seems like I only build tested after that :/
>
RTL8211E also supports normal pages (reg 0x1f = page).
See e.g. rtl8168e_2_hw_phy_config in the r8169 driver, this network
chip has an integrated RTL8211E PHY. There settings on page 3 and 5
are done.
Therefore I would prefer to use .read/write_page for normal paging
in all Realtek PHY drivers. Means the code here would remain as it
is and just the changelog would need to be fixed.
>>> - use phy_select_page() and phy_restore_page(), get rid of
>>> rtl8211e_restore_page()
>>> - s/rtl821e_select_ext_page/rtl8211e_select_ext_page/
>>> - updated commit message
>>> ---
>>> drivers/net/phy/realtek.c | 42 +++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 42 insertions(+)
>>>
>>> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
>>> index eb815cbe1e72..9cd6241e2a6d 100644
>>> --- a/drivers/net/phy/realtek.c
>>> +++ b/drivers/net/phy/realtek.c
>>> @@ -27,6 +27,9 @@
>>> #define RTL821x_EXT_PAGE_SELECT 0x1e
>>> #define RTL821x_PAGE_SELECT 0x1f
>>>
>>> +#define RTL8211E_EXT_PAGE 7
>>> +#define RTL8211E_EPAGSR 0x1e
>>> +
>>> /* RTL8211E page 5 */
>>> #define RTL8211E_EEE_LED_MODE1 0x05
>>> #define RTL8211E_EEE_LED_MODE2 0x06
>>> @@ -58,6 +61,44 @@ static int rtl821x_write_page(struct phy_device *phydev, int page)
>>> return __phy_write(phydev, RTL821x_PAGE_SELECT, page);
>>> }
>>>
>>> +static int rtl8211e_select_ext_page(struct phy_device *phydev, int page)
>>> +{
>>> + int ret, oldpage;
>>> +
>>> + oldpage = phy_select_page(phydev, RTL8211E_EXT_PAGE);
>>> + if (oldpage < 0)
>>> + return oldpage;
>>> +
>>> + ret = __phy_write(phydev, RTL8211E_EPAGSR, page);
>>> + if (ret)
>>> + return phy_restore_page(phydev, page, ret);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int __maybe_unused rtl8211e_modify_ext_paged(struct phy_device *phydev,
>>> + int page, u32 regnum, u16 mask, u16 set)
>>
>> This __maybe_unused isn't too nice as you use the function in a subsequent patch.
>
> It's needed to avoid a compiler warning (unless we don't care about
> that for an interim version), the attribute is removed again in the
> next patch.
>
OK
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: net: Add bindings for Realtek PHYs
From: Rob Herring @ 2019-07-03 21:11 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: David S . Miller, Mark Rutland, Andrew Lunn, Florian Fainelli,
Heiner Kallweit, netdev, devicetree, linux-kernel@vger.kernel.org,
Douglas Anderson
In-Reply-To: <20190703193724.246854-1-mka@chromium.org>
On Wed, Jul 3, 2019 at 1:37 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> Add the 'realtek,eee-led-mode-disable' property to disable EEE
> LED mode on Realtek PHYs that support it.
>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> Changes in v2:
> - document 'realtek,eee-led-mode-disable' instead of
> 'realtek,enable-ssc' in the initial version
> ---
> .../devicetree/bindings/net/realtek.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/realtek.txt
>
> diff --git a/Documentation/devicetree/bindings/net/realtek.txt b/Documentation/devicetree/bindings/net/realtek.txt
> new file mode 100644
> index 000000000000..63f7002fa704
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek.txt
> @@ -0,0 +1,19 @@
> +Realtek PHY properties.
> +
> +This document describes properties of Realtek PHYs.
> +
> +Optional properties:
> +- realtek,eee-led-mode-disable: Disable EEE LED mode on this port.
> +
> +Example:
> +
> +mdio0 {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy: ethernet-phy@1 {
> + reg = <1>;
> + realtek,eee-led-mode-disable;
I think if we're going to have custom properties for phys, we should
have a compatible string to at least validate whether the custom
properties are even valid for the node.
Rob
^ permalink raw reply
* Re: [PATCH v2 4/7] net: phy: realtek: Enable accessing RTL8211E extension pages
From: Matthias Kaehlcke @ 2019-07-03 21:24 UTC (permalink / raw)
To: Heiner Kallweit
Cc: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <98326ec2-6e90-fd3a-32f5-cf0db26c31a9@gmail.com>
On Wed, Jul 03, 2019 at 11:01:09PM +0200, Heiner Kallweit wrote:
> On 03.07.2019 22:36, Matthias Kaehlcke wrote:
> > On Wed, Jul 03, 2019 at 10:12:12PM +0200, Heiner Kallweit wrote:
> >> On 03.07.2019 21:37, Matthias Kaehlcke wrote:
> >>> The RTL8211E has extension pages, which can be accessed after
> >>> selecting a page through a custom method. Add a function to
> >>> modify bits in a register of an extension page and a helper for
> >>> selecting an ext page.
> >>>
> >>> rtl8211e_modify_ext_paged() is inspired by its counterpart
> >>> phy_modify_paged().
> >>>
> >>> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> >>> ---
> >>> Changes in v2:
> >>> - assign .read/write_page handlers for RTL8211E
> >>
> >> Maybe this was planned, but it's not part of the patch.
> >
> > Oops, it was definitely there when I tested ... I guess this got
> > somehow lost when changing the patch order and resolving minor
> > conflicts, seems like I only build tested after that :/
> >
> RTL8211E also supports normal pages (reg 0x1f = page).
> See e.g. rtl8168e_2_hw_phy_config in the r8169 driver, this network
> chip has an integrated RTL8211E PHY. There settings on page 3 and 5
> are done.
> Therefore I would prefer to use .read/write_page for normal paging
> in all Realtek PHY drivers. Means the code here would remain as it
> is and just the changelog would need to be fixed.
Do I understand correctly that you suggest an additional patch that
assigns .read/write_page() for all entries of realtek_drvs?
^ permalink raw reply
* Re: [PATCH v2 4/7] net: phy: realtek: Enable accessing RTL8211E extension pages
From: Heiner Kallweit @ 2019-07-03 21:27 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <20190703212407.GI250418@google.com>
On 03.07.2019 23:24, Matthias Kaehlcke wrote:
> On Wed, Jul 03, 2019 at 11:01:09PM +0200, Heiner Kallweit wrote:
>> On 03.07.2019 22:36, Matthias Kaehlcke wrote:
>>> On Wed, Jul 03, 2019 at 10:12:12PM +0200, Heiner Kallweit wrote:
>>>> On 03.07.2019 21:37, Matthias Kaehlcke wrote:
>>>>> The RTL8211E has extension pages, which can be accessed after
>>>>> selecting a page through a custom method. Add a function to
>>>>> modify bits in a register of an extension page and a helper for
>>>>> selecting an ext page.
>>>>>
>>>>> rtl8211e_modify_ext_paged() is inspired by its counterpart
>>>>> phy_modify_paged().
>>>>>
>>>>> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
>>>>> ---
>>>>> Changes in v2:
>>>>> - assign .read/write_page handlers for RTL8211E
>>>>
>>>> Maybe this was planned, but it's not part of the patch.
>>>
>>> Oops, it was definitely there when I tested ... I guess this got
>>> somehow lost when changing the patch order and resolving minor
>>> conflicts, seems like I only build tested after that :/
>>>
>> RTL8211E also supports normal pages (reg 0x1f = page).
>> See e.g. rtl8168e_2_hw_phy_config in the r8169 driver, this network
>> chip has an integrated RTL8211E PHY. There settings on page 3 and 5
>> are done.
>> Therefore I would prefer to use .read/write_page for normal paging
>> in all Realtek PHY drivers. Means the code here would remain as it
>> is and just the changelog would need to be fixed.
>
> Do I understand correctly that you suggest an additional patch that
> assigns .read/write_page() for all entries of realtek_drvs?
>
No, basically all the Realtek PHY drivers use the following already:
.read_page = rtl821x_read_page,
.write_page = rtl821x_write_page,
What I mean is that this should stay as it is, and not be overwritten
with the extended paging.
^ permalink raw reply
* [PATCH bpf-next] selftests/bpf: fix test_align liveliness expectations
From: Stanislav Fomichev @ 2019-07-03 21:29 UTC (permalink / raw)
To: netdev, bpf; +Cc: davem, ast, daniel, Stanislav Fomichev
Commit 2589726d12a1 ("bpf: introduce bounded loops") caused a change
in the way some registers liveliness is reported in the test_align.
Add missing "_w" to a couple of tests. Note, there are no offset
changes!
Fixes: 2589726d12a1 ("bpf: introduce bounded loops")
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
tools/testing/selftests/bpf/test_align.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_align.c b/tools/testing/selftests/bpf/test_align.c
index 3c789d03b629..0262f7b374f9 100644
--- a/tools/testing/selftests/bpf/test_align.c
+++ b/tools/testing/selftests/bpf/test_align.c
@@ -180,7 +180,7 @@ static struct bpf_align_test tests[] = {
},
.prog_type = BPF_PROG_TYPE_SCHED_CLS,
.matches = {
- {7, "R0=pkt(id=0,off=8,r=8,imm=0)"},
+ {7, "R0_w=pkt(id=0,off=8,r=8,imm=0)"},
{7, "R3_w=inv(id=0,umax_value=255,var_off=(0x0; 0xff))"},
{8, "R3_w=inv(id=0,umax_value=510,var_off=(0x0; 0x1fe))"},
{9, "R3_w=inv(id=0,umax_value=1020,var_off=(0x0; 0x3fc))"},
@@ -315,7 +315,7 @@ static struct bpf_align_test tests[] = {
/* Calculated offset in R6 has unknown value, but known
* alignment of 4.
*/
- {8, "R2=pkt(id=0,off=0,r=8,imm=0)"},
+ {8, "R2_w=pkt(id=0,off=0,r=8,imm=0)"},
{8, "R6_w=inv(id=0,umax_value=1020,var_off=(0x0; 0x3fc))"},
/* Offset is added to packet pointer R5, resulting in
* known fixed offset, and variable offset from R6.
@@ -405,7 +405,7 @@ static struct bpf_align_test tests[] = {
/* Calculated offset in R6 has unknown value, but known
* alignment of 4.
*/
- {8, "R2=pkt(id=0,off=0,r=8,imm=0)"},
+ {8, "R2_w=pkt(id=0,off=0,r=8,imm=0)"},
{8, "R6_w=inv(id=0,umax_value=1020,var_off=(0x0; 0x3fc))"},
/* Adding 14 makes R6 be (4n+2) */
{9, "R6_w=inv(id=0,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc))"},
@@ -473,12 +473,12 @@ static struct bpf_align_test tests[] = {
/* (4n) + 14 == (4n+2). We blow our bounds, because
* the add could overflow.
*/
- {7, "R5=inv(id=0,var_off=(0x2; 0xfffffffffffffffc))"},
+ {7, "R5_w=inv(id=0,var_off=(0x2; 0xfffffffffffffffc))"},
/* Checked s>=0 */
{9, "R5=inv(id=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
/* packet pointer + nonnegative (4n+2) */
{11, "R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
- {13, "R4=pkt(id=1,off=4,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
+ {13, "R4_w=pkt(id=1,off=4,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
/* NET_IP_ALIGN + (4n+2) == (4n), alignment is fine.
* We checked the bounds, but it might have been able
* to overflow if the packet pointer started in the
@@ -486,7 +486,7 @@ static struct bpf_align_test tests[] = {
* So we did not get a 'range' on R6, and the access
* attempt will fail.
*/
- {15, "R6=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
+ {15, "R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
}
},
{
@@ -521,7 +521,7 @@ static struct bpf_align_test tests[] = {
/* Calculated offset in R6 has unknown value, but known
* alignment of 4.
*/
- {7, "R2=pkt(id=0,off=0,r=8,imm=0)"},
+ {7, "R2_w=pkt(id=0,off=0,r=8,imm=0)"},
{9, "R6_w=inv(id=0,umax_value=1020,var_off=(0x0; 0x3fc))"},
/* Adding 14 makes R6 be (4n+2) */
{10, "R6_w=inv(id=0,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc))"},
@@ -574,7 +574,7 @@ static struct bpf_align_test tests[] = {
/* Calculated offset in R6 has unknown value, but known
* alignment of 4.
*/
- {7, "R2=pkt(id=0,off=0,r=8,imm=0)"},
+ {7, "R2_w=pkt(id=0,off=0,r=8,imm=0)"},
{10, "R6_w=inv(id=0,umax_value=60,var_off=(0x0; 0x3c))"},
/* Adding 14 makes R6 be (4n+2) */
{11, "R6_w=inv(id=0,umin_value=14,umax_value=74,var_off=(0x2; 0x7c))"},
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* Re: [PATCH v2 1/7] dt-bindings: net: Add bindings for Realtek PHYs
From: Andrew Lunn @ 2019-07-03 21:33 UTC (permalink / raw)
To: Rob Herring
Cc: Matthias Kaehlcke, David S . Miller, Mark Rutland,
Florian Fainelli, Heiner Kallweit, netdev, devicetree,
linux-kernel@vger.kernel.org, Douglas Anderson
In-Reply-To: <CAL_JsqJdBAMPc1sZJfL7V9cxGgCb4GWwRokwJDmac5L2AO2-wg@mail.gmail.com>
> I think if we're going to have custom properties for phys, we should
> have a compatible string to at least validate whether the custom
> properties are even valid for the node.
Hi Rob
What happens with other enumerable busses where a compatible string is
not used?
The Ethernet PHY subsystem will ignore the compatible string and load
the driver which fits the enumeration data. Using the compatible
string only to get the right YAML validator seems wrong. I would
prefer adding some other property with a clear name indicates its is
selecting the validator, and has nothing to do with loading the
correct driver. And it can then be used as well for USB and PCI
devices etc.
Andrew
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: net: realtek: Add property to configure LED mode
From: Florian Fainelli @ 2019-07-03 21:37 UTC (permalink / raw)
To: Matthias Kaehlcke, David S . Miller, Rob Herring, Mark Rutland,
Andrew Lunn, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson
In-Reply-To: <20190703193724.246854-6-mka@chromium.org>
On 7/3/19 12:37 PM, Matthias Kaehlcke wrote:
> The LED behavior of some Realtek PHYs is configurable. Add the
> property 'realtek,led-modes' to specify the configuration of the
> LEDs.
>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> Changes in v2:
> - patch added to the series
> ---
> .../devicetree/bindings/net/realtek.txt | 9 +++++++++
> include/dt-bindings/net/realtek.h | 17 +++++++++++++++++
> 2 files changed, 26 insertions(+)
> create mode 100644 include/dt-bindings/net/realtek.h
>
> diff --git a/Documentation/devicetree/bindings/net/realtek.txt b/Documentation/devicetree/bindings/net/realtek.txt
> index 71d386c78269..40b0d6f9ee21 100644
> --- a/Documentation/devicetree/bindings/net/realtek.txt
> +++ b/Documentation/devicetree/bindings/net/realtek.txt
> @@ -9,6 +9,12 @@ Optional properties:
>
> SSC is only available on some Realtek PHYs (e.g. RTL8211E).
>
> +- realtek,led-modes: LED mode configuration.
> +
> + A 0..3 element vector, with each element configuring the operating
> + mode of an LED. Omitted LEDs are turned off. Allowed values are
> + defined in "include/dt-bindings/net/realtek.h".
This should probably be made more general and we should define LED modes
that makes sense regardless of the PHY device, introduce a set of
generic functions for validating and then add new function pointer for
setting the LED configuration to the PHY driver. This would allow to be
more future proof where each PHY driver could expose standard LEDs class
devices to user-space, and it would also allow facilities like: ethtool
-p to plug into that.
Right now, each driver invents its own way of configuring LEDs, that
does not scale, and there is not really a good reason for that other
than reviewing drivers in isolation and therefore making it harder to
extract the commonality. Yes, I realize that since you are the latest
person submitting something in that area, you are being selected :)
> +
> Example:
>
> mdio0 {
> @@ -20,5 +26,8 @@ mdio0 {
> reg = <1>;
> realtek,eee-led-mode-disable;
> realtek,enable-ssc;
> + realtek,led-modes = <RTL8211E_LINK_ACTIVITY
> + RTL8211E_LINK_100
> + RTL8211E_LINK_1000>;
> };
> };
> diff --git a/include/dt-bindings/net/realtek.h b/include/dt-bindings/net/realtek.h
> new file mode 100644
> index 000000000000..8d64f58d58f8
> --- /dev/null
> +++ b/include/dt-bindings/net/realtek.h
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _DT_BINDINGS_REALTEK_H
> +#define _DT_BINDINGS_REALTEK_H
> +
> +/* LED modes for RTL8211E PHY */
> +
> +#define RTL8211E_LINK_10 1
> +#define RTL8211E_LINK_100 2
> +#define RTL8211E_LINK_1000 4
> +#define RTL8211E_LINK_10_100 3
> +#define RTL8211E_LINK_10_1000 5
> +#define RTL8211E_LINK_100_1000 6
> +#define RTL8211E_LINK_10_100_1000 7
> +
> +#define RTL8211E_LINK_ACTIVITY (1 << 16)
> +
> +#endif
>
--
Florian
^ permalink raw reply
* linux-next: Fixes tag needs some work in the net-next tree
From: Stephen Rothwell @ 2019-07-03 21:42 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Mahesh Bandewar
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
Hi all,
In commit
d62962b37ceb ("loopback: fix lockdep splat")
Fixes tag
Fixes: 4de83b88c66 ("loopback: create blackhole net device similar to loopack.")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net-next] iavf: remove unused debug function iavf_debug_d
From: Bowers, AndrewX @ 2019-07-03 21:44 UTC (permalink / raw)
To: intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190702062021.41524-1-yuehaibing@huawei.com>
> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> Behalf Of YueHaibing
> Sent: Monday, July 1, 2019 11:20 PM
> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>; davem@davemloft.net;
> intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; YueHaibing <yuehaibing@huawei.com>; linux-
> kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH net-next] iavf: remove unused debug
> function iavf_debug_d
>
> There is no caller of function iavf_debug_d() in tree since commit
> 75051ce4c5d8 ("iavf: Fix up debug print macro"), so it can be removed.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/ethernet/intel/iavf/iavf_main.c | 22 ----------------------
> 1 file changed, 22 deletions(-)
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: net: Add bindings for Realtek PHYs
From: Matthias Kaehlcke @ 2019-07-03 22:08 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, David S . Miller, Mark Rutland, Florian Fainelli,
Heiner Kallweit, netdev, devicetree, linux-kernel@vger.kernel.org,
Douglas Anderson
In-Reply-To: <20190703213327.GH18473@lunn.ch>
On Wed, Jul 03, 2019 at 11:33:27PM +0200, Andrew Lunn wrote:
> > I think if we're going to have custom properties for phys, we should
> > have a compatible string to at least validate whether the custom
> > properties are even valid for the node.
>
> Hi Rob
>
> What happens with other enumerable busses where a compatible string is
> not used?
>
> The Ethernet PHY subsystem will ignore the compatible string and load
> the driver which fits the enumeration data. Using the compatible
> string only to get the right YAML validator seems wrong. I would
> prefer adding some other property with a clear name indicates its is
> selecting the validator, and has nothing to do with loading the
> correct driver. And it can then be used as well for USB and PCI
> devices etc.
I also have doubts whether a compatible string is the right answer
here. It's not needed/used by the subsystem, but would it be a
required property because it's needed for validation?
^ permalink raw reply
* Re: [PATCH v3 bpf-next 2/4] selftests/bpf: add __int and __type macro for BTF-defined maps
From: Yonghong Song @ 2019-07-03 22:41 UTC (permalink / raw)
To: Andrii Nakryiko, andrii.nakryiko@gmail.com, Alexei Starovoitov,
daniel@iogearbox.net, bpf@vger.kernel.org, netdev@vger.kernel.org,
Kernel Team
In-Reply-To: <20190703190604.4173641-3-andriin@fb.com>
On 7/3/19 12:06 PM, Andrii Nakryiko wrote:
> Add simple __int and __type macro that hide details of how type and
The "__int" should be "__uint".
The subject line should change from __int to __uint.
> integer values are captured in BTF-defined maps.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> tools/testing/selftests/bpf/bpf_helpers.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
> index 1a5b1accf091..5a3d92c8bec8 100644
> --- a/tools/testing/selftests/bpf/bpf_helpers.h
> +++ b/tools/testing/selftests/bpf/bpf_helpers.h
> @@ -8,6 +8,9 @@
> */
> #define SEC(NAME) __attribute__((section(NAME), used))
>
> +#define __uint(name, val) int (*name)[val]
> +#define __type(name, val) val *name
> +
> /* helper macro to print out debug messages */
> #define bpf_printk(fmt, ...) \
> ({ \
>
^ permalink raw reply
* Re: [PATCH v3 bpf-next 0/4] capture integers in BTF type info for map defs
From: Yonghong Song @ 2019-07-03 22:42 UTC (permalink / raw)
To: Andrii Nakryiko, andrii.nakryiko@gmail.com, Alexei Starovoitov,
daniel@iogearbox.net, bpf@vger.kernel.org, netdev@vger.kernel.org,
Kernel Team
In-Reply-To: <20190703190604.4173641-1-andriin@fb.com>
On 7/3/19 12:06 PM, Andrii Nakryiko wrote:
> This patch set implements an update to how BTF-defined maps are specified. The
> change is in how integer attributes, e.g., type, max_entries, map_flags, are
> specified: now they are captured as part of map definition struct's BTF type
> information (using array dimension), eliminating the need for compile-time
> data initialization and keeping all the metadata in one place.
>
> All existing selftests that were using BTF-defined maps are updated, along
> with some other selftests, that were switched to new syntax.
>
> v2->v3:
> - rename __int into __uint (Yonghong);
> v1->v2:
> - split bpf_helpers.h change from libbpf change (Song).
>
> Andrii Nakryiko (4):
> libbpf: capture value in BTF type info for BTF-defined map defs
> selftests/bpf: add __int and __type macro for BTF-defined maps
> selftests/bpf: convert selftests using BTF-defined maps to new syntax
> selftests/bpf: convert legacy BPF maps to BTF-defined ones
>
With typos in patch 2/4 (mentioned in another thread), ack the whole series.
Acked-by: Yonghong Song <yhs@fb.com>
> tools/lib/bpf/libbpf.c | 58 +++++----
> tools/testing/selftests/bpf/bpf_helpers.h | 3 +
> tools/testing/selftests/bpf/progs/bpf_flow.c | 28 ++---
> .../selftests/bpf/progs/get_cgroup_id_kern.c | 26 ++---
> .../testing/selftests/bpf/progs/netcnt_prog.c | 20 ++--
> tools/testing/selftests/bpf/progs/pyperf.h | 90 +++++++-------
> .../selftests/bpf/progs/sample_map_ret0.c | 24 ++--
> .../selftests/bpf/progs/socket_cookie_prog.c | 13 +--
> .../bpf/progs/sockmap_verdict_prog.c | 48 ++++----
> .../testing/selftests/bpf/progs/strobemeta.h | 68 +++++------
> .../selftests/bpf/progs/test_btf_newkv.c | 13 +--
> .../bpf/progs/test_get_stack_rawtp.c | 39 +++----
> .../selftests/bpf/progs/test_global_data.c | 37 +++---
> tools/testing/selftests/bpf/progs/test_l4lb.c | 65 ++++-------
> .../selftests/bpf/progs/test_l4lb_noinline.c | 65 ++++-------
> .../selftests/bpf/progs/test_map_in_map.c | 30 ++---
> .../selftests/bpf/progs/test_map_lock.c | 26 ++---
> .../testing/selftests/bpf/progs/test_obj_id.c | 12 +-
> .../bpf/progs/test_select_reuseport_kern.c | 67 ++++-------
> .../bpf/progs/test_send_signal_kern.c | 26 ++---
> .../bpf/progs/test_sock_fields_kern.c | 78 +++++--------
> .../selftests/bpf/progs/test_spin_lock.c | 36 +++---
> .../bpf/progs/test_stacktrace_build_id.c | 55 ++++-----
> .../selftests/bpf/progs/test_stacktrace_map.c | 52 +++------
> .../selftests/bpf/progs/test_tcp_estats.c | 13 +--
> .../selftests/bpf/progs/test_tcpbpf_kern.c | 26 ++---
> .../selftests/bpf/progs/test_tcpnotify_kern.c | 28 ++---
> tools/testing/selftests/bpf/progs/test_xdp.c | 26 ++---
> .../selftests/bpf/progs/test_xdp_loop.c | 26 ++---
> .../selftests/bpf/progs/test_xdp_noinline.c | 81 +++++--------
> .../selftests/bpf/progs/xdp_redirect_map.c | 12 +-
> .../testing/selftests/bpf/progs/xdping_kern.c | 12 +-
> .../selftests/bpf/test_queue_stack_map.h | 30 ++---
> .../testing/selftests/bpf/test_sockmap_kern.h | 110 +++++++++---------
> 34 files changed, 571 insertions(+), 772 deletions(-)
>
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: add test_tcp_rtt to .gitignore
From: Y Song @ 2019-07-03 22:46 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: netdev, bpf, David Miller, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko
In-Reply-To: <20190703200952.159728-1-sdf@google.com>
On Wed, Jul 3, 2019 at 1:10 PM Stanislav Fomichev <sdf@google.com> wrote:
>
> Forgot to add it in the original patch.
>
> Fixes: b55873984dab ("selftests/bpf: test BPF_SOCK_OPS_RTT_CB")
> Reported-by: Andrii Nakryiko <andriin@fb.com>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Acked-by: Yonghong Song <yhs@fb.com>
> ---
> tools/testing/selftests/bpf/.gitignore | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/testing/selftests/bpf/.gitignore b/tools/testing/selftests/bpf/.gitignore
> index a2f7f79c7908..90f70d2c7c22 100644
> --- a/tools/testing/selftests/bpf/.gitignore
> +++ b/tools/testing/selftests/bpf/.gitignore
> @@ -42,3 +42,4 @@ xdping
> test_sockopt
> test_sockopt_sk
> test_sockopt_multi
> +test_tcp_rtt
> --
> 2.22.0.410.gd8fdbe21b5-goog
>
^ permalink raw reply
* pull-request: bpf-next 2019-07-03
From: Daniel Borkmann @ 2019-07-03 22:47 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, saeedm, netdev, bpf
Hi David,
The following pull-request contains BPF updates for your *net-next* tree.
There is a minor merge conflict in mlx5 due to 8960b38932be ("linux/dim:
Rename externally used net_dim members") which has been pulled into your
tree in the meantime, but resolution seems not that bad ... getting current
bpf-next out now before there's coming more on mlx5. ;) I'm Cc'ing Saeed
just so he's aware of the resolution below:
** First conflict in drivers/net/ethernet/mellanox/mlx5/core/en_main.c:
<<<<<<< HEAD
static int mlx5e_open_cq(struct mlx5e_channel *c,
struct dim_cq_moder moder,
struct mlx5e_cq_param *param,
struct mlx5e_cq *cq)
=======
int mlx5e_open_cq(struct mlx5e_channel *c, struct net_dim_cq_moder moder,
struct mlx5e_cq_param *param, struct mlx5e_cq *cq)
>>>>>>> e5a3e259ef239f443951d401db10db7d426c9497
Resolution is to take the second chunk and rename net_dim_cq_moder into
dim_cq_moder. Also the signature for mlx5e_open_cq() in ...
drivers/net/ethernet/mellanox/mlx5/core/en.h +977
... and in mlx5e_open_xsk() ...
drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c +64
... needs the same rename from net_dim_cq_moder into dim_cq_moder.
** Second conflict in drivers/net/ethernet/mellanox/mlx5/core/en_main.c:
<<<<<<< HEAD
int cpu = cpumask_first(mlx5_comp_irq_get_affinity_mask(priv->mdev, ix));
struct dim_cq_moder icocq_moder = {0, 0};
struct net_device *netdev = priv->netdev;
struct mlx5e_channel *c;
unsigned int irq;
=======
struct net_dim_cq_moder icocq_moder = {0, 0};
>>>>>>> e5a3e259ef239f443951d401db10db7d426c9497
Take the second chunk and rename net_dim_cq_moder into dim_cq_moder
as well.
Let me know if you run into any issues. Anyway, the main changes are:
1) Long-awaited AF_XDP support for mlx5e driver, from Maxim.
2) Addition of two new per-cgroup BPF hooks for getsockopt and
setsockopt along with a new sockopt program type which allows more
fine-grained pass/reject settings for containers. Also add a sock_ops
callback that can be selectively enabled on a per-socket basis and is
executed for every RTT to help tracking TCP statistics, both features
from Stanislav.
3) Follow-up fix from loops in precision tracking which was not propagating
precision marks and as a result verifier assumed that some branches were
not taken and therefore wrongly removed as dead code, from Alexei.
4) Fix BPF cgroup release synchronization race which could lead to a
double-free if a leaf's cgroup_bpf object is released and a new BPF
program is attached to the one of ancestor cgroups in parallel, from Roman.
5) Support for bulking XDP_TX on veth devices which improves performance
in some cases by around 9%, from Toshiaki.
6) Allow for lookups into BPF devmap and improve feedback when calling into
bpf_redirect_map() as lookup is now performed right away in the helper
itself, from Toke.
7) Add support for fq's Earliest Departure Time to the Host Bandwidth
Manager (HBM) sample BPF program, from Lawrence.
8) Various cleanups and minor fixes all over the place from many others.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 7d30a7f6424e88c958c19a02f6f54ab8d25919cd:
Merge branch 'ipv6-avoid-taking-refcnt-on-dst-during-route-lookup' (2019-06-23 13:24:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
for you to fetch changes up to e5a3e259ef239f443951d401db10db7d426c9497:
Merge branch 'bpf-tcp-rtt-hook' (2019-07-03 16:52:03 +0200)
----------------------------------------------------------------
Alexei Starovoitov (2):
Merge branch 'bpf-sockopt-hooks'
bpf: fix precision tracking
Andrii Nakryiko (2):
selftests/bpf: build tests with debug info
libbpf: fix GCC8 warning for strncpy
Colin Ian King (1):
libbpf: fix spelling mistake "conflictling" -> "conflicting"
Daniel Borkmann (3):
Merge branch 'bpf-af-xdp-mlx5e'
Merge branch 'bpf-lookup-devmap'
Merge branch 'bpf-tcp-rtt-hook'
Daniel T. Lee (1):
samples: bpf: make the use of xdp samples consistent
Eric Leblond (1):
xsk: sample kernel code is now in libbpf
Ivan Khoronzhuk (1):
libbpf: fix max() type mismatch for 32bit
Jiri Benc (1):
selftests: bpf: standardize to static __always_inline
Leo Yan (1):
bpf, libbpf, smatch: Fix potential NULL pointer dereference
Maxim Mikityanskiy (16):
net/mlx5e: Attach/detach XDP program safely
xsk: Add API to check for available entries in FQ
xsk: Add getsockopt XDP_OPTIONS
libbpf: Support getsockopt XDP_OPTIONS
xsk: Change the default frame size to 4096 and allow controlling it
xsk: Return the whole xdp_desc from xsk_umem_consume_tx
net/mlx5e: Replace deprecated PCI_DMA_TODEVICE
net/mlx5e: Calculate linear RX frag size considering XSK
net/mlx5e: Allow ICO SQ to be used by multiple RQs
net/mlx5e: Refactor struct mlx5e_xdp_info
net/mlx5e: Share the XDP SQ for XDP_TX between RQs
net/mlx5e: XDP_TX from UMEM support
net/mlx5e: Consider XSK in XDP MTU limit calculation
net/mlx5e: Encapsulate open/close queues into a function
net/mlx5e: Move queue param structs to en/params.h
net/mlx5e: Add XSK zero-copy support
Michal Rostecki (1):
samples: bpf: Remove bpf_debug macro in favor of bpf_printk
Roman Gushchin (1):
bpf: fix cgroup bpf release synchronization
Stanislav Fomichev (18):
bpf: implement getsockopt and setsockopt hooks
bpf: sync bpf.h to tools/
libbpf: support sockopt hooks
selftests/bpf: test sockopt section name
selftests/bpf: add sockopt test
selftests/bpf: add sockopt test that exercises sk helpers
selftests/bpf: add sockopt test that exercises BPF_F_ALLOW_MULTI
bpf: add sockopt documentation
bpftool: support cgroup sockopt
selftests/bpf: fix -Wstrict-aliasing in test_sockopt_sk.c
bpf: add BPF_CGROUP_SOCK_OPS callback that is executed on every RTT
bpf: split shared bpf_tcp_sock and bpf_sock_ops implementation
bpf: add dsack_dups/delivered{, _ce} to bpf_tcp_sock
bpf: add icsk_retransmits to bpf_tcp_sock
bpf/tools: sync bpf.h
selftests/bpf: test BPF_SOCK_OPS_RTT_CB
samples/bpf: add sample program that periodically dumps TCP stats
samples/bpf: fix tcp_bpf.readme detach command
Toke Høiland-Jørgensen (5):
xskmap: Move non-standard list manipulation to helper
devmap/cpumap: Use flush list instead of bitmap
devmap: Rename ifindex member in bpf_redirect_info
bpf_xdp_redirect_map: Perform map lookup in eBPF helper
devmap: Allow map lookups from eBPF
Toshiaki Makita (3):
selftests, bpf: Add test for veth native XDP
xdp: Add tracepoint for bulk XDP_TX
veth: Support bulk XDP_TX
Yonghong Song (1):
bpf: fix compiler warning with CONFIG_MODULES=n
YueHaibing (1):
xdp: Make __mem_id_disconnect static
brakmo (1):
bpf: Add support for fq's EDT to HBM
Documentation/bpf/index.rst | 1 +
Documentation/bpf/prog_cgroup_sockopt.rst | 93 ++
Documentation/networking/af_xdp.rst | 16 +-
drivers/net/ethernet/intel/i40e/i40e_xsk.c | 12 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 15 +-
drivers/net/ethernet/mellanox/mlx5/core/Makefile | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en.h | 155 ++-
.../net/ethernet/mellanox/mlx5/core/en/params.c | 108 ++-
.../net/ethernet/mellanox/mlx5/core/en/params.h | 118 ++-
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 231 +++--
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.h | 36 +-
.../ethernet/mellanox/mlx5/core/en/xsk/Makefile | 1 +
.../net/ethernet/mellanox/mlx5/core/en/xsk/rx.c | 192 ++++
.../net/ethernet/mellanox/mlx5/core/en/xsk/rx.h | 27 +
.../net/ethernet/mellanox/mlx5/core/en/xsk/setup.c | 223 +++++
.../net/ethernet/mellanox/mlx5/core/en/xsk/setup.h | 25 +
.../net/ethernet/mellanox/mlx5/core/en/xsk/tx.c | 111 +++
.../net/ethernet/mellanox/mlx5/core/en/xsk/tx.h | 15 +
.../net/ethernet/mellanox/mlx5/core/en/xsk/umem.c | 267 +++++
.../net/ethernet/mellanox/mlx5/core/en/xsk/umem.h | 31 +
.../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 25 +-
.../ethernet/mellanox/mlx5/core/en_fs_ethtool.c | 18 +-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 730 +++++++++-----
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 12 +-
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 104 +-
drivers/net/ethernet/mellanox/mlx5/core/en_stats.c | 115 ++-
drivers/net/ethernet/mellanox/mlx5/core/en_stats.h | 30 +
drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 42 +-
.../net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c | 14 +-
drivers/net/ethernet/mellanox/mlx5/core/wq.h | 5 -
drivers/net/veth.c | 60 +-
include/linux/bpf-cgroup.h | 45 +
include/linux/bpf.h | 2 +
include/linux/bpf_types.h | 1 +
include/linux/filter.h | 13 +-
include/linux/list.h | 14 +
include/net/tcp.h | 8 +
include/net/xdp_sock.h | 27 +-
include/trace/events/xdp.h | 34 +-
include/uapi/linux/bpf.h | 33 +-
include/uapi/linux/if_xdp.h | 8 +
kernel/bpf/cgroup.c | 352 ++++++-
kernel/bpf/core.c | 10 +
kernel/bpf/cpumap.c | 105 +-
kernel/bpf/devmap.c | 112 +--
kernel/bpf/syscall.c | 19 +
kernel/bpf/verifier.c | 136 ++-
kernel/bpf/xskmap.c | 3 +-
kernel/trace/bpf_trace.c | 27 +-
net/core/filter.c | 269 ++++--
net/core/xdp.c | 2 +-
net/ipv4/tcp_input.c | 4 +
net/socket.c | 30 +
net/xdp/xsk.c | 36 +-
net/xdp/xsk_queue.h | 14 +
samples/bpf/Makefile | 3 +
samples/bpf/do_hbm_test.sh | 22 +-
samples/bpf/hbm.c | 18 +-
samples/bpf/hbm_edt_kern.c | 168 ++++
samples/bpf/hbm_kern.h | 40 +-
samples/bpf/ibumad_kern.c | 18 +-
samples/bpf/tcp_bpf.readme | 2 +-
samples/bpf/tcp_dumpstats_kern.c | 68 ++
samples/bpf/xdp_adjust_tail_user.c | 12 +-
samples/bpf/xdp_redirect_map_user.c | 15 +-
samples/bpf/xdp_redirect_user.c | 15 +-
samples/bpf/xdp_tx_iptunnel_user.c | 12 +-
samples/bpf/xdpsock_user.c | 44 +-
tools/bpf/bpftool/Documentation/bpftool-cgroup.rst | 7 +-
tools/bpf/bpftool/Documentation/bpftool-prog.rst | 3 +-
tools/bpf/bpftool/bash-completion/bpftool | 9 +-
tools/bpf/bpftool/cgroup.c | 5 +-
tools/bpf/bpftool/main.h | 1 +
tools/bpf/bpftool/prog.c | 3 +-
tools/include/uapi/linux/bpf.h | 26 +-
tools/include/uapi/linux/if_xdp.h | 8 +
tools/lib/bpf/libbpf.c | 23 +-
tools/lib/bpf/libbpf_probes.c | 1 +
tools/lib/bpf/xsk.c | 15 +-
tools/lib/bpf/xsk.h | 2 +-
tools/testing/selftests/bpf/.gitignore | 3 +
tools/testing/selftests/bpf/Makefile | 10 +-
tools/testing/selftests/bpf/progs/pyperf.h | 9 +-
tools/testing/selftests/bpf/progs/sockopt_multi.c | 71 ++
tools/testing/selftests/bpf/progs/sockopt_sk.c | 111 +++
tools/testing/selftests/bpf/progs/strobemeta.h | 36 +-
tools/testing/selftests/bpf/progs/tcp_rtt.c | 61 ++
tools/testing/selftests/bpf/progs/test_jhash.h | 3 +-
tools/testing/selftests/bpf/progs/test_seg6_loop.c | 23 +-
.../selftests/bpf/progs/test_verif_scale2.c | 2 +-
.../testing/selftests/bpf/progs/xdp_redirect_map.c | 31 +
tools/testing/selftests/bpf/progs/xdp_tx.c | 12 +
tools/testing/selftests/bpf/test_section_names.c | 10 +
tools/testing/selftests/bpf/test_sockopt.c | 1021 ++++++++++++++++++++
tools/testing/selftests/bpf/test_sockopt_multi.c | 374 +++++++
tools/testing/selftests/bpf/test_sockopt_sk.c | 211 ++++
tools/testing/selftests/bpf/test_tcp_rtt.c | 254 +++++
tools/testing/selftests/bpf/test_xdp_veth.sh | 118 +++
98 files changed, 6197 insertions(+), 841 deletions(-)
create mode 100644 Documentation/bpf/prog_cgroup_sockopt.rst
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/Makefile
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.h
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.h
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.h
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/umem.c
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/umem.h
create mode 100644 samples/bpf/hbm_edt_kern.c
create mode 100644 samples/bpf/tcp_dumpstats_kern.c
create mode 100644 tools/testing/selftests/bpf/progs/sockopt_multi.c
create mode 100644 tools/testing/selftests/bpf/progs/sockopt_sk.c
create mode 100644 tools/testing/selftests/bpf/progs/tcp_rtt.c
create mode 100644 tools/testing/selftests/bpf/progs/xdp_redirect_map.c
create mode 100644 tools/testing/selftests/bpf/progs/xdp_tx.c
create mode 100644 tools/testing/selftests/bpf/test_sockopt.c
create mode 100644 tools/testing/selftests/bpf/test_sockopt_multi.c
create mode 100644 tools/testing/selftests/bpf/test_sockopt_sk.c
create mode 100644 tools/testing/selftests/bpf/test_tcp_rtt.c
create mode 100755 tools/testing/selftests/bpf/test_xdp_veth.sh
^ permalink raw reply
* Re: [PATCH v2 4/7] net: phy: realtek: Enable accessing RTL8211E extension pages
From: Matthias Kaehlcke @ 2019-07-03 22:56 UTC (permalink / raw)
To: Heiner Kallweit
Cc: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <3e47639a-bbbb-f438-bc66-a29423090e95@gmail.com>
On Wed, Jul 03, 2019 at 11:27:41PM +0200, Heiner Kallweit wrote:
> On 03.07.2019 23:24, Matthias Kaehlcke wrote:
> > On Wed, Jul 03, 2019 at 11:01:09PM +0200, Heiner Kallweit wrote:
> >> On 03.07.2019 22:36, Matthias Kaehlcke wrote:
> >>> On Wed, Jul 03, 2019 at 10:12:12PM +0200, Heiner Kallweit wrote:
> >>>> On 03.07.2019 21:37, Matthias Kaehlcke wrote:
> >>>>> The RTL8211E has extension pages, which can be accessed after
> >>>>> selecting a page through a custom method. Add a function to
> >>>>> modify bits in a register of an extension page and a helper for
> >>>>> selecting an ext page.
> >>>>>
> >>>>> rtl8211e_modify_ext_paged() is inspired by its counterpart
> >>>>> phy_modify_paged().
> >>>>>
> >>>>> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> >>>>> ---
> >>>>> Changes in v2:
> >>>>> - assign .read/write_page handlers for RTL8211E
> >>>>
> >>>> Maybe this was planned, but it's not part of the patch.
> >>>
> >>> Oops, it was definitely there when I tested ... I guess this got
> >>> somehow lost when changing the patch order and resolving minor
> >>> conflicts, seems like I only build tested after that :/
> >>>
> >> RTL8211E also supports normal pages (reg 0x1f = page).
> >> See e.g. rtl8168e_2_hw_phy_config in the r8169 driver, this network
> >> chip has an integrated RTL8211E PHY. There settings on page 3 and 5
> >> are done.
> >> Therefore I would prefer to use .read/write_page for normal paging
> >> in all Realtek PHY drivers. Means the code here would remain as it
> >> is and just the changelog would need to be fixed.
> >
> > Do I understand correctly that you suggest an additional patch that
> > assigns .read/write_page() for all entries of realtek_drvs?
> >
>
> No, basically all the Realtek PHY drivers use the following already:
> .read_page = rtl821x_read_page,
> .write_page = rtl821x_write_page,
> What I mean is that this should stay as it is, and not be overwritten
> with the extended paging.
I now see the source of our/my misunderstanding. I'm working on a 4.19
kernel, which doesn't have your recent patch:
commit daf3ddbe11a2ff74c95bc814df8e5fe3201b4cb5
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri May 10 22:11:26 2019 +0200
net: phy: realtek: add missing page operations
That's what I intended to do for RTL8211E, no need to overwrite it
with the extended paging.
Thanks
Matthias
^ permalink raw reply
* [PATCH iproute2 1/2] tc: added mask parameter in skbedit action
From: Roman Mashak @ 2019-07-03 23:05 UTC (permalink / raw)
To: stephen; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri, Roman Mashak
Add 32-bit missing mask attribute in iproute2/tc, which has been long
supported by the kernel side.
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
---
tc/m_skbedit.c | 30 ++++++++++++++++++++++++++----
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/tc/m_skbedit.c b/tc/m_skbedit.c
index b6b839f8ef6c..f47c9705a990 100644
--- a/tc/m_skbedit.c
+++ b/tc/m_skbedit.c
@@ -33,7 +33,7 @@ static void explain(void)
fprintf(stderr, "Usage: ... skbedit <[QM] [PM] [MM] [PT] [IF]>\n"
"QM = queue_mapping QUEUE_MAPPING\n"
"PM = priority PRIORITY\n"
- "MM = mark MARK\n"
+ "MM = mark MARK[/MASK]\n"
"PT = ptype PACKETYPE\n"
"IF = inheritdsfield\n"
"PACKETYPE = is one of:\n"
@@ -41,6 +41,7 @@ static void explain(void)
"QUEUE_MAPPING = device transmit queue to use\n"
"PRIORITY = classID to assign to priority field\n"
"MARK = firewall mark to set\n"
+ "MASK = mask applied to firewall mark (0xffffffff by default)\n"
"note: inheritdsfield maps DS field to skb->priority\n");
}
@@ -61,7 +62,7 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
struct rtattr *tail;
unsigned int tmp;
__u16 queue_mapping, ptype;
- __u32 flags = 0, priority, mark;
+ __u32 flags = 0, priority, mark, mask;
__u64 pure_flags = 0;
struct tc_skbedit sel = { 0 };
@@ -89,12 +90,26 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
}
ok++;
} else if (matches(*argv, "mark") == 0) {
- flags |= SKBEDIT_F_MARK;
+ char *slash;
+
NEXT_ARG();
+ slash = strchr(*argv, '/');
+ if (slash)
+ *slash = '\0';
+
+ flags |= SKBEDIT_F_MARK;
if (get_u32(&mark, *argv, 0)) {
fprintf(stderr, "Illegal mark\n");
return -1;
}
+
+ if (slash) {
+ if (get_u32(&mask, slash + 1, 0)) {
+ fprintf(stderr, "Illegal mask\n");
+ return -1;
+ }
+ flags |= SKBEDIT_F_MASK;
+ }
ok++;
} else if (matches(*argv, "ptype") == 0) {
@@ -133,7 +148,7 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
if (matches(*argv, "index") == 0) {
NEXT_ARG();
if (get_u32(&sel.index, *argv, 10)) {
- fprintf(stderr, "Pedit: Illegal \"index\"\n");
+ fprintf(stderr, "skbedit: Illegal \"index\"\n");
return -1;
}
argc--;
@@ -159,6 +174,9 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
if (flags & SKBEDIT_F_MARK)
addattr_l(n, MAX_MSG, TCA_SKBEDIT_MARK,
&mark, sizeof(mark));
+ if (flags & SKBEDIT_F_MASK)
+ addattr_l(n, MAX_MSG, TCA_SKBEDIT_MASK,
+ &mask, sizeof(mask));
if (flags & SKBEDIT_F_PTYPE)
addattr_l(n, MAX_MSG, TCA_SKBEDIT_PTYPE,
&ptype, sizeof(ptype));
@@ -206,6 +224,10 @@ static int print_skbedit(struct action_util *au, FILE *f, struct rtattr *arg)
print_uint(PRINT_ANY, "mark", " mark %u",
rta_getattr_u32(tb[TCA_SKBEDIT_MARK]));
}
+ if (tb[TCA_SKBEDIT_MASK]) {
+ print_uint(PRINT_ANY, "mask", "/0x%x",
+ rta_getattr_u32(tb[TCA_SKBEDIT_MASK]));
+ }
if (tb[TCA_SKBEDIT_PTYPE] != NULL) {
ptype = rta_getattr_u16(tb[TCA_SKBEDIT_PTYPE]);
if (ptype == PACKET_HOST)
--
2.7.4
^ permalink raw reply related
* [PATCH iproute2 2/2] tc: document 'mask' parameter in skbedit man page
From: Roman Mashak @ 2019-07-03 23:05 UTC (permalink / raw)
To: stephen; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri, Roman Mashak
In-Reply-To: <1562195132-9829-1-git-send-email-mrv@mojatatu.com>
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
---
man/man8/tc-skbedit.8 | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/man/man8/tc-skbedit.8 b/man/man8/tc-skbedit.8
index 2459198261e6..704f63bdb061 100644
--- a/man/man8/tc-skbedit.8
+++ b/man/man8/tc-skbedit.8
@@ -9,8 +9,7 @@ skbedit - SKB editing action
.IR QUEUE_MAPPING " ] ["
.B priority
.IR PRIORITY " ] ["
-.B mark
-.IR MARK " ] ["
+.BI mark " MARK\fR[\fB/\fIMASK] ] ["
.B ptype
.IR PTYPE " ] ["
.BR inheritdsfield " ]"
@@ -49,12 +48,14 @@ or a hexadecimal major class ID optionally followed by a colon
.RB ( : )
and a hexadecimal minor class ID.
.TP
-.BI mark " MARK"
+.BI mark " MARK\fR[\fB/\fIMASK]"
Change the packet's firewall mark value.
.I MARK
is an unsigned 32bit value in automatically detected format (i.e., prefix with
.RB ' 0x '
for hexadecimal interpretation, etc.).
+.I MASK
+defines the 32-bit mask selecting bits of mark value. Default is 0xffffffff.
.TP
.BI ptype " PTYPE"
Override the packet's type. Useful for setting packet type to host when
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 0/2] Mellanox, mlx5 devlink versions query
From: Saeed Mahameed @ 2019-07-03 23:07 UTC (permalink / raw)
To: David Miller; +Cc: Saeed Mahameed, Linux Netdev List
In-Reply-To: <20190703.134935.540885263693556753.davem@davemloft.net>
On Wed, Jul 3, 2019 at 1:49 PM David Miller <davem@davemloft.net> wrote:
>
> From: David Miller <davem@davemloft.net>
> Date: Wed, 03 Jul 2019 13:47:00 -0700 (PDT)
>
> > From: Saeed Mahameed <saeedm@mellanox.com>
> > Date: Tue, 2 Jul 2019 23:55:07 +0000
> >
> >> This humble 2 patch series from Shay adds the support for devlink fw
> >> versions query to mlx5 driver.
> >>
> >> In the first patch we implement the needed fw commands to support this
> >> feature.
> >> In the 2nd patch we implement the devlink callbacks themselves.
> >>
> >> I am not sending this as a pull request since i am not sure when my next
> >> pull request is going to be ready, and these two patches are straight
> >> forward net-next patches.
> >
> > Series applied to net-next, thanks.
>
> This doesn't build, there is some dependency...
>
> [davem@localhost net-next]$ make -s -j14
> In file included from ./include/linux/mlx5/driver.h:51,
> from drivers/net/ethernet/mellanox/mlx5/core/fw.c:33:
> drivers/net/ethernet/mellanox/mlx5/core/fw.c: In function ‘mlx5_reg_mcqi_query’:
> ./include/linux/mlx5/device.h:68:36: error: invalid application of ‘sizeof’ to incomplete type ‘union mlx5_ifc_mcqi_reg_data_bits’
> #define MLX5_UN_SZ_DW(typ) (sizeof(union mlx5_ifc_##typ##_bits) / 32)
> ^~~~~
Yep, My bad :(, I thought [1] was part of my last pull, but it wasn't
One way to solve this is if you pull latest mlx5-next branch form:
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git
All patches there already passed review on net-next and rdma-next mailing lists.
Or just wait for my next pull request.
sorry for this!
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/commit/?h=mlx5-next&id=a82e0b5bdac29d9719d3ca2df01494a7947351aa
^ permalink raw reply
* Re: pull-request: bpf-next 2019-07-03
From: Saeed Mahameed @ 2019-07-03 23:11 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David S. Miller, Alexei Starovoitov, Saeed Mahameed,
Linux Netdev List, bpf
In-Reply-To: <20190703224740.15354-1-daniel@iogearbox.net>
On Wed, Jul 3, 2019 at 3:47 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> Hi David,
>
> The following pull-request contains BPF updates for your *net-next* tree.
>
> There is a minor merge conflict in mlx5 due to 8960b38932be ("linux/dim:
> Rename externally used net_dim members") which has been pulled into your
> tree in the meantime, but resolution seems not that bad ... getting current
> bpf-next out now before there's coming more on mlx5. ;) I'm Cc'ing Saeed
> just so he's aware of the resolution below:
>
> ** First conflict in drivers/net/ethernet/mellanox/mlx5/core/en_main.c:
>
> <<<<<<< HEAD
> static int mlx5e_open_cq(struct mlx5e_channel *c,
> struct dim_cq_moder moder,
> struct mlx5e_cq_param *param,
> struct mlx5e_cq *cq)
> =======
> int mlx5e_open_cq(struct mlx5e_channel *c, struct net_dim_cq_moder moder,
> struct mlx5e_cq_param *param, struct mlx5e_cq *cq)
> >>>>>>> e5a3e259ef239f443951d401db10db7d426c9497
>
> Resolution is to take the second chunk and rename net_dim_cq_moder into
> dim_cq_moder. Also the signature for mlx5e_open_cq() in ...
>
> drivers/net/ethernet/mellanox/mlx5/core/en.h +977
>
> ... and in mlx5e_open_xsk() ...
>
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c +64
>
> ... needs the same rename from net_dim_cq_moder into dim_cq_moder.
>
> ** Second conflict in drivers/net/ethernet/mellanox/mlx5/core/en_main.c:
>
> <<<<<<< HEAD
> int cpu = cpumask_first(mlx5_comp_irq_get_affinity_mask(priv->mdev, ix));
> struct dim_cq_moder icocq_moder = {0, 0};
> struct net_device *netdev = priv->netdev;
> struct mlx5e_channel *c;
> unsigned int irq;
> =======
> struct net_dim_cq_moder icocq_moder = {0, 0};
> >>>>>>> e5a3e259ef239f443951d401db10db7d426c9497
>
> Take the second chunk and rename net_dim_cq_moder into dim_cq_moder
> as well.
>
Thank you Daniel, Looks Good,
I didn't test this since i am traveling, will double check tomorrow.
but basically all you need is to pass the build.
Thanks,
Saeed.
^ 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