* Re: [PATCH bpf] bpf: use per htab salt for bucket hash
From: Song Liu @ 2018-08-23 5:06 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Alexei Starovoitov, Networking
In-Reply-To: <3d91bc248da2fb1d2a88bcaa75d1b2d2da936986.1534974407.git.daniel@iogearbox.net>
On Wed, Aug 22, 2018 at 2:49 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> All BPF hash and LRU maps currently have a known and global seed
> we feed into jhash() which is 0. This is suboptimal, thus fix it
> by generating a random seed upon hashtab setup time which we can
> later on feed into jhash() on lookup, update and deletions.
>
> Fixes: 0f8e4bd8a1fc8 ("bpf: add hashtable type of eBPF maps")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> kernel/bpf/hashtab.c | 23 +++++++++++++----------
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index 04b8eda..03cc59e 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -15,6 +15,7 @@
> #include <linux/jhash.h>
> #include <linux/filter.h>
> #include <linux/rculist_nulls.h>
> +#include <linux/random.h>
> #include <uapi/linux/btf.h>
> #include "percpu_freelist.h"
> #include "bpf_lru_list.h"
> @@ -41,6 +42,7 @@ struct bpf_htab {
> atomic_t count; /* number of elements in this hashtable */
> u32 n_buckets; /* number of hash buckets */
> u32 elem_size; /* size of each element in bytes */
> + u32 hashrnd;
> };
>
> /* each htab element is struct htab_elem + key + value */
> @@ -371,6 +373,7 @@ static struct bpf_map *htab_map_alloc(union bpf_attr *attr)
> if (!htab->buckets)
> goto free_htab;
>
> + htab->hashrnd = get_random_int();
> for (i = 0; i < htab->n_buckets; i++) {
> INIT_HLIST_NULLS_HEAD(&htab->buckets[i].head, i);
> raw_spin_lock_init(&htab->buckets[i].lock);
> @@ -402,9 +405,9 @@ static struct bpf_map *htab_map_alloc(union bpf_attr *attr)
> return ERR_PTR(err);
> }
>
> -static inline u32 htab_map_hash(const void *key, u32 key_len)
> +static inline u32 htab_map_hash(const void *key, u32 key_len, u32 hashrnd)
> {
> - return jhash(key, key_len, 0);
> + return jhash(key, key_len, hashrnd);
> }
>
> static inline struct bucket *__select_bucket(struct bpf_htab *htab, u32 hash)
> @@ -470,7 +473,7 @@ static void *__htab_map_lookup_elem(struct bpf_map *map, void *key)
>
> key_size = map->key_size;
>
> - hash = htab_map_hash(key, key_size);
> + hash = htab_map_hash(key, key_size, htab->hashrnd);
>
> head = select_bucket(htab, hash);
>
> @@ -597,7 +600,7 @@ static int htab_map_get_next_key(struct bpf_map *map, void *key, void *next_key)
> if (!key)
> goto find_first_elem;
>
> - hash = htab_map_hash(key, key_size);
> + hash = htab_map_hash(key, key_size, htab->hashrnd);
>
> head = select_bucket(htab, hash);
>
> @@ -824,7 +827,7 @@ static int htab_map_update_elem(struct bpf_map *map, void *key, void *value,
>
> key_size = map->key_size;
>
> - hash = htab_map_hash(key, key_size);
> + hash = htab_map_hash(key, key_size, htab->hashrnd);
>
> b = __select_bucket(htab, hash);
> head = &b->head;
> @@ -880,7 +883,7 @@ static int htab_lru_map_update_elem(struct bpf_map *map, void *key, void *value,
>
> key_size = map->key_size;
>
> - hash = htab_map_hash(key, key_size);
> + hash = htab_map_hash(key, key_size, htab->hashrnd);
>
> b = __select_bucket(htab, hash);
> head = &b->head;
> @@ -945,7 +948,7 @@ static int __htab_percpu_map_update_elem(struct bpf_map *map, void *key,
>
> key_size = map->key_size;
>
> - hash = htab_map_hash(key, key_size);
> + hash = htab_map_hash(key, key_size, htab->hashrnd);
>
> b = __select_bucket(htab, hash);
> head = &b->head;
> @@ -998,7 +1001,7 @@ static int __htab_lru_percpu_map_update_elem(struct bpf_map *map, void *key,
>
> key_size = map->key_size;
>
> - hash = htab_map_hash(key, key_size);
> + hash = htab_map_hash(key, key_size, htab->hashrnd);
>
> b = __select_bucket(htab, hash);
> head = &b->head;
> @@ -1071,7 +1074,7 @@ static int htab_map_delete_elem(struct bpf_map *map, void *key)
>
> key_size = map->key_size;
>
> - hash = htab_map_hash(key, key_size);
> + hash = htab_map_hash(key, key_size, htab->hashrnd);
> b = __select_bucket(htab, hash);
> head = &b->head;
>
> @@ -1103,7 +1106,7 @@ static int htab_lru_map_delete_elem(struct bpf_map *map, void *key)
>
> key_size = map->key_size;
>
> - hash = htab_map_hash(key, key_size);
> + hash = htab_map_hash(key, key_size, htab->hashrnd);
> b = __select_bucket(htab, hash);
> head = &b->head;
>
> --
> 2.9.5
>
^ permalink raw reply
* Re: [Patch net 0/2] net: hns3: bug fix & optimization for HNS3 driver
From: David Miller @ 2018-08-23 5:13 UTC (permalink / raw)
To: tanhuazhong; +Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321
In-Reply-To: <1534995436-25259-1-git-send-email-tanhuazhong@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
Date: Thu, 23 Aug 2018 11:37:14 +0800
> This patchset presents a bug fix found out when CONFIG_ARM64_64K_PAGES
> enable and an optimization for HNS3 driver.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH 1/2] net: netsec: enable tx-irq during open callback
From: Jassi Brar @ 2018-08-23 5:15 UTC (permalink / raw)
To: <netdev@vger.kernel.org>
Cc: David S . Miller, Masahisa Kojima, Ard Biesheuvel, Jassi Brar
In-Reply-To: <1523863336-12653-1-git-send-email-jassisinghbrar@gmail.com>
Hi Dave,
This patch (1/2) seems to have fallen through the cracks. The other
one (2/2), you already picked.
Thanks
On Mon, Apr 16, 2018 at 1:08 PM <jassisinghbrar@gmail.com> wrote:
>
> From: Jassi Brar <jaswinder.singh@linaro.org>
>
> Enable TX-irq as well during ndo_open() as we can not count upon
> RX to arrive early enough to trigger the napi. This patch is critical
> for installation over network.
>
> Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver")
> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> ---
> drivers/net/ethernet/socionext/netsec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c
> index f4c0b02..f6fe70e 100644
> --- a/drivers/net/ethernet/socionext/netsec.c
> +++ b/drivers/net/ethernet/socionext/netsec.c
> @@ -1313,8 +1313,8 @@ static int netsec_netdev_open(struct net_device *ndev)
> napi_enable(&priv->napi);
> netif_start_queue(ndev);
>
> - /* Enable RX intr. */
> - netsec_write(priv, NETSEC_REG_INTEN_SET, NETSEC_IRQ_RX);
> + /* Enable TX+RX intr. */
> + netsec_write(priv, NETSEC_REG_INTEN_SET, NETSEC_IRQ_RX | NETSEC_IRQ_TX);
>
> return 0;
> err3:
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] netlink: add nl_set_extack_cookie_u64()
From: Johannes Berg @ 2018-08-23 8:48 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Johannes Berg
From: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Add a helper function nl_set_extack_cookie_u64() to use a u64 as
the netlink extended ACK cookie, to avoid having to open-code it
in any users of the cookie.
A u64 should be sufficient for most subsystems though we allow
for up to 20 bytes right now. This also matches the cookies in
nl80211 where I intend to use this.
Signed-off-by: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
include/linux/netlink.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
index 71f121b66ca8..dc3c21dc4ba2 100644
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -110,6 +110,15 @@ struct netlink_ext_ack {
} \
} while (0)
+static inline void nl_set_extack_cookie_u64(struct netlink_ext_ack *extack,
+ u64 cookie)
+{
+ u64 __cookie = cookie;
+
+ memcpy(extack->cookie, &__cookie, sizeof(__cookie));
+ extack->cookie_len = sizeof(__cookie);
+}
+
extern void netlink_kernel_release(struct sock *sk);
extern int __netlink_change_ngroups(struct sock *sk, unsigned int groups);
extern int netlink_change_ngroups(struct sock *sk, unsigned int groups);
--
2.14.4
^ permalink raw reply related
* [PATCH net] tipc: fix the big/little endian issue in tipc_dest
From: Haiqing Bai @ 2018-08-23 8:49 UTC (permalink / raw)
To: netdev, jon.maloy, ying.xue, davem; +Cc: zhenbo.gao, haiqing.bai, linux-kernel
In function tipc_dest_push, the 32bit variables 'node' and 'port'
are stored separately in uppper and lower part of 64bit 'value'.
Then this value is assigned to dst->value which is a union like:
union
{
struct {
u32 port;
u32 node;
};
u64 value;
}
This works on little-endian machines like x86 but fails on big-endian
machines.
The fix remove the 'value' stack parameter and even the 'value'
member of the union in tipc_dest, assign the 'node' and 'port' member
directly with the input parameter to avoid the endian issue.
Fixes: d06b2fa34f18 ("tipc: improve destination linked list")
Signed-off-by: Zhenbo Gao <zhenbo.gao@windriver.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Haiqing Bai <Haiqing.Bai@windriver.com>
---
net/tipc/name_table.c | 10 ++++------
net/tipc/name_table.h | 9 ++-------
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index 88f027b..66d5b2c 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -980,20 +980,17 @@ int tipc_nl_name_table_dump(struct sk_buff *skb, struct netlink_callback *cb)
struct tipc_dest *tipc_dest_find(struct list_head *l, u32 node, u32 port)
{
- u64 value = (u64)node << 32 | port;
struct tipc_dest *dst;
list_for_each_entry(dst, l, list) {
- if (dst->value != value)
- continue;
- return dst;
+ if (dst->node == node && dst->port == port)
+ return dst;
}
return NULL;
}
bool tipc_dest_push(struct list_head *l, u32 node, u32 port)
{
- u64 value = (u64)node << 32 | port;
struct tipc_dest *dst;
if (tipc_dest_find(l, node, port))
@@ -1002,7 +999,8 @@ bool tipc_dest_push(struct list_head *l, u32 node, u32 port)
dst = kmalloc(sizeof(*dst), GFP_ATOMIC);
if (unlikely(!dst))
return false;
- dst->value = value;
+ dst->node = node;
+ dst->port = port;
list_add(&dst->list, l);
return true;
}
diff --git a/net/tipc/name_table.h b/net/tipc/name_table.h
index 0febba4..892bd75 100644
--- a/net/tipc/name_table.h
+++ b/net/tipc/name_table.h
@@ -133,13 +133,8 @@ struct publication *tipc_nametbl_remove_publ(struct net *net, u32 type,
struct tipc_dest {
struct list_head list;
- union {
- struct {
- u32 port;
- u32 node;
- };
- u64 value;
- };
+ u32 port;
+ u32 node;
};
struct tipc_dest *tipc_dest_find(struct list_head *l, u32 node, u32 port);
--
1.9.1
^ permalink raw reply related
* pull request: bluetooth 2018-08-23
From: Johan Hedberg @ 2018-08-23 5:34 UTC (permalink / raw)
To: davem; +Cc: linux-bluetooth, netdev
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
Hi Dave,
Here are two important Bluetooth fixes for the MediaTek and RealTek HCI
drivers.
Please let me know if there are any issues pulling, thanks.
Johan
---
The following changes since commit ab08dcd724543896303eae7de6288242bbaff458:
rhashtable: remove duplicated include from rhashtable.c (2018-08-20 19:18:50 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git for-upstream
for you to fetch changes up to addb3ffbca66954fb1d1791d2db2153c403f81af:
Bluetooth: mediatek: Fix memory leak (2018-08-21 16:56:20 +0200)
----------------------------------------------------------------
Gustavo A. R. Silva (1):
Bluetooth: mediatek: Fix memory leak
Hans de Goede (1):
Bluetooth: Make BT_HCIUART_RTL configuration option depend on ACPI
drivers/bluetooth/Kconfig | 1 +
drivers/bluetooth/btmtkuart.c | 8 +++++---
2 files changed, 6 insertions(+), 3 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: pull request: bluetooth 2018-08-23
From: David Miller @ 2018-08-23 5:43 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, netdev
In-Reply-To: <20180823053440.GA12312@x1c.home>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Thu, 23 Aug 2018 08:34:40 +0300
> Here are two important Bluetooth fixes for the MediaTek and RealTek HCI
> drivers.
>
> Please let me know if there are any issues pulling, thanks.
Pulled, thank you.
^ permalink raw reply
* Failed to call bpf_l3_csum_replace() twice for IPIP tunnel
From: IMBRIUS AGER @ 2018-08-23 6:39 UTC (permalink / raw)
To: netdev
hello, I am trying to modify the src addr (both inner and outer) of IPIP tunnel.
this is the testing code:
=======================================
void *data = (void *)(long)skb->data;
void *data_end = (void *)(long)skb->data_end;
struct ethhdr *eth = data;
struct iphdr *ip_outer = (void *)(eth + 1);
if (ip_outer->ihl != 5 || ip_outer + 1 > data_end)
return;
struct iphdr *ip_inner = (void *)(ip4_outer + 1);
if (ip_inner->ihl != 5 || ip_inner + 1 > data_end)
return;
src = 0x11111111;
/* First I modify the inner ip */
bpf_l3_csum_replace(skb, IP4_CSUM_OFF + sizeof(struct iphdr),
ip_inner->saddr, src, sizeof(src));
bpf_skb_store_bytes(skb, IP4_SRC_OFF + sizeof(struct iphdr), &src,
sizeof(src), 0);
/* Second I modify the outer ip */
bpf_l3_csum_replace(skb, IP4_CSUM_OFF, ip_outer->saddr, src, sizeof(src));
bpf_skb_store_bytes(skb, IP4_SRC_OFF, &src, sizeof(src), 0);
========================================
I found that I could only modify one of the src addr (inner or outer).
If both, the kernel always rejected the code at the first
bpf_l3_csum_replace():
========================================
Prog section '__xxxxx' rejected: Permission denied (13)!
- Type: 3
- Instructions: 171 (0 over limit)
- License: GPL
.....
96: (85) call bpf_l3_csum_replace#10
97: (61) r4 = *(u32 *)(r7 +0)
R0=inv(id=0) R6=ctx(id=0,off=0,imm=0)
R7=map_value(id=0,off=0,ks=4,vs=4,imm=0) R8=inv(id=0) R9=inv(id=0)
R10=fp0
98: (61) r3 = *(u32 *)(r9 +26)
R9 invalid mem access 'inv'
Error fetching program/map!
Unable to load program
========================================
I tried to validate the pointer again before the second modification.
But nothing good has happened.
if (ip_outer->ihl != 5 || ip_outer + 1 > data_end)
return;
/* Second I modify the outer ip */
bpf_l3_csum_replace(skb, IP4_CSUM_OFF, ip_outer->saddr, src, sizeof(src));
bpf_skb_store_bytes(skb, IP4_SRC_OFF, &src, sizeof(src), 0);
Any idea?
Thanks very much
^ permalink raw reply
* Re: [PATCH iproute2 1/3] testsuite: remove all temp files and implement make clean
From: Stefan Bader @ 2018-08-23 7:07 UTC (permalink / raw)
To: Luca Boccassi, netdev; +Cc: stephen
In-Reply-To: <20180822180903.26443-1-bluca@debian.org>
[-- Attachment #1.1: Type: text/plain, Size: 1987 bytes --]
On 22.08.2018 20:09, Luca Boccassi wrote:
> Some generated test files were not removed, including one executable in
> the testsuite/tools directory.
> Ensure make clean from the top level directory works for the testsuite
> subdirs too, and that all the files are removed.
>
> Signed-off-by: Luca Boccassi <bluca@debian.org>
> ---
Patch 1+2 look good to me and I would ack if that would count in any way.
For patch 3 I only wonder whether that might re-use $PREFIX (which is
defined as "sudo -E unshare -n"). Ok, the unshare part might be slight
overkill, but maybe a little better in style. Not sure though, and it
is high level whining...
-Stefan
> Makefile | 2 +-
> testsuite/Makefile | 3 +++
> testsuite/tools/Makefile | 3 +++
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 651d2a50..ea2f797c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -96,7 +96,7 @@ snapshot:
> > include/SNAPSHOT.h
>
> clean:
> - @for i in $(SUBDIRS); \
> + @for i in $(SUBDIRS) testsuite; \
> do $(MAKE) $(MFLAGS) -C $$i clean; done
>
> clobber:
> diff --git a/testsuite/Makefile b/testsuite/Makefile
> index 8fcbc557..2acd0427 100644
> --- a/testsuite/Makefile
> +++ b/testsuite/Makefile
> @@ -43,6 +43,9 @@ alltests: $(TESTS)
> clean:
> @echo "Removing $(RESULTS_DIR) dir ..."
> @rm -rf $(RESULTS_DIR)
> + @rm -f iproute2/iproute2-this
> + @rm -f tests/ip/link/dev_wo_vf_rate.nl
> + $(MAKE) -C tools clean
>
> distclean: clean
> echo "Entering iproute2" && cd iproute2 && $(MAKE) distclean && cd ..;
> diff --git a/testsuite/tools/Makefile b/testsuite/tools/Makefile
> index f2cdc980..f0ce4ee2 100644
> --- a/testsuite/tools/Makefile
> +++ b/testsuite/tools/Makefile
> @@ -1,3 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> generate_nlmsg: generate_nlmsg.c ../../lib/libnetlink.c
> $(CC) -o $@ $^
> +
> +clean:
> + rm -f generate_nlmsg
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: Failed to call bpf_l3_csum_replace() twice for IPIP tunnel
From: Daniel Borkmann @ 2018-08-23 7:17 UTC (permalink / raw)
To: IMBRIUS AGER, netdev
In-Reply-To: <CAHM1nT13_AYoRydkGnKF8hbshUw2VMz8kgBK+_7-pJxuRDAHww@mail.gmail.com>
On 08/23/2018 08:39 AM, IMBRIUS AGER wrote:
> hello, I am trying to modify the src addr (both inner and outer) of IPIP tunnel.
>
> this is the testing code:
>
> =======================================
>
> void *data = (void *)(long)skb->data;
> void *data_end = (void *)(long)skb->data_end;
>
> struct ethhdr *eth = data;
> struct iphdr *ip_outer = (void *)(eth + 1);
>
> if (ip_outer->ihl != 5 || ip_outer + 1 > data_end)
> return;
>
> struct iphdr *ip_inner = (void *)(ip4_outer + 1);
>
> if (ip_inner->ihl != 5 || ip_inner + 1 > data_end)
> return;
>
> src = 0x11111111;
>
> /* First I modify the inner ip */
> bpf_l3_csum_replace(skb, IP4_CSUM_OFF + sizeof(struct iphdr),
> ip_inner->saddr, src, sizeof(src));
> bpf_skb_store_bytes(skb, IP4_SRC_OFF + sizeof(struct iphdr), &src,
> sizeof(src), 0);
>
> /* Second I modify the outer ip */
> bpf_l3_csum_replace(skb, IP4_CSUM_OFF, ip_outer->saddr, src, sizeof(src));
> bpf_skb_store_bytes(skb, IP4_SRC_OFF, &src, sizeof(src), 0);
You need to reload skb->data pointer as otherwise the first l3_csum_replace
could have uncloned the skb and then ip_outer->saddr would point to invalid
mem. Other, better option is to use the bpf_csum_diff() helper and calc the
diff which then only needs to be fed into bpf_l3_csum_replace() once.
> ========================================
>
> I found that I could only modify one of the src addr (inner or outer).
> If both, the kernel always rejected the code at the first
> bpf_l3_csum_replace():
>
> ========================================
>
> Prog section '__xxxxx' rejected: Permission denied (13)!
> - Type: 3
> - Instructions: 171 (0 over limit)
> - License: GPL
>
> .....
>
> 96: (85) call bpf_l3_csum_replace#10
> 97: (61) r4 = *(u32 *)(r7 +0)
> R0=inv(id=0) R6=ctx(id=0,off=0,imm=0)
> R7=map_value(id=0,off=0,ks=4,vs=4,imm=0) R8=inv(id=0) R9=inv(id=0)
> R10=fp0
> 98: (61) r3 = *(u32 *)(r9 +26)
> R9 invalid mem access 'inv'
>
> Error fetching program/map!
> Unable to load program
>
> ========================================
>
> I tried to validate the pointer again before the second modification.
> But nothing good has happened.
>
> if (ip_outer->ihl != 5 || ip_outer + 1 > data_end)
> return;
> /* Second I modify the outer ip */
> bpf_l3_csum_replace(skb, IP4_CSUM_OFF, ip_outer->saddr, src, sizeof(src));
> bpf_skb_store_bytes(skb, IP4_SRC_OFF, &src, sizeof(src), 0);
>
>
> Any idea?
> Thanks very much
>
^ permalink raw reply
* [PATCH v2] net: macb: do not disable MDIO bus at open/close time
From: Anssi Hannula @ 2018-08-23 7:45 UTC (permalink / raw)
To: netdev, Nicolas Ferre, Claudiu Beznea; +Cc: David S. Miller, Andrew Lunn
In-Reply-To: <6b9e6b74-374b-8ad1-cae6-7d00548a88a5@microchip.com>
macb_reset_hw() is called from macb_close() and indirectly from
macb_open(). macb_reset_hw() zeroes the NCR register, including the MPE
(Management Port Enable) bit.
This will prevent accessing any other PHYs for other Ethernet MACs on
the MDIO bus, which remains registered at macb_reset_hw() time, until
macb_init_hw() is called from macb_open() which sets the MPE bit again.
I.e. currently the MDIO bus has a short disruption at open time and is
disabled at close time until the interface is opened again.
Fix that by only touching the RE and TE bits when enabling and disabling
RX/TX.
v2: Make macb_init_hw() NCR write a single statement.
Fixes: 6c36a7074436 ("macb: Use generic PHY layer")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
---
drivers/net/ethernet/cadence/macb_main.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index dc09f9a8a49b..225a7c8bad2d 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2028,14 +2028,17 @@ static void macb_reset_hw(struct macb *bp)
{
struct macb_queue *queue;
unsigned int q;
+ u32 ctrl = macb_readl(bp, NCR);
/* Disable RX and TX (XXX: Should we halt the transmission
* more gracefully?)
*/
- macb_writel(bp, NCR, 0);
+ ctrl &= ~(MACB_BIT(RE) | MACB_BIT(TE));
/* Clear the stats registers (XXX: Update stats first?) */
- macb_writel(bp, NCR, MACB_BIT(CLRSTAT));
+ ctrl |= MACB_BIT(CLRSTAT);
+
+ macb_writel(bp, NCR, ctrl);
/* Clear all status flags */
macb_writel(bp, TSR, -1);
@@ -2223,7 +2226,7 @@ static void macb_init_hw(struct macb *bp)
}
/* Enable TX and RX */
- macb_writel(bp, NCR, MACB_BIT(RE) | MACB_BIT(TE) | MACB_BIT(MPE));
+ macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(RE) | MACB_BIT(TE));
}
/* The hash address register is 64 bits long and takes up two
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] ath9k: turn on btcoex_enable as default
From: Kalle Valo @ 2018-08-23 11:18 UTC (permalink / raw)
To: Kai-Heng Feng
Cc: Felix Fietkau, ath9k-devel, linux-wireless, netdev, linux-kernel
In-Reply-To: <9AF82E83-2EBE-4076-BAFA-EEA44B1DB423@canonical.com>
Kai-Heng Feng <kai.heng.feng@canonical.com> writes:
> at 12:15, Kai Heng Feng <kai.heng.feng@canonical.com> wrote:
>
>>
>>
>>> On 10 Feb 2018, at 10:05 PM, Felix Fietkau <nbd@nbd.name> wrote:
>>>
>>> On 2018-02-10 14:56, Kai Heng Feng wrote:
>>>>> On 9 Feb 2018, at 3:16 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
>>>>> Sure, but we have to make sure that we don't create regressions on
>>>>> existing systems. For example, did you test this with any system which
>>>>> don't support btcoex? (just asking, haven't tested this myself)
>>>>
>>>> No not really, but I will definitely test it.
>>>> The only module I have that uses ath9k is Dell’s DW1707.
>>>> How do I check if it support btcoex or not?
>>> I just reviewed the code again, and I am sure that we cannot merge this
>>> patch. Enabling the btcoex parameter makes the driver enable a whole
>>> bunch of code starting timers, listening to some GPIOs, etc.
>>>
>>> On non-btcoex systems, some of those GPIOs might be floating or even
>>> connected to different things, which could cause a lot of undefined
>>> behavior.
>>>
>>> This is simply too big a risk, so there absolutely needs to be a
>>> whitelist for systems that need this, otherwise it has to remain
>>> disabled by default.
>>
>> So what information can we use to whitelist btcoex chips?
>> Can we get btcoex support status at ath9k probing?
>
> Sorry for bringing this up again.
>
> Is DMI based match an acceptable approach for ath9k?
I don't know what Felix thinkgs, but to me using DMI sounds like a good
idea to try, assuming the matches are unique enough and there's no risk
of enabling bt coex on wrong platforms. Should the PCI bus number etc
checked as well in case the user adds more ath9k devices to the
platform?
But of course I need to see the patch to comment more.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH iproute2 1/3] testsuite: remove all temp files and implement make clean
From: Luca Boccassi @ 2018-08-23 8:34 UTC (permalink / raw)
To: Stefan Bader, netdev; +Cc: stephen
In-Reply-To: <ba5dd436-4495-55a6-40e5-e28ef83edbb5@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Thu, 2018-08-23 at 09:07 +0200, Stefan Bader wrote:
> On 22.08.2018 20:09, Luca Boccassi wrote:
> > Some generated test files were not removed, including one
> > executable in
> > the testsuite/tools directory.
> > Ensure make clean from the top level directory works for the
> > testsuite
> > subdirs too, and that all the files are removed.
> >
> > Signed-off-by: Luca Boccassi <bluca@debian.org>
> > ---
>
> Patch 1+2 look good to me and I would ack if that would count in any
> way.
> For patch 3 I only wonder whether that might re-use $PREFIX (which is
> defined as "sudo -E unshare -n"). Ok, the unshare part might be
> slight
> overkill, but maybe a little better in style. Not sure though, and it
> is high level whining...
>
> -Stefan
Hi,
Yeah I thought about that, but as you noticed it would run it through
unshare so I changed it in the end. I don't mind either way - Stephen,
let me know which one you prefer.
--
Kind regards,
Luca Boccassi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 3/3] dt-bindings: can: rcar_can: Add r8a774a1 support
From: Fabrizio Castro @ 2018-08-23 13:07 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, Rob Herring, Mark Rutland
Cc: Fabrizio Castro, Sergei Shtylyov, David S. Miller, linux-can,
netdev, devicetree, Simon Horman, Geert Uytterhoeven,
Chris Paterson, Biju Das, linux-renesas-soc, linux-kernel
In-Reply-To: <1535029653-7418-1-git-send-email-fabrizio.castro@bp.renesas.com>
Document RZ/G2M (r8a774a1) SoC specific bindings and RZ/G2
generic bindings.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
This patch applies on next-20180823
Documentation/devicetree/bindings/net/can/rcar_can.txt | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 94a7f33..ae8fccc 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -4,6 +4,7 @@ Renesas R-Car CAN controller Device Tree Bindings
Required properties:
- compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC.
"renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC.
+ "renesas,can-r8a774a1" if CAN controller is a part of R8A774A1 SoC.
"renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
"renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC.
"renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC.
@@ -17,6 +18,7 @@ Required properties:
"renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1
compatible device.
"renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
+ "renesas,rzg-gen2-can" for a generic RZ/G2 compatible device.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first
followed by the generic version.
@@ -24,7 +26,9 @@ Required properties:
- reg: physical base address and size of the R-Car CAN register map.
- interrupts: interrupt specifier for the sole interrupt.
- clocks: phandles and clock specifiers for 3 CAN clock inputs.
-- clock-names: 3 clock input name strings: "clkp1", "clkp2", "can_clk".
+- clock-names: 2 clock input name strings for RZ/G2: "clkp1", "can_clk".
+ 3 clock input name strings for every other SoC: "clkp1", "clkp2",
+ "can_clk".
- pinctrl-0: pin control group to be used for this controller.
- pinctrl-names: must be "default".
@@ -41,8 +45,9 @@ using the below properties:
Optional properties:
- renesas,can-clock-select: R-Car CAN Clock Source Select. Valid values are:
<0x0> (default) : Peripheral clock (clkp1)
- <0x1> : Peripheral clock (clkp2)
- <0x3> : Externally input clock
+ <0x1> : Peripheral clock (clkp2) (not supported by
+ RZ/G2 devices)
+ <0x3> : External input clock
Example
-------
--
2.7.4
^ permalink raw reply related
* [PATCH iproute2] q_cake: Add description of the tc filter override mechanism to man page
From: Toke Høiland-Jørgensen @ 2018-08-23 10:05 UTC (permalink / raw)
To: netdev; +Cc: cake, Toke Høiland-Jørgensen
Since CAKE now has three different settings that can be overridden by tc
filters (priority and host and flow hashes), documenting how they work is
probably a good idea.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
---
man/man8/tc-cake.8 | 55 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/man/man8/tc-cake.8 b/man/man8/tc-cake.8
index c1e751d6..c62e5547 100644
--- a/man/man8/tc-cake.8
+++ b/man/man8/tc-cake.8
@@ -569,6 +569,61 @@ possible latency. At link speeds higher than 10 Gbps, setting the
no-split-gso parameter can increase the maximum achievable throughput by
retaining the full GSO packets.
+.SH OVERRIDING CLASSIFICATION WITH TC FILTERS
+
+CAKE supports overriding of its internal classification of packets through the
+tc filter mechanism. Packets can be assigned to different priority tins by
+setting the
+.B priority
+field on the skb, and the flow hashing can be overridden by setting the
+.B classid
+parameter.
+
+.PP
+.B Tin override
+
+.br
+ To assign a priority tin, the major number of the priority field needs
+to match the qdisc handle of the cake instance; if it does, the minor number
+will be interpreted as the tin index. For example, to classify all ICMP packets
+as 'bulk', the following filter can be used:
+
+.br
+ # tc qdisc replace dev eth0 handle 1: root cake diffserv3
+ # tc filter add dev eth0 parent 1: protocol ip prio 1 \\
+ u32 match icmp type 0 0 action skbedit priority 1:1
+
+.PP
+.B Flow hash override
+
+.br
+ To override flow hashing, the classid can be set. CAKE will interpret
+the major number of the classid as the host hash used in host isolation mode,
+and the minor number as the flow hash used for flow-based queueing. One or both
+of those can be set, and will be used if the relevant flow isolation parameter
+is set (i.e., the major number will be ignored if CAKE is not configured in
+hosts mode, and the minor number will be ignored if CAKE is not configured in
+flows mode).
+
+.br
+This example will assign all ICMP packets to the first queue:
+
+.br
+ # tc qdisc replace dev eth0 handle 1: root cake
+ # tc filter add dev eth0 parent 1: protocol ip prio 1 \\
+ u32 match icmp type 0 0 classid 0:1
+
+.br
+If only one of the host and flow overrides is set, CAKE will compute the other
+hash from the packet as normal. Note, however, that the host isolation mode
+works by assigning a host ID to the flow queue; so if overriding both host and
+flow, the same flow cannot have more than one host assigned. In addition, it is
+not possible to assign different source and destination host IDs through the
+override mechanism; if a host ID is assigned, it will be used as both source and
+destination host.
+
+
+
.SH EXAMPLES
# tc qdisc delete root dev eth0
.br
--
2.18.0
^ permalink raw reply related
* [PATCH v2 0/2] tree-wide: use SPDX identifier for Renesas drivers
From: Wolfram Sang @ 2018-08-23 13:34 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Kuninori Morimoto, Wolfram Sang, dmaengine, linux-can,
linux-kernel, netdev
I am resending only the patches which needed the s/GPL-2.0-or-later/GPL-2.0+/
replacement. I fixed that and checkpatch is still happy.
Wolfram Sang (2):
dmaengine: use SPDX identifier for Renesas drivers
can: rcar: use SPDX identifier for Renesas drivers
drivers/dma/nbpfaxi.c | 5 +----
drivers/dma/sh/shdma-arm.h | 5 +----
drivers/dma/sh/shdma-base.c | 5 +----
drivers/dma/sh/shdma-of.c | 5 +----
drivers/dma/sh/shdma-r8a73a4.c | 5 +----
drivers/dma/sh/shdma.h | 6 +-----
drivers/dma/sh/shdmac.c | 6 +-----
drivers/dma/sh/sudmac.c | 5 +----
drivers/dma/sh/usb-dmac.c | 5 +----
drivers/net/can/rcar/rcar_can.c | 6 +-----
drivers/net/can/rcar/rcar_canfd.c | 6 +-----
11 files changed, 11 insertions(+), 48 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH v2 2/2] can: rcar: use SPDX identifier for Renesas drivers
From: Wolfram Sang @ 2018-08-23 13:34 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Kuninori Morimoto, Wolfram Sang, Wolfgang Grandegger,
Marc Kleine-Budde, David S. Miller, linux-can, netdev,
linux-kernel
In-Reply-To: <20180823133456.4748-1-wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Change since V1: s/GPL-2.0-or-later/GPL-2.0+/
drivers/net/can/rcar/rcar_can.c | 6 +-----
drivers/net/can/rcar/rcar_canfd.c | 6 +-----
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/net/can/rcar/rcar_can.c b/drivers/net/can/rcar/rcar_can.c
index 11662f479e76..06f90a0fdc93 100644
--- a/drivers/net/can/rcar/rcar_can.c
+++ b/drivers/net/can/rcar/rcar_can.c
@@ -1,12 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
/* Renesas R-Car CAN device driver
*
* Copyright (C) 2013 Cogent Embedded, Inc. <source@cogentembedded.com>
* Copyright (C) 2013 Renesas Solutions Corp.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
*/
#include <linux/module.h>
diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
index 602c19e23f05..05410008aa6b 100644
--- a/drivers/net/can/rcar/rcar_canfd.c
+++ b/drivers/net/can/rcar/rcar_canfd.c
@@ -1,11 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
/* Renesas R-Car CAN FD device driver
*
* Copyright (C) 2015 Renesas Electronics Corp.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
*/
/* The R-Car CAN FD controller can operate in either one of the below two modes
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] r8169: don't use MSI-X on RTL8106e
From: Bjorn Helgaas @ 2018-08-23 13:38 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: Heiner Kallweit, Thomas Gleixner, David Miller,
Realtek linux nic maintainers, netdev, Linux Kernel,
Linux Upstreaming Team, linux-pci, marc.zyngier, hch
In-Reply-To: <CAPpJ_edz3H81EqRSg5jeOXoULt7AKwcTpNFL6Ntt8rhQBPFBFQ@mail.gmail.com>
On Thu, Aug 23, 2018 at 06:46:28PM +0800, Jian-Hong Pan wrote:
> > On 22.08.2018 13:44, Thomas Gleixner wrote:
> >> Can you please do the following:
>
> Tested on ASUS X441AUR equipped with RTL8106e.
> This is the laptop whose ethernet does not come back after resume, if
> it does not fallback to MSI.
> ...
> dev@endless:~$ sudo lspci -xnnvvs 02:00.0
> ...
> 00: ec 10 36 81 07 04 10 00 07 00 00 02 10 00 00 00
> 10: 01 e0 00 00 00 00 00 00 04 00 10 ef 00 00 00 00
> 20: 0c 00 00 e0 00 00 00 00 00 00 00 00 43 10 0f 20
> 30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00
>
> After comparing, there is no difference between before suspend and
> after resume.
It'd be better to compare the hex data directly and ignore the lspci
decoding, since lspci doesn't decode everything. You only dumped the
first 0x40 bytes of config space, and all capabilities, including the
MSI and MSI-X capabilities, are past that:
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
> Vector table: BAR=4 offset=00000000
> PBA: BAR=4 offset=00000800
In addition, some of the MSI-X information for this device is in BAR
4. "lspci -xxx" will dump all config space, and you can use a tool
like http://cmp.felk.cvut.cz/~pisa/linux/rdwrmem.c or
https://github.com/billfarrow/pcimem to dump the BAR contents.
^ permalink raw reply
* Re: [PATCH] r8169: don't use MSI-X on RTL8106e
From: Jian-Hong Pan @ 2018-08-23 10:46 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Thomas Gleixner, David Miller, helgaas,
Realtek linux nic maintainers, netdev, Linux Kernel,
Linux Upstreaming Team, linux-pci, marc.zyngier, hch
In-Reply-To: <36bd086d-8d26-5162-ae24-95b259571221@gmail.com>
2018-08-23 3:49 GMT+08:00 Heiner Kallweit <hkallweit1@gmail.com>:
> On 22.08.2018 13:44, Thomas Gleixner wrote:
>> On Tue, 21 Aug 2018, Heiner Kallweit wrote:
>>> On 21.08.2018 21:31, David Miller wrote:
>>>> From: Heiner Kallweit <hkallweit1@gmail.com>
>>>> Date: Mon, 20 Aug 2018 22:46:48 +0200
>>>>
>>>>> I'm in contact with Realtek and according to them few chip versions
>>>>> seem to clear MSI-X table entries on resume from suspend. Checking
>>>>> with them how this could be fixed / worked around.
>>>>> Worst case we may have to disable MSI-X in general.
>>>>
>>>> I worry that if the chip does this, and somehow MSI-X is enabled and
>>>> an interrupt is generated, the chip will write to the cleared out
>>>> MSI-X address. This will either write garbage into memory or cause
>>>> a bus error and require PCI error recovery.
>>>>
>>>> It also looks like your test patch doesn't fix things for people who
>>>> have tested it.
>>>>
>>> The test patch was based on the first info from Realtek which made me
>>> think that the base address of the MSI-X table is cleared, what
>>> obviously is not the case.
>>>
>>> After some further tests it seems that the solution isn't as simple
>>> as storing the MSI-X table entries on suspend and restore them on
>>> resume. On my system (where MSI-X works fine) MSI-X table entries
>>> on resume are partially different from the ones on suspend.
>>
>> Which is not a surprise. Please don't try to fiddle with that at the driver
>> level. The irq and PCI core code are the ones in charge and if you'd
>> restore at the wrong point then hell breaks lose.
>>
> Instead of spending a lot of effort on a workaround which may not be
> acceptable, it may be better to fall back to MSI on all affected chip
> versions. For two chip versions which were reported to have this issues
> we're doing this already. I asked Realtek whether they have an overview
> which chip versions are affected, let's see ..
>
> The Realtek chips provide an alternative, register-based way to access
> the MSI-X table, and their Windows driver seems to use it. See here:
> https://patchwork.kernel.org/patch/4149171/
>
> But as we handle all MSI-X basics in the PCI core, this isn't an option.
>
>
>> Can you please do the following:
Tested on ASUS X441AUR equipped with RTL8106e.
This is the laptop whose ethernet does not come back after resume, if
it does not fallback to MSI.
Here is the full dmesg:
https://gist.github.com/starnight/e65a97c9bf2d558926895ab76974687e
>> 1) Store the PCI config space at suspend time
Before suspend:
dev@endless:~$ sudo lspci -xnnvvs 02:00.0
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller [10ec:8136]
(rev 07)
Subsystem: ASUSTeK Computer Inc. RTL810xE PCI Express Fast Ethernet
controller [1043:200f]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at e000 [size=256]
Region 2: Memory at ef100000 (64-bit, non-prefetchable) [size=4K]
Region 4: Memory at e0000000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 01
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency
L0s unlimited, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Via
message/WAKE#
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
pcilib: sysfs_read_vpd: read failed: Input/output error
Not readable
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 01-00-00-00-36-4c-e0-00
Capabilities: [170 v1] Latency Tolerance Reporting
Max snoop latency: 3145728ns
Max no snoop latency: 3145728ns
Kernel driver in use: r8169
Kernel modules: r8169
00: ec 10 36 81 07 04 10 00 07 00 00 02 10 00 00 00
10: 01 e0 00 00 00 00 00 00 04 00 10 ef 00 00 00 00
20: 0c 00 00 e0 00 00 00 00 00 00 00 00 43 10 0f 20
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00
>> 2) Compare the PCI config space at resume time and print the difference
After resume:
dev@endless:~$ sudo lspci -xnnvvs 02:00.0
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller [10ec:8136]
(rev 07)
Subsystem: ASUSTeK Computer Inc. RTL810xE PCI Express Fast Ethernet
controller [1043:200f]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at e000 [size=256]
Region 2: Memory at ef100000 (64-bit, non-prefetchable) [size=4K]
Region 4: Memory at e0000000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 01
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency
L0s unlimited, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Via
message/WAKE#
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
pcilib: sysfs_read_vpd: read failed: Input/output error
Not readable
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 01-00-00-00-36-4c-e0-00
Capabilities: [170 v1] Latency Tolerance Reporting
Max snoop latency: 3145728ns
Max no snoop latency: 3145728ns
Kernel driver in use: r8169
Kernel modules: r8169
00: ec 10 36 81 07 04 10 00 07 00 00 02 10 00 00 00
10: 01 e0 00 00 00 00 00 00 04 00 10 ef 00 00 00 00
20: 0c 00 00 e0 00 00 00 00 00 00 00 00 43 10 0f 20
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00
After comparing, there is no difference between before suspend and after resume.
Regards,
Jian-Hong Pan
>> Do that on a working and a non-working version of Realtek NICs.
>>
>> Thanks,
>>
>> tglx
>>
>>
>>
>
^ permalink raw reply
* KASAN: use-after-free Read in __rhashtable_lookup (2)
From: syzbot @ 2018-08-23 14:35 UTC (permalink / raw)
To: davem, linux-kernel, linux-rdma, netdev, rds-devel,
santosh.shilimkar, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: ad1d69735878 Merge tag 'fuse-update-4.19' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=100e3b36400000
kernel config: https://syzkaller.appspot.com/x/.config?x=6a24c33b9ed66aa
dashboard link: https://syzkaller.appspot.com/bug?extid=8967084bcac563795dc6
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+8967084bcac563795dc6@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in memcmp+0xe8/0x150 lib/string.c:861
Read of size 1 at addr ffff8801b5201bf0 by task syz-executor5/14889
CPU: 0 PID: 14889 Comm: syz-executor5 Not tainted 4.18.0+ #202
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
memcmp+0xe8/0x150 lib/string.c:861
memcmp include/linux/string.h:386 [inline]
rhashtable_compare include/linux/rhashtable.h:462 [inline]
__rhashtable_lookup.isra.8.constprop.19+0x70f/0xd50
include/linux/rhashtable.h:484
rhashtable_lookup include/linux/rhashtable.h:516 [inline]
rhashtable_lookup_fast include/linux/rhashtable.h:542 [inline]
rds_add_bound net/rds/bind.c:117 [inline]
rds_bind+0x7c9/0x1510 net/rds/bind.c:238
__sys_bind+0x331/0x440 net/socket.c:1481
__do_sys_bind net/socket.c:1492 [inline]
__se_sys_bind net/socket.c:1490 [inline]
__x64_sys_bind+0x73/0xb0 net/socket.c:1490
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457089
Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fdf40632c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000031
RAX: ffffffffffffffda RBX: 00007fdf406336d4 RCX: 0000000000457089
RDX: 0000000000000010 RSI: 0000000020000840 RDI: 0000000000000009
RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004caff8 R14: 00000000004c2de7 R15: 0000000000000000
Allocated by task 14887:
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/0x710 mm/slab.c:3554
sk_prot_alloc+0x69/0x2e0 net/core/sock.c:1462
sk_alloc+0x106/0x17b0 net/core/sock.c:1522
rds_create+0x14f/0x770 net/rds/af_rds.c:666
__sock_create+0x53c/0x940 net/socket.c:1275
sock_create net/socket.c:1315 [inline]
__sys_socket+0x106/0x260 net/socket.c:1345
__do_sys_socket net/socket.c:1354 [inline]
__se_sys_socket net/socket.c:1352 [inline]
__x64_sys_socket+0x73/0xb0 net/socket.c:1352
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 14886:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kmem_cache_free+0x86/0x280 mm/slab.c:3756
sk_prot_free net/core/sock.c:1503 [inline]
__sk_destruct+0x70a/0xa60 net/core/sock.c:1587
sk_destruct+0x78/0x90 net/core/sock.c:1595
__sk_free+0xcf/0x300 net/core/sock.c:1606
sk_free+0x42/0x50 net/core/sock.c:1617
sock_put include/net/sock.h:1691 [inline]
rds_release+0x3e9/0x570 net/rds/af_rds.c:91
__sock_release+0xd7/0x250 net/socket.c:579
sock_close+0x19/0x20 net/socket.c:1139
__fput+0x36e/0x8c0 fs/file_table.c:278
____fput+0x15/0x20 fs/file_table.c:309
task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:193 [inline]
exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8801b5201780
which belongs to the cache RDS(76:syz7) of size 1608
The buggy address is located 1136 bytes inside of
1608-byte region [ffff8801b5201780, ffff8801b5201dc8)
The buggy address belongs to the page:
page:ffffea0006d48040 count:1 mapcount:0 mapping:ffff8801d75e2c80 index:0x0
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffffea0006e74188 ffff8801ca20ef48 ffff8801d75e2c80
raw: 0000000000000000 ffff8801b5201080 0000000100000002 ffff8801acaa4640
page dumped because: kasan: bad access detected
page->mem_cgroup:ffff8801acaa4640
Memory state around the buggy address:
ffff8801b5201a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801b5201b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801b5201b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8801b5201c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801b5201c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
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. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: is "volatile" the cause of ifconfig flags not matching sysfs flags?
From: Robert P. J. Day @ 2018-08-23 11:50 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux kernel netdev mailing list
In-Reply-To: <20180822155322.335bd34c@xeon-e3>
On Wed, 22 Aug 2018, Stephen Hemminger wrote:
> On Wed, 22 Aug 2018 18:32:36 -0400 (EDT)
> "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
>
> > almost certainly another dumb question, but i was poking around the
> > sysfs, particularly /sys/class/net/<ifname>/*, to familiarize myself
> > with what i can glean (or set) re interfaces under /sys, and i noticed
> > "flags", but what i get there doesn't match what i get by running
> > ifconfig.
> >
> > specifically, if i list the flags for my wireless interface under
> > /sys:
> >
> > $ cat flags
> > 0x1003
> > $
> >
> > but with ifconfig:
> >
> > $ ifconfig wlp2s0
> > wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> > ^^^^
> >
> > do those two "flags" values represent the same set of flags? and
> > does the obvious difference have to do with some of those flags being
> > "volatile" as dewscribed in include/uapi/linux/if.h? or am i just
> > totally misreading this?
> >
> > rday
> >
>
> sysfs reports netdevice->if_flags where as ifconfig is getting hex
> value from SIOCGIFFLAGS which does:
> dev_get_flags(dev)
>
> The value in sysfs is more intended for internal debugging, where
> all the normal userspace API's return a more limited set of
> historical values.
so the history aside, those values ultimately represent the same
flags?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* [PATCH 0/3] Add CAN support to rcar_can driver
From: Fabrizio Castro @ 2018-08-23 13:07 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, Rob Herring, Mark Rutland
Cc: Fabrizio Castro, Sergei Shtylyov, David S. Miller, linux-can,
netdev, devicetree, Simon Horman, Geert Uytterhoeven,
Chris Paterson, Biju Das, linux-renesas-soc, linux-kernel
Dear All,
RZ/G2 is slightly different from other R-Car and RZ/G1 SoCs as clkp2
isn't available on RZ/G2 devices. Changes to driver and documentation
are therefore necessary and taken care of here.
Thanks,
Fab
Fabrizio Castro (3):
can: rcar_can: Fix erroneous registration
can: rcar_can: Add RZ/G2 support
dt-bindings: can: rcar_can: Add r8a774a1 support
.../devicetree/bindings/net/can/rcar_can.txt | 11 +++--
drivers/net/can/rcar/rcar_can.c | 48 ++++++++++++++++++----
2 files changed, 48 insertions(+), 11 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3][can-next] can: rcar_can: Fix erroneous registration
From: Fabrizio Castro @ 2018-08-23 13:07 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: Fabrizio Castro, Sergei Shtylyov, David S. Miller, linux-can,
netdev, Simon Horman, Geert Uytterhoeven, Chris Paterson,
Biju Das, linux-renesas-soc
In-Reply-To: <1535029653-7418-1-git-send-email-fabrizio.castro@bp.renesas.com>
Assigning 2 to "renesas,can-clock-select" tricks the driver into
registering the CAN interface, even though we don't want that.
This patch fixes this problem and also allows for architectures
missing some of the clocks (e.g. RZ/G2) to behave as expected.
Fixes: 862e2b6af9413b43 ("can: rcar_can: support all input clocks")
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
---
This patch applies on linux-can-next-for-4.19-20180727
drivers/net/can/rcar/rcar_can.c | 43 +++++++++++++++++++++++++++++++++--------
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/drivers/net/can/rcar/rcar_can.c b/drivers/net/can/rcar/rcar_can.c
index 11662f4..fbd9284 100644
--- a/drivers/net/can/rcar/rcar_can.c
+++ b/drivers/net/can/rcar/rcar_can.c
@@ -21,9 +21,13 @@
#include <linux/clk.h>
#include <linux/can/platform/rcar_can.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#define RCAR_CAN_DRV_NAME "rcar_can"
+#define RCAR_SUPPORTED_CLOCKS (BIT(CLKR_CLKP1) | BIT(CLKR_CLKP2) | \
+ BIT(CLKR_CLKEXT))
+
/* Mailbox configuration:
* mailbox 60 - 63 - Rx FIFO mailboxes
* mailbox 56 - 59 - Tx FIFO mailboxes
@@ -745,10 +749,12 @@ static int rcar_can_probe(struct platform_device *pdev)
u32 clock_select = CLKR_CLKP1;
int err = -ENODEV;
int irq;
+ uintptr_t allowed_clks = RCAR_SUPPORTED_CLOCKS;
if (pdev->dev.of_node) {
of_property_read_u32(pdev->dev.of_node,
"renesas,can-clock-select", &clock_select);
+ allowed_clks = (uintptr_t)of_device_get_match_data(&pdev->dev);
} else {
pdata = dev_get_platdata(&pdev->dev);
if (!pdata) {
@@ -789,7 +795,7 @@ static int rcar_can_probe(struct platform_device *pdev)
goto fail_clk;
}
- if (clock_select >= ARRAY_SIZE(clock_names)) {
+ if (!(BIT(clock_select) & allowed_clks)) {
err = -EINVAL;
dev_err(&pdev->dev, "invalid CAN clock selected\n");
goto fail_clk;
@@ -899,13 +905,34 @@ static int __maybe_unused rcar_can_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(rcar_can_pm_ops, rcar_can_suspend, rcar_can_resume);
static const struct of_device_id rcar_can_of_table[] __maybe_unused = {
- { .compatible = "renesas,can-r8a7778" },
- { .compatible = "renesas,can-r8a7779" },
- { .compatible = "renesas,can-r8a7790" },
- { .compatible = "renesas,can-r8a7791" },
- { .compatible = "renesas,rcar-gen1-can" },
- { .compatible = "renesas,rcar-gen2-can" },
- { .compatible = "renesas,rcar-gen3-can" },
+ {
+ .compatible = "renesas,can-r8a7778",
+ .data = (void *)RCAR_SUPPORTED_CLOCKS,
+ },
+ {
+ .compatible = "renesas,can-r8a7779",
+ .data = (void *)RCAR_SUPPORTED_CLOCKS,
+ },
+ {
+ .compatible = "renesas,can-r8a7790",
+ .data = (void *)RCAR_SUPPORTED_CLOCKS,
+ },
+ {
+ .compatible = "renesas,can-r8a7791",
+ .data = (void *)RCAR_SUPPORTED_CLOCKS,
+ },
+ {
+ .compatible = "renesas,rcar-gen1-can",
+ .data = (void *)RCAR_SUPPORTED_CLOCKS,
+ },
+ {
+ .compatible = "renesas,rcar-gen2-can",
+ .data = (void *)RCAR_SUPPORTED_CLOCKS,
+ },
+ {
+ .compatible = "renesas,rcar-gen3-can",
+ .data = (void *)RCAR_SUPPORTED_CLOCKS,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, rcar_can_of_table);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3][can-next] can: rcar_can: Add RZ/G2 support
From: Fabrizio Castro @ 2018-08-23 13:07 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: Fabrizio Castro, Sergei Shtylyov, David S. Miller, linux-can,
netdev, Simon Horman, Geert Uytterhoeven, Chris Paterson,
Biju Das, linux-renesas-soc
In-Reply-To: <1535029653-7418-1-git-send-email-fabrizio.castro@bp.renesas.com>
RZ/G2 devices don't have clkp2, therefore this commit adds a
generic compatible string for them to allow for proper checking
during probe.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
---
This patch applies on linux-can-next-for-4.19-20180727
drivers/net/can/rcar/rcar_can.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/can/rcar/rcar_can.c b/drivers/net/can/rcar/rcar_can.c
index fbd9284..397208e 100644
--- a/drivers/net/can/rcar/rcar_can.c
+++ b/drivers/net/can/rcar/rcar_can.c
@@ -27,6 +27,7 @@
#define RCAR_SUPPORTED_CLOCKS (BIT(CLKR_CLKP1) | BIT(CLKR_CLKP2) | \
BIT(CLKR_CLKEXT))
+#define RZG2_SUPPORTED_CLOCKS (BIT(CLKR_CLKP1) | BIT(CLKR_CLKEXT))
/* Mailbox configuration:
* mailbox 60 - 63 - Rx FIFO mailboxes
@@ -933,6 +934,10 @@ static const struct of_device_id rcar_can_of_table[] __maybe_unused = {
.compatible = "renesas,rcar-gen3-can",
.data = (void *)RCAR_SUPPORTED_CLOCKS,
},
+ {
+ .compatible = "renesas,rzg-gen2-can",
+ .data = (void *)RZG2_SUPPORTED_CLOCKS,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, rcar_can_of_table);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] ath9k: turn on btcoex_enable as default
From: Tom Psyborg @ 2018-08-23 17:06 UTC (permalink / raw)
To: Kalle Valo
Cc: Kai-Heng Feng, Felix Fietkau, ath9k-devel, linux-wireless, netdev,
linux-kernel
In-Reply-To: <87in41nxfx.fsf@kamboji.qca.qualcomm.com>
I keep this setting on all the time and just when i read this mail
again i'm suspicious if the bluetooth could actually have an impact on
wifi reception? I am using AR9462 card and it can transmit at 215Mbps
average, but receives only about 125Mbps (2spatial streams AP, 2.4GHz,
AR9531)
On 23/08/2018, Kalle Valo <kvalo@codeaurora.org> wrote:
> Kai-Heng Feng <kai.heng.feng@canonical.com> writes:
>
>> at 12:15, Kai Heng Feng <kai.heng.feng@canonical.com> wrote:
>>
>>>
>>>
>>>> On 10 Feb 2018, at 10:05 PM, Felix Fietkau <nbd@nbd.name> wrote:
>>>>
>>>> On 2018-02-10 14:56, Kai Heng Feng wrote:
>>>>>> On 9 Feb 2018, at 3:16 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
>>>>>> Sure, but we have to make sure that we don't create regressions on
>>>>>> existing systems. For example, did you test this with any system
>>>>>> which
>>>>>> don't support btcoex? (just asking, haven't tested this myself)
>>>>>
>>>>> No not really, but I will definitely test it.
>>>>> The only module I have that uses ath9k is Dell’s DW1707.
>>>>> How do I check if it support btcoex or not?
>>>> I just reviewed the code again, and I am sure that we cannot merge this
>>>> patch. Enabling the btcoex parameter makes the driver enable a whole
>>>> bunch of code starting timers, listening to some GPIOs, etc.
>>>>
>>>> On non-btcoex systems, some of those GPIOs might be floating or even
>>>> connected to different things, which could cause a lot of undefined
>>>> behavior.
>>>>
>>>> This is simply too big a risk, so there absolutely needs to be a
>>>> whitelist for systems that need this, otherwise it has to remain
>>>> disabled by default.
>>>
>>> So what information can we use to whitelist btcoex chips?
>>> Can we get btcoex support status at ath9k probing?
>>
>> Sorry for bringing this up again.
>>
>> Is DMI based match an acceptable approach for ath9k?
>
> I don't know what Felix thinkgs, but to me using DMI sounds like a good
> idea to try, assuming the matches are unique enough and there's no risk
> of enabling bt coex on wrong platforms. Should the PCI bus number etc
> checked as well in case the user adds more ath9k devices to the
> platform?
>
> But of course I need to see the patch to comment more.
>
> --
> Kalle Valo
>
^ 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