* Re: [PATCH net] stmmac: fix reception of 802.1ad Ethernet tagged frames
From: Toshiaki Makita @ 2018-05-08 6:43 UTC (permalink / raw)
To: Elad Nachman; +Cc: davem, netdev
In-Reply-To: <b3f73283-cc98-fbb3-7b65-cd0dd4d41d41@gmail.com>
On 2018/05/08 15:01, Elad Nachman wrote:
> stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before calling napi_gro_receive().
>
> The function assumes VLAN tagged frames are always tagged with 802.1Q protocol,
> and assigns ETH_P_8021Q to the skb by hard-coding the parameter on call to __vlan_hwaccel_put_tag() .
>
> This causes packets not to be passed to the VLAN slave if it was created with 802.1AD protocol
> (ip link add link eth0 eth0.100 type vlan proto 802.1ad id 100).
>
> This fix passes the protocol from the VLAN header into __vlan_hwaccel_put_tag()
> instead of using the hard-coded value of ETH_P_8021Q.
>
> Signed-off-by: Elad Nachman <eladn@gilat.com>
>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index b65e2d1..ced2d34 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -3293,17 +3293,19 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
>
> static void stmmac_rx_vlan(struct net_device *dev, struct sk_buff *skb)
> {
> - struct ethhdr *ehdr;
> + struct vlan_ethhdr *veth;
> u16 vlanid;
> + __be16 vlan_proto;
>
> if ((dev->features & NETIF_F_HW_VLAN_CTAG_RX) ==
> NETIF_F_HW_VLAN_CTAG_RX &&
> !__vlan_get_tag(skb, &vlanid)) {
> /* pop the vlan tag */
> - ehdr = (struct ethhdr *)skb->data;
> - memmove(skb->data + VLAN_HLEN, ehdr, ETH_ALEN * 2);
> + veth = (struct vlan_ethhdr *)skb->data;
> + vlan_proto = veth->h_vlan_proto;
> + memmove(skb->data + VLAN_HLEN, veth, ETH_ALEN * 2);
> skb_pull(skb, VLAN_HLEN);
> - __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlanid);
> + __vlan_hwaccel_put_tag(skb, vlan_proto, vlanid);
This is what devices with NETIF_F_HW_VLAN_STAG_RX are supposed to do,
not NETIF_F_HW_VLAN_CTAG_RX.
By the way this looks like doing the same thing as skb_vlan_untag in
__netif_receive_skb_core, so seems unnecessary to add HW_VLAN_STAG_RX.
Alternatively you can check if vlan_proto is 8021Q here.
--
Toshiaki Makita
^ permalink raw reply
* Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring
From: Tiwei Bie @ 2018-05-08 6:44 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, virtualization, linux-kernel, netdev, wexu,
jfreimann
In-Reply-To: <12ede490-f674-2b89-d639-266b5fe15466@redhat.com>
On Tue, May 08, 2018 at 01:40:40PM +0800, Jason Wang wrote:
> On 2018年05月08日 11:05, Jason Wang wrote:
> > >
> > > Because in virtqueue_enable_cb_delayed(), we may set an
> > > event_off which is bigger than new and both of them have
> > > wrapped. And in this case, although new is smaller than
> > > event_off (i.e. the third param -- old), new shouldn't
> > > add vq->num, and actually we are expecting a very big
> > > idx diff.
> >
> > Yes, so to calculate distance correctly between event and new, we just
> > need to compare the warp counter and return false if it doesn't match
> > without the need to try to add vq.num here.
> >
> > Thanks
>
> Sorry, looks like the following should work, we need add vq.num if
> used_wrap_counter does not match:
>
> static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
> __u16 off_wrap, __u16 new,
> __u16 old)
> {
> bool wrap = off_wrap >> 15;
> int off = off_wrap & ~(1 << 15);
> __u16 d1, d2;
>
> if (wrap != vq->used_wrap_counter)
> d1 = new + vq->num - off - 1;
Just to draw your attention (maybe you have already
noticed this).
In this case (i.e. wrap != vq->used_wrap_counter),
it's also possible that (off < new) is true. Because,
when virtqueue_enable_cb_delayed_packed() is used,
`off` is calculated in driver in a way like this:
off = vq->last_used_idx + bufs;
if (off >= vq->vring_packed.num) {
off -= vq->vring_packed.num;
wrap_counter ^= 1;
}
And when `new` (in vhost) is close to vq->num. The
vq->last_used_idx + bufs (in driver) can be bigger
than vq->vring_packed.num, and:
1. `off` will wrap;
2. wrap counters won't match;
3. off < new;
And d1 (i.e. new + vq->num - off - 1) will be a value
bigger than vq->num. I'm okay with this, although it's
a bit weird.
Best regards,
Tiwei Bie
> else
> d1 = new - off - 1;
>
> if (new > old)
> d2 = new - old;
> else
> d2 = new + vq->num - old;
>
> return d1 < d2;
> }
>
> Thanks
>
^ permalink raw reply
* Re: [PATCH] net: 8390: Fix possible data races in __ei_get_stats
From: Jia-Ju Bai @ 2018-05-08 6:47 UTC (permalink / raw)
To: Eric Dumazet, davem, fthain, joe; +Cc: netdev, linux-kernel
In-Reply-To: <dddbec3f-4b63-3e70-d857-4980135d6f31@gmail.com>
On 2018/5/8 13:04, Eric Dumazet wrote:
>
> On 05/07/2018 07:16 PM, Jia-Ju Bai wrote:
>
>> Yes, "&dev->stats" will not change, because it is a fixed address.
>> But the field data in "dev->stats" is changed (rx_frame_errors, rx_crc_errors and rx_missed_errors).
>> So if the driver returns "&dev->stats" without lock protection (like on line 858), the field data value of this return value can be the changed field data value or unchanged field data value.
>
> We do not care.
>
> This function can be called by multiple cpus at the same time.
>
> As soon as one cpu returns from it, another cpu can happily modify dev->stats.ANYFIELD.
>
> Your patch fixes nothing at all.
>
Okay, thanks.
I also find that my patch does not work...
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH net] stmmac: fix reception of 802.1ad Ethernet tagged frames
From: Elad Nachman @ 2018-05-08 7:11 UTC (permalink / raw)
To: Toshiaki Makita; +Cc: davem, netdev, eladv6
In-Reply-To: <dcd6ce9c-e098-d901-ecb9-0c2b6d4219cf@lab.ntt.co.jp>
Currently running:
ip link add link eth0 eth0.100 type vlan proto 802.1ad id 100
On eth0=stmmac succeeds, but the end result is that the vlan device gets proto 802.1q instead of proto 802.1ad and drops the received packet. Without the patch packets gets dropped for a seemingly "correct" 802.1ad ip link configuration.
If NETIF_F_HW_VLAN_STAG_RX is a requirement for the driver for supporting 802.1ad protocols then the Linux kernel should return error when user-space requests to create a vlan device with proto 802.1ad for physical devices which lacks NETIF_F_HW_VLAN_STAG_RX, which is not currently the case.
skb_vlan_untag() does nothing if __vlan_hwaccel_put_tag() was already called before (in the driver). The only possible alternative is to completely remove stmmac_rx_vlan() from the stmmac code and let skb_vlan_untag() handles things in a generic way.
On 08/05/18 09:43, Toshiaki Makita wrote:
> On 2018/05/08 15:01, Elad Nachman wrote:
>> stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before calling napi_gro_receive().
>>
>> The function assumes VLAN tagged frames are always tagged with 802.1Q protocol,
>> and assigns ETH_P_8021Q to the skb by hard-coding the parameter on call to __vlan_hwaccel_put_tag() .
>>
>> This causes packets not to be passed to the VLAN slave if it was created with 802.1AD protocol
>> (ip link add link eth0 eth0.100 type vlan proto 802.1ad id 100).
>>
>> This fix passes the protocol from the VLAN header into __vlan_hwaccel_put_tag()
>> instead of using the hard-coded value of ETH_P_8021Q.
>>
>> Signed-off-by: Elad Nachman <eladn@gilat.com>
>>
>> ---
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++++++----
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index b65e2d1..ced2d34 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -3293,17 +3293,19 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
>>
>> static void stmmac_rx_vlan(struct net_device *dev, struct sk_buff *skb)
>> {
>> - struct ethhdr *ehdr;
>> + struct vlan_ethhdr *veth;
>> u16 vlanid;
>> + __be16 vlan_proto;
>>
>> if ((dev->features & NETIF_F_HW_VLAN_CTAG_RX) ==
>> NETIF_F_HW_VLAN_CTAG_RX &&
>> !__vlan_get_tag(skb, &vlanid)) {
>> /* pop the vlan tag */
>> - ehdr = (struct ethhdr *)skb->data;
>> - memmove(skb->data + VLAN_HLEN, ehdr, ETH_ALEN * 2);
>> + veth = (struct vlan_ethhdr *)skb->data;
>> + vlan_proto = veth->h_vlan_proto;
>> + memmove(skb->data + VLAN_HLEN, veth, ETH_ALEN * 2);
>> skb_pull(skb, VLAN_HLEN);
>> - __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlanid);
>> + __vlan_hwaccel_put_tag(skb, vlan_proto, vlanid);
>
> This is what devices with NETIF_F_HW_VLAN_STAG_RX are supposed to do,
> not NETIF_F_HW_VLAN_CTAG_RX.
>
> By the way this looks like doing the same thing as skb_vlan_untag in
> __netif_receive_skb_core, so seems unnecessary to add HW_VLAN_STAG_RX.
> Alternatively you can check if vlan_proto is 8021Q here.
>
^ permalink raw reply
* Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring
From: Jason Wang @ 2018-05-08 7:16 UTC (permalink / raw)
To: Tiwei Bie
Cc: Michael S. Tsirkin, virtualization, linux-kernel, netdev, wexu,
jfreimann
In-Reply-To: <20180508064409.kcn6amhsxu7nkuuc@debian>
On 2018年05月08日 14:44, Tiwei Bie wrote:
> On Tue, May 08, 2018 at 01:40:40PM +0800, Jason Wang wrote:
>> On 2018年05月08日 11:05, Jason Wang wrote:
>>>> Because in virtqueue_enable_cb_delayed(), we may set an
>>>> event_off which is bigger than new and both of them have
>>>> wrapped. And in this case, although new is smaller than
>>>> event_off (i.e. the third param -- old), new shouldn't
>>>> add vq->num, and actually we are expecting a very big
>>>> idx diff.
>>> Yes, so to calculate distance correctly between event and new, we just
>>> need to compare the warp counter and return false if it doesn't match
>>> without the need to try to add vq.num here.
>>>
>>> Thanks
>> Sorry, looks like the following should work, we need add vq.num if
>> used_wrap_counter does not match:
>>
>> static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
>> __u16 off_wrap, __u16 new,
>> __u16 old)
>> {
>> bool wrap = off_wrap >> 15;
>> int off = off_wrap & ~(1 << 15);
>> __u16 d1, d2;
>>
>> if (wrap != vq->used_wrap_counter)
>> d1 = new + vq->num - off - 1;
> Just to draw your attention (maybe you have already
> noticed this).
I miss this, thanks!
>
> In this case (i.e. wrap != vq->used_wrap_counter),
> it's also possible that (off < new) is true. Because,
>
> when virtqueue_enable_cb_delayed_packed() is used,
> `off` is calculated in driver in a way like this:
>
> off = vq->last_used_idx + bufs;
> if (off >= vq->vring_packed.num) {
> off -= vq->vring_packed.num;
> wrap_counter ^= 1;
> }
>
> And when `new` (in vhost) is close to vq->num. The
> vq->last_used_idx + bufs (in driver) can be bigger
> than vq->vring_packed.num, and:
>
> 1. `off` will wrap;
> 2. wrap counters won't match;
> 3. off < new;
>
> And d1 (i.e. new + vq->num - off - 1) will be a value
> bigger than vq->num. I'm okay with this, although it's
> a bit weird.
So I'm considering something more compact by reusing vring_need_event()
by pretending a larger queue size and adding vq->num back when necessary:
static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
__u16 off_wrap, __u16 new,
__u16 old)
{
bool wrap = vq->used_wrap_counter;
int off = off_wrap & ~(1 << 15);
__u16 d1, d2;
if (new < old) {
new += vq->num;
wrap ^= 1;
}
if (wrap != off_wrap >> 15)
off += vq->num;
return vring_need_event(off, new, old);
}
>
> Best regards,
> Tiwei Bie
>
>> else
>> d1 = new - off - 1;
>>
>> if (new > old)
>> d2 = new - old;
>> else
>> d2 = new + vq->num - old;
>>
>> return d1 < d2;
>> }
>>
>> Thanks
>>
^ permalink raw reply
* Re: Build regressions/improvements in v4.17-rc4
From: Geert Uytterhoeven @ 2018-05-08 7:17 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Israel Rukshin, netdev
In-Reply-To: <1525762955-26767-1-git-send-email-geert@linux-m68k.org>
On Tue, May 8, 2018 at 9:02 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> JFYI, when comparing v4.17-rc4[1] to v4.17-rc3[3], the summaries are:
> - build errors: +1/-4
+ /kisskb/src/include/linux/mlx5/driver.h: error: 'struct irq_desc'
has no member named 'affinity_hint': => 1299:13
xtensa-allmodconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/75bc37fefc4471e718ba8e651aa74673d4e0a9eb/ (244 out of 246 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/6da6c0db5316275015e8cc2959f12a17584aeb64/ (244 out of 246 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH net-next 1/4] bnxt_en: Fix firmware message delay loop regression.
From: Michael Chan @ 2018-05-08 7:18 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1525763921-20698-1-git-send-email-michael.chan@broadcom.com>
A recent change to reduce delay granularity waiting for firmware
reponse has caused a regression. With a tighter delay loop,
the driver may see the beginning part of the response faster.
The original 5 usec delay to wait for the rest of the message
is not long enough and some messages are detected as invalid.
Increase the maximum wait time from 5 usec to 20 usec. Also, fix
the debug message that shows the total delay time for the response
when the message times out. With the new logic, the delay time
is not fixed per iteration of the loop, so we define a macro to
show the total delay time.
Fixes: 9751e8e71487 ("bnxt_en: reduce timeout on initial HWRM calls")
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 12 ++++++++----
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 7 +++++++
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index efe5c72..168342a 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -3530,6 +3530,8 @@ static int bnxt_hwrm_do_send_msg(struct bnxt *bp, void *msg, u32 msg_len,
HWRM_RESP_LEN_SFT;
valid = bp->hwrm_cmd_resp_addr + len - 1;
} else {
+ int j;
+
/* Check if response len is updated */
for (i = 0; i < tmo_count; i++) {
len = (le32_to_cpu(*resp_len) & HWRM_RESP_LEN_MASK) >>
@@ -3547,14 +3549,15 @@ static int bnxt_hwrm_do_send_msg(struct bnxt *bp, void *msg, u32 msg_len,
if (i >= tmo_count) {
netdev_err(bp->dev, "Error (timeout: %d) msg {0x%x 0x%x} len:%d\n",
- timeout, le16_to_cpu(req->req_type),
+ HWRM_TOTAL_TIMEOUT(i),
+ le16_to_cpu(req->req_type),
le16_to_cpu(req->seq_id), len);
return -1;
}
/* Last byte of resp contains valid bit */
valid = bp->hwrm_cmd_resp_addr + len - 1;
- for (i = 0; i < 5; i++) {
+ for (j = 0; j < HWRM_VALID_BIT_DELAY_USEC; j++) {
/* make sure we read from updated DMA memory */
dma_rmb();
if (*valid)
@@ -3562,9 +3565,10 @@ static int bnxt_hwrm_do_send_msg(struct bnxt *bp, void *msg, u32 msg_len,
udelay(1);
}
- if (i >= 5) {
+ if (j >= HWRM_VALID_BIT_DELAY_USEC) {
netdev_err(bp->dev, "Error (timeout: %d) msg {0x%x 0x%x} len:%d v:%d\n",
- timeout, le16_to_cpu(req->req_type),
+ HWRM_TOTAL_TIMEOUT(i),
+ le16_to_cpu(req->req_type),
le16_to_cpu(req->seq_id), len, *valid);
return -1;
}
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index 8df1d8b..a9c210e 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -539,6 +539,13 @@ struct rx_tpa_end_cmp_ext {
#define HWRM_MIN_TIMEOUT 25
#define HWRM_MAX_TIMEOUT 40
+#define HWRM_TOTAL_TIMEOUT(n) (((n) <= HWRM_SHORT_TIMEOUT_COUNTER) ? \
+ ((n) * HWRM_SHORT_MIN_TIMEOUT) : \
+ (HWRM_SHORT_TIMEOUT_COUNTER * HWRM_SHORT_MIN_TIMEOUT + \
+ ((n) - HWRM_SHORT_TIMEOUT_COUNTER) * HWRM_MIN_TIMEOUT))
+
+#define HWRM_VALID_BIT_DELAY_USEC 20
+
#define BNXT_RX_EVENT 1
#define BNXT_AGG_EVENT 2
#define BNXT_TX_EVENT 4
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 0/4] bnxt_en: Fixes for net-next.
From: Michael Chan @ 2018-05-08 7:18 UTC (permalink / raw)
To: davem; +Cc: netdev
This series includes a bug fix for a regression in firmware message polling
introduced recently on net-next. There are 3 additional minor fixes for
unsupported link speed checking, VF MAC address handling, and setting
PHY eeprom length.
Michael Chan (3):
bnxt_en: Fix firmware message delay loop regression.
bnxt_en: Check unsupported speeds in bnxt_update_link() on PF only.
bnxt_en: Always forward VF MAC address to the PF.
Vasundhara Volam (1):
bnxt_en: Read phy eeprom A2h address only when optical diagnostics is
supported.
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 17 ++++++++++++-----
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 10 ++++++++--
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 20 ++++++++------------
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 3 ++-
4 files changed, 30 insertions(+), 20 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net-next 2/4] bnxt_en: Check unsupported speeds in bnxt_update_link() on PF only.
From: Michael Chan @ 2018-05-08 7:18 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1525763921-20698-1-git-send-email-michael.chan@broadcom.com>
Only non-NPAR PFs need to actively check and manage unsupported link
speeds. NPAR functions and VFs do not control the link speed and
should skip the unsupported speed detection logic, to avoid warning
messages from firmware rejecting the unsupported firmware calls.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 168342a..cd3ab78 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -6462,6 +6462,9 @@ static int bnxt_update_link(struct bnxt *bp, bool chng_link_state)
}
mutex_unlock(&bp->hwrm_cmd_lock);
+ if (!BNXT_SINGLE_PF(bp))
+ return 0;
+
diff = link_info->support_auto_speeds ^ link_info->advertising;
if ((link_info->support_auto_speeds | diff) !=
link_info->support_auto_speeds) {
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 3/4] bnxt_en: Read phy eeprom A2h address only when optical diagnostics is supported.
From: Michael Chan @ 2018-05-08 7:18 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1525763921-20698-1-git-send-email-michael.chan@broadcom.com>
From: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
For SFP+ modules, 0xA2 page is available only when Diagnostic Monitoring
Type [Address A0h, Byte 92] is implemented. Extend bnxt_get_module_info(),
to read optical diagnostics support at offset 92(0x5c) and set eeprom_len
length to ETH_MODULE_SFF_8436_LEN (to exclude A2 page), if dianostics is
not supported.
Also in bnxt_get_module_info(), module id is read from offset 0x5e which
is not correct. It was working by accident, as offset was not effective
without setting enables flag in the firmware request. SFP module id is
present at location 0. Fix this by removing the offset and read it
from location 0.
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 3 +--
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 20 ++++++++------------
2 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index a9c210e..9b14eb6 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -1414,8 +1414,7 @@ struct bnxt {
#define I2C_DEV_ADDR_A0 0xa0
#define I2C_DEV_ADDR_A2 0xa2
-#define SFP_EEPROM_SFF_8472_COMP_ADDR 0x5e
-#define SFP_EEPROM_SFF_8472_COMP_SIZE 1
+#define SFF_DIAG_SUPPORT_OFFSET 0x5c
#define SFF_MODULE_ID_SFP 0x3
#define SFF_MODULE_ID_QSFP 0xc
#define SFF_MODULE_ID_QSFP_PLUS 0xd
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
index ad98b78..7270c8b 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
@@ -2184,9 +2184,8 @@ static int bnxt_read_sfp_module_eeprom_info(struct bnxt *bp, u16 i2c_addr,
static int bnxt_get_module_info(struct net_device *dev,
struct ethtool_modinfo *modinfo)
{
+ u8 data[SFF_DIAG_SUPPORT_OFFSET + 1];
struct bnxt *bp = netdev_priv(dev);
- struct hwrm_port_phy_i2c_read_input req = {0};
- struct hwrm_port_phy_i2c_read_output *output = bp->hwrm_cmd_resp_addr;
int rc;
/* No point in going further if phy status indicates
@@ -2201,21 +2200,19 @@ static int bnxt_get_module_info(struct net_device *dev,
if (bp->hwrm_spec_code < 0x10202)
return -EOPNOTSUPP;
- bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_PORT_PHY_I2C_READ, -1, -1);
- req.i2c_slave_addr = I2C_DEV_ADDR_A0;
- req.page_number = 0;
- req.page_offset = cpu_to_le16(SFP_EEPROM_SFF_8472_COMP_ADDR);
- req.data_length = SFP_EEPROM_SFF_8472_COMP_SIZE;
- req.port_id = cpu_to_le16(bp->pf.port_id);
- mutex_lock(&bp->hwrm_cmd_lock);
- rc = _hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT);
+ rc = bnxt_read_sfp_module_eeprom_info(bp, I2C_DEV_ADDR_A0, 0, 0,
+ SFF_DIAG_SUPPORT_OFFSET + 1,
+ data);
if (!rc) {
- u32 module_id = le32_to_cpu(output->data[0]);
+ u8 module_id = data[0];
+ u8 diag_supported = data[SFF_DIAG_SUPPORT_OFFSET];
switch (module_id) {
case SFF_MODULE_ID_SFP:
modinfo->type = ETH_MODULE_SFF_8472;
modinfo->eeprom_len = ETH_MODULE_SFF_8472_LEN;
+ if (!diag_supported)
+ modinfo->eeprom_len = ETH_MODULE_SFF_8436_LEN;
break;
case SFF_MODULE_ID_QSFP:
case SFF_MODULE_ID_QSFP_PLUS:
@@ -2231,7 +2228,6 @@ static int bnxt_get_module_info(struct net_device *dev,
break;
}
}
- mutex_unlock(&bp->hwrm_cmd_lock);
return rc;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 4/4] bnxt_en: Always forward VF MAC address to the PF.
From: Michael Chan @ 2018-05-08 7:18 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1525763921-20698-1-git-send-email-michael.chan@broadcom.com>
The current code already forwards the VF MAC address to the PF, except
in one case. If the VF driver gets a valid MAC address from the firmware
during probe time, it will not forward the MAC address to the PF,
incorrectly assuming that the PF already knows the MAC address. This
causes "ip link show" to show zero VF MAC addresses for this case.
This assumption is not correct. Newer firmware remembers the VF MAC
address last used by the VF and provides it to the VF driver during
probe. So we need to always forward the VF MAC address to the PF.
The forwarded MAC address may now be the PF assigned MAC address and so we
need to make sure we approve it for this case.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index cd3ab78..dfa0839 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -8678,8 +8678,8 @@ static int bnxt_init_mac_addr(struct bnxt *bp)
memcpy(bp->dev->dev_addr, vf->mac_addr, ETH_ALEN);
} else {
eth_hw_addr_random(bp->dev);
- rc = bnxt_approve_mac(bp, bp->dev->dev_addr);
}
+ rc = bnxt_approve_mac(bp, bp->dev->dev_addr);
#endif
}
return rc;
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
index cc21d87..a649108 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
@@ -923,7 +923,8 @@ static int bnxt_vf_configure_mac(struct bnxt *bp, struct bnxt_vf_info *vf)
if (req->enables & cpu_to_le32(FUNC_VF_CFG_REQ_ENABLES_DFLT_MAC_ADDR)) {
if (is_valid_ether_addr(req->dflt_mac_addr) &&
((vf->flags & BNXT_VF_TRUST) ||
- (!is_valid_ether_addr(vf->mac_addr)))) {
+ !is_valid_ether_addr(vf->mac_addr) ||
+ ether_addr_equal(req->dflt_mac_addr, vf->mac_addr))) {
ether_addr_copy(vf->vf_mac_addr, req->dflt_mac_addr);
return bnxt_hwrm_exec_fwd_resp(bp, vf, msg_size);
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] net: aquantia: Fix an error handling path in 'aq_pci_probe()'
From: Igor Russkikh @ 2018-05-08 7:19 UTC (permalink / raw)
To: Christophe JAILLET, davem, pavel.belous, weiyongjun1,
dan.carpenter
Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <20180508063947.11317-1-christophe.jaillet@wanadoo.fr>
Hi Christophe,
On 08.05.2018 09:39, Christophe JAILLET wrote:
> The position of 2 labels should be swapped in order to release resources
> in the correct order and avoid leaks.
>
> kfree(self->aq_hw);
> err_ioremap:
> free_netdev(ndev);
> -err_pci_func:
> - pci_release_regions(pdev);
> err_ndev:
> + pci_release_regions(pdev);
> +err_pci_func:
> pci_disable_device(pdev);
> return err;
> }
>
This was just submitted yesterday and is already accepted in netdev by David:
http://patchwork.ozlabs.org/patch/909746/
Thanks!
BR, Igor
^ permalink raw reply
* INFO: rcu detected stall in sctp_generate_heartbeat_event
From: syzbot @ 2018-05-08 7:35 UTC (permalink / raw)
To: davem, linux-kernel, linux-sctp, marcelo.leitner, netdev, nhorman,
syzkaller-bugs, vyasevich
Hello,
syzbot found the following crash on:
HEAD commit: 90278871d4b0 Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=119a7237800000
kernel config: https://syzkaller.appspot.com/x/.config?x=aea320d3af5ef99d
dashboard link: https://syzkaller.appspot.com/bug?extid=e4a5bbd54260c93014f9
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e4a5bbd54260c93014f9@syzkaller.appspotmail.com
device bridge0 left promiscuous mode
IPVS: set_ctl: invalid protocol: 56 0.0.0.0:20003 fo
IPVS: set_ctl: invalid protocol: 175 224.0.0.2:20003 dh
INFO: rcu_sched self-detected stall on CPU
0-...!: (119824 ticks this GP) idle=4b6/1/4611686018427387908
softirq=23864/23864 fqs=5
(t=125000 jiffies g=13072 c=13071 q=480954)
NMI backtrace for cpu 0
CPU: 0 PID: 4547 Comm: udevd Not tainted 4.17.0-rc3+ #34
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376
print_cpu_stall kernel/rcu/tree.c:1525 [inline]
check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593
__rcu_pending kernel/rcu/tree.c:3356 [inline]
rcu_pending kernel/rcu/tree.c:3401 [inline]
rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763
update_process_times+0x2d/0x70 kernel/time/timer.c:1636
tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164
tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274
__run_hrtimer kernel/time/hrtimer.c:1398 [inline]
__hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1460
hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
RIP: 0010:rep_nop arch/x86/include/asm/processor.h:667 [inline]
RIP: 0010:cpu_relax arch/x86/include/asm/processor.h:672 [inline]
RIP: 0010:virt_spin_lock arch/x86/include/asm/qspinlock.h:69 [inline]
RIP: 0010:native_queued_spin_lock_slowpath+0x204/0xde0
kernel/locking/qspinlock.c:305
RSP: 0018:ffff8801dae07390 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000000 RBX: ffffed003b5c0e8b RCX: 0000000000000004
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff8801a9e9d088
RBP: ffff8801dae07700 R08: ffffed00353d3a12 R09: ffffed00353d3a11
R10: ffffed00353d3a11 R11: ffff8801a9e9d08b R12: ffff8801a9e9d088
R13: ffff8801dae076d8 R14: 0000000000000001 R15: dffffc0000000000
pv_queued_spin_lock_slowpath arch/x86/include/asm/paravirt.h:674 [inline]
queued_spin_lock_slowpath arch/x86/include/asm/qspinlock.h:30 [inline]
queued_spin_lock include/asm-generic/qspinlock.h:90 [inline]
do_raw_spin_lock+0x1a7/0x200 kernel/locking/spinlock_debug.c:113
__raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline]
_raw_spin_lock+0x32/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:310 [inline]
sctp_generate_heartbeat_event+0xa4/0x450 net/sctp/sm_sideeffect.c:386
call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0x79e/0xc50 kernel/time/timer.c:1666
run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
__do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
invoke_softirq kernel/softirq.c:365 [inline]
irq_exit+0x1d1/0x200 kernel/softirq.c:405
exiting_irq arch/x86/include/asm/apic.h:525 [inline]
smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
</IRQ>
RIP: 0010:rcu_is_watching+0x41/0x140 kernel/rcu/tree.c:1071
RSP: 0018:ffff8801ad457848 EFLAGS: 00000296 ORIG_RAX: ffffffffffffff13
RAX: ffffed0035a8af0a RBX: 1ffff10035a8af0a RCX: ffff8801ad4578f0
RDX: 0000000000000000 RSI: ffff8801ad457f58 RDI: ffffffff897bf004
RBP: ffff8801ad4578d8 R08: ffff8801ad457978 R09: ffff8801ad53e040
R10: ffffed0035a8af32 R11: ffff8801ad457997 R12: ffff8801ad457988
R13: 0000000000000000 R14: ffff8801ad4578b0 R15: dffffc0000000000
syz-executor3 (7657) used greatest stack depth: 15968 bytes left
kernel_text_address+0x61/0xf0 kernel/extable.c:140
__kernel_text_address+0xd/0x40 kernel/extable.c:107
unwind_get_return_address+0x61/0xa0 arch/x86/kernel/unwind_frame.c:18
__save_stack_trace+0x7e/0xd0 arch/x86/kernel/stacktrace.c:45
save_stack_trace+0x1a/0x20 arch/x86/kernel/stacktrace.c:60
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
getname_flags+0xd0/0x5a0 fs/namei.c:140
getname+0x19/0x20 fs/namei.c:211
do_sys_open+0x39a/0x740 fs/open.c:1087
__do_sys_open fs/open.c:1111 [inline]
__se_sys_open fs/open.c:1106 [inline]
__x64_sys_open+0x7e/0xc0 fs/open.c:1106
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f7621c19120
RSP: 002b:00007fff6a9646f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7621c19120
RDX: 0000000000000124 RSI: 0000000000080000 RDI: 00007fff6a9647a0
RBP: 0000000000ddd744 R08: 0000000000ddd744 R09: 00007f7621c6ec20
R10: 7269762f73656369 R11: 0000000000000246 R12: 0000000000dc3810
R13: 0000000000dc3900 R14: 0000000000dc3250 R15: 0000000000dc8e10
device bridge_slave_1 left promiscuous mode
bridge0: port 2(bridge_slave_1) entered disabled state
device bridge_slave_0 left promiscuous mode
bridge0: port 1(bridge_slave_0) entered disabled state
device bridge_slave_1 left promiscuous mode
bridge0: port 2(bridge_slave_1) entered disabled state
device bridge_slave_0 left promiscuous mode
bridge0: port 1(bridge_slave_0) entered disabled state
device bridge_slave_1 left promiscuous mode
bridge0: port 2(bridge_slave_1) entered disabled state
device bridge_slave_0 left promiscuous mode
bridge0: port 1(bridge_slave_0) entered disabled state
device bridge_slave_1 left promiscuous mode
bridge0: port 2(bridge_slave_1) entered disabled state
device bridge_slave_0 left promiscuous mode
bridge0: port 1(bridge_slave_0) entered disabled state
IPVS: ftp: loaded support on port[0] = 21
team0 (unregistering): Port device team_slave_1 removed
team0 (unregistering): Port device team_slave_0 removed
bond0 (unregistering): Releasing backup interface bond_slave_1
bond0 (unregistering): Releasing backup interface bond_slave_0
bond0 (unregistering): Released all slaves
team0 (unregistering): Port device team_slave_1 removed
team0 (unregistering): Port device team_slave_0 removed
bond0 (unregistering): Releasing backup interface bond_slave_1
bond0 (unregistering): Releasing backup interface bond_slave_0
bond0 (unregistering): Released all slaves
team0 (unregistering): Port device team_slave_1 removed
team0 (unregistering): Port device team_slave_0 removed
bond0 (unregistering): Releasing backup interface bond_slave_1
bond0 (unregistering): Releasing backup interface bond_slave_0
bond0 (unregistering): Released all slaves
team0 (unregistering): Port device team_slave_1 removed
team0 (unregistering): Port device team_slave_0 removed
bond0 (unregistering): Releasing backup interface bond_slave_1
bond0 (unregistering): Releasing backup interface bond_slave_0
bond0 (unregistering): Released all slaves
bridge0: port 1(bridge_slave_0) entered blocking state
bridge0: port 1(bridge_slave_0) entered disabled state
device bridge_slave_0 entered promiscuous mode
bridge0: port 2(bridge_slave_1) entered blocking state
bridge0: port 2(bridge_slave_1) entered disabled state
device bridge_slave_1 entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): veth0_to_bridge: link is not ready
IPv6: ADDRCONF(NETDEV_UP): veth1_to_bridge: link is not ready
bond0: Enslaving bond_slave_0 as an active interface with an up link
bond0: Enslaving bond_slave_1 as an active interface with an up link
IPv6: ADDRCONF(NETDEV_UP): veth1_to_bond: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_bond: link becomes ready
IPv6: ADDRCONF(NETDEV_UP): team_slave_0: link is not ready
team0: Port device team_slave_0 added
IPv6: ADDRCONF(NETDEV_UP): team_slave_1: link is not ready
team0: Port device team_slave_1 added
IPv6: ADDRCONF(NETDEV_CHANGE): team_slave_0: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): team_slave_1: link becomes ready
IPv6: ADDRCONF(NETDEV_UP): bridge_slave_0: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): bridge_slave_0: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0_to_bridge: link becomes ready
IPv6: ADDRCONF(NETDEV_UP): bridge_slave_1: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): bridge_slave_1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_bridge: link becomes ready
bridge0: port 2(bridge_slave_1) entered blocking state
bridge0: port 2(bridge_slave_1) entered forwarding state
bridge0: port 1(bridge_slave_0) entered blocking state
bridge0: port 1(bridge_slave_0) entered forwarding state
IPv6: ADDRCONF(NETDEV_UP): bridge0: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): bridge0: link becomes ready
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [PATCH net] stmmac: fix reception of 802.1ad Ethernet tagged frames
From: Toshiaki Makita @ 2018-05-08 7:34 UTC (permalink / raw)
To: Elad Nachman; +Cc: davem, netdev
In-Reply-To: <f82648ab-0cfb-0bc2-e0f4-759e32ee445a@gmail.com>
On 2018/05/08 16:11, Elad Nachman wrote:
> Currently running:
> ip link add link eth0 eth0.100 type vlan proto 802.1ad id 100
>
> On eth0=stmmac succeeds, but the end result is that the vlan device gets proto 802.1q instead of proto 802.1ad and drops the received packet. Without the patch packets gets dropped for a seemingly "correct" 802.1ad ip link configuration.
>
> If NETIF_F_HW_VLAN_STAG_RX is a requirement for the driver for supporting 802.1ad protocols then the Linux kernel should return error when user-space requests to create a vlan device with proto 802.1ad for physical devices which lacks NETIF_F_HW_VLAN_STAG_RX, which is not currently the case.
No. You can create 802.1ad devices without HW_VLAN_STAG_RX, but you
should not strip 802.1ad tag in driver without HW_VLAN_STAG_RX.
__netif_receive_skb_core should handle them if the device does not have
HW_VLAN_STAG_RX.
> skb_vlan_untag() does nothing if __vlan_hwaccel_put_tag() was already called before (in the driver). The only possible alternative is to completely remove stmmac_rx_vlan() from the stmmac code and let skb_vlan_untag() handles things in a generic way.
You cannot remove an already added feature in the driver.
Alternatively you can skip stripping vlan if vlan_proto is not 8021Q.
Something like this.
if ((dev->features & NETIF_F_HW_VLAN_CTAG_RX) ==
NETIF_F_HW_VLAN_CTAG_RX &&
!__vlan_get_tag(skb, &vlanid)) {
veth = (struct vlan_ethhdr *)skb->data;
vlan_proto = veth->h_vlan_proto;
if (vlan_proto == htons(ETH_P_8021Q)) {
/* pop the vlan tag */
memmove(skb->data + VLAN_HLEN, veth, ETH_ALEN * 2);
skb_pull(skb, VLAN_HLEN);
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlanid);
}
}
}
--
Toshiaki Makita
^ permalink raw reply
* [PATCH] net: wireless: ath: ath9k: Fix a possible data race in ath_chanctx_set_next
From: Jia-Ju Bai @ 2018-05-08 8:06 UTC (permalink / raw)
To: ath9k-devel, kvalo; +Cc: linux-wireless, netdev, linux-kernel, Jia-Ju Bai
The write operation to "sc->next_chan" is protected by
the lock on line 1287, but the read operation to
this data on line 1262 is not protected by the lock.
Thus, there may exist a data race for "sc->next_chan".
To fix this data race, the read operation to "sc->next_chan"
should be also protected by the lock.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/net/wireless/ath/ath9k/channel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c b/drivers/net/wireless/ath/ath9k/channel.c
index 1b05b5d7a038..ed3cd5523481 100644
--- a/drivers/net/wireless/ath/ath9k/channel.c
+++ b/drivers/net/wireless/ath/ath9k/channel.c
@@ -1257,12 +1257,12 @@ void ath_chanctx_set_next(struct ath_softc *sc, bool force)
"Stopping current chanctx: %d\n",
sc->cur_chan->chandef.center_freq1);
sc->cur_chan->stopped = true;
- spin_unlock_bh(&sc->chan_lock);
if (sc->next_chan == &sc->offchannel.chan) {
getrawmonotonic(&ts);
measure_time = true;
}
+ spin_unlock_bh(&sc->chan_lock);
ath9k_chanctx_stop_queues(sc, sc->cur_chan);
queues_stopped = true;
--
2.17.0
^ permalink raw reply related
* Re: linux-next: manual merge of the bpf-next tree with the s390 tree
From: Daniel Borkmann @ 2018-05-08 8:19 UTC (permalink / raw)
To: Stephen Rothwell, Alexei Starovoitov, Networking,
Martin Schwidefsky, Heiko Carstens
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20180508102638.1e19b7f2@canb.auug.org.au>
On 05/08/2018 02:26 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
> arch/s390/net/bpf_jit.S
>
> between commit:
>
> de5cb6eb514e ("s390: use expoline thunks in the BPF JIT")
>
> from the s390 tree and commit:
>
> e1cf4befa297 ("bpf, s390x: remove ld_abs/ld_ind")
>
> from the bpf-next tree.
>
> I fixed it up (I just removed the file as the latter does) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
Yep, sounds good, thanks!
^ permalink raw reply
* [PATCH net-next] drivers: net: davinci_mdio: prevent sprious timeout
From: Sekhar Nori @ 2018-05-08 8:26 UTC (permalink / raw)
To: Grygorii Strashko; +Cc: David S . Miller, linux-omap, netdev
A well timed kernel preemption in the time_after() loop
in wait_for_idle() can result in a spurious timeout
error to be returned.
Fix it by checking for status of hardware before returning
timeout error.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
The issue has not been personally observed by me, but has
been reported by users. Sending for next-next given the
non-critical nature. There is seems to be no easy way to
reproduce this.
drivers/net/ethernet/ti/davinci_mdio.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 3c33f4504d8e..4fbd04fd38cf 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -231,10 +231,16 @@ static inline int wait_for_idle(struct davinci_mdio_data *data)
while (time_after(timeout, jiffies)) {
if (__raw_readl(®s->control) & CONTROL_IDLE)
- return 0;
+ goto out;
}
- dev_err(data->dev, "timed out waiting for idle\n");
- return -ETIMEDOUT;
+
+ if (!(__raw_readl(®s->control) & CONTROL_IDLE)) {
+ dev_err(data->dev, "timed out waiting for idle\n");
+ return -ETIMEDOUT;
+ }
+
+out:
+ return 0;
}
static int davinci_mdio_read(struct mii_bus *bus, int phy_id, int phy_reg)
--
2.16.2
^ permalink raw reply related
* Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node
From: Kevin Easton @ 2018-05-08 8:27 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jason Wang, kvm, virtualization, netdev, linux-kernel,
syzkaller-bugs
In-Reply-To: <20180507155534-mutt-send-email-mst@kernel.org>
On Mon, May 07, 2018 at 04:03:25PM +0300, Michael S. Tsirkin wrote:
> On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote:
> > The struct vhost_msg within struct vhost_msg_node is copied to userspace,
> > so it should be allocated with kzalloc() to ensure all structure padding
> > is zeroed.
> >
> > Signed-off-by: Kevin Easton <kevin@guarana.org>
> > Reported-by: syzbot+87cfa083e727a224754b@syzkaller.appspotmail.com
> > ---
> > drivers/vhost/vhost.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index f3bd8e9..1b84dcff 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -2339,7 +2339,7 @@ EXPORT_SYMBOL_GPL(vhost_disable_notify);
> > /* Create a new message. */
> > struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type)
> > {
> > - struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
> > + struct vhost_msg_node *node = kzalloc(sizeof *node, GFP_KERNEL);
> > if (!node)
> > return NULL;
> > node->vq = vq;
>
>
> Let's just init the msg though.
>
> OK it seems this is the best we can do for now,
> we need a new feature bit to fix it for 32 bit
> userspace on 64 bit kernels.
>
> Does the following help?
Yes, the reproducer doesn't trigger the error with that patch applied.
- Kevin
^ permalink raw reply
* Re: RTL8723BE performance regression
From: Pkshih @ 2018-05-08 8:37 UTC (permalink / raw)
To: jprvita@gmail.com
Cc: linux-kernel@vger.kernel.org, Larry.Finger@lwfinger.net,
jprvita@endlessm.com, Birming Chiu, drake@endlessm.com,
Chaoming_Li, kvalo@codeaurora.org, 莊彥宣,
derosier@gmail.com, Steven Ting, netdev@vger.kernel.org,
linux@endlessm.com, Shaofu, linux-wireless@vger.kernel.org
In-Reply-To: <CA+A7VXWywjTVeb3DTjVMVTUw-vjAjD+3XTuVNk8S=8D7W=MkPQ@mail.gmail.com>
On Mon, 2018-05-07 at 14:49 -0700, João Paulo Rechi Vita wrote:
> On Tue, May 1, 2018 at 10:58 PM, Pkshih <pkshih@realtek.com> wrote:
> > On Wed, 2018-05-02 at 05:44 +0000, Pkshih wrote:
> >>
> >> > -----Original Message-----
> >> > From: João Paulo Rechi Vita [mailto:jprvita@gmail.com]
> >> > Sent: Wednesday, May 02, 2018 6:41 AM
> >> > To: Larry Finger
> >> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; Chaoming_Li; Kalle Valo;
> >> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi Vita; linux@endless
> m.c
> >> om
> >> > Subject: Re: RTL8723BE performance regression
> >> >
> >> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> >> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >> > >>
> >> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <Larry.Finger@lwfinger.net>
> >> > >> wrote:
> >> > >>
> >> > >> (...)
> >> > >>
> >> > >>> As the antenna selection code changes affected your first bisection, do
> >> > >>> you
> >> > >>> have one of those HP laptops with only one antenna and the incorrect
> >> > >>> coding
> >> > >>> in the FUSE?
> >> > >>
> >> > >>
> >> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> >> > >> was needed to achieve a good performance in the past, before this
> >> > >> regression. I've also opened the laptop chassis and confirmed the
> >> > >> antenna cable is plugged to the connector labeled with "1" on the
> >> > >> card.
> >> > >>
> >> > >>> If so, please make sure that you still have the same signal
> >> > >>> strength for good and bad cases. I have tried to keep the driver and the
> >> > >>> btcoex code in sync, but there may be some combinations of antenna
> >> > >>> configuration and FUSE contents that cause the code to fail.
> >> > >>>
> >> > >>
> >> > >> What is the recommended way to monitor the signal strength?
> >> > >
> >> > >
> >> > > The btcoex code is developed for multiple platforms by a different group
> >> > > than the Linux driver. I think they made a change that caused ant_sel to
> >> > > switch from 1 to 2. At least numerous comments at
> >> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
> >> > >
> >> > > Mhy recommended method is to verify the wifi device name with "iw dev". Then
> >> > > using that device
> >> > >
> >> > > sudo iw dev <dev_name> scan | egrep "SSID|signal"
> >> > >
> >> >
> >> > I have confirmed that the performance regression is indeed tied to
> >> > signal strength: on the good cases signal was between -16 and -8 dBm,
> >> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> >> > also switched to testing bandwidth in controlled LAN environment using
> >> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> >> > machine connected to the 2.4 GHz radio and the machine running the
> >> > iperf3 server connected via ethernet.
> >> >
> >>
> >> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup
> >> 8723be ant_sel definition"). You can use the above commit and do the same
> >> experiments (with ant_sel=0, 1 and 2) in your side, and then share your results.
> >> Since performance is tied to signal strength, you can only share signal strength.
> >>
> >
> > Please pay attention to cold reboot once ant_sel is changed.
> >
>
> I've tested the commit mentioned above and it fixes the problem on top
> of v4.16 (in addition to the latest wireless-drivers-next also been
> fixed as it already contains such commit). On v4.15, we also need the
> following commits before "af8a41cccf8f rtlwifi: cleanup 8723be ant_sel
> definition" to have a good performance again:
>
> 874e837d67d0 rtlwifi: fill FW version and subversion
> a44709bba70f rtlwifi: btcoex: Add power_on_setting routine
> 40d9dd4f1c5d rtlwifi: btcoex: Remove global variables from btcoex
v4.15 isn't longterm version and had been EOL.
>
> Surprisingly, it seems forcing ant_sel=1 is not needed anymore on
> these machines, as the shown by the numbers bellow (ant_sel=0 means
> that actually no parameter was passed to the module). I have powered
> off the machine and done a cold boot for every test. It seems
> something have changed in the antenna auto-selection code since v4.11,
> the latest point where I could confirm we definitely need to force
> ant_sel=1. I've been trying to understand what causes this difference,
> but haven't made progress on that so far, so any suggestions are
> appreciated (we are trying to decide if we can confidently drop the
> downstream DMI quirks for these specific machines).
>
I think your rtl8723be module programed correct efuse content, so it
works properly with ant_sel=0, and quirk isn't required for your
machine.
> w-d-n ant_sel=0: -14.00 dBm, 69.5 Mbps -> good
> w-d-n ant_sel=1: -10.00 dBm, 41.1 Mbps -> good
> w-d-n ant_sel=2: -44.00 dBm, 607 kbps -> bad
>
> v4.16 ant_sel=0: -12.00 dBm, 63.0 Mbps -> good
> v4.16 ant_sel=1: - 8.00 dBm, 69.0 Mbps -> good
> v4.16 ant_sel=2: -50.00 dBm, 224 kbps -> bad
>
> v4.15 ant_sel=0: - 8.00 dBm, 33.0 Mbps -> good
> v4.15 ant_sel=1: -10.00 dBm, 38.1 Mbps -> good
> v4.15 ant_sel=2: -48.00 dBm, 206 kbps -> bad
>
With your results, the efuse content is programmed as one or two antenna
on AUX path.
Regards,
PK
^ permalink raw reply
* pull-request: ieee802154 2018-05-08
From: Stefan Schmidt @ 2018-05-08 8:29 UTC (permalink / raw)
To: davem; +Cc: linux-wpan, alex.aring, netdev
Hello Dave.
An update from ieee802154 for your *net* tree.
Two fixes for the mcr20a driver, which was being added in the 4.17 merge window,
by Gustavo and myself.
The atusb driver got a change to GFP_KERNEL where no GFP_ATOMIC is needed by
Jia-Ju.
The last and most important fix is from Alex to get IPv6 reassembly working
again for the ieee802154 6lowpan adaptation. This got broken in 4.16 so please
queue this one also up for the 4.16 stable tree.
regards
Stefan Schmidt
The following changes since commit aa8f8778493c85fff480cdf8b349b1e1dcb5f243:
ipv6: add RTA_TABLE and RTA_PREFSRC to rtm_ipv6_policy (2018-04-23 12:01:21 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan.git ieee802154-for-davem-2018-05-08
for you to fetch changes up to f18fa5de5ba7f1d6650951502bb96a6e4715a948:
net: ieee802154: 6lowpan: fix frag reassembly (2018-04-23 20:56:24 +0200)
----------------------------------------------------------------
Alexander Aring (1):
net: ieee802154: 6lowpan: fix frag reassembly
Gustavo A. R. Silva (1):
ieee802154: mcr20a: Fix memory leak in mcr20a_probe
Jia-Ju Bai (1):
net: ieee802154: atusb: Replace GFP_ATOMIC with GFP_KERNEL in atusb_probe
Stefan Schmidt (1):
net: ieee802154: mcr20a: do not leak resources on error path
drivers/net/ieee802154/atusb.c | 2 +-
drivers/net/ieee802154/mcr20a.c | 15 ++++++++++-----
net/ieee802154/6lowpan/6lowpan_i.h | 4 ++--
net/ieee802154/6lowpan/reassembly.c | 14 +++++++-------
4 files changed, 20 insertions(+), 15 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next v10 2/4] net: Introduce generic failover module
From: kbuild test robot @ 2018-05-08 9:02 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: kbuild-all, mst, stephen, davem, netdev, virtualization,
virtio-dev, jesse.brandeburg, alexander.h.duyck, kubakici,
sridhar.samudrala, jasowang, loseweigh, jiri, aaron.f.brown
In-Reply-To: <1525731046-10989-3-git-send-email-sridhar.samudrala@intel.com>
Hi Sridhar,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Sridhar-Samudrala/Enable-virtio_net-to-act-as-a-standby-for-a-passthru-device/20180508-123531
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> net/core/net_failover.c:868:16: sparse: Using plain integer as NULL pointer
net/core/net_failover.c:115:12: sparse: context imbalance in 'net_failover_select_queue' - wrong count at exit
vim +868 net/core/net_failover.c
828
829 /**
830 * net_failover_register - Register a failover instance
831 *
832 * @dev: failover or standby netdev
833 * @ops: failover ops
834 *
835 * Paravirtual drivers supporting 3-netdev model call this routine indirectly
836 * via net_failover_create(). It passes failover netdev and ops will be NULL
837 * as the slave events are handled internally.
838 * Paravirtual drivers supporting 2-netdev model call this routine by passing
839 * standby netdev and ops that are called to handle slave register/unregister/
840 * link change events.
841 *
842 * Return: pointer to failover instance
843 */
844 struct net_failover *net_failover_register(struct net_device *dev,
845 struct net_failover_ops *ops)
846 {
847 struct net_failover *failover;
848
849 failover = kzalloc(sizeof(*failover), GFP_KERNEL);
850 if (!failover)
851 return ERR_PTR(-ENOMEM);
852
853 rcu_assign_pointer(failover->ops, ops);
854 dev_hold(dev);
855 dev->priv_flags |= IFF_FAILOVER;
856 rcu_assign_pointer(failover->failover_dev, dev);
857
858 spin_lock(&net_failover_lock);
859 list_add_tail(&failover->list, &net_failover_list);
860 spin_unlock(&net_failover_lock);
861
862 netdev_info(dev, "failover master:%s registered\n", dev->name);
863
864 net_failover_existing_slave_register(dev);
865
866 return failover;
867
> 868 return 0;
869 }
870 EXPORT_SYMBOL_GPL(net_failover_register);
871
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring
From: Tiwei Bie @ 2018-05-08 9:16 UTC (permalink / raw)
To: Jason Wang; +Cc: Michael S. Tsirkin, netdev, linux-kernel, virtualization, wexu
In-Reply-To: <34f2c690-7cb2-f9ea-2ce9-40f4ccb594c9@redhat.com>
On Tue, May 08, 2018 at 03:16:53PM +0800, Jason Wang wrote:
> On 2018年05月08日 14:44, Tiwei Bie wrote:
> > On Tue, May 08, 2018 at 01:40:40PM +0800, Jason Wang wrote:
> > > On 2018年05月08日 11:05, Jason Wang wrote:
> > > > > Because in virtqueue_enable_cb_delayed(), we may set an
> > > > > event_off which is bigger than new and both of them have
> > > > > wrapped. And in this case, although new is smaller than
> > > > > event_off (i.e. the third param -- old), new shouldn't
> > > > > add vq->num, and actually we are expecting a very big
> > > > > idx diff.
> > > > Yes, so to calculate distance correctly between event and new, we just
> > > > need to compare the warp counter and return false if it doesn't match
> > > > without the need to try to add vq.num here.
> > > >
> > > > Thanks
> > > Sorry, looks like the following should work, we need add vq.num if
> > > used_wrap_counter does not match:
> > >
> > > static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
> > > __u16 off_wrap, __u16 new,
> > > __u16 old)
> > > {
> > > bool wrap = off_wrap >> 15;
> > > int off = off_wrap & ~(1 << 15);
> > > __u16 d1, d2;
> > >
> > > if (wrap != vq->used_wrap_counter)
> > > d1 = new + vq->num - off - 1;
> > Just to draw your attention (maybe you have already
> > noticed this).
>
> I miss this, thanks!
>
> >
> > In this case (i.e. wrap != vq->used_wrap_counter),
> > it's also possible that (off < new) is true. Because,
> >
> > when virtqueue_enable_cb_delayed_packed() is used,
> > `off` is calculated in driver in a way like this:
> >
> > off = vq->last_used_idx + bufs;
> > if (off >= vq->vring_packed.num) {
> > off -= vq->vring_packed.num;
> > wrap_counter ^= 1;
> > }
> >
> > And when `new` (in vhost) is close to vq->num. The
> > vq->last_used_idx + bufs (in driver) can be bigger
> > than vq->vring_packed.num, and:
> >
> > 1. `off` will wrap;
> > 2. wrap counters won't match;
> > 3. off < new;
> >
> > And d1 (i.e. new + vq->num - off - 1) will be a value
> > bigger than vq->num. I'm okay with this, although it's
> > a bit weird.
>
>
> So I'm considering something more compact by reusing vring_need_event() by
> pretending a larger queue size and adding vq->num back when necessary:
>
> static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
> __u16 off_wrap, __u16 new,
> __u16 old)
> {
> bool wrap = vq->used_wrap_counter;
If the wrap counter is obtained from the vq,
I think `new` should also be obtained from
the vq. Or the wrap counter should be carried
in `new`.
> int off = off_wrap & ~(1 << 15);
> __u16 d1, d2;
>
> if (new < old) {
> new += vq->num;
> wrap ^= 1;
> }
>
> if (wrap != off_wrap >> 15)
> off += vq->num;
When `new` and `old` wraps, and `off` doesn't wrap,
wrap != (off_wrap >> 15) will be true. In this case,
`off` is bigger than `new`, and what we should do
is `off -= vq->num` instead of `off += vq->num`.
Best regards,
Tiwei Bie
>
> return vring_need_event(off, new, old);
> }
>
>
> >
> > Best regards,
> > Tiwei Bie
> >
> > > else
> > > d1 = new - off - 1;
> > >
> > > if (new > old)
> > > d2 = new - old;
> > > else
> > > d2 = new + vq->num - old;
> > >
> > > return d1 < d2;
> > > }
> > >
> > > Thanks
> > >
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH 1/7] can: dev: increase bus-off message severity
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Jakob Unterwurzacher, linux-kernel,
Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
bus-off is usually caused by hardware malfunction or configuration error
(baud rate mismatch) and causes a complete loss of communication.
Increase the "bus-off" message's severity from netdev_dbg() to
netdev_info() to make it visible to the user.
A can interface going into bus-off is similar in severity to ethernet's
"Link is Down" message, which is also printed at info level.
It is debatable whether the the "restarted" message should also be
changed to netdev_info() to make the interface state changes
comprehensible from the kernel log. I have chosen to keep the
"restarted" message at dbg for now as the "bus-off" message should be
enough for the user to notice and investigate the problem.
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
Cc: linux-can@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index b1779566c5bb..3c71f1cb205f 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -605,7 +605,7 @@ void can_bus_off(struct net_device *dev)
{
struct can_priv *priv = netdev_priv(dev);
- netdev_dbg(dev, "bus-off\n");
+ netdev_info(dev, "bus-off\n");
netif_carrier_off(dev);
--
2.17.0
^ permalink raw reply related
* [PATCH 3/7] arm: dts: imx[35]*: declare flexcan devices to be compatible to imx25's flexcan
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Uwe Kleine-König, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Commit d50f4630c2e1 ("arm: dts: Remove p1010-flexcan compatible from imx
series dts") removed the fallback compatible "fsl,p1010-flexcan" from
the imx device trees. As the flexcan cores on i.MX25, i.MX35 and i.MX53
are identical, introduce the first as fallback for the two latter ones.
Fixes: d50f4630c2e1 ("arm: dts: Remove p1010-flexcan compatible from imx series dts")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: linux-stable <stable@vger.kernel.org> # >= v4.16
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
arch/arm/boot/dts/imx35.dtsi | 4 ++--
arch/arm/boot/dts/imx53.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index bf343195697e..54111ed218b1 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -303,7 +303,7 @@
};
can1: can@53fe4000 {
- compatible = "fsl,imx35-flexcan";
+ compatible = "fsl,imx35-flexcan", "fsl,imx25-flexcan";
reg = <0x53fe4000 0x1000>;
clocks = <&clks 33>, <&clks 33>;
clock-names = "ipg", "per";
@@ -312,7 +312,7 @@
};
can2: can@53fe8000 {
- compatible = "fsl,imx35-flexcan";
+ compatible = "fsl,imx35-flexcan", "fsl,imx25-flexcan";
reg = <0x53fe8000 0x1000>;
clocks = <&clks 34>, <&clks 34>;
clock-names = "ipg", "per";
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 7d647d043f52..3d65c0192f69 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -551,7 +551,7 @@
};
can1: can@53fc8000 {
- compatible = "fsl,imx53-flexcan";
+ compatible = "fsl,imx53-flexcan", "fsl,imx25-flexcan";
reg = <0x53fc8000 0x4000>;
interrupts = <82>;
clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>,
@@ -561,7 +561,7 @@
};
can2: can@53fcc000 {
- compatible = "fsl,imx53-flexcan";
+ compatible = "fsl,imx53-flexcan", "fsl,imx25-flexcan";
reg = <0x53fcc000 0x4000>;
interrupts = <83>;
clocks = <&clks IMX5_CLK_CAN2_IPG_GATE>,
--
2.17.0
^ permalink raw reply related
* [PATCH 4/7] can: kvaser_usb: Increase correct stats counter in kvaser_usb_rx_can_msg()
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Jimmy Assarsson, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Jimmy Assarsson <extja@kvaser.com>
Increase rx_dropped, if alloc_can_skb() fails, not tx_dropped.
Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/kvaser_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 63587b8e6825..daed57d3d209 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1179,7 +1179,7 @@ static void kvaser_usb_rx_can_msg(const struct kvaser_usb *dev,
skb = alloc_can_skb(priv->netdev, &cf);
if (!skb) {
- stats->tx_dropped++;
+ stats->rx_dropped++;
return;
}
--
2.17.0
^ 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