* [PATCH 5/6] net: cxgb3_main: remove redundant null pointer check before kfree_skb
From: zhong jiang @ 2018-09-20 9:37 UTC (permalink / raw)
To: davem; +Cc: kuznet, yoshfuji, santosh, netdev, linux-kernel
In-Reply-To: <1537436266-41955-1-git-send-email-zhongjiang@huawei.com>
kfree_skb has taken the null pointer into account. hence it is safe
to remove the redundant null pointer check before kfree_skb.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
index a19172d..680c6fe 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -3423,8 +3423,7 @@ static void remove_one(struct pci_dev *pdev)
free_netdev(adapter->port[i]);
iounmap(adapter->regs);
- if (adapter->nofail_skb)
- kfree_skb(adapter->nofail_skb);
+ kfree_skb(adapter->nofail_skb);
kfree(adapter);
pci_release_regions(pdev);
pci_disable_device(pdev);
--
1.7.12.4
^ permalink raw reply related
* [PATCH 6/6] ipv6: remove redundant null pointer check before kfree_skb
From: zhong jiang @ 2018-09-20 9:37 UTC (permalink / raw)
To: davem; +Cc: kuznet, yoshfuji, santosh, netdev, linux-kernel
In-Reply-To: <1537436266-41955-1-git-send-email-zhongjiang@huawei.com>
kfree_skb has taken the null pointer into account. hence it is safe
to remove the redundant null pointer check before kfree_skb.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/ipv6/af_inet6.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 77ef847..e9c8cfd 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -468,12 +468,10 @@ void inet6_destroy_sock(struct sock *sk)
/* Release rx options */
skb = xchg(&np->pktoptions, NULL);
- if (skb)
- kfree_skb(skb);
+ kfree_skb(skb);
skb = xchg(&np->rxpmtu, NULL);
- if (skb)
- kfree_skb(skb);
+ kfree_skb(skb);
/* Free flowlabels */
fl6_free_socklist(sk);
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH] netfilter: nf_tables: add SECMARK support
From: Florian Westphal @ 2018-09-20 9:44 UTC (permalink / raw)
To: Christian Göttsche
Cc: fw, casey, pablo, kadlec, davem, netfilter-devel, coreteam,
netdev, linux-kernel, Paul Moore, Stephen Smalley, Eric Paris,
jmorris, serge, selinux, linux-security-module
In-Reply-To: <CAJ2a_DfGCRXaH9BkBj=0R1Cr3jiHQHgq-pU2HGuWudvWCSKLQg@mail.gmail.com>
Christian Göttsche <cgzones@googlemail.com> wrote:
> > Fixes should go into nf.git whereas feature goes to nf-next.git.
>
> No, that should not be a unroll fix.
> Currently there are no objects registered by the main nf_tables
> module, so for nft_secmark_obj_type I had to introduce this new logic.
I see, ok.
> > > > + if (err) {
> > > > + if (err == -EINVAL)
> > > > + pr_notice_ratelimited("invalid security context \'%s\'\n", priv->ctx);
> > > > + else
> > > > + pr_notice_ratelimited("unable to convert security context \'%s\': %d\n", priv->ctx, -err);
> > > > + return;
> > > > + }
> >
> > Please remove these printks(), they do not really help as user can't
> > take any action anyway.
>
> Aren't they helpful?
> "invalid security context" can pop up if someone supplies an invalid
> SELinux context (nft add secmark inet filter sshtag
> \"this_is_invalid\") and uses it
Can't that be caught at ->init() time?
We can then reject this via plain -EINVAL.
No need for printk because caller knows which expression/object caused
the error.
> "unable to convert security context" can pop up if no LSM is enabled
Can that be done at ->init() time when we can still reject the (invalid)
rule?
> "unable to map security context" should never happen, but one never knows
Ok, but what is user supposed to do?
This just causes perpetual spew of warnings in the kernel ring buffer.
> "unable to obtain relabeling permission" can pop up if e.g. the
> SELinux permission "kernel_t ssh_server_packet:packet relabelto" is
> missing
Makes sense, but this will need to be a plain
return -EPERM, this function can only be used in process context.
^ permalink raw reply
* [PATCH] bpf: remove redundant null pointer check before consume_skb
From: zhong jiang @ 2018-09-20 9:46 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev, linux-kernel
consume_skb has taken the null pointer into account. hence it is safe
to remove the redundant null pointer check before consume_skb.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
kernel/bpf/sockmap.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 488ef96..a9359cb 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -590,8 +590,7 @@ static int free_sg(struct sock *sk, int start,
if (i == MAX_SKB_FRAGS)
i = 0;
}
- if (md->skb)
- consume_skb(md->skb);
+ consume_skb(md->skb);
return free;
}
@@ -973,8 +972,7 @@ static int bpf_tcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
if (!sg->length && md->sg_start == md->sg_end) {
list_del(&md->list);
- if (md->skb)
- consume_skb(md->skb);
+ consume_skb(md->skb);
kfree(md);
}
}
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH net-next 0/2] net: phy: make phy_stop() synchronous
From: David Miller @ 2018-09-20 4:07 UTC (permalink / raw)
To: hkallweit1; +Cc: f.fainelli, andrew, netdev, geert+renesas
In-Reply-To: <fc18a6b5-5022-ac2b-9e68-584b4c28bb71@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Tue, 18 Sep 2018 21:54:23 +0200
> There have been few not that successful attempts in the past to make
> phy_stop() a synchronous call instead of just changing the state.
> Patch 1 of this series addresses an issue which prevented this change.
> At least for me it works fine now. Would appreciate if Geert could
> re-test as well that suspend doesn't throw an error.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH v2 net-next] ravb: remove tx buffer addr 4byte alilgnment restriction for R-Car Gen3
From: David Miller @ 2018-09-20 4:08 UTC (permalink / raw)
To: horms+renesas
Cc: sergei.shtylyov, magnus.damm, netdev, linux-renesas-soc,
kazuya.mizuguchi.ks
In-Reply-To: <20180919080621.821-1-horms+renesas@verge.net.au>
From: Simon Horman <horms+renesas@verge.net.au>
Date: Wed, 19 Sep 2018 10:06:21 +0200
> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>
> This patch sets from two descriptor to one descriptor because R-Car Gen3
> does not have the 4 bytes alignment restriction of the transmission buffer.
>
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> v2 [Simon Horman]
> * As per review by Sergi Shtylyov
> - Use reverse xmas tree for variable declarations
> - Use > rather than >= for conditions
> - Dropped unnecessary parentheses
> - Don't allocate memory for tx_align when it will not be used
> - But, kept NUM_TX_DESC_GEN[23] as I see some value in
> the self-documentation provided by these #defines
>
> v1 [Kazuya Mizuguchi]
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: toshiba: fix return type of ndo_start_xmit function
From: David Miller @ 2018-09-20 4:19 UTC (permalink / raw)
To: yuehaibing
Cc: geoff, benh, paulus, mpe, kou.ishizaki, andrew, f.fainelli,
linux-kernel, netdev, linuxppc-dev
In-Reply-To: <20180919102339.13988-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Wed, 19 Sep 2018 18:23:39 +0800
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, so make sure the implementation in
> this driver has returns 'netdev_tx_t' value, and change the function
> return type to netdev_tx_t.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* [PATCH net-next] vhost_net: add a missing error return
From: Dan Carpenter @ 2018-09-20 10:01 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang
Cc: netdev, kernel-janitors, kvm, virtualization
We accidentally left out this error return so it leads to some use after
free bugs later on.
Fixes: 0a0be13b8fe2 ("vhost_net: batch submitting XDP buffers to underlayer sockets")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index dd4e0a301635..1bff6bc8161a 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1244,6 +1244,7 @@ static int vhost_net_open(struct inode *inode, struct file *f)
kfree(vqs);
kvfree(n);
kfree(queue);
+ return -ENOMEM;
}
n->vqs[VHOST_NET_VQ_TX].xdp = xdp;
^ permalink raw reply related
* Re: [PATCH net-next] ipv6: Allow the l3mdev to be a loopback
From: David Miller @ 2018-09-20 4:23 UTC (permalink / raw)
To: dsahern; +Cc: mmanning, netdev, rshearma
In-Reply-To: <bd5d267a-f419-4735-bdf1-eee2a1f7135d@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Wed, 19 Sep 2018 10:19:05 -0700
> On 9/19/18 5:56 AM, Mike Manning wrote:
>> From: Robert Shearman <rshearma@vyatta.att-mail.com>
>>
>> There is no way currently for an IPv6 client connect using a loopback
>> address in a VRF, whereas for IPv4 the loopback address can be added:
>>
>> $ sudo ip addr add dev vrfred 127.0.0.1/8
>> $ sudo ip -6 addr add ::1/128 dev vrfred
>> RTNETLINK answers: Cannot assign requested address
>>
>> So allow ::1 to be configured on an L3 master device. In order for
>> this to be usable ip_route_output_flags needs to not consider ::1 to
>> be a link scope address (since oif == l3mdev and so it would be
>> dropped), and ipv6_rcv needs to consider the l3mdev to be a loopback
>> device so that it doesn't drop the packets.
>>
>> Signed-off-by: Robert Shearman <rshearma@vyatta.att-mail.com>
>> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
>> ---
>> net/ipv6/addrconf.c | 1 +
>> net/ipv6/ip6_input.c | 3 ++-
>> net/ipv6/route.c | 3 ++-
>> 3 files changed, 5 insertions(+), 2 deletions(-)
>>
>
> Reviewed-by: David Ahern <dsahern@gmail.com>
>
> Been on my to-do list for a while. Thanks for the patch. This resolves,
> for example, a harmless error message from the 'host' command from
> bind9-host-9.10.3 which probes for dscp support via the loopback
> address. e.g.,
>
> $ host www.google.com
> ../../../../lib/isc/unix/net.c:581: sendmsg() failed: Network is unreachable
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net] ip6_tunnel: be careful when accessing the inner header
From: David Miller @ 2018-09-20 4:25 UTC (permalink / raw)
To: pabeni; +Cc: netdev, glider
In-Reply-To: <78ef06b7731007ff16b00962c58f36f87d689d65.1537362057.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Wed, 19 Sep 2018 15:02:07 +0200
> the ip6 tunnel xmit ndo assumes that the processed skb always
> contains an ip[v6] header, but syzbot has found a way to send
> frames that fall short of this assumption, leading to the following splat:
...
> This change addresses the issue adding the needed check before
> accessing the inner header.
>
> The ipv4 side of the issue is apparently there since the ipv4 over ipv6
> initial support, and the ipv6 side predates git history.
>
> Fixes: c4d3efafcc93 ("[IPV6] IP6TUNNEL: Add support to IPv4 over IPv6 tunnel.")
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: syzbot+3fde91d4d394747d6db4@syzkaller.appspotmail.com
> Tested-by: Alexander Potapenko <glider@google.com>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] net: mvneta: fix the Rx desc buffer DMA unmapping
From: David Miller @ 2018-09-20 4:25 UTC (permalink / raw)
To: antoine.tenart
Cc: yelena, netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20180919132906.26868-1-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Wed, 19 Sep 2018 15:29:06 +0200
> With CONFIG_DMA_API_DEBUG enabled we now get a warning when using the
> mvneta driver:
>
> mvneta d0030000.ethernet: DMA-API: device driver frees DMA memory with
> wrong function [device address=0x000000001165b000] [size=4096 bytes]
> [mapped as page] [unmapped as single]
>
> This is because when using the s/w buffer management, the Rx descriptor
> buffer is mapped with dma_map_page but unmapped with dma_unmap_single.
> This patch fixes this by using the right unmapping function.
>
> Fixes: 562e2f467e71 ("net: mvneta: Improve the buffer allocation method for SWBM")
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Applied.
^ permalink raw reply
* [PATCH net] net: mscc: fix the frame extraction into the skb
From: Antoine Tenart @ 2018-09-20 10:08 UTC (permalink / raw)
To: davem
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
alexandre.belloni, quentin.schulz, allan.nielsen
When extracting frames from the Ocelot switch, the frame check sequence
(FCS) is present at the end of the data extracted. The FCS was put into
the sk buffer which introduced some issues (as length related ones), as
the FCS shouldn't be part of an Rx sk buffer.
This patch fixes the Ocelot switch extraction behaviour by discarding
the FCS.
Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
Hi all,
Once this patch will be accepted and net merged into net-next, I'll
probably send another patch to fill skb->csum with the FCS based on
NETIF_F_RXFCS.
Thanks!
Antoine
drivers/net/ethernet/mscc/ocelot_board.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c
index 26bb3b18f3be..3cdf63e35b53 100644
--- a/drivers/net/ethernet/mscc/ocelot_board.c
+++ b/drivers/net/ethernet/mscc/ocelot_board.c
@@ -91,7 +91,7 @@ static irqreturn_t ocelot_xtr_irq_handler(int irq, void *arg)
struct sk_buff *skb;
struct net_device *dev;
u32 *buf;
- int sz, len;
+ int sz, len, buf_len;
u32 ifh[4];
u32 val;
struct frame_info info;
@@ -116,14 +116,20 @@ static irqreturn_t ocelot_xtr_irq_handler(int irq, void *arg)
err = -ENOMEM;
break;
}
- buf = (u32 *)skb_put(skb, info.len);
+ buf_len = info.len - ETH_FCS_LEN;
+ buf = (u32 *)skb_put(skb, buf_len);
len = 0;
do {
sz = ocelot_rx_frame_word(ocelot, grp, false, &val);
*buf++ = val;
len += sz;
- } while ((sz == 4) && (len < info.len));
+ } while (len < buf_len);
+
+ /* Read the FCS and discard it */
+ sz = ocelot_rx_frame_word(ocelot, grp, false, &val);
+ /* Update the statistics if part of the FCS was read before */
+ len -= ETH_FCS_LEN - sz;
if (sz < 0) {
err = sz;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Marek Szyprowski @ 2018-09-20 10:11 UTC (permalink / raw)
To: Janusz Krzysztofik, Linus Walleij
Cc: Jonathan Corbet, Miguel Ojeda Sandonis, Peter Korsgaard,
Peter Rosin, Ulf Hansson, Andrew Lunn, Florian Fainelli,
David S. Miller, Dominik Brodowski, Greg Kroah-Hartman,
Kishon Vijay Abraham I, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, Hartmut Knaack, Peter Meerwald-Stadler,
Jiri Slaby, Willy Tarreau, Geert Uytterhoeven
In-Reply-To: <20180902120144.6855-5-jmkrzyszt@gmail.com>
Hi All,
On 2018-09-02 14:01, Janusz Krzysztofik wrote:
> Certain GPIO descriptor arrays returned by gpio_get_array() may contain
> information on direct mapping of array members to pins of a single GPIO
> chip in hardware order. In such cases, bitmaps of values can be passed
> directly from/to the chip's .get/set_multiple() callbacks without
> wasting time on iterations.
>
> Add respective code to gpiod_get/set_array_bitmap_complex() functions.
> Pins not applicable for fast path are processed as before, skipping
> over the 'fast' ones.
>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
I've just noticed that this patch landed in today's linux-next. Sadly it
breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
Booting hangs after detecting MMC cards. Reverting this patch fixes the
boot. I will try later to add some debugs and investigate it further what
really happens when booting hangs.
> ---
> Documentation/driver-api/gpio/board.rst | 15 ++++++
> Documentation/driver-api/gpio/consumer.rst | 8 +++
> drivers/gpio/gpiolib.c | 87 ++++++++++++++++++++++++++++--
> 3 files changed, 105 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/driver-api/gpio/board.rst b/Documentation/driver-api/gpio/board.rst
> index 2c112553df84..c66821e033c2 100644
> --- a/Documentation/driver-api/gpio/board.rst
> +++ b/Documentation/driver-api/gpio/board.rst
> @@ -193,3 +193,18 @@ And the table can be added to the board code as follows::
>
> The line will be hogged as soon as the gpiochip is created or - in case the
> chip was created earlier - when the hog table is registered.
> +
> +Arrays of pins
> +--------------
> +In addition to requesting pins belonging to a function one by one, a device may
> +also request an array of pins assigned to the function. The way those pins are
> +mapped to the device determines if the array qualifies for fast bitmap
> +processing. If yes, a bitmap is passed over get/set array functions directly
> +between a caller and a respective .get/set_multiple() callback of a GPIO chip.
> +
> +In order to qualify for fast bitmap processing, the pin mapping must meet the
> +following requirements:
> +- it must belong to the same chip as other 'fast' pins of the function,
> +- its index within the function must match its hardware number within the chip.
> +
> +Open drain and open source pins are excluded from fast bitmap output processing.
> diff --git a/Documentation/driver-api/gpio/consumer.rst b/Documentation/driver-api/gpio/consumer.rst
> index 0afd95a12b10..cf992e5ab976 100644
> --- a/Documentation/driver-api/gpio/consumer.rst
> +++ b/Documentation/driver-api/gpio/consumer.rst
> @@ -388,6 +388,14 @@ array_info should be set to NULL.
> Note that for optimal performance GPIOs belonging to the same chip should be
> contiguous within the array of descriptors.
>
> +Still better performance may be achieved if array indexes of the descriptors
> +match hardware pin numbers of a single chip. If an array passed to a get/set
> +array function matches the one obtained from gpiod_get_array() and array_info
> +associated with the array is also passed, the function may take a fast bitmap
> +processing path, passing the value_bitmap argument directly to the respective
> +.get/set_multiple() callback of the chip. That allows for utilization of GPIO
> +banks as data I/O ports without much loss of performance.
> +
> The return value of gpiod_get_array_value() and its variants is 0 on success
> or negative on error. Note the difference to gpiod_get_value(), which returns
> 0 or 1 on success to convey the GPIO value. With the array functions, the GPIO
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index cef6ee31fe05..b9d083fb13ee 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -2789,7 +2789,36 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
> struct gpio_array *array_info,
> unsigned long *value_bitmap)
> {
> - int i = 0;
> + int err, i = 0;
> +
> + /*
> + * Validate array_info against desc_array and its size.
> + * It should immediately follow desc_array if both
> + * have been obtained from the same gpiod_get_array() call.
> + */
> + if (array_info && array_info->desc == desc_array &&
> + array_size <= array_info->size &&
> + (void *)array_info == desc_array + array_info->size) {
> + if (!can_sleep)
> + WARN_ON(array_info->chip->can_sleep);
> +
> + err = gpio_chip_get_multiple(array_info->chip,
> + array_info->get_mask,
> + value_bitmap);
> + if (err)
> + return err;
> +
> + if (!raw && !bitmap_empty(array_info->invert_mask, array_size))
> + bitmap_xor(value_bitmap, value_bitmap,
> + array_info->invert_mask, array_size);
> +
> + if (bitmap_full(array_info->get_mask, array_size))
> + return 0;
> +
> + i = find_first_zero_bit(array_info->get_mask, array_size);
> + } else {
> + array_info = NULL;
> + }
>
> while (i < array_size) {
> struct gpio_chip *chip = desc_array[i]->gdev->chip;
> @@ -2820,7 +2849,12 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
> int hwgpio = gpio_chip_hwgpio(desc);
>
> __set_bit(hwgpio, mask);
> - i++;
> +
> + if (array_info)
> + find_next_zero_bit(array_info->get_mask,
> + array_size, i);
> + else
> + i++;
> } while ((i < array_size) &&
> (desc_array[i]->gdev->chip == chip));
>
> @@ -2831,7 +2865,7 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
> return ret;
> }
>
> - for (j = first; j < i; j++) {
> + for (j = first; j < i; ) {
> const struct gpio_desc *desc = desc_array[j];
> int hwgpio = gpio_chip_hwgpio(desc);
> int value = test_bit(hwgpio, bits);
> @@ -2840,6 +2874,11 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
> value = !value;
> __assign_bit(j, value_bitmap, value);
> trace_gpio_value(desc_to_gpio(desc), 1, value);
> +
> + if (array_info)
> + find_next_zero_bit(array_info->get_mask, i, j);
> + else
> + j++;
> }
>
> if (mask != fastpath)
> @@ -3041,6 +3080,32 @@ int gpiod_set_array_value_complex(bool raw, bool can_sleep,
> {
> int i = 0;
>
> + /*
> + * Validate array_info against desc_array and its size.
> + * It should immediately follow desc_array if both
> + * have been obtained from the same gpiod_get_array() call.
> + */
> + if (array_info && array_info->desc == desc_array &&
> + array_size <= array_info->size &&
> + (void *)array_info == desc_array + array_info->size) {
> + if (!can_sleep)
> + WARN_ON(array_info->chip->can_sleep);
> +
> + if (!raw && !bitmap_empty(array_info->invert_mask, array_size))
> + bitmap_xor(value_bitmap, value_bitmap,
> + array_info->invert_mask, array_size);
> +
> + gpio_chip_set_multiple(array_info->chip, array_info->set_mask,
> + value_bitmap);
> +
> + if (bitmap_full(array_info->set_mask, array_size))
> + return 0;
> +
> + i = find_first_zero_bit(array_info->set_mask, array_size);
> + } else {
> + array_info = NULL;
> + }
> +
> while (i < array_size) {
> struct gpio_chip *chip = desc_array[i]->gdev->chip;
> unsigned long fastpath[2 * BITS_TO_LONGS(FASTPATH_NGPIO)];
> @@ -3068,7 +3133,14 @@ int gpiod_set_array_value_complex(bool raw, bool can_sleep,
> int hwgpio = gpio_chip_hwgpio(desc);
> int value = test_bit(i, value_bitmap);
>
> - if (!raw && test_bit(FLAG_ACTIVE_LOW, &desc->flags))
> + /*
> + * Pins applicable for fast input but not for
> + * fast output processing may have been already
> + * inverted inside the fast path, skip them.
> + */
> + if (!raw && !(array_info &&
> + test_bit(i, array_info->invert_mask)) &&
> + test_bit(FLAG_ACTIVE_LOW, &desc->flags))
> value = !value;
> trace_gpio_value(desc_to_gpio(desc), 0, value);
> /*
> @@ -3087,7 +3159,12 @@ int gpiod_set_array_value_complex(bool raw, bool can_sleep,
> __clear_bit(hwgpio, bits);
> count++;
> }
> - i++;
> +
> + if (array_info)
> + find_next_zero_bit(array_info->set_mask,
> + array_size, i);
> + else
> + i++;
> } while ((i < array_size) &&
> (desc_array[i]->gdev->chip == chip));
> /* push collected bits to outputs */
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* RE: [EXT] [PATCH net] net: mvneta: fix the Rx desc buffer DMA unmapping
From: Yelena Krivosheev @ 2018-09-20 10:14 UTC (permalink / raw)
To: Antoine Tenart, davem@davemloft.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
thomas.petazzoni@bootlin.com, maxime.chevallier@bootlin.com,
gregory.clement@bootlin.com, miquel.raynal@bootlin.com,
Nadav Haklai, Stefan Chulski, Yan Markman, mw@semihalf.com
In-Reply-To: <20180919132906.26868-1-antoine.tenart@bootlin.com>
Hi Antoine.
Good point.
Please, check and fix all cases of dma_unmap_single() usage.
See mvneta_rxq_drop_pkts()
...
if (!data || !(rx_desc->buf_phys_addr))
continue;
dma_unmap_single(pp->dev->dev.parent, rx_desc->buf_phys_addr,
MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE);
__free_page(data);
...
Thanks.
Yelena
-----Original Message-----
From: Antoine Tenart [mailto:antoine.tenart@bootlin.com]
Sent: Wednesday, September 19, 2018 4:29 PM
To: davem@davemloft.net; Yelena Krivosheev <yelena@marvell.com>
Cc: Antoine Tenart <antoine.tenart@bootlin.com>; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; thomas.petazzoni@bootlin.com; maxime.chevallier@bootlin.com; gregory.clement@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai <nadavh@marvell.com>; Stefan Chulski <stefanc@marvell.com>; Yan Markman <ymarkman@marvell.com>; mw@semihalf.com
Subject: [EXT] [PATCH net] net: mvneta: fix the Rx desc buffer DMA unmapping
External Email
----------------------------------------------------------------------
With CONFIG_DMA_API_DEBUG enabled we now get a warning when using the mvneta driver:
mvneta d0030000.ethernet: DMA-API: device driver frees DMA memory with
wrong function [device address=0x000000001165b000] [size=4096 bytes]
[mapped as page] [unmapped as single]
This is because when using the s/w buffer management, the Rx descriptor buffer is mapped with dma_map_page but unmapped with dma_unmap_single.
This patch fixes this by using the right unmapping function.
Fixes: 562e2f467e71 ("net: mvneta: Improve the buffer allocation method for SWBM")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/ethernet/marvell/mvneta.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index bc80a678abc3..2db9708f2e24 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2008,8 +2008,8 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
skb_add_rx_frag(rxq->skb, frag_num, page,
frag_offset, frag_size,
PAGE_SIZE);
- dma_unmap_single(dev->dev.parent, phys_addr,
- PAGE_SIZE, DMA_FROM_DEVICE);
+ dma_unmap_page(dev->dev.parent, phys_addr,
+ PAGE_SIZE, DMA_FROM_DEVICE);
rxq->left_size -= frag_size;
}
} else {
--
2.17.1
^ permalink raw reply related
* Re: [PATCH RFT net-next 0/2] net: phy: Eliminate unnecessary soft
From: Chris Healy @ 2018-09-20 4:39 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Andrew Lunn, Felix Fietkau,
harini.katakam, afleming, Anatolij Gustschin, Arnd Bergmann,
asmirnov, avi.kp.137, avorontsov, baijiaju1990, benh,
charles-antoine.couret, clemens.gruber, Colin King, cyril,
david.thomson, ddaney, dongsheng.wang, David Woodhouse, eha,
houjingj, jeff, Jingju.Hou, Jisheng.Zhang, johan, Kapil.Juneja,
kim.phillips
In-Reply-To: <20180919013505.11347-1-f.fainelli@gmail.com>
> This patch series eliminates unnecessary software resets of the PHY.
> This should hopefully not break anybody's hardware; but I would
> appreciate testing to make sure this is is the case.
Tested-by: Chris Healy <cphealy@gmail.com>
Tested with Marvell 88E6161 and Marvell 88E6352 switches (which use
Marvell PHY driver.)
^ permalink raw reply
* Re: [PATCH] net: toshiba: remove a redundant local variable 'index_specified'
From: Sergei Shtylyov @ 2018-09-20 10:23 UTC (permalink / raw)
To: zhong jiang, davem; +Cc: benh, paulus, mpe, netdev, linux-kernel
In-Reply-To: <1537408565-22315-1-git-send-email-zhongjiang@huawei.com>
On 9/20/2018 4:56 AM, zhong jiang wrote:
> The local variable 'index_specified' is never used after being assigned.
> hence it should be redundant adn can be removed.
s/adn/and/.
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] netlink: ipv4 igmp join notifications
From: David Ahern @ 2018-09-20 4:47 UTC (permalink / raw)
To: pruddy, Roopa Prabhu
Cc: netdev, Jiří Pírko, Stephen Hemminger,
Nikolay Aleksandrov
In-Reply-To: <a7629503af0aa345d65b1651586f906dc7259484.camel@vyatta.att-mail.com>
On 9/18/18 6:12 AM, Patrick Ruddy wrote:
>
> I've hit a small snag with adding the new groups. The number of defined
> groups currently sits at 31 so I can only add one before hitting the
I believe you have no more available. RTNLGRP_* has been defined from 0
(RTNLGRP_NONE) to 31 (RTNLGRP_IPV6_MROUTE_R) which covers the u32 range.
> limit defined by the 32 bit groups bitmask in socakddr_nl. I can use 1
> group for both v4 and v6 notifications which seems like the sensible
> options since the AF is carried separately, but it breaks the precedent
> where there are separate IPV4 and IPV6 groups for IFADDR.
>
> I have the combined group patches ready and can share them if that's
> the preference.
>
> Has there been any previous discussion about extending the number of
> availabel groups?
>
I have not tried it, but from a prior code review I believe you have you
use setsockopt to add groups > 31.
^ permalink raw reply
* Re: [PATCH bpf-next 2/2] xsk: fix bug when trying to use both copy and zero-copy on one queue id
From: Y Song @ 2018-09-20 4:47 UTC (permalink / raw)
To: Magnus Karlsson
Cc: magnus.karlsson, Björn Töpel, Alexei Starovoitov,
Daniel Borkmann, netdev
In-Reply-To: <CAJ8uoz0VjFUqbRRPAO_Gqqz8+APwYNqbpz6eCv2PiXYd9Lf66Q@mail.gmail.com>
On Wed, Sep 19, 2018 at 12:15 AM Magnus Karlsson
<magnus.karlsson@gmail.com> wrote:
>
> On Tue, Sep 18, 2018 at 7:23 PM Y Song <ys114321@gmail.com> wrote:
> >
> > On Tue, Sep 18, 2018 at 3:13 AM Magnus Karlsson
> > <magnus.karlsson@intel.com> wrote:
> > >
> > > Previously, the xsk code did not record which umem was bound to a
> > > specific queue id. This was not required if all drivers were zero-copy
> > > enabled as this had to be recorded in the driver anyway. So if a user
> > > tried to bind two umems to the same queue, the driver would say
> > > no. But if copy-mode was first enabled and then zero-copy mode (or the
> > > reverse order), we mistakenly enabled both of them on the same umem
> > > leading to buggy behavior. The main culprit for this is that we did
> > > not store the association of umem to queue id in the copy case and
> > > only relied on the driver reporting this. As this relation was not
> > > stored in the driver for copy mode (it does not rely on the AF_XDP
> > > NDOs), this obviously could not work.
> > >
> > > This patch fixes the problem by always recording the umem to queue id
> > > relationship in the netdev_queue and netdev_rx_queue structs. This way
> > > we always know what kind of umem has been bound to a queue id and can
> > > act appropriately at bind time.
> > >
> > > Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
> > > ---
> > > net/xdp/xdp_umem.c | 87 +++++++++++++++++++++++++++++++++++++++++++-----------
> > > net/xdp/xdp_umem.h | 2 +-
> > > 2 files changed, 71 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
> > > index b3b632c..12300b5 100644
> > > --- a/net/xdp/xdp_umem.c
> > > +++ b/net/xdp/xdp_umem.c
> > > @@ -42,6 +42,41 @@ void xdp_del_sk_umem(struct xdp_umem *umem, struct xdp_sock *xs)
> > > }
> > > }
> > >
> > > +/* The umem is stored both in the _rx struct and the _tx struct as we do
> > > + * not know if the device has more tx queues than rx, or the opposite.
> > > + * This might also change during run time.
> > > + */
> > > +static void xdp_reg_umem_at_qid(struct net_device *dev, struct xdp_umem *umem,
> > > + u16 queue_id)
> > > +{
> > > + if (queue_id < dev->real_num_rx_queues)
> > > + dev->_rx[queue_id].umem = umem;
> > > + if (queue_id < dev->real_num_tx_queues)
> > > + dev->_tx[queue_id].umem = umem;
> > > +}
> > > +
> > > +static struct xdp_umem *xdp_get_umem_from_qid(struct net_device *dev,
> > > + u16 queue_id)
> > > +{
> > > + if (queue_id < dev->real_num_rx_queues)
> > > + return dev->_rx[queue_id].umem;
> > > + if (queue_id < dev->real_num_tx_queues)
> > > + return dev->_tx[queue_id].umem;
> > > +
> > > + return NULL;
> > > +}
> > > +
> > > +static void xdp_clear_umem_at_qid(struct net_device *dev, u16 queue_id)
> > > +{
> > > + /* Zero out the entry independent on how many queues are configured
> > > + * at this point in time, as it might be used in the future.
> > > + */
> > > + if (queue_id < dev->num_rx_queues)
> > > + dev->_rx[queue_id].umem = NULL;
> > > + if (queue_id < dev->num_tx_queues)
> > > + dev->_tx[queue_id].umem = NULL;
> > > +}
> > > +
> >
> > I am sure whether the following scenario can happen or not.
> > Could you clarify?
> > 1. suppose initially we have num_rx_queues = num_tx_queues = 10
> > xdp_reg_umem_at_qid() set umem1 to queue_id = 8
> > 2. num_tx_queues is changed to 5
>
> You probably mean real_num_tx_queues here. This is the current number
> of queues configured via e.g. ethtool. num_tx_queues will not change
> unless you change device (or device driver).
I am actually not really familiar with this area of
code. Your explanation definitely helps my understanding.
>
> > 3. xdp_clear_umem_at_qid() is called for queue_id = 8,
> > and dev->_rx[8].umum = 0.
>
> At this point both _rx[8].umem and _tx[8].umem are set to NULL as the
> test is against num_[rx|tx]_queues which is the max allowed for the
> device, not the current allocated one which is real_num_tx_queues.
> With this in mind, the scenario below will not happen. Do you agree?
I agree. If num_{rx,tx}_queues are not changed, than clear should set
both with NULL and the step 4/5 won't happen any more.
>
> > 4. xdp_reg_umem_at_qid() is called gain to set for queue_id = 8
> > dev->_rx[8].umem = umem2
> > 5. num_tx_queues is changed to 10
> > Now dev->_rx[8].umem != dev->_tx[8].umem, is this possible and is it
> > a problem?
> >
> > > int xdp_umem_query(struct net_device *dev, u16 queue_id)
> > > {
> > > struct netdev_bpf bpf;
> > > @@ -58,11 +93,11 @@ int xdp_umem_query(struct net_device *dev, u16 queue_id)
> > > }
> > >
> > > int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
> > > - u32 queue_id, u16 flags)
> > > + u16 queue_id, u16 flags)
> > > {
> > > bool force_zc, force_copy;
> > > struct netdev_bpf bpf;
> > > - int err;
> > > + int err = 0;
> > >
> > > force_zc = flags & XDP_ZEROCOPY;
> > > force_copy = flags & XDP_COPY;
> > > @@ -70,18 +105,28 @@ int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
> > > if (force_zc && force_copy)
> > > return -EINVAL;
> > >
> > > + rtnl_lock();
> > > + if (xdp_get_umem_from_qid(dev, queue_id)) {
> > > + err = -EBUSY;
> > > + goto rtnl_unlock;
> > > + }
> > > +
> > > + xdp_reg_umem_at_qid(dev, umem, queue_id);
> > > + umem->dev = dev;
> > > + umem->queue_id = queue_id;
> > > if (force_copy)
> > > - return 0;
> > > + /* For copy-mode, we are done. */
> > > + goto rtnl_unlock;
> > >
> > > - if (!dev->netdev_ops->ndo_bpf || !dev->netdev_ops->ndo_xsk_async_xmit)
> > > - return force_zc ? -EOPNOTSUPP : 0; /* fail or fallback */
> > > + if (!dev->netdev_ops->ndo_bpf ||
> > > + !dev->netdev_ops->ndo_xsk_async_xmit) {
> > > + err = -EOPNOTSUPP;
> > > + goto err_unreg_umem;
> > > + }
> > >
> > > - rtnl_lock();
> > > err = xdp_umem_query(dev, queue_id);
> > > - if (err) {
> > > - err = err < 0 ? -EOPNOTSUPP : -EBUSY;
> > > - goto err_rtnl_unlock;
> > > - }
> > > + if (err)
> > > + goto err_unreg_umem;
> > >
> > > bpf.command = XDP_SETUP_XSK_UMEM;
> > > bpf.xsk.umem = umem;
> > > @@ -89,18 +134,20 @@ int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
> > >
> > > err = dev->netdev_ops->ndo_bpf(dev, &bpf);
> > > if (err)
> > > - goto err_rtnl_unlock;
> > > + goto err_unreg_umem;
> > > rtnl_unlock();
> > >
> > > dev_hold(dev);
> > > - umem->dev = dev;
> > > - umem->queue_id = queue_id;
> > > umem->zc = true;
> > > return 0;
> > >
> > > -err_rtnl_unlock:
> > > +err_unreg_umem:
> > > + xdp_clear_umem_at_qid(dev, queue_id);
> >
> > You did not clear umem->dev and umem->queue_id,is a problem here?
> > For example in xdp_umem_clear_dev(), umem->dev is checked.
>
> As the umem might be shared, I cannot clear these variables as they
> are used by another socket when it is shared.
>
> The umem->dev check in xdp_umem_clear_dev() is for sockets that are
> killed when only half-ways set up. In that case, umem->dev might still
> be NULL.
Make sense.
>
> > > + if (!force_zc)
> > > + err = 0; /* fallback to copy mode */
> > > +rtnl_unlock:
> > > rtnl_unlock();
> > > - return force_zc ? err : 0; /* fail or fallback */
> > > + return err;
> > > }
> > >
> > > static void xdp_umem_clear_dev(struct xdp_umem *umem)
> > > @@ -108,7 +155,7 @@ static void xdp_umem_clear_dev(struct xdp_umem *umem)
> > > struct netdev_bpf bpf;
> > > int err;
> > >
> > > - if (umem->dev) {
> > > + if (umem->zc) {
> > > bpf.command = XDP_SETUP_XSK_UMEM;
> > > bpf.xsk.umem = NULL;
> > > bpf.xsk.queue_id = umem->queue_id;
> > > @@ -121,7 +168,13 @@ static void xdp_umem_clear_dev(struct xdp_umem *umem)
> > > WARN(1, "failed to disable umem!\n");
> > >
> > > dev_put(umem->dev);
> > > - umem->dev = NULL;
> > > + umem->zc = false;
> > > + }
> > > +
> > > + if (umem->dev) {
> > > + rtnl_lock();
> > > + xdp_clear_umem_at_qid(umem->dev, umem->queue_id);
> > > + rtnl_unlock();
> >
> > Previously, umem->dev is reset to NULL. Now, it is left as is. I
> > assume it is not possible
> > that this function xdp_umem_clear_dev() is called again for this umem, right?
>
> This function will only be called once for each umem / queue_id pair.
> We only allow one such binding with this patch. This is what was
> broken with the original code.
Thanks for explanation.
>
> Thanks Song for your review. I appreciate that you take a look at my code.
>
> /Magnus
>
> > > }
> > > }
> > >
> > > diff --git a/net/xdp/xdp_umem.h b/net/xdp/xdp_umem.h
> > > index c8be1ad..2760322 100644
> > > --- a/net/xdp/xdp_umem.h
> > > +++ b/net/xdp/xdp_umem.h
> > > @@ -9,7 +9,7 @@
> > > #include <net/xdp_sock.h>
> > >
> > > int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
> > > - u32 queue_id, u16 flags);
> > > + u16 queue_id, u16 flags);
> > > bool xdp_umem_validate_queues(struct xdp_umem *umem);
> > > void xdp_get_umem(struct xdp_umem *umem);
> > > void xdp_put_umem(struct xdp_umem *umem);
> > > --
> > > 2.7.4
> > >
^ permalink raw reply
* Re: [PATCH mlx5-next 07/25] net/mlx5: Update mlx5_ifc with DEVX UID bits
From: Leon Romanovsky @ 2018-09-20 4:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Yishai Hadas, Saeed Mahameed,
linux-netdev
In-Reply-To: <20180919173147.GO11367@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 880 bytes --]
On Wed, Sep 19, 2018 at 11:31:47AM -0600, Jason Gunthorpe wrote:
> On Mon, Sep 17, 2018 at 02:04:00PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > Add DEVX information to WQ, SRQ, CQ, TRI, TIS, QP,
> > RQ, XRCD, PD, MKEY and MCG.
> >
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > ---
> > include/linux/mlx5/mlx5_ifc.h | 67 +++++++++++++++++++++++++++----------------
> > 1 file changed, 43 insertions(+), 24 deletions(-)
>
> It is weird that we sometimes have these IFC bundle updates and
> sometimes the IFC is inlined in the patch..
>
> Why not just do one big IFC only patch with everything the series
> needs?
Nothing fancy, this "ifc change" came from my need to put all mlx5-next
related code in separate patches from IB and those definitions were
sprinkled in all following IB-specific patches.
Thanks
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH mlx5-next 02/25] net/mlx5: Set uid as part of QP commands
From: Leon Romanovsky @ 2018-09-20 4:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Yishai Hadas, Saeed Mahameed,
linux-netdev
In-Reply-To: <20180919172731.GM11367@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 3618 bytes --]
On Wed, Sep 19, 2018 at 11:27:31AM -0600, Jason Gunthorpe wrote:
> On Mon, Sep 17, 2018 at 02:03:55PM +0300, Leon Romanovsky wrote:
> > From: Yishai Hadas <yishaih@mellanox.com>
> >
> > Set uid as part of QP commands so that the firmware can manage the
> > QP object in a secured way.
> >
> > That will enable using a QP that was created by verbs application to
> > be used by the DEVX flow in case the uid is equal.
> >
> > Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > drivers/net/ethernet/mellanox/mlx5/core/qp.c | 45 +++++++++++++++++-----------
> > include/linux/mlx5/mlx5_ifc.h | 22 +++++++-------
> > include/linux/mlx5/qp.h | 1 +
> > 3 files changed, 39 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/qp.c b/drivers/net/ethernet/mellanox/mlx5/core/qp.c
> > index 4ca07bfb6b14..04f72a1cdbcc 100644
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/qp.c
> > @@ -240,6 +240,7 @@ int mlx5_core_create_qp(struct mlx5_core_dev *dev,
> > if (err)
> > return err;
> >
> > + qp->uid = MLX5_GET(create_qp_in, in, uid);
> > qp->qpn = MLX5_GET(create_qp_out, out, qpn);
> > mlx5_core_dbg(dev, "qpn = 0x%x\n", qp->qpn);
> >
> > @@ -261,6 +262,7 @@ int mlx5_core_create_qp(struct mlx5_core_dev *dev,
> > memset(dout, 0, sizeof(dout));
> > MLX5_SET(destroy_qp_in, din, opcode, MLX5_CMD_OP_DESTROY_QP);
> > MLX5_SET(destroy_qp_in, din, qpn, qp->qpn);
> > + MLX5_SET(destroy_qp_in, din, uid, qp->uid);
> > mlx5_cmd_exec(dev, din, sizeof(din), dout, sizeof(dout));
> > return err;
> > }
> > @@ -320,6 +322,7 @@ int mlx5_core_destroy_qp(struct mlx5_core_dev *dev,
> >
> > MLX5_SET(destroy_qp_in, in, opcode, MLX5_CMD_OP_DESTROY_QP);
> > MLX5_SET(destroy_qp_in, in, qpn, qp->qpn);
> > + MLX5_SET(destroy_qp_in, in, uid, qp->uid);
> > err = mlx5_cmd_exec(dev, in, sizeof(in), out, sizeof(out));
> > if (err)
> > return err;
> > @@ -373,7 +376,7 @@ static void mbox_free(struct mbox_info *mbox)
> >
> > static int modify_qp_mbox_alloc(struct mlx5_core_dev *dev, u16 opcode, int qpn,
> > u32 opt_param_mask, void *qpc,
> > - struct mbox_info *mbox)
> > + struct mbox_info *mbox, u16 uid)
> > {
> > mbox->out = NULL;
> > mbox->in = NULL;
> > @@ -381,26 +384,32 @@ static int modify_qp_mbox_alloc(struct mlx5_core_dev *dev, u16 opcode, int qpn,
> > #define MBOX_ALLOC(mbox, typ) \
> > mbox_alloc(mbox, MLX5_ST_SZ_BYTES(typ##_in), MLX5_ST_SZ_BYTES(typ##_out))
> >
> > -#define MOD_QP_IN_SET(typ, in, _opcode, _qpn) \
> > - MLX5_SET(typ##_in, in, opcode, _opcode); \
> > - MLX5_SET(typ##_in, in, qpn, _qpn)
> > -
> > -#define MOD_QP_IN_SET_QPC(typ, in, _opcode, _qpn, _opt_p, _qpc) \
> > - MOD_QP_IN_SET(typ, in, _opcode, _qpn); \
> > - MLX5_SET(typ##_in, in, opt_param_mask, _opt_p); \
> > - memcpy(MLX5_ADDR_OF(typ##_in, in, qpc), _qpc, MLX5_ST_SZ_BYTES(qpc))
> > +#define MOD_QP_IN_SET(typ, in, _opcode, _qpn, _uid) \
> > + do { \
> > + MLX5_SET(typ##_in, in, opcode, _opcode); \
> > + MLX5_SET(typ##_in, in, qpn, _qpn); \
> > + MLX5_SET(typ##_in, in, uid, _uid); \
> > + } while (0)
> > +
> > +#define MOD_QP_IN_SET_QPC(typ, in, _opcode, _qpn, _opt_p, _qpc, _uid) \
> > + do { \
> > + MOD_QP_IN_SET(typ, in, _opcode, _qpn, _uid); \
> > + MLX5_SET(typ##_in, in, opt_param_mask, _opt_p); \
> > + memcpy(MLX5_ADDR_OF(typ##_in, in, qpc), \
> > + _qpc, MLX5_ST_SZ_BYTES(qpc)); \
> > + } while (0)
>
> These should get touched by clang-format to follow the usual
> formatting for macros..
Thanks, we will do.
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 00/21] SMMU enablement for NXP LS1043A and LS1046A
From: Laurentiu Tudor @ 2018-09-20 10:38 UTC (permalink / raw)
To: Robin Murphy, devicetree@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Madalin-cristian Bucur, Roy Pledge, Leo Li, shawnguo@kernel.org,
davem@davemloft.net
In-Reply-To: <39211e7a-034b-cdca-f182-1b6f6e5fbc53@arm.com>
On 19.09.2018 17:37, Robin Murphy wrote:
> On 19/09/18 15:18, Laurentiu Tudor wrote:
>> Hi Robin,
>>
>> On 19.09.2018 16:25, Robin Murphy wrote:
>>> Hi Laurentiu,
>>>
>>> On 19/09/18 13:35, laurentiu.tudor@nxp.com wrote:
>>>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>>>
>>>> This patch series adds SMMU support for NXP LS1043A and LS1046A chips
>>>> and consists mostly in important driver fixes and the required device
>>>> tree updates. It touches several subsystems and consists of three main
>>>> parts:
>>>> - changes in soc/drivers/fsl/qbman drivers adding iommu mapping of
>>>> reserved memory areas, fixes and defered probe support
>>>> - changes in drivers/net/ethernet/freescale/dpaa_eth drivers
>>>> consisting in misc dma mapping related fixes and probe ordering
>>>> - addition of the actual arm smmu device tree node together with
>>>> various adjustments to the device trees
>>>>
>>>> Performance impact
>>>>
>>>> Running iperf benchmarks in a back-to-back setup (both sides
>>>> having smmu enabled) on a 10GBps port show an important
>>>> networking performance degradation of around %40 (9.48Gbps
>>>> linerate vs 5.45Gbps). If you need performance but without
>>>> SMMU support you can use "iommu.passthrough=1" to disable
>>>> SMMU.
>>>>
>>>> USB issue and workaround
>>>>
>>>> There's a problem with the usb controllers in these chips
>>>> generating smaller, 40-bit wide dma addresses instead of the
>>>> 48-bit
>>>> supported at the smmu input. So you end up in a situation
>>>> where the
>>>> smmu is mapped with 48-bit address translations, but the device
>>>> generates transactions with clipped 40-bit addresses, thus smmu
>>>> context faults are triggered. I encountered a similar
>>>> situation for
>>>> mmc that I managed to fix in software [1] however for USB I
>>>> did not
>>>> find a proper place in the code to add a similar fix. The only
>>>> workaround I found was to add this kernel parameter which
>>>> limits the
>>>> usb dma to 32-bit size: "xhci-hcd.quirks=0x800000".
>>>> This workaround if far from ideal, so any suggestions for a code
>>>> based workaround in this area would be greatly appreciated.
>>>
>>> If you have a nominally-64-bit device with a
>>> narrower-than-the-main-interconnect link in front of it, that should
>>> already be fixed in 4.19-rc by bus_dma_mask picking up DT dma-ranges,
>>> provided the interconnect hierarchy can be described appropriately (or
>>> at least massaged sufficiently to satisfy the binding), e.g.:
>>>
>>> / {
>>> ...
>>>
>>> soc {
>>> ranges;
>>> dma-ranges = <0 0 10000 0>;
>>>
>>> dev_48bit { ... };
>>>
>>> periph_bus {
>>> ranges;
>>> dma-ranges = <0 0 100 0>;
>>>
>>> dev_40bit { ... };
>>> };
>>> };
>>> };
>>>
>>> and if that fails to work as expected (except for PCI hosts where
>>> handling dma-ranges properly still needs sorting out), please do let us
>>> know ;)
>>>
>>
>> Just to confirm, Is this [1] the change I was supposed to test?
>
> Not quite - dma-ranges is only valid for nodes representing a bus, so
> putting it directly in the USB device nodes doesn't work (FWIW that's
> why PCI is broken, because the parser doesn't expect the
> bus-as-leaf-node case). That's teh point of that intermediate simple-bus
> node represented by "periph_bus" in my example (sorry, I should have put
> compatibles in to make it clearer) - often that's actually true to life
> (i.e. "soc" is something like a CCI and "periph_bus" is something like
> an AXI NIC gluing a bunch of lower-bandwidth DMA masters to one of the
> CCI ports) but at worst it's just a necessary evil to make the binding
> happy (if it literally only represents the point-to-point link between
> the device master port and interconnect slave port).
>
Quick update: so I adjusted to device tree according to your example and
it works so now I can get rid of that nasty kernel arg based workaround,
yey! :-)
Thanks a lot, that was really helpful.
---
Best Regards, Laurentiu
^ permalink raw reply
* [PATCH net 1/3] qed: Fix populating the invalid stag value in multi function mode.
From: Sudarsana Reddy Kalluru @ 2018-09-20 4:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon, Tomer.Tayar
In-Reply-To: <20180920045912.28437-1-sudarsana.kalluru@cavium.com>
In multi-function mode, driver receives the stag value (outer vlan)
for a PF from management FW (MFW). If the stag value is negotiated prior to
the driver load, then the stag is not notified to the driver and hence
driver will have the invalid stag value.
The fix is to request the MFW for STAG value during the driver load time.
Fixes: cac6f691 ("qed: Add support for Unified Fabric Port")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Tomer Tayar <Tomer.Tayar@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 15 ++++++++++++++-
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 4 ++++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index 016ca8a..97f073f 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -1706,7 +1706,7 @@ static int qed_vf_start(struct qed_hwfn *p_hwfn,
int qed_hw_init(struct qed_dev *cdev, struct qed_hw_init_params *p_params)
{
struct qed_load_req_params load_req_params;
- u32 load_code, param, drv_mb_param;
+ u32 load_code, resp, param, drv_mb_param;
bool b_default_mtu = true;
struct qed_hwfn *p_hwfn;
int rc = 0, mfw_rc, i;
@@ -1852,6 +1852,19 @@ int qed_hw_init(struct qed_dev *cdev, struct qed_hw_init_params *p_params)
if (IS_PF(cdev)) {
p_hwfn = QED_LEADING_HWFN(cdev);
+
+ /* Get pre-negotiated values for stag, bandwidth etc. */
+ DP_VERBOSE(p_hwfn,
+ QED_MSG_SPQ,
+ "Sending GET_OEM_UPDATES command to trigger stag/bandwidth attention handling\n");
+ drv_mb_param = 1 << DRV_MB_PARAM_DUMMY_OEM_UPDATES_OFFSET;
+ rc = qed_mcp_cmd(p_hwfn, p_hwfn->p_main_ptt,
+ DRV_MSG_CODE_GET_OEM_UPDATES,
+ drv_mb_param, &resp, ¶m);
+ if (rc)
+ DP_NOTICE(p_hwfn,
+ "Failed to send GET_OEM_UPDATES attention request\n");
+
drv_mb_param = STORM_FW_VERSION;
rc = qed_mcp_cmd(p_hwfn, p_hwfn->p_main_ptt,
DRV_MSG_CODE_OV_UPDATE_STORM_FW_VER,
diff --git a/drivers/net/ethernet/qlogic/qed/qed_hsi.h b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
index 8faceb6..9b3ef00e 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_hsi.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
@@ -12414,6 +12414,7 @@ struct public_drv_mb {
#define DRV_MSG_SET_RESOURCE_VALUE_MSG 0x35000000
#define DRV_MSG_CODE_OV_UPDATE_WOL 0x38000000
#define DRV_MSG_CODE_OV_UPDATE_ESWITCH_MODE 0x39000000
+#define DRV_MSG_CODE_GET_OEM_UPDATES 0x41000000
#define DRV_MSG_CODE_BW_UPDATE_ACK 0x32000000
#define DRV_MSG_CODE_NIG_DRAIN 0x30000000
@@ -12541,6 +12542,9 @@ struct public_drv_mb {
#define DRV_MB_PARAM_ESWITCH_MODE_VEB 0x1
#define DRV_MB_PARAM_ESWITCH_MODE_VEPA 0x2
+#define DRV_MB_PARAM_DUMMY_OEM_UPDATES_MASK 0x1
+#define DRV_MB_PARAM_DUMMY_OEM_UPDATES_OFFSET 0
+
#define DRV_MB_PARAM_SET_LED_MODE_OPER 0x0
#define DRV_MB_PARAM_SET_LED_MODE_ON 0x1
#define DRV_MB_PARAM_SET_LED_MODE_OFF 0x2
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 2/3] qed: Do not add VLAN 0 tag to untagged frames in multi-function mode.
From: Sudarsana Reddy Kalluru @ 2018-09-20 4:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon, Tomer.Tayar
In-Reply-To: <20180920045912.28437-1-sudarsana.kalluru@cavium.com>
In certain multi-function switch dependent modes, firmware adds vlan tag 0
to the untagged frames. This leads to double tagging for the traffic
if the dcbx is enabled, which is not the desired behavior. To avoid this,
driver needs to set "dcb_dont_add_vlan0" flag.
Fixes: cac6f691 ("qed: Add support for Unified Fabric Port")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Tomer Tayar <Tomer.Tayar@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 9 ++++++++-
drivers/net/ethernet/qlogic/qed/qed_dcbx.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index 6bb76e6..d53f33c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -190,6 +190,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
static void
qed_dcbx_set_params(struct qed_dcbx_results *p_data,
+ struct qed_hwfn *p_hwfn,
struct qed_hw_info *p_info,
bool enable,
u8 prio,
@@ -206,6 +207,11 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
else
p_data->arr[type].update = DONT_UPDATE_DCB_DSCP;
+ /* Do not add vlan tag 0 when DCB is enabled and port in UFP/OV mode */
+ if ((test_bit(QED_MF_8021Q_TAGGING, &p_hwfn->cdev->mf_bits) ||
+ test_bit(QED_MF_8021AD_TAGGING, &p_hwfn->cdev->mf_bits)))
+ p_data->arr[type].dont_add_vlan0 = true;
+
/* QM reconf data */
if (p_info->personality == personality)
qed_hw_info_set_offload_tc(p_info, tc);
@@ -231,7 +237,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
personality = qed_dcbx_app_update[i].personality;
- qed_dcbx_set_params(p_data, p_info, enable,
+ qed_dcbx_set_params(p_data, p_hwfn, p_info, enable,
prio, tc, type, personality);
}
}
@@ -954,6 +960,7 @@ static void qed_dcbx_update_protocol_data(struct protocol_dcb_data *p_data,
p_data->dcb_enable_flag = p_src->arr[type].enable;
p_data->dcb_priority = p_src->arr[type].priority;
p_data->dcb_tc = p_src->arr[type].tc;
+ p_data->dcb_dont_add_vlan0 = p_src->arr[type].dont_add_vlan0;
}
/* Set pf update ramrod command params */
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.h b/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
index a4d688c..01f253e 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
@@ -55,6 +55,7 @@ struct qed_dcbx_app_data {
u8 update; /* Update indication */
u8 priority; /* Priority */
u8 tc; /* Traffic Class */
+ bool dont_add_vlan0; /* Do not insert a vlan tag with id 0 */
};
#define QED_DCBX_VERSION_DISABLED 0
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 3/3] qed: Add missing device config for RoCE EDPM in UFP mode.
From: Sudarsana Reddy Kalluru @ 2018-09-20 4:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon, Tomer.Tayar
In-Reply-To: <20180920045912.28437-1-sudarsana.kalluru@cavium.com>
This patch adds support to configure the DORQ to use vlan-id/priority for
roce EDPM.
Fixes: cac6f691 ("qed: Add support for Unified Fabric Port")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Tomer Tayar <Tomer.Tayar@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 40 ++++++++++++++------------
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 24 +++++++++++++---
drivers/net/ethernet/qlogic/qed/qed_reg_addr.h | 6 ++++
3 files changed, 48 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index d53f33c..f5459de 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -190,11 +190,8 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
static void
qed_dcbx_set_params(struct qed_dcbx_results *p_data,
- struct qed_hwfn *p_hwfn,
- struct qed_hw_info *p_info,
- bool enable,
- u8 prio,
- u8 tc,
+ struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
+ bool enable, u8 prio, u8 tc,
enum dcbx_protocol_type type,
enum qed_pci_personality personality)
{
@@ -213,18 +210,24 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
p_data->arr[type].dont_add_vlan0 = true;
/* QM reconf data */
- if (p_info->personality == personality)
- qed_hw_info_set_offload_tc(p_info, tc);
+ if (p_hwfn->hw_info.personality == personality)
+ qed_hw_info_set_offload_tc(&p_hwfn->hw_info, tc);
+
+ /* Configure dcbx vlan priority in doorbell block for roce EDPM */
+ if (test_bit(QED_MF_UFP_SPECIFIC, &p_hwfn->cdev->mf_bits) &&
+ type == DCBX_PROTOCOL_ROCE) {
+ qed_wr(p_hwfn, p_ptt, DORQ_REG_TAG1_OVRD_MODE, 1);
+ qed_wr(p_hwfn, p_ptt, DORQ_REG_PF_PCP_BB_K2, prio << 1);
+ }
}
/* Update app protocol data and hw_info fields with the TLV info */
static void
qed_dcbx_update_app_info(struct qed_dcbx_results *p_data,
- struct qed_hwfn *p_hwfn,
- bool enable,
- u8 prio, u8 tc, enum dcbx_protocol_type type)
+ struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
+ bool enable, u8 prio, u8 tc,
+ enum dcbx_protocol_type type)
{
- struct qed_hw_info *p_info = &p_hwfn->hw_info;
enum qed_pci_personality personality;
enum dcbx_protocol_type id;
int i;
@@ -237,7 +240,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
personality = qed_dcbx_app_update[i].personality;
- qed_dcbx_set_params(p_data, p_hwfn, p_info, enable,
+ qed_dcbx_set_params(p_data, p_hwfn, p_ptt, enable,
prio, tc, type, personality);
}
}
@@ -271,7 +274,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
* reconfiguring QM. Get protocol specific data for PF update ramrod command.
*/
static int
-qed_dcbx_process_tlv(struct qed_hwfn *p_hwfn,
+qed_dcbx_process_tlv(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
struct qed_dcbx_results *p_data,
struct dcbx_app_priority_entry *p_tbl,
u32 pri_tc_tbl, int count, u8 dcbx_version)
@@ -315,7 +318,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
enable = true;
}
- qed_dcbx_update_app_info(p_data, p_hwfn, enable,
+ qed_dcbx_update_app_info(p_data, p_hwfn, p_ptt, enable,
priority, tc, type);
}
}
@@ -337,7 +340,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
continue;
enable = (type == DCBX_PROTOCOL_ETH) ? false : !!dcbx_version;
- qed_dcbx_update_app_info(p_data, p_hwfn, enable,
+ qed_dcbx_update_app_info(p_data, p_hwfn, p_ptt, enable,
priority, tc, type);
}
@@ -347,7 +350,8 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
/* Parse app TLV's to update TC information in hw_info structure for
* reconfiguring QM. Get protocol specific data for PF update ramrod command.
*/
-static int qed_dcbx_process_mib_info(struct qed_hwfn *p_hwfn)
+static int
+qed_dcbx_process_mib_info(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
{
struct dcbx_app_priority_feature *p_app;
struct dcbx_app_priority_entry *p_tbl;
@@ -371,7 +375,7 @@ static int qed_dcbx_process_mib_info(struct qed_hwfn *p_hwfn)
p_info = &p_hwfn->hw_info;
num_entries = QED_MFW_GET_FIELD(p_app->flags, DCBX_APP_NUM_ENTRIES);
- rc = qed_dcbx_process_tlv(p_hwfn, &data, p_tbl, pri_tc_tbl,
+ rc = qed_dcbx_process_tlv(p_hwfn, p_ptt, &data, p_tbl, pri_tc_tbl,
num_entries, dcbx_version);
if (rc)
return rc;
@@ -897,7 +901,7 @@ static void qed_dcbx_aen(struct qed_hwfn *hwfn, u32 mib_type)
return rc;
if (type == QED_DCBX_OPERATIONAL_MIB) {
- rc = qed_dcbx_process_mib_info(p_hwfn);
+ rc = qed_dcbx_process_mib_info(p_hwfn, p_ptt);
if (!rc) {
/* reconfigure tcs of QM queues according
* to negotiation results
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index 5d37ec7..58c7eb9 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -1581,13 +1581,29 @@ static void qed_mcp_update_stag(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
p_hwfn->mcp_info->func_info.ovlan = (u16)shmem_info.ovlan_stag &
FUNC_MF_CFG_OV_STAG_MASK;
p_hwfn->hw_info.ovlan = p_hwfn->mcp_info->func_info.ovlan;
- if ((p_hwfn->hw_info.hw_mode & BIT(MODE_MF_SD)) &&
- (p_hwfn->hw_info.ovlan != QED_MCP_VLAN_UNSET)) {
- qed_wr(p_hwfn, p_ptt,
- NIG_REG_LLH_FUNC_TAG_VALUE, p_hwfn->hw_info.ovlan);
+ if (test_bit(QED_MF_OVLAN_CLSS, &p_hwfn->cdev->mf_bits)) {
+ if (p_hwfn->hw_info.ovlan != QED_MCP_VLAN_UNSET) {
+ qed_wr(p_hwfn, p_ptt, NIG_REG_LLH_FUNC_TAG_VALUE,
+ p_hwfn->hw_info.ovlan);
+ qed_wr(p_hwfn, p_ptt, NIG_REG_LLH_FUNC_TAG_EN, 1);
+
+ /* Configure DB to add external vlan to EDPM packets */
+ qed_wr(p_hwfn, p_ptt, DORQ_REG_TAG1_OVRD_MODE, 1);
+ qed_wr(p_hwfn, p_ptt, DORQ_REG_PF_EXT_VID_BB_K2,
+ p_hwfn->hw_info.ovlan);
+ } else {
+ qed_wr(p_hwfn, p_ptt, NIG_REG_LLH_FUNC_TAG_EN, 0);
+ qed_wr(p_hwfn, p_ptt, NIG_REG_LLH_FUNC_TAG_VALUE, 0);
+ qed_wr(p_hwfn, p_ptt, DORQ_REG_TAG1_OVRD_MODE, 0);
+ qed_wr(p_hwfn, p_ptt, DORQ_REG_PF_EXT_VID_BB_K2, 0);
+ }
+
qed_sp_pf_update_stag(p_hwfn);
}
+ DP_VERBOSE(p_hwfn, QED_MSG_SP, "ovlan = %d hw_mode = 0x%x\n",
+ p_hwfn->mcp_info->func_info.ovlan, p_hwfn->hw_info.hw_mode);
+
/* Acknowledge the MFW */
qed_mcp_cmd(p_hwfn, p_ptt, DRV_MSG_CODE_S_TAG_UPDATE_ACK, 0,
&resp, ¶m);
diff --git a/drivers/net/ethernet/qlogic/qed/qed_reg_addr.h b/drivers/net/ethernet/qlogic/qed/qed_reg_addr.h
index f736f70..2440970 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_reg_addr.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_reg_addr.h
@@ -216,6 +216,12 @@
0x00c000UL
#define DORQ_REG_IFEN \
0x100040UL
+#define DORQ_REG_TAG1_OVRD_MODE \
+ 0x1008b4UL
+#define DORQ_REG_PF_PCP_BB_K2 \
+ 0x1008c4UL
+#define DORQ_REG_PF_EXT_VID_BB_K2 \
+ 0x1008c8UL
#define DORQ_REG_DB_DROP_REASON \
0x100a2cUL
#define DORQ_REG_DB_DROP_DETAILS \
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 0/3] qed: Fix series for multi-function mode implementation.
From: Sudarsana Reddy Kalluru @ 2018-09-20 4:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon, Tomer.Tayar, Sudarsana Reddy Kalluru
From: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
The patch series addresses few issues in the switch dependent multi-function modes.
Please consider applying it to 'net' tree.
Sudarsana Reddy Kalluru (3):
qed: Fix populating the invalid stag value in multi function mode.
qed: Do not add VLAN 0 tag to untagged frames in multi-function mode.
qed: Add missing device config for RoCE EDPM in UFP mode.
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 45 ++++++++++++++++----------
drivers/net/ethernet/qlogic/qed/qed_dcbx.h | 1 +
drivers/net/ethernet/qlogic/qed/qed_dev.c | 15 ++++++++-
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 4 +++
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 24 +++++++++++---
drivers/net/ethernet/qlogic/qed/qed_reg_addr.h | 6 ++++
6 files changed, 73 insertions(+), 22 deletions(-)
--
1.8.3.1
^ 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