* [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 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
* 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 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: 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][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 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
* [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 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
* 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 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 v2 7/7] net: phy: realtek: configure RTL8211E LEDs
From: Matthias Kaehlcke @ 2019-07-03 20:43 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, Rob Herring, Mark Rutland, Florian Fainelli,
Heiner Kallweit, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <20190703201032.GG18473@lunn.ch>
On Wed, Jul 03, 2019 at 10:10:32PM +0200, Andrew Lunn wrote:
> > + for (i = 0; i < count; i++) {
> > + u32 val;
> > +
> > + of_property_read_u32_index(dev->of_node,
> > + "realtek,led-modes", i, &val);
>
> Please validate the value, 0 - 7.
ok, will be 0-7 and 0x10000 - 0x10007 (w/ RTL8211E_LINK_ACTIVITY) though.
This is the somewhat quirky part about the property, each value
translates to two registers. This seemed to be the cleanest solution
from the bindings perspective, but I'm open to other suggestions.
^ permalink raw reply
* Re: [PATCH net-next 0/3 v2] macsec: a few cleanups in the receive path
From: David Miller @ 2019-07-03 20:42 UTC (permalink / raw)
To: ast; +Cc: netdev, sd
In-Reply-To: <7ec44dd08280f0b32dcf18aa35f687fc227c0197.camel@domdv.de>
From: Andreas Steinmetz <ast@domdv.de>
Date: Tue, 02 Jul 2019 22:49:54 +0200
> This patchset removes some unnecessary code in the receive path of the
> macsec driver, and re-indents the error handling after calling
> macsec_decrypt to make the post-processing clearer.
>
> This is a combined effort of Sabrina Dubroca <sd@queasysnail.net> and me.
>
> Change in 3/3:
>
> The patch now only moves the IS_ERR(skb) case under the block where
> macsec_decrypt() is called, but not the call to macsec_post_decrypt().
>
I really don't like these changes, especially patches #1 and #2.
Like Willem I don't think you can blindly remove the share check like
this (and you ignored his feedback about this from v1 it seems), and
the removal is *pskb assignment to NULL is undoing defensive
programming.
I'm not applying this series.
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: stmmac: Implement RX Coalesce Frames setting
From: Jakub Kicinski @ 2019-07-03 20:41 UTC (permalink / raw)
To: Jose Abreu
Cc: linux-kernel, netdev, linux-stm32, linux-arm-kernel, Joao Pinto,
David S . Miller, Giuseppe Cavallaro, Alexandre Torgue,
Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai
In-Reply-To: <003df660052f33891ab74ee79c5f1272b72bde54.1562149883.git.joabreu@synopsys.com>
On Wed, 3 Jul 2019 12:37:48 +0200, Jose Abreu wrote:
> Add support for coalescing RX path by specifying number of frames which
> don't need to have interrupt on completion bit set.
>
> This is only available when RX Watchdog is enabled.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Cc: Joao Pinto <jpinto@synopsys.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
^ permalink raw reply
* Re: [PATCH v2 4/7] net: phy: realtek: Enable accessing RTL8211E extension pages
From: Matthias Kaehlcke @ 2019-07-03 20:36 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: <dd7a569b-41e4-5925-88fc-227e69c82f67@gmail.com>
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 :/
> > - 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.
^ permalink raw reply
* Re: [PATCH v2 2/7] net: phy: realtek: Allow disabling RTL8211E EEE LED mode
From: Matthias Kaehlcke @ 2019-07-03 20:32 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: <743dda1b-532d-175f-1f87-5d80ba4a2e94@gmail.com>
Hi,
On Wed, Jul 03, 2019 at 10:09:39PM +0200, Heiner Kallweit wrote:
> On 03.07.2019 21:37, Matthias Kaehlcke wrote:
> > EEE LED mode is enabled by default on the RTL8211E. Disable it when
> > the device tree property 'realtek,eee-led-mode-disable' exists.
> >
> > The magic values to disable EEE LED mode were taken from the RTL8211E
> > datasheet, unfortunately they are not further documented.
> >
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> > Changes in v2:
> > - patch added to the series
> > ---
> > drivers/net/phy/realtek.c | 37 ++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 36 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> > index a669945eb829..eb815cbe1e72 100644
> > --- a/drivers/net/phy/realtek.c
> > +++ b/drivers/net/phy/realtek.c
> > @@ -9,8 +9,9 @@
> > * Copyright (c) 2004 Freescale Semiconductor, Inc.
> > */
> > #include <linux/bitops.h>
> > -#include <linux/phy.h>
> > #include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/phy.h>
> >
> > #define RTL821x_PHYSR 0x11
> > #define RTL821x_PHYSR_DUPLEX BIT(13)
> > @@ -26,6 +27,10 @@
> > #define RTL821x_EXT_PAGE_SELECT 0x1e
> > #define RTL821x_PAGE_SELECT 0x1f
> >
> > +/* RTL8211E page 5 */
> > +#define RTL8211E_EEE_LED_MODE1 0x05
> > +#define RTL8211E_EEE_LED_MODE2 0x06
> > +
> > #define RTL8211F_INSR 0x1d
> >
> > #define RTL8211F_TX_DELAY BIT(8)
> > @@ -53,6 +58,35 @@ static int rtl821x_write_page(struct phy_device *phydev, int page)
> > return __phy_write(phydev, RTL821x_PAGE_SELECT, page);
> > }
> >
> > +static int rtl8211e_disable_eee_led_mode(struct phy_device *phydev)
> > +{
>
> You define return type int but AFAICS the return value is never used,
> also in subsequent patches.
ok, I'll change it to void
> > + int ret = 0;
> > + int oldpage;
> > +
> > + oldpage = phy_select_page(phydev, 5);
> > + if (oldpage < 0)
> > + goto out;
> > +
> > + /* write magic values to disable EEE LED mode */
> > + ret = __phy_write(phydev, RTL8211E_EEE_LED_MODE1, 0x8b82);
> > + if (ret)
> > + goto out;
> > +
> > + ret = __phy_write(phydev, RTL8211E_EEE_LED_MODE2, 0x052b);
> > +
> > +out:
> > + return phy_restore_page(phydev, oldpage, ret);
> > +}
> > +
> > +static int rtl8211e_config_init(struct phy_device *phydev)
> > +{
> > + struct device *dev = &phydev->mdio.dev;
> > +
> > + if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
> > + rtl8211e_disable_eee_led_mode(phydev);
> > +
> > + return 0;
> > +}
>
> I suppose checkpatch complains about the missing empty line.
> You add it in a later patch, in case of a v3 you could fix that.
Actually checkpatch does not complain, I'll fix it in v3.
Thanks
Matthias
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: net: realtek: Add property to configure LED mode
From: Heiner Kallweit @ 2019-07-03 20:22 UTC (permalink / raw)
To: Matthias Kaehlcke, David S . Miller, Rob Herring, Mark Rutland,
Andrew Lunn, Florian Fainelli
Cc: netdev, devicetree, linux-kernel, Douglas Anderson
In-Reply-To: <e7fa2c8c-d53e-2480-d239-e2c0b362dc4f@gmail.com>
On 03.07.2019 22:13, Heiner Kallweit wrote:
> On 03.07.2019 21:37, 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".
>> +
>> 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)
>
> I don't see where this is used.
>
Clear now, disregard my comment.
>> +
>> +#endif
>>
>
^ permalink raw reply
* Re: [PATCH v2 7/7] net: phy: realtek: configure RTL8211E LEDs
From: Heiner Kallweit @ 2019-07-03 20:28 UTC (permalink / raw)
To: Matthias Kaehlcke, David S . Miller, Rob Herring, Mark Rutland,
Andrew Lunn, Florian Fainelli
Cc: netdev, devicetree, linux-kernel, Douglas Anderson
In-Reply-To: <20190703193724.246854-7-mka@chromium.org>
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);
> + 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.
> + goto err;
> + }
> +
> + ret = __phy_modify(phydev, RTL8211E_LACR,
> + RLT8211E_LACR_LEDACTCTRL_MASK, lacr_bits);
> + if (ret) {
> + dev_err(dev, "failed to write LACR reg: %d\n", ret);
> + goto err;
> + }
> +
> + ret = __phy_modify(phydev, RTL8211E_LCR,
> + RTL8211E_LCR_LEDCTRL_MASK, lcr_bits);
> + if (ret)
> + dev_err(dev, "failed to write LCR reg: %d\n", ret);
> +
> +err:
> + return phy_restore_page(phydev, oldpage, ret);
> +}
> +
> static int rtl8211e_config_init(struct phy_device *phydev)
> {
> struct device *dev = &phydev->mdio.dev;
> @@ -137,8 +197,7 @@ static int rtl8211e_config_init(struct phy_device *phydev)
> dev_err(dev, "failed to enable SSC on RXC: %d\n", ret);
> }
>
> - if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
> - rtl8211e_disable_eee_led_mode(phydev);
> + rtl8211e_config_leds(phydev);
>
> return 0;
> }
>
^ permalink raw reply
* Re: [Patch net] bonding: validate ip header before check IPPROTO_IGMP
From: David Miller @ 2019-07-03 20:26 UTC (permalink / raw)
To: xiyou.wangcong
Cc: netdev, syzbot+e5be16aa39ad6e755391, j.vosburgh, vfalico, andy
In-Reply-To: <20190702034024.25962-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 1 Jul 2019 20:40:24 -0700
> bond_xmit_roundrobin() checks for IGMP packets but it parses
> the IP header even before checking skb->protocol.
>
> We should validate the IP header with pskb_may_pull() before
> using iph->protocol.
>
> Reported-and-tested-by: syzbot+e5be16aa39ad6e755391@syzkaller.appspotmail.com
> Fixes: a2fd940f4cff ("bonding: fix broken multicast with round-robin mode")
> Cc: Jay Vosburgh <j.vosburgh@gmail.com>
> Cc: Veaceslav Falico <vfalico@gmail.com>
> Cc: Andy Gospodarek <andy@greyhouse.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: net: Add bindings for Realtek PHYs
From: David Miller @ 2019-07-03 20:21 UTC (permalink / raw)
To: mka
Cc: robh+dt, mark.rutland, andrew, f.fainelli, hkallweit1, netdev,
devicetree, linux-kernel, dianders
In-Reply-To: <20190703193724.246854-1-mka@chromium.org>
Please repost this patch set with a proper "[PATCH 0/7] ..." header posting
describing at a high level what this patch series is doing, how it is doing
it, and why it is doing it that way.
Such header postings are absolutely essential for the proper understanding
and review of your changes.
Thank you.
^ permalink raw reply
* Re: [PATCH rdma-next v2 00/13] DEVX asynchronous events
From: Jason Gunthorpe @ 2019-07-03 20:19 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Saeed Mahameed,
Yishai Hadas, linux-netdev
In-Reply-To: <20190630162334.22135-1-leon@kernel.org>
On Sun, Jun 30, 2019 at 07:23:21PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Changelog:
> v1 -> v2:
> * Added Saeed's ack to net patches
> * Patch #2:
> * Fix to gather user asynchronous events on top of kernel events.
> * Patch #7:
> * Fix obj_id to be 32 bits.
> * Patch #8:
> * Inline async_event_queue applicable fields into devx_async_event_file.
> * Move to use bitfields in few places rather than flags.
> * Shorten name of UAPI attribute.
> * Patch #10:
> * Use explicitly 'struct file *' instead of void *
> * Store struct devx_async_event_file * instead of uobj * on the subscription.
> * Drop 'is_obj_related' and use list_empty instead.
> * Drop the temp arrays as part of the subscription API and move to simpler logic.
> * Revise devx_cleanup_subscription() to be success oriented without
> the is_close flag.
> * Leave key level 1 in the tree upon bad flow to prevent a race with IRQ flow.
> * Fix some styling notes.
> * Patch #11:
> * Use rcu read lock also for the un-affiliated event flow.
> * Improve locking scheme as part of read events.
> * Return -EIO as soon as destroyed occurred.
> * Use a better errno as part read event failure when the buffer size
> was too small.
> * Upon hot unplug call wake_up_interruptible() unconditionally.
> * Use eqe->data for affiliated events header.
> * Fix some styling notes.
> * Patch #12:
> * Use rcu read lock also for the first XA layer.
> * Patch #13:
> * A new patch to clean up mdev usage from devx code, it can be accessed
> from ib_dev now.
> v0 -> v1:
> * Fix the unbind / hot unplug flows to work properly.
> * Fix Ref count handling on the eventfd mode in some flow.
> * Rebased to latest rdma-next
>
> Thanks
>
> >From Yishai:
>
> This series enables RDMA applications that use the DEVX interface to
> subscribe and read device asynchronous events.
>
> The solution is designed to allow extension of events in the future
> without need to perform any changes in the driver code.
>
> To enable that few changes had been done in mlx5_core, it includes:
> * Reading device event capabilities that are user related
> (affiliated and un-affiliated) and set the matching mask upon
> creating the matching EQ.
> * Enable DEVX/mlx5_ib to register for ANY event instead of the option to
> get some hard-coded ones.
> * Enable DEVX/mlx5_ib to get the device raw data for CQ completion events.
> * Enhance mlx5_core_create/destroy CQ to enable DEVX using them so that CQ
> events will be reported as well.
>
> In mlx5_ib layer the below changes were done:
> * A new DEVX API was introduced to allocate an event channel by using
> the uverbs FD object type.
> * Implement the FD channel operations to enable read/poo/close over it.
> * A new DEVX API was introduced to subscribe for specific events over an
> event channel.
> * Manage an internal data structure over XA(s) to subscribe/dispatch events
> over the different event channels.
> * Use from DEVX the mlx5_core APIs to create/destroy a CQ to be able to
> get its relevant events.
Applied to for-next, thanks
Jason
^ permalink raw reply
* Re: [PATCH rdma-next v2 10/13] IB/mlx5: Enable subscription for device events over DEVX
From: Jason Gunthorpe @ 2019-07-03 20:18 UTC (permalink / raw)
To: Leon Romanovsky, Matthew Wilcox
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Saeed Mahameed,
Yishai Hadas, linux-netdev
In-Reply-To: <20190630162334.22135-11-leon@kernel.org>
On Sun, Jun 30, 2019 at 07:23:31PM +0300, Leon Romanovsky wrote:
> From: Yishai Hadas <yishaih@mellanox.com>
>
> Enable subscription for device events over DEVX.
>
> Each subscription is added to the two level XA data structure according
> to its event number and the DEVX object information in case was given
> with the given target fd.
>
> Those events will be reported over the given fd once will occur.
> Downstream patches will mange the dispatching to any subscription.
BTW Matt,
Here is another vote for a 64 bit indexing xarray in the kernel.. Any
further thought on doing that?
Jason
^ permalink raw reply
* Re: [PATCH v2 4/7] net: phy: realtek: Enable accessing RTL8211E extension pages
From: Heiner Kallweit @ 2019-07-03 20:12 UTC (permalink / raw)
To: Matthias Kaehlcke, David S . Miller, Rob Herring, Mark Rutland,
Andrew Lunn, Florian Fainelli
Cc: netdev, devicetree, linux-kernel, Douglas Anderson
In-Reply-To: <20190703193724.246854-4-mka@chromium.org>
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.
> - 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.
> +{
> + int ret = 0;
> + int oldpage;
> + int new;
> +
> + oldpage = rtl8211e_select_ext_page(phydev, page);
> + if (oldpage < 0)
> + goto out;
> +
> + ret = __phy_read(phydev, regnum);
> + if (ret < 0)
> + goto out;
> +
> + new = (ret & ~mask) | set;
> + if (new != ret)
> + ret = __phy_write(phydev, regnum, new);
> +
> +out:
> + return phy_restore_page(phydev, oldpage, ret);
> +}
> +
> static int rtl8211e_disable_eee_led_mode(struct phy_device *phydev)
> {
> int ret = 0;
> @@ -87,6 +128,7 @@ static int rtl8211e_config_init(struct phy_device *phydev)
>
> return 0;
> }
> +
> static int rtl8201_ack_interrupt(struct phy_device *phydev)
> {
> int err;
>
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: net: realtek: Add property to configure LED mode
From: Heiner Kallweit @ 2019-07-03 20:13 UTC (permalink / raw)
To: Matthias Kaehlcke, David S . Miller, Rob Herring, Mark Rutland,
Andrew Lunn, Florian Fainelli
Cc: netdev, devicetree, linux-kernel, Douglas Anderson
In-Reply-To: <20190703193724.246854-6-mka@chromium.org>
On 03.07.2019 21:37, 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".
> +
> 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)
I don't see where this is used.
> +
> +#endif
>
^ permalink raw reply
* Re: [PATCH v2 2/7] net: phy: realtek: Allow disabling RTL8211E EEE LED mode
From: Heiner Kallweit @ 2019-07-03 20:09 UTC (permalink / raw)
To: Matthias Kaehlcke, David S . Miller, Rob Herring, Mark Rutland,
Andrew Lunn, Florian Fainelli
Cc: netdev, devicetree, linux-kernel, Douglas Anderson
In-Reply-To: <20190703193724.246854-2-mka@chromium.org>
On 03.07.2019 21:37, Matthias Kaehlcke wrote:
> EEE LED mode is enabled by default on the RTL8211E. Disable it when
> the device tree property 'realtek,eee-led-mode-disable' exists.
>
> The magic values to disable EEE LED mode were taken from the RTL8211E
> datasheet, unfortunately they are not further documented.
>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> Changes in v2:
> - patch added to the series
> ---
> drivers/net/phy/realtek.c | 37 ++++++++++++++++++++++++++++++++++++-
> 1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> index a669945eb829..eb815cbe1e72 100644
> --- a/drivers/net/phy/realtek.c
> +++ b/drivers/net/phy/realtek.c
> @@ -9,8 +9,9 @@
> * Copyright (c) 2004 Freescale Semiconductor, Inc.
> */
> #include <linux/bitops.h>
> -#include <linux/phy.h>
> #include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/phy.h>
>
> #define RTL821x_PHYSR 0x11
> #define RTL821x_PHYSR_DUPLEX BIT(13)
> @@ -26,6 +27,10 @@
> #define RTL821x_EXT_PAGE_SELECT 0x1e
> #define RTL821x_PAGE_SELECT 0x1f
>
> +/* RTL8211E page 5 */
> +#define RTL8211E_EEE_LED_MODE1 0x05
> +#define RTL8211E_EEE_LED_MODE2 0x06
> +
> #define RTL8211F_INSR 0x1d
>
> #define RTL8211F_TX_DELAY BIT(8)
> @@ -53,6 +58,35 @@ static int rtl821x_write_page(struct phy_device *phydev, int page)
> return __phy_write(phydev, RTL821x_PAGE_SELECT, page);
> }
>
> +static int rtl8211e_disable_eee_led_mode(struct phy_device *phydev)
> +{
You define return type int but AFAICS the return value is never used,
also in subsequent patches.
> + int ret = 0;
> + int oldpage;
> +
> + oldpage = phy_select_page(phydev, 5);
> + if (oldpage < 0)
> + goto out;
> +
> + /* write magic values to disable EEE LED mode */
> + ret = __phy_write(phydev, RTL8211E_EEE_LED_MODE1, 0x8b82);
> + if (ret)
> + goto out;
> +
> + ret = __phy_write(phydev, RTL8211E_EEE_LED_MODE2, 0x052b);
> +
> +out:
> + return phy_restore_page(phydev, oldpage, ret);
> +}
> +
> +static int rtl8211e_config_init(struct phy_device *phydev)
> +{
> + struct device *dev = &phydev->mdio.dev;
> +
> + if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
> + rtl8211e_disable_eee_led_mode(phydev);
> +
> + return 0;
> +}
I suppose checkpatch complains about the missing empty line.
You add it in a later patch, in case of a v3 you could fix that.
> static int rtl8201_ack_interrupt(struct phy_device *phydev)
> {
> int err;
> @@ -310,6 +344,7 @@ static struct phy_driver realtek_drvs[] = {
> .name = "RTL8211E Gigabit Ethernet",
> .config_init = &rtl8211e_config_init,
> .ack_interrupt = &rtl821x_ack_interrupt,
> + .config_init = &rtl8211e_config_init,
> .config_intr = &rtl8211e_config_intr,
> .suspend = genphy_suspend,
> .resume = genphy_resume,
>
^ 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