* Re: [PATCH net-next 5/7] net: phy: marvell10g: Force reading of 2.5/5G PMA extended abilities
From: Maxime Chevallier @ 2019-01-28 14:26 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, davem, netdev, linux-kernel, Florian Fainelli,
Heiner Kallweit, linux-arm-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
mw
In-Reply-To: <20190121130030.i5kkjb55gwttobvq@e5254000004ec.dyn.armlinux.org.uk>
Hello Russell,
On Mon, 21 Jan 2019 13:00:30 +0000
Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
>On Mon, Jan 21, 2019 at 01:29:45PM +0100, Maxime Chevallier wrote:
>> Hello Russell,
>>
>> On Mon, 21 Jan 2019 10:52:06 +0000
>> Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
>> >It's entirely possible that the 3310 switches to different hardware
>> >blocks for 2.5G and 5G speeds, and reading _just_ the 1.4 register
>> >is not sufficient.
>>
>> I agree with you but in that particular case, I think we are reading
>> from the correct device. The datasheet itself says that we should be
>> reading 1.4 and 1.11 as we expect, with 2.5G/5G support being set (these
>> registers are read-only, and the datasheet's values aren't what we
>> actually read).
>
>No, you missed what I was saying.
>
>The 88x3310 is a hybrid device. It contains multiple instances of
>each individual device at different offsets in each MMD address space.
Ah I see, I indeed thought you refered to the MMDs.
[...]
>The exception seems to be the PMA/PMD MMD which I've only discovered
>a single instance.
Yes there only seems to be one. There are some other registers in the
1.0xCxxx range, but those who are documented don't help a lot with
determing wether or not these modes are supported.
I wonder if these values are correctly reported in newer PHY firmware
revisions.
I've checked other PCS instances, but it seems the one at 3.0x0xxx is
the one used in 2.5/5GBASET.
I've tested with other PHYs from this family, it looks like they are
derivatives of the 33x0 design, with the addition/removal of internal
IPs. Since the 2110 returns the correct values and has a similar
design, with the PMA returning the correct abilities, I think we are
reading from the correct instance.
Thanks,
Maxime
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next v8 6/8] devlink: Add devlink notifications support for port params
From: Jiri Pirko @ 2019-01-28 14:23 UTC (permalink / raw)
To: Vasundhara Volam
Cc: davem, michael.chan, jiri, jakub.kicinski, mkubecek, netdev
In-Reply-To: <1548678627-21938-7-git-send-email-vasundhara-v.volam@broadcom.com>
Mon, Jan 28, 2019 at 01:30:25PM CET, vasundhara-v.volam@broadcom.com wrote:
>Add notification call for devlink port param set, register and unregister
>functions.
>Add devlink_port_param_value_changed() function to enable the driver notify
>devlink on value change. Driver should use this function after value was
>changed on any configuration mode part to driverinit.
>
>v7->v8:
>Order devlink_port_param_value_changed() definitions followed by
>devlink_param_value_changed()
>
>Cc: Jiri Pirko <jiri@mellanox.com>
>Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH] ucc_geth: Reset BQL queue when stopping device
From: Mathias Thore @ 2019-01-28 14:36 UTC (permalink / raw)
To: Christophe Leroy, leoyang.li@nxp.com, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David Gounaris, Joakim Tjernlund
In-Reply-To: <6bc7e64a-b91a-cb6e-ed65-5e412cef3a76@c-s.fr>
Hi,
This is what we observed: there was a storm on the medium so that our controller could not do its TX, resulting in timeout. When timeout occurs, the driver clears all descriptors from the TX queue. The function called in this patch is used to reflect this clearing also in the BQL layer. Without it, the controller would get stuck, unable to perform TX, even several minutes after the storm had ended. Bringing the device down and then up again would solve the problem, but this patch also solves it automatically.
Some other drivers do the same, for example e1000e driver calls netdev_reset_queue in its e1000_clean_tx_ring function. It is possible that other drivers should do the same; I have no way of verifying this.
Regards,
Mathias
--
From: Christophe Leroy <christophe.leroy@c-s.fr>
Sent: Monday, January 28, 2019 10:48 AM
To: Mathias Thore; leoyang.li@nxp.com; netdev@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; David Gounaris; Joakim Tjernlund
Subject: Re: [PATCH] ucc_geth: Reset BQL queue when stopping device
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi,
Le 28/01/2019 à 10:07, Mathias Thore a écrit :
> After a timeout event caused by for example a broadcast storm, when
> the MAC and PHY are reset, the BQL TX queue needs to be reset as
> well. Otherwise, the device will exhibit severe performance issues
> even after the storm has ended.
What are the symptomns ?
Is this reset needed on any network driver in that case, or is it
something particular for the ucc_geth ?
For instance, the freescale fs_enet doesn't have that reset. Should it
have it too ?
Christophe
>
> Co-authored-by: David Gounaris <david.gounaris@infinera.com>
> Signed-off-by: Mathias Thore <mathias.thore@infinera.com>
> ---
> drivers/net/ethernet/freescale/ucc_geth.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
> index c3d539e209ed..eb3e65e8868f 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.c
> +++ b/drivers/net/ethernet/freescale/ucc_geth.c
> @@ -1879,6 +1879,8 @@ static void ucc_geth_free_tx(struct ucc_geth_private *ugeth)
> u16 i, j;
> u8 __iomem *bd;
>
> + netdev_reset_queue(ugeth->ndev);
> +
> ug_info = ugeth->ug_info;
> uf_info = &ug_info->uf_info;
>
>
^ permalink raw reply
* Re: [PATCH net-next] mdio_bus: Fix PTR_ERR() usage after initialization to constant
From: Andrew Lunn @ 2019-01-28 14:36 UTC (permalink / raw)
To: YueHaibing; +Cc: davem, f.fainelli, hkallweit1, linux-kernel, netdev
In-Reply-To: <20190128132409.17736-1-yuehaibing@huawei.com>
On Mon, Jan 28, 2019 at 09:24:09PM +0800, YueHaibing wrote:
> Fix coccinelle warning:
>
> ./drivers/net/phy/mdio_bus.c:51:5-12: ERROR: PTR_ERR applied after initialization to constant on line 44
> ./drivers/net/phy/mdio_bus.c:52:5-12: ERROR: PTR_ERR applied after initialization to constant on line 44
>
> fix this by using IS_ERR before PTR_ERR
>
> Fixes: bafbdd527d56 ("phylib: Add device reset GPIO support")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/phy/mdio_bus.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 3d31358..802716a 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -42,17 +42,20 @@
> static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
> {
> struct gpio_desc *gpiod = NULL;
> + int ret;
>
Hi YueHaibing
I think i prefer the simpler fix:
static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
{
- struct gpio_desc *gpiod = NULL;
+ struct gpio_desc *gpiod = ERR_PTR(-ENOENT);
Totally untested...
Andrew
> /* Deassert the optional reset signal */
> if (mdiodev->dev.of_node)
> gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
> "reset-gpios", 0, GPIOD_OUT_LOW,
> "PHY reset");
> - if (PTR_ERR(gpiod) == -ENOENT ||
> - PTR_ERR(gpiod) == -ENOSYS)
> - gpiod = NULL;
> - else if (IS_ERR(gpiod))
> - return PTR_ERR(gpiod);
> + if (IS_ERR(gpiod)) {
> + ret = PTR_ERR(gpiod);
> + if (ret == -ENOENT || ret == -ENOSYS)
> + gpiod = NULL;
> + else
> + return ret;
> + }
>
> mdiodev->reset = gpiod;
>
> --
> 2.7.4
>
>
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] net: dsa: mv88e6xxx: Save switch rules
From: Miquel Raynal @ 2019-01-28 14:24 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Vivien Didelot, David S. Miller, netdev,
linux-kernel, Thomas Petazzoni, Gregory Clement, Antoine Tenart,
Maxime Chevallier, Nadav Haklai
In-Reply-To: <c1421a5d-5f92-bb86-b5cc-9fa19a1c8d9f@gmail.com>
Hi Florian,
Florian Fainelli <f.fainelli@gmail.com> wrote on Fri, 25 Jan 2019
10:37:38 -0800:
> Hi Miquel,
>
> On 1/25/19 1:55 AM, Miquel Raynal wrote:
> > The user might apply a specific switch configuration, with specific
> > forwarding rules, VLAN, bridges, etc.
> >
> > During suspend to RAM the switch power will be turned off and the
> > switch will lost its configuration. In an attempt to bring S2RAM
> > support to the mv88e6xxx DSA, let's first save these rules in a
> > per-chip list thanks to the mv88e6xxx_add/del_xxx_rule()
> > helpers. These helpers are then called from various callbacks:
> > * mv88e6xxx_port_fdb_add/del()
> > * mv88e6xxx_port_mdb_add/del()
> > * mv88e6xxx_port_vlan_add/del()
> > * mv88e6xxx_port_bridge_join/leave()
> > * mv88e6xxx_crosschip_bridge_join/leave()
> >
> > To avoid recursion problems when replaying the rules, the content of
> > the above *_add()/*_join() callbacks has been moved in separate
> > helpers with a '_' prefix. Hence, each callback just calls the
> > corresponding helper and the corresponding *_add_xxx_rule().
>
> None of this should be done in the driver IMHO, because this is
> presumably applicable to all switch devices that lose their state during
> suspend/resume, so at best, this should be moved to the core DSA layer,
> but doing this means that we should also have a well established
> contract between the DSA layer and individual switch drivers as far as
> quiescing/saving/restoring state goes.
>
> By moving things to the core we can also more tightly control what data
> structures get used to represent e.g.: VLANs, FDBs, MDBs etc and
> possibly push/utilize caching into the original subsystem. For instance
> VLAN/bridge already do maintain caches of VLANs, so if we could somehow
> expose those, we would not bloat the kernel's memory footprint by having
> an additional layer to maintain with identical information.
So you suggest to move the intelligence of FDBs/MDBs in net/dsa/port.c,
is this right?
I don't see where VLAN and bridge information are cached, can you point
me to the relevant locations?
What about cross-chip bridges? There is nothing about them in
net/dsa/port.c. The implementation I see in the mv88e6xxx driver
only touches the PVT but I don't get whether we should handle this
calls like regular bridge-join/leave events or not (maybe they are
cached with regular bridge events?).
Thanks,
Miquèl
^ permalink raw reply
* [PATCH net V2] net: i825xx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
From: Yang Wei @ 2019-01-28 14:42 UTC (permalink / raw)
To: netdev, davem; +Cc: andrew, Yang Wei
dev_consume_skb_irq() should be called in i596_interrupt() when skb
xmit done. It makes drop profiles(dropwatch, perf) more friendly.
Signed-off-by: Yang Wei <albin_yang@163.com>
---
drivers/net/ethernet/i825xx/82596.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/i825xx/82596.c b/drivers/net/ethernet/i825xx/82596.c
index d719668..855900a 100644
--- a/drivers/net/ethernet/i825xx/82596.c
+++ b/drivers/net/ethernet/i825xx/82596.c
@@ -1310,7 +1310,7 @@ static irqreturn_t i596_interrupt(int irq, void *dev_id)
dev->stats.tx_aborted_errors++;
}
- dev_kfree_skb_irq(skb);
+ dev_consume_skb_irq(skb);
tx_cmd->cmd.command = 0; /* Mark free */
break;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v2 1/2] net: dsa: mv88e6xxx: Save switch rules
From: Andrew Lunn @ 2019-01-28 14:44 UTC (permalink / raw)
To: Miquel Raynal
Cc: Florian Fainelli, Vivien Didelot, David S. Miller, netdev,
linux-kernel, Thomas Petazzoni, Gregory Clement, Antoine Tenart,
Maxime Chevallier, Nadav Haklai
In-Reply-To: <20190128152456.212ae5ac@xps13>
> I don't see where VLAN and bridge information are cached, can you point
> me to the relevant locations?
Miquèl
The bridge should have all that information. You need to ask it to
enumerate the current configuration and replay it to the switch.
There might be something in the Mellanox driver you can copy? But i've
not looked, i'm just guessing.
We also need to think about how we are going to test this. There is a
lot of state information in a switch. So we are going to need some
pretty good tests to show we have recreated all of it.
Andrew
^ permalink raw reply
* RE: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
From: Fabrizio Castro @ 2019-01-28 14:49 UTC (permalink / raw)
To: Simon Horman
Cc: Geert Uytterhoeven, Wolfgang Grandegger, Marc Kleine-Budde,
Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
David S. Miller, Magnus Damm, Geert Uytterhoeven, Chris Paterson,
Biju Das, linux-can@vger.kernel.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <20190128130111.t54jbcyx35fiymq6@verge.net.au>
> From: Simon Horman <horms@verge.net.au>
> Sent: 28 January 2019 13:01
> Subject: Re: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
>
> On Fri, Jan 25, 2019 at 11:33:41AM +0000, Fabrizio Castro wrote:
> > Hello Simon,
> >
> > Thank you for your feedback!
> >
> > > From: Simon Horman <horms@verge.net.au>
> > > Sent: 24 January 2019 10:01
> > > Subject: Re: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
> > >
> > > On Wed, Jan 23, 2019 at 12:18:45PM +0000, Fabrizio Castro wrote:
> > > > Hello Geert,
> > > >
> > > > Thank you for your feedback!
> > > >
> > > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > Sent: 23 January 2019 12:08
> > > > > Subject: Re: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
> > > > >
> > > > > Hi Fabrizio,
> > > > >
> > > > > On Wed, Jan 23, 2019 at 1:01 PM Fabrizio Castro
> > > > > <fabrizio.castro@bp.renesas.com> wrote:
> > > > > > > From: Simon Horman <horms@verge.net.au>
> > > > > > > Sent: 23 January 2019 11:38
> > > > > > > Subject: Re: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
> > > > > > >
> > > > > > > On Wed, Jan 23, 2019 at 10:51:23AM +0100, Simon Horman wrote:
> > > > > > > > On Fri, Jan 18, 2019 at 01:13:53PM +0100, Simon Horman wrote:
> > > > > > > > > On Thu, Jan 17, 2019 at 02:54:15PM +0000, Fabrizio Castro wrote:
> > > > > > > > > > According to the latest information, clkp2 is available on RZ/G2.
> > > > > > > > > > Modify CAN0 and CAN1 nodes accordingly.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > > > > > > > > Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com>
> > > > >
> > > > > > > > Thanks again, applied for v5.1.
> > > > > > >
> > > > > > > Sorry, I was a little hasty there.
> > > > > > >
> > > > > > > This patch depends on the presence of R8A774A1_CLK_CANFD which
> > > > > > > (rightly) is added in a different patch in this series which is to
> > > > > > > go upstream via a different tree.
> > > > > > >
> > > > > > > I have dropped this patch for now. I think there are two solution to this
> > > > > > > problem.
> > > > > > >
> > > > > > > 1. Provide a version of this patch which uses a numeric index instead of
> > > > > > > R8A774A1_CLK_CANFD. And then, once R8A774A1_CLK_CANFD is present in an
> > > > > > > RC release provide a patch to switch to using R8A774A1_CLK_CANFD.
> > > > > > >
> > > > > > > 2. Defer this patch until R8A774A1_CLK_CANFD is present in an RC release.
> > > > > >
> > > > > > Yeah, my personal preference is solution 2.
> > > > >
> > > > > Note that solution 2 will probably defer the DT patch to v5.2.
> > > >
> > > > Yeah, my understanding is that even if we chose solution 1 we would still
> > > > need to be waiting for v5.2 for the patch to switch to using
> > > > R8A774A1_CLK_CANFD to appear in a rc, therefore I think solution 2 is
> > > > fine.
> > >
> > > Your understanding is the same as mine.
> > >
> > > I do seem some slight value in option 1 in terms of getting the change,
> > > less the minor issue of using an index rather than a symbol, upstream
> > > earlier. But I do not feel strongly about this.
> > >
> > > I am marking this patch as deferred. Please repost or otherwise ping me
> > > when you would like to revisit this topic.
> >
> > Thank you. Will do.
>
> Thanks.
>
> I believe "[10/11] arm64: dts: renesas: r8a774c0: Add clkp2 clock to CAN nodes"
> falls into the same category. I have marked it as deferred accordingly.
Ok, thank you Simon
Fab
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* Re: [PATCH 3/7] sh_eth: offload RX checksum on R7S72100
From: Sergei Shtylyov @ 2019-01-28 15:21 UTC (permalink / raw)
To: Simon Horman; +Cc: netdev, David S. Miller, linux-renesas-soc, linux-sh
In-Reply-To: <20190128122053.vb5ifhf34zbnuclp@verge.net.au>
On 01/28/2019 03:20 PM, Simon Horman wrote:
>> The RZ/A1H (R7S721000) SoC manual describes the Ether MAC's RX checksum
>> offload the same way as it's implemented in the EtherAVB MACs...
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Regarding this and the remaining patches in this series,
> which add rx-csum offload support in the sh_eth driver for
> various SoCs: has this been tested?
As I said, I've only tested it on R8A77980.
MBR, Sergei
^ permalink raw reply
* Re: [PATCH RFC v2 1/3] UDP: enable GRO by default.
From: Paolo Abeni @ 2019-01-28 15:30 UTC (permalink / raw)
To: Steffen Klassert, netdev; +Cc: Willem de Bruijn, Jason A. Donenfeld
In-Reply-To: <20190128085025.14532-2-steffen.klassert@secunet.com>
Hi,
On Mon, 2019-01-28 at 09:50 +0100, Steffen Klassert wrote:
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 64f9715173ac..584635db9231 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -392,35 +392,24 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,
> return NULL;
> }
>
> -INDIRECT_CALLABLE_DECLARE(struct sock *udp6_lib_lookup_skb(struct sk_buff *skb,
> - __be16 sport, __be16 dport));
> struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb,
> - struct udphdr *uh, udp_lookup_t lookup)
> + struct udphdr *uh, struct sock *sk)
> {
> struct sk_buff *pp = NULL;
> struct sk_buff *p;
> struct udphdr *uh2;
> unsigned int off = skb_gro_offset(skb);
> int flush = 1;
> - struct sock *sk;
> -
> - rcu_read_lock();
> - sk = INDIRECT_CALL_INET(lookup, udp6_lib_lookup_skb,
> - udp4_lib_lookup_skb, skb, uh->source, uh->dest);
> - if (!sk)
> - goto out_unlock;
>
> - if (udp_sk(sk)->gro_enabled) {
> + if (!sk || !udp_sk(sk)->gro_receive) {
> pp = call_gro_receive(udp_gro_receive_segment, head, skb);
> - rcu_read_unlock();
> return pp;
> }
>
> if (NAPI_GRO_CB(skb)->encap_mark ||
> (skb->ip_summed != CHECKSUM_PARTIAL &&
> NAPI_GRO_CB(skb)->csum_cnt == 0 &&
> - !NAPI_GRO_CB(skb)->csum_valid) ||
> - !udp_sk(sk)->gro_receive)
> + !NAPI_GRO_CB(skb)->csum_valid))
> goto out_unlock;
Here I think an additional chunk is missing: the caller is holding the
rcu lock, we should drop the rcu_read_unlock() from this function (and
likely rename the associated label).
> /* mark that this skb passed once through the tunnel gro layer */
> @@ -459,8 +448,10 @@ INDIRECT_CALLABLE_SCOPE
> struct sk_buff *udp4_gro_receive(struct list_head *head, struct sk_buff *skb)
> {
> struct udphdr *uh = udp_gro_udphdr(skb);
> + struct sk_buff *pp;
> + struct sock *sk;
>
> - if (unlikely(!uh) || !static_branch_unlikely(&udp_encap_needed_key))
> + if (unlikely(!uh))
> goto flush;
>
> /* Don't bother verifying checksum if we're going to flush anyway. */
> @@ -475,7 +466,11 @@ struct sk_buff *udp4_gro_receive(struct list_head *head, struct sk_buff *skb)
> inet_gro_compute_pseudo);
> skip:
> NAPI_GRO_CB(skb)->is_ipv6 = 0;
> - return udp_gro_receive(head, skb, uh, udp4_lib_lookup_skb);
> + rcu_read_lock();
> + sk = static_branch_unlikely(&udp_encap_needed_key) ? udp4_lib_lookup_skb(skb, uh->source, uh->dest) : NULL;
> + pp = udp_gro_receive(head, skb, uh, sk);
> + rcu_read_unlock();
> + return pp;
>
> flush:
> NAPI_GRO_CB(skb)->flush = 1;
_Unrelated_ to this patch, but IIRC the RCU lock is already help by
dev_gro_receive(), so IMHO a follow-up patch could possibly remove the
lock here and make the code smaller.
Apart from first point above, I like this patch a lot!
Paolo
^ permalink raw reply
* Re: [PATCH net v4 2/2] net/mlx5e: Don't overwrite pedit action when multiple pedit used
From: Or Gerlitz @ 2019-01-28 15:34 UTC (permalink / raw)
To: Tonghao Zhang; +Cc: Saeed Mahameed, Linux Netdev List, Or Gerlitz
In-Reply-To: <CAMDZJNWxQN5f=msq5Pp7dYPrSuakjZ3b88cGdkve0B6JodjOKQ@mail.gmail.com>
On Mon, Jan 28, 2019 at 2:10 PM Tonghao Zhang <xiangxia.m.yue@gmail.com> wrote:
> On Mon, Jan 28, 2019 at 12:40 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
> >
> > On Sun, Jan 27, 2019 at 1:06 PM <xiangxia.m.yue@gmail.com> wrote:
> > > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> > >
> > > In some case, we may use multiple pedit actions to modify packets.
> > > The command shown as below: the last pedit action is effective.
> >
> > > @@ -2073,7 +2076,8 @@ static int alloc_mod_hdr_actions(struct mlx5e_priv *priv,
> > > if (!parse_attr->mod_hdr_actions)
> > > return -ENOMEM;
> > >
> > > - parse_attr->num_mod_hdr_actions = max_actions;
> > > + parse_attr->max_mod_hdr_actions = max_actions;
> > > + parse_attr->num_mod_hdr_actions = 0;
> >
> > why would we want to do this zeroing? what purpose does it serve?
> Because we use the num_mod_hdr_actions to store the number of actions
> we have parsed,
> and when we alloc it, we init it 0 as default.
>
> > On a probably related note, I suspect that the patch broke the caching
> > we do for modify header contexts, see mlx5e_attach_mod_hdr where we
> > look if a given set of modify header operations already has hw modify header
> > context and we use it.
> >
> > To test that, put two tc rules with different matching but same set of
> > modify header
> > (pedit) actions and see that only one modify header context is used.
> The patch does't break the cache, I think that different matching may
> share the same set of pedit actions.
I suspect it does break it.. at [1] we have this code for the cache lookup:
num_actions = parse_attr->num_mod_hdr_actions;
[..]
key.actions = parse_attr->mod_hdr_actions;
key.num_actions = num_actions;
hash_key = hash_mod_hdr_info(&key);
so we are doing the cached insertion and lookup with
parse_attr->num_mod_hdr_actions
which was zeroed along the way and not accounting for the full set of
pedit actions, agree?
[1] https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c#L179
^ permalink raw reply
* [PATCH] mwifiex: don't print error message on coex event
From: Stefan Agner @ 2019-01-28 15:43 UTC (permalink / raw)
To: amitkarwar, nishants, gbhat, huxinming820
Cc: kvalo, davem, linux-wireless, netdev, linux-kernel, Stefan Agner
The BT coex event is not an error condition. Don't print an error
message in this case. The same even in sta_event.c prints a
message using the debug level already.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
drivers/net/wireless/marvell/mwifiex/uap_event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/uap_event.c b/drivers/net/wireless/marvell/mwifiex/uap_event.c
index e86217a6b9ca..ca759d9c0253 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_event.c
@@ -300,7 +300,7 @@ int mwifiex_process_uap_event(struct mwifiex_private *priv)
mwifiex_11h_handle_radar_detected(priv, adapter->event_skb);
break;
case EVENT_BT_COEX_WLAN_PARA_CHANGE:
- dev_err(adapter->dev, "EVENT: BT coex wlan param update\n");
+ mwifiex_dbg(adapter, EVENT, "event: BT coex wlan param update\n");
mwifiex_bt_coex_wlan_param_update_event(priv,
adapter->event_skb);
break;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 017/304] ath10k: assign 'n_cipher_suites' for WCN3990
From: Sasha Levin @ 2019-01-28 15:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Brian Norris, Rakesh Pillai, Govind Singh, Kalle Valo,
Sasha Levin, ath10k, linux-wireless, netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Brian Norris <briannorris@chromium.org>
[ Upstream commit 2bd345cd2bfc0bd44528896313c0b45f087bdf67 ]
Commit 2ea9f12cefe4 ("ath10k: add new cipher suite support") added a new
n_cipher_suites HW param with a fallback value and a warning log. Commit
03a72288c546 ("ath10k: wmi: add hw params entry for wcn3990") later
added WCN3990 HW entries, but it missed the n_cipher_suites.
Rather than seeing this warning every boot
ath10k_snoc 18800000.wifi: invalid hw_params.n_cipher_suites 0
let's provide the appropriate value.
Cc: Rakesh Pillai <pillair@qti.qualcomm.com>
Cc: Govind Singh <govinds@qti.qualcomm.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath10k/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index d210b0ed59be..59fdda67f89f 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -561,6 +561,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.hw_ops = &wcn3990_ops,
.decap_align_bytes = 1,
.num_peers = TARGET_HL_10_TLV_NUM_PEERS,
+ .n_cipher_suites = 8,
.ast_skid_limit = TARGET_HL_10_TLV_AST_SKID_LIMIT,
.num_wds_entries = TARGET_HL_10_TLV_NUM_WDS_ENTRIES,
.target_64bit = true,
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 018/304] ath9k: dynack: use authentication messages for 'late' ack
From: Sasha Levin @ 2019-01-28 15:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lorenzo Bianconi, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
[ Upstream commit 3831a2a0010c72e3956020cbf1057a1701a2e469 ]
In order to properly support dynack in ad-hoc mode running
wpa_supplicant, take into account authentication frames for
'late ack' detection. This patch has been tested on devices
mounted on offshore high-voltage stations connected through
~24Km link
Reported-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath9k/dynack.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/dynack.c b/drivers/net/wireless/ath/ath9k/dynack.c
index 7334c9b09e82..cc0dc966c512 100644
--- a/drivers/net/wireless/ath/ath9k/dynack.c
+++ b/drivers/net/wireless/ath/ath9k/dynack.c
@@ -187,7 +187,8 @@ void ath_dynack_sample_tx_ts(struct ath_hw *ah, struct sk_buff *skb,
/* late ACK */
if (ts->ts_status & ATH9K_TXERR_XRETRY) {
if (ieee80211_is_assoc_req(hdr->frame_control) ||
- ieee80211_is_assoc_resp(hdr->frame_control)) {
+ ieee80211_is_assoc_resp(hdr->frame_control) ||
+ ieee80211_is_auth(hdr->frame_control)) {
ath_dbg(common, DYNACK, "late ack\n");
ath9k_hw_setslottime(ah, (LATEACK_TO - 3) / 2);
ath9k_hw_set_ack_timeout(ah, LATEACK_TO);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 039/304] sctp: Fix SKB list traversal in sctp_intl_store_ordered().
From: Sasha Levin @ 2019-01-28 15:39 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: David S. Miller, Sasha Levin, linux-sctp, netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: "David S. Miller" <davem@davemloft.net>
[ Upstream commit e15e067d0656625c77c52b4e5f0cfbf0c0c3583f ]
Same change as made to sctp_intl_store_reasm().
To be fully correct, an iterator has an undefined value when something
like skb_queue_walk() naturally terminates.
This will actually matter when SKB queues are converted over to
list_head.
Formalize what this code ends up doing with the current
implementation.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/sctp/stream_interleave.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/net/sctp/stream_interleave.c b/net/sctp/stream_interleave.c
index 0a78cdf86463..500449b72eca 100644
--- a/net/sctp/stream_interleave.c
+++ b/net/sctp/stream_interleave.c
@@ -383,7 +383,7 @@ static void sctp_intl_store_ordered(struct sctp_ulpq *ulpq,
struct sctp_ulpevent *event)
{
struct sctp_ulpevent *cevent;
- struct sk_buff *pos;
+ struct sk_buff *pos, *loc;
pos = skb_peek_tail(&ulpq->lobby);
if (!pos) {
@@ -403,18 +403,25 @@ static void sctp_intl_store_ordered(struct sctp_ulpq *ulpq,
return;
}
+ loc = NULL;
skb_queue_walk(&ulpq->lobby, pos) {
cevent = (struct sctp_ulpevent *)pos->cb;
- if (cevent->stream > event->stream)
+ if (cevent->stream > event->stream) {
+ loc = pos;
break;
-
+ }
if (cevent->stream == event->stream &&
- MID_lt(event->mid, cevent->mid))
+ MID_lt(event->mid, cevent->mid)) {
+ loc = pos;
break;
+ }
}
- __skb_queue_before(&ulpq->lobby, pos, sctp_event2skb(event));
+ if (!loc)
+ __skb_queue_tail(&ulpq->lobby, sctp_event2skb(event));
+ else
+ __skb_queue_before(&ulpq->lobby, loc, sctp_event2skb(event));
}
static void sctp_intl_retrieve_ordered(struct sctp_ulpq *ulpq,
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 048/304] i40e: suppress bogus error message
From: Sasha Levin @ 2019-01-28 15:39 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Mitch Williams, Jeff Kirsher, Sasha Levin, netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Mitch Williams <mitch.a.williams@intel.com>
[ Upstream commit 7cd8eb0861981ad212ce4242a1870c4b5831ceff ]
The i40e driver complains about unprivileged VFs trying to configure
promiscuous mode each time a VF reset occurs. This isn't the fault of
the poor VF driver - the PF driver itself is making the request.
To fix this, skip the privilege check if the request is to disable all
promiscuous activity. This gets rid of the bogus message, but doesn't
affect privilege checks, since we really only care if the unprivileged
VF is trying to enable promiscuous mode.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index ac5698ed0b11..c41e8ada23d1 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -1112,7 +1112,8 @@ static i40e_status i40e_config_vf_promiscuous_mode(struct i40e_vf *vf,
if (!i40e_vc_isvalid_vsi_id(vf, vsi_id) || !vsi)
return I40E_ERR_PARAM;
- if (!test_bit(I40E_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps)) {
+ if (!test_bit(I40E_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps) &&
+ (allmulti || alluni)) {
dev_err(&pf->pdev->dev,
"Unprivileged VF %d is attempting to configure promiscuous mode\n",
vf->vf_id);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 049/304] i40e: prevent overlapping tx_timeout recover
From: Sasha Levin @ 2019-01-28 15:39 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Alan Brady, Jeff Kirsher, Sasha Levin, netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Alan Brady <alan.brady@intel.com>
[ Upstream commit d5585b7b6846a6d0f9517afe57be3843150719da ]
If a TX hang occurs, we attempt to recover by incrementally resetting.
If we're starved for CPU time, it's possible the reset doesn't actually
complete (or even fire) before another tx_timeout fires causing us to
fly through the different resets without actually doing them.
This adds a bit to set and check if a timeout recovery is already
pending and, if so, bail out of tx_timeout. The bit will get cleared at
the end of i40e_rebuild when reset is complete.
Signed-off-by: Alan Brady <alan.brady@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/i40e/i40e.h | 1 +
drivers/net/ethernet/intel/i40e/i40e_main.c | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h
index 876cac317e79..8245ff12fd64 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -122,6 +122,7 @@ enum i40e_state_t {
__I40E_MDD_EVENT_PENDING,
__I40E_VFLR_EVENT_PENDING,
__I40E_RESET_RECOVERY_PENDING,
+ __I40E_TIMEOUT_RECOVERY_PENDING,
__I40E_MISC_IRQ_REQUESTED,
__I40E_RESET_INTR_RECEIVED,
__I40E_REINIT_REQUESTED,
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 0e5dc74b4ef2..419cf3faada6 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -338,6 +338,10 @@ static void i40e_tx_timeout(struct net_device *netdev)
(pf->tx_timeout_last_recovery + netdev->watchdog_timeo)))
return; /* don't do any new action before the next timeout */
+ /* don't kick off another recovery if one is already pending */
+ if (test_and_set_bit(__I40E_TIMEOUT_RECOVERY_PENDING, pf->state))
+ return;
+
if (tx_ring) {
head = i40e_get_head(tx_ring);
/* Read interrupt register */
@@ -9632,6 +9636,7 @@ end_core_reset:
clear_bit(__I40E_RESET_FAILED, pf->state);
clear_recovery:
clear_bit(__I40E_RESET_RECOVERY_PENDING, pf->state);
+ clear_bit(__I40E_TIMEOUT_RECOVERY_PENDING, pf->state);
}
/**
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 058/304] net/mlx5: EQ, Use the right place to store/read IRQ affinity hint
From: Sasha Levin @ 2019-01-28 15:39 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Saeed Mahameed, Leon Romanovsky, Sasha Levin, netdev, linux-rdma
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Saeed Mahameed <saeedm@mellanox.com>
[ Upstream commit 1e86ace4c140fd5a693e266c9b23409358f25381 ]
Currently the cpu affinity hint mask for completion EQs is stored and
read from the wrong place, since reading and storing is done from the
same index, there is no actual issue with that, but internal irq_info
for completion EQs stars at MLX5_EQ_VEC_COMP_BASE offset in irq_info
array, this patch changes the code to use the correct offset to store
and read the IRQ affinity hint.
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/main.c | 14 ++++++++------
include/linux/mlx5/driver.h | 2 +-
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index b70cb6fd164c..9577d0657839 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -1771,7 +1771,7 @@ static void mlx5e_close_cq(struct mlx5e_cq *cq)
static int mlx5e_get_cpu(struct mlx5e_priv *priv, int ix)
{
- return cpumask_first(priv->mdev->priv.irq_info[ix].mask);
+ return cpumask_first(priv->mdev->priv.irq_info[ix + MLX5_EQ_VEC_COMP_BASE].mask);
}
static int mlx5e_open_tx_cqs(struct mlx5e_channel *c,
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 28132c7dc05f..d5cea0a36e6a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -640,18 +640,19 @@ u64 mlx5_read_internal_timer(struct mlx5_core_dev *dev)
static int mlx5_irq_set_affinity_hint(struct mlx5_core_dev *mdev, int i)
{
struct mlx5_priv *priv = &mdev->priv;
- int irq = pci_irq_vector(mdev->pdev, MLX5_EQ_VEC_COMP_BASE + i);
+ int vecidx = MLX5_EQ_VEC_COMP_BASE + i;
+ int irq = pci_irq_vector(mdev->pdev, vecidx);
- if (!zalloc_cpumask_var(&priv->irq_info[i].mask, GFP_KERNEL)) {
+ if (!zalloc_cpumask_var(&priv->irq_info[vecidx].mask, GFP_KERNEL)) {
mlx5_core_warn(mdev, "zalloc_cpumask_var failed");
return -ENOMEM;
}
cpumask_set_cpu(cpumask_local_spread(i, priv->numa_node),
- priv->irq_info[i].mask);
+ priv->irq_info[vecidx].mask);
if (IS_ENABLED(CONFIG_SMP) &&
- irq_set_affinity_hint(irq, priv->irq_info[i].mask))
+ irq_set_affinity_hint(irq, priv->irq_info[vecidx].mask))
mlx5_core_warn(mdev, "irq_set_affinity_hint failed, irq 0x%.4x", irq);
return 0;
@@ -659,11 +660,12 @@ static int mlx5_irq_set_affinity_hint(struct mlx5_core_dev *mdev, int i)
static void mlx5_irq_clear_affinity_hint(struct mlx5_core_dev *mdev, int i)
{
+ int vecidx = MLX5_EQ_VEC_COMP_BASE + i;
struct mlx5_priv *priv = &mdev->priv;
- int irq = pci_irq_vector(mdev->pdev, MLX5_EQ_VEC_COMP_BASE + i);
+ int irq = pci_irq_vector(mdev->pdev, vecidx);
irq_set_affinity_hint(irq, NULL);
- free_cpumask_var(priv->irq_info[i].mask);
+ free_cpumask_var(priv->irq_info[vecidx].mask);
}
static int mlx5_irq_set_affinity_hints(struct mlx5_core_dev *mdev)
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index aa5963b5d38e..7d4ed995b4ce 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -1309,7 +1309,7 @@ enum {
static inline const struct cpumask *
mlx5_get_vector_affinity_hint(struct mlx5_core_dev *dev, int vector)
{
- return dev->priv.irq_info[vector].mask;
+ return dev->priv.irq_info[vector + MLX5_EQ_VEC_COMP_BASE].mask;
}
#endif /* MLX5_DRIVER_H */
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 104/304] mt76x0: dfs: fix IBI_R11 configuration on non-radar channels
From: Sasha Levin @ 2019-01-28 15:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lorenzo Bianconi, Felix Fietkau, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
[ Upstream commit 6bf4a8e902aad7df55d7f2b10b850cfa3f880996 ]
Fix IBI_R11 configuration on non-radar channels for mt76x0e
driver. This patch improve system stability under heavy load.
Moreover use IBI_R11 name and remove magic numbers for
0x212c register
Fixes: 0c3b3abc9251 ("mt76x0: pci: add DFS support")
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76x2/pci_dfs.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_dfs.c b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_dfs.c
index b56febae8945..764528c9f48a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_dfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_dfs.c
@@ -800,7 +800,7 @@ static void mt76x2_dfs_set_bbp_params(struct mt76x02_dev *dev)
/* enable detection*/
mt76_wr(dev, MT_BBP(DFS, 0), MT_DFS_CH_EN << 16);
- mt76_wr(dev, 0x212c, 0x0c350001);
+ mt76_wr(dev, MT_BBP(IBI, 11), 0x0c350001);
}
void mt76x2_dfs_adjust_agc(struct mt76x02_dev *dev)
@@ -843,7 +843,11 @@ void mt76x2_dfs_init_params(struct mt76x02_dev *dev)
mt76_wr(dev, MT_BBP(DFS, 0), 0);
/* clear detector status */
mt76_wr(dev, MT_BBP(DFS, 1), 0xf);
- mt76_wr(dev, 0x212c, 0);
+ if (mt76_chip(&dev->mt76) == 0x7610 ||
+ mt76_chip(&dev->mt76) == 0x7630)
+ mt76_wr(dev, MT_BBP(IBI, 11), 0xfde8081);
+ else
+ mt76_wr(dev, MT_BBP(IBI, 11), 0);
mt76x02_irq_disable(dev, MT_INT_GPTIMER);
mt76_rmw_field(dev, MT_INT_TIMER_EN,
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 105/304] mt76x0: use band parameter for LC calibration
From: Sasha Levin @ 2019-01-28 15:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Stanislaw Gruszka, Felix Fietkau, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Stanislaw Gruszka <sgruszka@redhat.com>
[ Upstream commit ad3f993a0857ad3b792e7463828eb0d90cdd6f4d ]
We use always 1 as band parameter for MCU_CAL_LC, this break 2GHz,
we should use 0 for this band instead.
Patch fixes problems happened sometimes when try to associate with 2GHz
AP and manifest by errors like below:
[14680.920823] wlan0: authenticate with 18:31:bf:c0:51:b0
[14681.109506] wlan0: send auth to 18:31:bf:c0:51:b0 (try 1/3)
[14681.310454] wlan0: send auth to 18:31:bf:c0:51:b0 (try 2/3)
[14681.518469] wlan0: send auth to 18:31:bf:c0:51:b0 (try 3/3)
[14681.726499] wlan0: authentication with 18:31:bf:c0:51:b0 timed out
Fixes: 9aec146d0f6b ("mt76x0: pci: introduce mt76x0_phy_calirate routine")
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index cf024950e0ed..9c0a042c28b0 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -585,6 +585,7 @@ void mt76x0_phy_set_txpower(struct mt76x02_dev *dev)
void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool power_on)
{
struct ieee80211_channel *chan = dev->mt76.chandef.chan;
+ int is_5ghz = (chan->band == NL80211_BAND_5GHZ) ? 1 : 0;
u32 val, tx_alc, reg_val;
if (power_on) {
@@ -602,7 +603,7 @@ void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool power_on)
reg_val = mt76_rr(dev, MT_BBP(IBI, 9));
mt76_wr(dev, MT_BBP(IBI, 9), 0xffffff7e);
- if (chan->band == NL80211_BAND_5GHZ) {
+ if (is_5ghz) {
if (chan->hw_value < 100)
val = 0x701;
else if (chan->hw_value < 140)
@@ -615,7 +616,7 @@ void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool power_on)
mt76x02_mcu_calibrate(dev, MCU_CAL_FULL, val, false);
msleep(350);
- mt76x02_mcu_calibrate(dev, MCU_CAL_LC, 1, false);
+ mt76x02_mcu_calibrate(dev, MCU_CAL_LC, is_5ghz, false);
usleep_range(15000, 20000);
mt76_wr(dev, MT_BBP(IBI, 9), reg_val);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 109/304] nfp: add locking around representor changes
From: Sasha Levin @ 2019-01-28 15:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jakub Kicinski, David S . Miller, Sasha Levin, oss-drivers,
netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
[ Upstream commit 71844fac1ed459024dd2a448d63d5b28b8c87daa ]
Up until now we never needed to keep a networking locks around
representors accesses, we only accessed them when device was
reconfigured (under nfp pf->lock) or on fast path (under RCU).
Now we want to be able to iterate over all representors during
notifications, so make sure representor assignment is done
under RTNL lock.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: John Hurley <john.hurley@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/netronome/nfp/abm/main.c | 4 ++++
drivers/net/ethernet/netronome/nfp/nfp_app.c | 2 ++
drivers/net/ethernet/netronome/nfp/nfp_net_repr.c | 2 ++
3 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/abm/main.c b/drivers/net/ethernet/netronome/nfp/abm/main.c
index c0830c0c2c3f..376df412ea55 100644
--- a/drivers/net/ethernet/netronome/nfp/abm/main.c
+++ b/drivers/net/ethernet/netronome/nfp/abm/main.c
@@ -384,7 +384,9 @@ nfp_abm_spawn_repr(struct nfp_app *app, struct nfp_abm_link *alink,
reprs = nfp_reprs_get_locked(app, rtype);
WARN(nfp_repr_get_locked(app, reprs, alink->id), "duplicate repr");
+ rtnl_lock();
rcu_assign_pointer(reprs->reprs[alink->id], netdev);
+ rtnl_unlock();
nfp_info(app->cpp, "%s Port %d Representor(%s) created\n",
ptype == NFP_PORT_PF_PORT ? "PCIe" : "Phys",
@@ -410,7 +412,9 @@ nfp_abm_kill_repr(struct nfp_app *app, struct nfp_abm_link *alink,
netdev = nfp_repr_get_locked(app, reprs, alink->id);
if (!netdev)
return;
+ rtnl_lock();
rcu_assign_pointer(reprs->reprs[alink->id], NULL);
+ rtnl_unlock();
synchronize_rcu();
/* Cast to make sure nfp_repr_clean_and_free() takes a nfp_repr */
nfp_repr_clean_and_free((struct nfp_repr *)netdev_priv(netdev));
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_app.c b/drivers/net/ethernet/netronome/nfp/nfp_app.c
index 68a0991aac22..3bd1386162b9 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_app.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_app.c
@@ -131,7 +131,9 @@ nfp_app_reprs_set(struct nfp_app *app, enum nfp_repr_type type,
struct nfp_reprs *old;
old = nfp_reprs_get_locked(app, type);
+ rtnl_lock();
rcu_assign_pointer(app->reprs[type], reprs);
+ rtnl_unlock();
return old;
}
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
index c09b893c30dd..0cf3f40eb8cf 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
@@ -442,7 +442,9 @@ int nfp_reprs_resync_phys_ports(struct nfp_app *app)
continue;
nfp_app_repr_preclean(app, netdev);
+ rtnl_lock();
rcu_assign_pointer(reprs->reprs[i], NULL);
+ rtnl_unlock();
synchronize_rcu();
nfp_repr_clean(repr);
}
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 130/304] tipc: fix node keep alive interval calculation
From: Sasha Levin @ 2019-01-28 15:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Hoang Le, David S . Miller, Sasha Levin, netdev, tipc-discussion
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Hoang Le <hoang.h.le@dektech.com.au>
[ Upstream commit f5d6c3e5a359c0507800e7ac68d565c21de9b5a1 ]
When setting LINK tolerance, node timer interval will be calculated
base on the LINK with lowest tolerance.
But when calculated, the old node timer interval only updated if current
setting value (tolerance/4) less than old ones regardless of number of
links as well as links' lowest tolerance value.
This caused to two cases missing if tolerance changed as following:
Case 1:
1.1/ There is one link (L1) available in the system
1.2/ Set L1's tolerance from 1500ms => lower (i.e 500ms)
1.3/ Then, fallback to default (1500ms) or higher (i.e 2000ms)
Expected:
node timer interval is 1500/4=375ms after 1.3
Result:
node timer interval will not being updated after changing tolerance at 1.3
since its value 1500/4=375ms is not less than 500/4=125ms at 1.2.
Case 2:
2.1/ There are two links (L1, L2) available in the system
2.2/ L1 and L2 tolerance value are 2000ms as initial
2.3/ Set L2's tolerance from 2000ms => lower 1500ms
2.4/ Disable link L2 (bring down its bearer)
Expected:
node timer interval is 2000ms/4=500ms after 2.4
Result:
node timer interval will not being updated after disabling L2 since
its value 2000ms/4=500ms is still not less than 1500/4=375ms at 2.3
although L2 is already not available in the system.
To fix this, we start the node interval calculation by initializing it to
a value larger than any conceivable calculated value. This way, the link
with the lowest tolerance will always determine the calculated value.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/tipc/node.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index 488019766433..32556f480a60 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -624,6 +624,12 @@ static void tipc_node_timeout(struct timer_list *t)
__skb_queue_head_init(&xmitq);
+ /* Initial node interval to value larger (10 seconds), then it will be
+ * recalculated with link lowest tolerance
+ */
+ tipc_node_read_lock(n);
+ n->keepalive_intv = 10000;
+ tipc_node_read_unlock(n);
for (bearer_id = 0; remains && (bearer_id < MAX_BEARERS); bearer_id++) {
tipc_node_read_lock(n);
le = &n->links[bearer_id];
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 179/304] ipv6: Fix handling of LLA with VRF and sockets bound to VRF
From: Sasha Levin @ 2019-01-28 15:41 UTC (permalink / raw)
To: linux-kernel, stable
Cc: David Ahern, Mike Manning, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: David Ahern <dsahern@gmail.com>
[ Upstream commit c2027d1e17582903e368abf5d4838b22a98f2b7b ]
A recent commit allows sockets bound to a VRF to receive ipv6 link local
packets. However, it only works for UDP and worse TCP connection attempts
to the LLA with the only listener bound to the VRF just hang where as
before the client gets a reset and connection refused. Fix by adjusting
ir_iif for LL addresses and packets received through a device enslaved
to a VRF.
Fixes: 6f12fa775530 ("vrf: mark skb for multicast or link-local as enslaved to VRF")
Reported-by: Donald Sharp <sharpd@cumulusnetworks.com>
Cc: Mike Manning <mmanning@vyatta.att-mail.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/ipv6/tcp_ipv6.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 03e6b7a2bc53..f5c213001b05 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -734,6 +734,7 @@ static void tcp_v6_init_req(struct request_sock *req,
const struct sock *sk_listener,
struct sk_buff *skb)
{
+ bool l3_slave = ipv6_l3mdev_skb(TCP_SKB_CB(skb)->header.h6.flags);
struct inet_request_sock *ireq = inet_rsk(req);
const struct ipv6_pinfo *np = inet6_sk(sk_listener);
@@ -741,7 +742,7 @@ static void tcp_v6_init_req(struct request_sock *req,
ireq->ir_v6_loc_addr = ipv6_hdr(skb)->daddr;
/* So that link locals have meaning */
- if (!sk_listener->sk_bound_dev_if &&
+ if ((!sk_listener->sk_bound_dev_if || l3_slave) &&
ipv6_addr_type(&ireq->ir_v6_rmt_addr) & IPV6_ADDR_LINKLOCAL)
ireq->ir_iif = tcp_v6_iif(skb);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 180/304] tools: bpftool: fix -Wmissing declaration warnings
From: Sasha Levin @ 2019-01-28 15:41 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Quentin Monnet, Daniel Borkmann, Sasha Levin, netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Quentin Monnet <quentin.monnet@netronome.com>
[ Upstream commit c101189bc9680675a2686bafe908015a07a0da51 ]
Help compiler check arguments for several utility functions used to
print items to the console by adding the "printf" attribute when
declaring those functions.
Also, declare as "static" two functions that are only used in prog.c.
All of them discovered by compiling bpftool with
-Wmissing-format-attribute -Wmissing-declarations.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/bpf/bpftool/common.c | 4 ++--
tools/bpf/bpftool/json_writer.c | 6 ++++--
tools/bpf/bpftool/prog.c | 4 ++--
tools/bpf/bpftool/xlated_dumper.c | 7 ++++---
4 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/tools/bpf/bpftool/common.c b/tools/bpf/bpftool/common.c
index 70fd48d79f61..05d715e6b128 100644
--- a/tools/bpf/bpftool/common.c
+++ b/tools/bpf/bpftool/common.c
@@ -58,7 +58,7 @@
#define BPF_FS_MAGIC 0xcafe4a11
#endif
-void p_err(const char *fmt, ...)
+void __printf(1, 2) p_err(const char *fmt, ...)
{
va_list ap;
@@ -76,7 +76,7 @@ void p_err(const char *fmt, ...)
va_end(ap);
}
-void p_info(const char *fmt, ...)
+void __printf(1, 2) p_info(const char *fmt, ...)
{
va_list ap;
diff --git a/tools/bpf/bpftool/json_writer.c b/tools/bpf/bpftool/json_writer.c
index c6eef76322ae..4e4149421d07 100644
--- a/tools/bpf/bpftool/json_writer.c
+++ b/tools/bpf/bpftool/json_writer.c
@@ -19,6 +19,7 @@
#include <malloc.h>
#include <inttypes.h>
#include <stdint.h>
+#include <linux/compiler.h>
#include "json_writer.h"
@@ -156,7 +157,8 @@ void jsonw_name(json_writer_t *self, const char *name)
putc(' ', self->out);
}
-void jsonw_vprintf_enquote(json_writer_t *self, const char *fmt, va_list ap)
+void __printf(2, 0)
+jsonw_vprintf_enquote(json_writer_t *self, const char *fmt, va_list ap)
{
jsonw_eor(self);
putc('"', self->out);
@@ -164,7 +166,7 @@ void jsonw_vprintf_enquote(json_writer_t *self, const char *fmt, va_list ap)
putc('"', self->out);
}
-void jsonw_printf(json_writer_t *self, const char *fmt, ...)
+void __printf(2, 3) jsonw_printf(json_writer_t *self, const char *fmt, ...)
{
va_list ap;
diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
index ccee180dfb76..69b01a6158bd 100644
--- a/tools/bpf/bpftool/prog.c
+++ b/tools/bpf/bpftool/prog.c
@@ -84,7 +84,7 @@ static const char * const attach_type_strings[] = {
[__MAX_BPF_ATTACH_TYPE] = NULL,
};
-enum bpf_attach_type parse_attach_type(const char *str)
+static enum bpf_attach_type parse_attach_type(const char *str)
{
enum bpf_attach_type type;
@@ -713,7 +713,7 @@ struct map_replace {
char *name;
};
-int map_replace_compar(const void *p1, const void *p2)
+static int map_replace_compar(const void *p1, const void *p2)
{
const struct map_replace *a = p1, *b = p2;
diff --git a/tools/bpf/bpftool/xlated_dumper.c b/tools/bpf/bpftool/xlated_dumper.c
index 3284759df98a..98083e4dc0f9 100644
--- a/tools/bpf/bpftool/xlated_dumper.c
+++ b/tools/bpf/bpftool/xlated_dumper.c
@@ -114,7 +114,7 @@ struct kernel_sym *kernel_syms_search(struct dump_data *dd,
sizeof(*dd->sym_mapping), kernel_syms_cmp) : NULL;
}
-static void print_insn(void *private_data, const char *fmt, ...)
+static void __printf(2, 3) print_insn(void *private_data, const char *fmt, ...)
{
va_list args;
@@ -123,7 +123,7 @@ static void print_insn(void *private_data, const char *fmt, ...)
va_end(args);
}
-static void
+static void __printf(2, 3)
print_insn_for_graph(void *private_data, const char *fmt, ...)
{
char buf[64], *p;
@@ -154,7 +154,8 @@ print_insn_for_graph(void *private_data, const char *fmt, ...)
printf("%s", buf);
}
-static void print_insn_json(void *private_data, const char *fmt, ...)
+static void __printf(2, 3)
+print_insn_json(void *private_data, const char *fmt, ...)
{
unsigned int l = strlen(fmt);
char chomped_fmt[l];
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 217/304] net: hns3: fix incomplete uninitialization of IRQ in the hns3_nic_uninit_vector_data()
From: Sasha Levin @ 2019-01-28 15:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Huazhong Tan, Peng Li, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Huazhong Tan <tanhuazhong@huawei.com>
[ Upstream commit ae6017a71115ebc4e5c1a3f0f451319ab3f5c447 ]
In the hns3_nic_uninit_vector_data(), the procedure of uninitializing
the tqp_vector's IRQ has not set affinity_notify to NULL and changes
its init flag. This patch fixes it. And for simplificaton, local
variable tqp_vector is used instead of priv->tqp_vector[i].
Fixes: 424eb834a9be ("net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08 SoC")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 4aea3f57586e..85d534a24f2c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2971,12 +2971,12 @@ static int hns3_nic_uninit_vector_data(struct hns3_nic_priv *priv)
hns3_free_vector_ring_chain(tqp_vector, &vector_ring_chain);
- if (priv->tqp_vector[i].irq_init_flag == HNS3_VECTOR_INITED) {
- (void)irq_set_affinity_hint(
- priv->tqp_vector[i].vector_irq,
- NULL);
- free_irq(priv->tqp_vector[i].vector_irq,
- &priv->tqp_vector[i]);
+ if (tqp_vector->irq_init_flag == HNS3_VECTOR_INITED) {
+ irq_set_affinity_notifier(tqp_vector->vector_irq,
+ NULL);
+ irq_set_affinity_hint(tqp_vector->vector_irq, NULL);
+ free_irq(tqp_vector->vector_irq, tqp_vector);
+ tqp_vector->irq_init_flag = HNS3_VECTOR_NOT_INITED;
}
priv->ring_data[i].ring->irq_init_flag = HNS3_VECTOR_NOT_INITED;
--
2.19.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox