* Re: [PATCH net-next v2 2/2] ipv6: remove from fib tree aged out RTF_CACHE dst
From: Martin KaFai Lau @ 2017-10-19 1:11 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, David S. Miller, Wei Wang, Eric Dumazet,
Hannes Frederic Sowa
In-Reply-To: <12138554b307c66d0de7afd582ba83e027c383a2.1508358132.git.pabeni@redhat.com>
On Wed, Oct 18, 2017 at 08:23:32PM +0000, Paolo Abeni wrote:
> The commit 2b760fcf5cfb ("ipv6: hook up exception table to store
> dst cache") partially reverted 1e2ea8ad37be ("ipv6: set
> dst.obsolete when a cached route has expired").
>
> As a result, RTF_CACHE dst referenced outside the fib tree will
> not be removed until the next sernum change; dst_check() does not
> fail on aged-out dst, and dst->__refcnt can't decrease: the aged
> out dst will stay valid for a potentially unlimited time after the
> timeout expiration.
>
> This change explicitly removes RTF_CACHE dst from the fib tree when
> aged out. The rt6_remove_exception() logic will then obsolete the
> dst and other entities will drop the related reference on next
> dst_check().
>
> v1 -> v2:
> - do not touch dst.obsolete in rt6_remove_exception(), not needed
>
> Fixes: 2b760fcf5cfb ("ipv6: hook up exception table to store dst cache")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/ipv6/route.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 5c27313803d2..a4a7f199120e 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1575,8 +1575,11 @@ static void rt6_age_examine_exception(struct rt6_exception_bucket *bucket,
> {
> struct rt6_info *rt = rt6_ex->rt6i;
>
> - if (atomic_read(&rt->dst.__refcnt) == 1 &&
Wei and I have discussed a few cases:
1) For PMTU rt, the dst.expires should have been set (to ip6_rt_mtu_expires)
and the next dst_check() should have returned NULL. The
ip6_pol_route() should not have returned this expired pmtu rt also.
The ip6_rt_mtu_expires should be used to decide if the rt is no
longer useful instead of gc_args->timeout.
We should not ignore __refcnt in this case. Otherwise, we are
punishing sk that is caching the rt since lastuse
is only updated during the route lookup.
2) The cases that we can ignore __refcnt are:
a) RTF_CACHE rt that has no expire set. I believe only redirect rt falls
into this bucket. In this case, we can use gc_args->timeout.
b) If there is an urgency to cleanup (like reaching ip6_rt_max_size)
or user force a flush.
> - time_after_eq(now, rt->dst.lastuse + gc_args->timeout)) {
> + /* we are pruning and obsoleting the exception route even if others
> + * have still reference to it, so that on next dst_check() such
> + * reference can be dropped
> + */
> + if (time_after_eq(now, rt->dst.lastuse + gc_args->timeout)) {
> RT6_TRACE("aging clone %p\n", rt);
> rt6_remove_exception(bucket, rt6_ex);
> return;
> --
> 2.13.6
>
^ permalink raw reply
* Re: [PATCH net-next v6 0/5] bpf: security: New file mode and LSM hooks for eBPF object permission control
From: James Morris @ 2017-10-19 1:49 UTC (permalink / raw)
To: David Miller
Cc: chenbofeng.kernel, netdev, Selinux, linux-security-module, jeffv,
alexei.starovoitov, lorenzo, daniel, sds, paul, fengc
In-Reply-To: <20171018.134729.837318478487425125.davem@davemloft.net>
On Wed, 18 Oct 2017, David Miller wrote:
> Series applied.
I hadn't gotten to reviewing this patchset yet.
Please wait for more acks/reviews from LSM folk for things touching
security/, next time.
--
James Morris
<james.l.morris@oracle.com>
^ permalink raw reply
* 45488 netdev
From: marketing @ 2017-10-19 1:56 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 71593083392.doc --]
[-- Type: application/msword, Size: 75264 bytes --]
^ permalink raw reply
* RE: [PATCH 1/5] net: virtio dynamically disable/enable LRO
From: Caleb Raitto @ 2017-10-19 2:18 UTC (permalink / raw)
To: John Fastabend
Cc: tgraf, shm, alexei.starovoitov, daniel, davem, netdev, bblanco,
brouer, Catherine Sullivan, Michael S. Tsirkin
On Fri, Nov 18, 2016 at 11:00 AM, John Fastabend
<john.fastabend@gmail.com> wrote:
>
> From: John Fastabend <john.fastabend@gmail.com>
> Date: Fri, Nov 18, 2016 at 11:00 AM
> Subject: [PATCH 1/5] net: virtio dynamically disable/enable LRO
> To: <tgraf@suug.ch>, <shm@cumulusnetworks.com>, <alexei.starovoitov@gmail.com>, <daniel@iogearbox.net>, <davem@davemloft.net>
> Cc: <john.r.fastabend@intel.com>, <netdev@vger.kernel.org>, <bblanco@plumgrid.com>, <john.fastabend@gmail.com>, <brouer@redhat.com>
>
> This adds support for dynamically setting the LRO feature flag. The
> message to control guest features in the backend uses the
> CTRL_GUEST_OFFLOADS msg type.
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> drivers/net/virtio_net.c | 43 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 2cafd12..0758cae 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1419,6 +1419,41 @@ static void virtnet_init_settings(struct net_device *dev)
Hi,
I work on Google Compute Engine, and I noticed that you had this
unmerged patch that allows controlling offloads using ethtool for
virtionet.
We are interested in merging this patch as it will be useful in
debugging customer issues related to offloads and MTU.
If work remains to get the patch merged, I'm willing to help out.
Thanks,
-Caleb
^ permalink raw reply
* [PATCH net 1/5] net/ncsi: Fix AEN HNCDSC packet length
From: Samuel Mendoza-Jonas @ 2017-10-19 2:43 UTC (permalink / raw)
To: netdev; +Cc: Samuel Mendoza-Jonas, David S . Miller, linux-kernel
Correct the value of the HNCDSC AEN packet.
Fixes: 7a82ecf4cfb85 "net/ncsi: NCSI AEN packet handler"
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
---
net/ncsi/ncsi-aen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ncsi/ncsi-aen.c b/net/ncsi/ncsi-aen.c
index 6898e7229285..f135938bf781 100644
--- a/net/ncsi/ncsi-aen.c
+++ b/net/ncsi/ncsi-aen.c
@@ -187,7 +187,7 @@ static struct ncsi_aen_handler {
} ncsi_aen_handlers[] = {
{ NCSI_PKT_AEN_LSC, 12, ncsi_aen_handler_lsc },
{ NCSI_PKT_AEN_CR, 4, ncsi_aen_handler_cr },
- { NCSI_PKT_AEN_HNCDSC, 4, ncsi_aen_handler_hncdsc }
+ { NCSI_PKT_AEN_HNCDSC, 8, ncsi_aen_handler_hncdsc }
};
int ncsi_aen_handler(struct ncsi_dev_priv *ndp, struct sk_buff *skb)
--
2.14.2
^ permalink raw reply related
* [PATCH net 2/5] net/ncsi: Stop monitor if channel times out or is inactive
From: Samuel Mendoza-Jonas @ 2017-10-19 2:43 UTC (permalink / raw)
To: netdev; +Cc: Samuel Mendoza-Jonas, David S . Miller, linux-kernel
In-Reply-To: <20171019024309.13628-1-sam@mendozajonas.com>
ncsi_channel_monitor() misses stopping the channel monitor in several
places that it should, causing a WARN_ON_ONCE() to trigger when the
monitor is re-started later, eg:
[ 459.040000] WARNING: CPU: 0 PID: 1093 at net/ncsi/ncsi-manage.c:269 ncsi_start_channel_monitor+0x7c/0x90
[ 459.040000] CPU: 0 PID: 1093 Comm: kworker/0:3 Not tainted 4.10.17-gaca2fdd #140
[ 459.040000] Hardware name: ASpeed SoC
[ 459.040000] Workqueue: events ncsi_dev_work
[ 459.040000] [<80010094>] (unwind_backtrace) from [<8000d950>] (show_stack+0x20/0x24)
[ 459.040000] [<8000d950>] (show_stack) from [<801dbf70>] (dump_stack+0x20/0x28)
[ 459.040000] [<801dbf70>] (dump_stack) from [<80018d7c>] (__warn+0xe0/0x108)
[ 459.040000] [<80018d7c>] (__warn) from [<80018e70>] (warn_slowpath_null+0x30/0x38)
[ 459.040000] [<80018e70>] (warn_slowpath_null) from [<803f6a08>] (ncsi_start_channel_monitor+0x7c/0x90)
[ 459.040000] [<803f6a08>] (ncsi_start_channel_monitor) from [<803f7664>] (ncsi_configure_channel+0xdc/0x5fc)
[ 459.040000] [<803f7664>] (ncsi_configure_channel) from [<803f8160>] (ncsi_dev_work+0xac/0x474)
[ 459.040000] [<803f8160>] (ncsi_dev_work) from [<8002d244>] (process_one_work+0x1e0/0x450)
[ 459.040000] [<8002d244>] (process_one_work) from [<8002d510>] (worker_thread+0x5c/0x570)
[ 459.040000] [<8002d510>] (worker_thread) from [<80033614>] (kthread+0x124/0x164)
[ 459.040000] [<80033614>] (kthread) from [<8000a5e8>] (ret_from_fork+0x14/0x2c)
This also updates the monitor instead of just returning if
ncsi_xmit_cmd() fails to send the get-link-status command so that the
monitor properly times out.
Fixes: e6f44ed6d04d3 "net/ncsi: Package and channel management"
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
---
net/ncsi/ncsi-manage.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
index b6a449aa9d4b..b022deb39d31 100644
--- a/net/ncsi/ncsi-manage.c
+++ b/net/ncsi/ncsi-manage.c
@@ -202,11 +202,15 @@ static void ncsi_channel_monitor(unsigned long data)
monitor_state = nc->monitor.state;
spin_unlock_irqrestore(&nc->lock, flags);
- if (!enabled || chained)
+ if (!enabled || chained) {
+ ncsi_stop_channel_monitor(nc);
return;
+ }
if (state != NCSI_CHANNEL_INACTIVE &&
- state != NCSI_CHANNEL_ACTIVE)
+ state != NCSI_CHANNEL_ACTIVE) {
+ ncsi_stop_channel_monitor(nc);
return;
+ }
switch (monitor_state) {
case NCSI_CHANNEL_MONITOR_START:
@@ -217,12 +221,9 @@ static void ncsi_channel_monitor(unsigned long data)
nca.type = NCSI_PKT_CMD_GLS;
nca.req_flags = 0;
ret = ncsi_xmit_cmd(&nca);
- if (ret) {
+ if (ret)
netdev_err(ndp->ndev.dev, "Error %d sending GLS\n",
ret);
- return;
- }
-
break;
case NCSI_CHANNEL_MONITOR_WAIT ... NCSI_CHANNEL_MONITOR_WAIT_MAX:
break;
@@ -233,6 +234,8 @@ static void ncsi_channel_monitor(unsigned long data)
ndp->flags |= NCSI_DEV_RESHUFFLE;
}
+ ncsi_stop_channel_monitor(nc);
+
spin_lock_irqsave(&nc->lock, flags);
nc->state = NCSI_CHANNEL_INVISIBLE;
spin_unlock_irqrestore(&nc->lock, flags);
--
2.14.2
^ permalink raw reply related
* [PATCH net 4/5] net/ncsi: Enforce failover on link monitor timeout
From: Samuel Mendoza-Jonas @ 2017-10-19 2:43 UTC (permalink / raw)
To: netdev; +Cc: Gavin Shan, David S . Miller, linux-kernel, Samuel Mendoza-Jonas
In-Reply-To: <20171019024309.13628-1-sam@mendozajonas.com>
From: Gavin Shan <gwshan@linux.vnet.ibm.com>
The NCSI channel has been configured to provide service if its link
monitor timer is enabled, regardless of its state (inactive or active).
So the timeout event on the link monitor indicates the out-of-service
on that channel, for which a failover is needed.
This sets NCSI_DEV_RESHUFFLE flag to enforce failover on link monitor
timeout, regardless the channel's original state (inactive or active).
Also, the link is put into "down" state to give the failing channel
lowest priority when selecting for the active channel. The state of
failing channel should be set to active in order for deinitialization
and failover to be done.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
---
net/ncsi/ncsi-manage.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
index 0966eff48ce7..28c42b22b748 100644
--- a/net/ncsi/ncsi-manage.c
+++ b/net/ncsi/ncsi-manage.c
@@ -189,6 +189,7 @@ static void ncsi_channel_monitor(unsigned long data)
struct ncsi_channel *nc = (struct ncsi_channel *)data;
struct ncsi_package *np = nc->package;
struct ncsi_dev_priv *ndp = np->ndp;
+ struct ncsi_channel_mode *ncm;
struct ncsi_cmd_arg nca;
bool enabled, chained;
unsigned int monitor_state;
@@ -228,20 +229,21 @@ static void ncsi_channel_monitor(unsigned long data)
case NCSI_CHANNEL_MONITOR_WAIT ... NCSI_CHANNEL_MONITOR_WAIT_MAX:
break;
default:
- if (!(ndp->flags & NCSI_DEV_HWA) &&
- state == NCSI_CHANNEL_ACTIVE) {
+ if (!(ndp->flags & NCSI_DEV_HWA)) {
ncsi_report_link(ndp, true);
ndp->flags |= NCSI_DEV_RESHUFFLE;
}
ncsi_stop_channel_monitor(nc);
+ ncm = &nc->modes[NCSI_MODE_LINK];
spin_lock_irqsave(&nc->lock, flags);
nc->state = NCSI_CHANNEL_INVISIBLE;
+ ncm->data[2] &= ~0x1;
spin_unlock_irqrestore(&nc->lock, flags);
spin_lock_irqsave(&ndp->lock, flags);
- nc->state = NCSI_CHANNEL_INACTIVE;
+ nc->state = NCSI_CHANNEL_ACTIVE;
list_add_tail_rcu(&nc->link, &ndp->channel_queue);
spin_unlock_irqrestore(&ndp->lock, flags);
ncsi_process_next_channel(ndp);
--
2.14.2
^ permalink raw reply related
* [PATCH net 5/5] net/ncsi: Fix length of GVI response packet
From: Samuel Mendoza-Jonas @ 2017-10-19 2:43 UTC (permalink / raw)
To: netdev; +Cc: Gavin Shan, David S . Miller, linux-kernel, Samuel Mendoza-Jonas
In-Reply-To: <20171019024309.13628-1-sam@mendozajonas.com>
From: Gavin Shan <gwshan@linux.vnet.ibm.com>
The length of GVI (GetVersionInfo) response packet should be 40 instead
of 36. This issue was found from /sys/kernel/debug/ncsi/eth0/stats.
# ethtool --ncsi eth0 swstats
:
RESPONSE OK TIMEOUT ERROR
=======================================
GVI 0 0 2
With this applied, no error reported on GVI response packets:
# ethtool --ncsi eth0 swstats
:
RESPONSE OK TIMEOUT ERROR
=======================================
GVI 2 0 0
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
---
net/ncsi/ncsi-rsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
index 265b9a892d41..927dad4759d1 100644
--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -959,7 +959,7 @@ static struct ncsi_rsp_handler {
{ NCSI_PKT_RSP_EGMF, 4, ncsi_rsp_handler_egmf },
{ NCSI_PKT_RSP_DGMF, 4, ncsi_rsp_handler_dgmf },
{ NCSI_PKT_RSP_SNFC, 4, ncsi_rsp_handler_snfc },
- { NCSI_PKT_RSP_GVI, 36, ncsi_rsp_handler_gvi },
+ { NCSI_PKT_RSP_GVI, 40, ncsi_rsp_handler_gvi },
{ NCSI_PKT_RSP_GC, 32, ncsi_rsp_handler_gc },
{ NCSI_PKT_RSP_GP, -1, ncsi_rsp_handler_gp },
{ NCSI_PKT_RSP_GCPS, 172, ncsi_rsp_handler_gcps },
--
2.14.2
^ permalink raw reply related
* [PATCH net 3/5] net/ncsi: Disable HWA mode when no channels are found
From: Samuel Mendoza-Jonas @ 2017-10-19 2:43 UTC (permalink / raw)
To: netdev; +Cc: Gavin Shan, David S . Miller, linux-kernel, Samuel Mendoza-Jonas
In-Reply-To: <20171019024309.13628-1-sam@mendozajonas.com>
From: Gavin Shan <gwshan@linux.vnet.ibm.com>
When there are no NCSI channels probed, HWA (Hardware Arbitration)
mode is enabled. It's not correct because HWA depends on the fact:
NCSI channels exist and all of them support HWA mode. This disables
HWA when no channels are probed.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
---
net/ncsi/ncsi-manage.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
index b022deb39d31..0966eff48ce7 100644
--- a/net/ncsi/ncsi-manage.c
+++ b/net/ncsi/ncsi-manage.c
@@ -1005,12 +1005,15 @@ static bool ncsi_check_hwa(struct ncsi_dev_priv *ndp)
struct ncsi_package *np;
struct ncsi_channel *nc;
unsigned int cap;
+ bool has_channel = false;
/* The hardware arbitration is disabled if any one channel
* doesn't support explicitly.
*/
NCSI_FOR_EACH_PACKAGE(ndp, np) {
NCSI_FOR_EACH_CHANNEL(np, nc) {
+ has_channel = true;
+
cap = nc->caps[NCSI_CAP_GENERIC].cap;
if (!(cap & NCSI_CAP_GENERIC_HWA) ||
(cap & NCSI_CAP_GENERIC_HWA_MASK) !=
@@ -1021,8 +1024,13 @@ static bool ncsi_check_hwa(struct ncsi_dev_priv *ndp)
}
}
- ndp->flags |= NCSI_DEV_HWA;
- return true;
+ if (has_channel) {
+ ndp->flags |= NCSI_DEV_HWA;
+ return true;
+ }
+
+ ndp->flags &= ~NCSI_DEV_HWA;
+ return false;
}
static int ncsi_enable_hwa(struct ncsi_dev_priv *ndp)
--
2.14.2
^ permalink raw reply related
* Re: [PATCH 1/5] net: virtio dynamically disable/enable LRO
From: Michael S. Tsirkin @ 2017-10-19 2:47 UTC (permalink / raw)
To: Caleb Raitto
Cc: John Fastabend, tgraf, shm, alexei.starovoitov, daniel, davem,
netdev, bblanco, brouer, Catherine Sullivan, Jason Wang
In-Reply-To: <CA+7y87rYzKSDLb-wq9ok8TqgD_41u8oqZvfWLELYgDqQ4wCrKg@mail.gmail.com>
On Wed, Oct 18, 2017 at 07:18:31PM -0700, Caleb Raitto wrote:
> On Fri, Nov 18, 2016 at 11:00 AM, John Fastabend
> <john.fastabend@gmail.com> wrote:
> >
> > From: John Fastabend <john.fastabend@gmail.com>
> > Date: Fri, Nov 18, 2016 at 11:00 AM
> > Subject: [PATCH 1/5] net: virtio dynamically disable/enable LRO
> > To: <tgraf@suug.ch>, <shm@cumulusnetworks.com>, <alexei.starovoitov@gmail.com>, <daniel@iogearbox.net>, <davem@davemloft.net>
> > Cc: <john.r.fastabend@intel.com>, <netdev@vger.kernel.org>, <bblanco@plumgrid.com>, <john.fastabend@gmail.com>, <brouer@redhat.com>
> >
> > This adds support for dynamically setting the LRO feature flag. The
> > message to control guest features in the backend uses the
> > CTRL_GUEST_OFFLOADS msg type.
> > Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> > ---
> > drivers/net/virtio_net.c | 43 +++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 43 insertions(+)
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 2cafd12..0758cae 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -1419,6 +1419,41 @@ static void virtnet_init_settings(struct net_device *dev)
>
> Hi,
>
> I work on Google Compute Engine, and I noticed that you had this
> unmerged patch that allows controlling offloads using ethtool for
> virtionet.
>
> We are interested in merging this patch as it will be useful in
> debugging customer issues related to offloads and MTU.
>
> If work remains to get the patch merged, I'm willing to help out.
>
> Thanks,
> -Caleb
This patch needs to be rebased on top of latest patches by Jason.
In particular, there's code to disable/enable offloads automatically.
That either needs to go away if user configured them manually,
or the conflict resolved.
--
MST
^ permalink raw reply
* [PATCH net] hv_sock: add locking in the open/close/release code paths
From: Dexuan Cui @ 2017-10-19 3:33 UTC (permalink / raw)
To: David S. Miller, netdev@vger.kernel.org, Stephen Hemminger,
KY Srinivasan
Cc: Jork Loeser, Rolf Neugebauer, Haiyang Zhang,
linux-kernel@vger.kernel.org, Marcelo Cerri,
devel@linuxdriverproject.org, Vitaly Kuznetsov
Without the patch, when hvs_open_connection() hasn't completely established
a connection (e.g. it has changed sk->sk_state to SS_CONNECTED, but hasn't
inserted the sock into the connected queue), vsock_stream_connect() may see
the sk_state change and return the connection to the userspace, and next
when the userspace closes the connection quickly, hvs_release() may not see
the connection in the connected queue; finally hvs_open_connection()
inserts the connection into the queue, but we won't be able to purge the
connection for ever.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Cathy Avery <cavery@redhat.com>
Cc: Rolf Neugebauer <rolf.neugebauer@docker.com>
Cc: Marcelo Cerri <marcelo.cerri@canonical.com>
---
Please consider this for v4.14.
net/vmw_vsock/hyperv_transport.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index 14ed5a3..e21991f 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -310,11 +310,15 @@ static void hvs_close_connection(struct vmbus_channel *chan)
struct sock *sk = get_per_channel_state(chan);
struct vsock_sock *vsk = vsock_sk(sk);
+ lock_sock(sk);
+
sk->sk_state = SS_UNCONNECTED;
sock_set_flag(sk, SOCK_DONE);
vsk->peer_shutdown |= SEND_SHUTDOWN | RCV_SHUTDOWN;
sk->sk_state_change(sk);
+
+ release_sock(sk);
}
static void hvs_open_connection(struct vmbus_channel *chan)
@@ -344,6 +348,8 @@ static void hvs_open_connection(struct vmbus_channel *chan)
if (!sk)
return;
+ lock_sock(sk);
+
if ((conn_from_host && sk->sk_state != VSOCK_SS_LISTEN) ||
(!conn_from_host && sk->sk_state != SS_CONNECTING))
goto out;
@@ -395,9 +401,7 @@ static void hvs_open_connection(struct vmbus_channel *chan)
vsock_insert_connected(vnew);
- lock_sock(sk);
vsock_enqueue_accept(sk, new);
- release_sock(sk);
} else {
sk->sk_state = SS_CONNECTED;
sk->sk_socket->state = SS_CONNECTED;
@@ -410,6 +414,8 @@ static void hvs_open_connection(struct vmbus_channel *chan)
out:
/* Release refcnt obtained when we called vsock_find_bound_socket() */
sock_put(sk);
+
+ release_sock(sk);
}
static u32 hvs_get_local_cid(void)
@@ -476,13 +482,21 @@ static int hvs_shutdown(struct vsock_sock *vsk, int mode)
static void hvs_release(struct vsock_sock *vsk)
{
+ struct sock *sk = sk_vsock(vsk);
struct hvsock *hvs = vsk->trans;
- struct vmbus_channel *chan = hvs->chan;
+ struct vmbus_channel *chan;
+ lock_sock(sk);
+
+ sk->sk_state = SS_DISCONNECTING;
+ vsock_remove_sock(vsk);
+
+ release_sock(sk);
+
+ chan = hvs->chan;
if (chan)
hvs_shutdown(vsk, RCV_SHUTDOWN | SEND_SHUTDOWN);
- vsock_remove_sock(vsk);
}
static void hvs_destruct(struct vsock_sock *vsk)
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates
From: Sekhar Nori @ 2017-10-19 5:07 UTC (permalink / raw)
To: Franklin S Cooper Jr, Marc Kleine-Budde, Mario Hüttel,
Yang, Wenyou, wg, socketcan, quentin.schulz, edumazet, linux-can,
netdev, linux-kernel
Cc: Wenyou Yang, Dong Aisheng, Quadros, Roger
In-Reply-To: <848e965d-e6a1-8930-9064-0317563326c0@ti.com>
On Wednesday 18 October 2017 07:47 PM, Franklin S Cooper Jr wrote:
>
>
> On 10/18/2017 08:24 AM, Sekhar Nori wrote:
>> Hi Marc,
>>
>> On Wednesday 18 October 2017 06:14 PM, Marc Kleine-Budde wrote:
>>> On 09/21/2017 02:48 AM, Franklin S Cooper Jr wrote:
>>>>
>>>>
>>>> On 09/20/2017 04:37 PM, Mario Hüttel wrote:
>>>>>
>>>>>
>>>>> On 09/20/2017 10:19 PM, Franklin S Cooper Jr wrote:
>>>>>> Hi Wenyou,
>>>>>>
>>>>>> On 09/17/2017 10:47 PM, Yang, Wenyou wrote:
>>>>>>>
>>>>>>> On 2017/9/14 13:06, Sekhar Nori wrote:
>>>>>>>> On Thursday 14 September 2017 03:28 AM, Franklin S Cooper Jr wrote:
>>>>>>>>> On 08/18/2017 02:39 PM, Franklin S Cooper Jr wrote:
>>>>>>>>>> During test transmitting using CAN-FD at high bitrates (4 Mbps) only
>>>>>>>>>> resulted in errors. Scoping the signals I noticed that only a single
>>>>>>>>>> bit
>>>>>>>>>> was being transmitted and with a bit more investigation realized the
>>>>>>>>>> actual
>>>>>>>>>> MCAN IP would go back to initialization mode automatically.
>>>>>>>>>>
>>>>>>>>>> It appears this issue is due to the MCAN needing to use the Transmitter
>>>>>>>>>> Delay Compensation Mode as defined in the MCAN User's Guide. When this
>>>>>>>>>> mode is used the User's Guide indicates that the Transmitter Delay
>>>>>>>>>> Compensation Offset register should be set. The document mentions
>>>>>>>>>> that this
>>>>>>>>>> register should be set to (1/dbitrate)/2*(Func Clk Freq).
>>>>>>>>>>
>>>>>>>>>> Additional CAN-CIA's "Bit Time Requirements for CAN FD" document
>>>>>>>>>> indicates
>>>>>>>>>> that this TDC mode is only needed for data bit rates above 2.5 Mbps.
>>>>>>>>>> Therefore, only enable this mode and only set TDCO when the data bit
>>>>>>>>>> rate
>>>>>>>>>> is above 2.5 Mbps.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>>>>>>>>>> ---
>>>>>>>>>> I'm pretty surprised that this hasn't been implemented already since
>>>>>>>>>> the primary purpose of CAN-FD is to go beyond 1 Mbps and the MCAN IP
>>>>>>>>>> supports up to 10 Mbps.
>>>>>>>>>>
>>>>>>>>>> So it will be nice to get comments from users of this driver to
>>>>>>>>>> understand
>>>>>>>>>> if they have been able to use CAN-FD beyond 2.5 Mbps without this
>>>>>>>>>> patch.
>>>>>>>>>> If they haven't what did they do to get around it if they needed higher
>>>>>>>>>> speeds.
>>>>>>>>>>
>>>>>>>>>> Meanwhile I plan on testing this using a more "realistic" CAN bus to
>>>>>>>>>> insure
>>>>>>>>>> everything still works at 5 Mbps which is the max speed of my CAN
>>>>>>>>>> transceiver.
>>>>>>>>> ping. Anyone has any thoughts on this?
>>>>>>>> I added Dong who authored the m_can driver and Wenyou who added the only
>>>>>>>> in-kernel user of the driver for any help.
>>>>>>> I tested it on SAMA5D2 Xplained board both with and without this patch,
>>>>>>> both work with the 4M bps data bit rate.
>>>>>> Thank you for testing this out. Its interesting that you have been able
>>>>>> to use higher speeds without this patch. What is the CAN transceiver
>>>>>> being used on the SAMA5D2 Xplained board? I tried looking at the
>>>>>> schematic but it seems the CAN signals are used on an extension board
>>>>>> which I can't find the schematic for. Also do you mind sharing your test
>>>>>> setup? Were you doing a short point to point test?
>>>>>>
>>>>>> Thank You,
>>>>>> Franklin
>>>>> Hello Franklin,
>>>>>
>>>>> your patch definitely makes sense.
>>>>>
>>>>> I forgot the TDC in my patches because it was not present in the
>>>>> previous driver versions and because I didn't encounter any
>>>>> problems when testing it myself.
>>>>>
>>>>> The error is highly dependent on the hardware (transceiver) setup.
>>>>> So it is definitely possible that some people don't encounter errors
>>>>> without your patch.
>>>>
>>>> So the Transmission Delay Compensation feature Value register is suppose
>>>> to take into consideration the transceiver delay automatically and add
>>>> the value of TDCO on top of that. So why would TDCO be dependent on the
>>>> transceiver? I've heard conflicting things regarding TDC so any
>>>> clarification on what actually impacts it would be appreciated.
>>>>
>>>> Also part of the issue I'm having is how can we properly configure TDCO?
>>>> Configuring TDCO is essentially figuring out what Secondary Sample Point
>>>> to use. However, it is unclear what value to set SSP to and which use
>>>> cases a given SSP will work or doesn't work. I've seen various
>>>> recommendations from Bosch on choosing SSP but ultimately it seems they
>>>> suggestion "real world testing" to come up with a proper value. Not
>>>> setting TDCO causes problems for my device and improperly setting TDCO
>>>> causes problems for my device. So its likely any value I use could end
>>>> up breaking something for someone else.
>>>>
>>>> Currently I leaning to a DT property that can be used for setting SSP.
>>>> Perhaps use a generic default value and allow individuals to override it
>>>> via DT?
>>>
>>> Sounds reasonable. What's the status of this series?
>>
>> I have had some offline discussions with Franklin on this, and I am not
>> fully convinced that DT is the way to go here (although I don't have the
>> agreement with Franklin there).
>
> Probably the fundamental area where we disagree is what "default" SSP
> value should be used. Based on a short (< 1 ft) point to point test
> using a SSP of 50% worked fine. However, I'm not convinced that this
> default value of 50% will work in a more "traditional" CAN bus at higher
> speeds. Nor am I convinced that a SSP of 50% will work on every MCAN
> board in even the simplest test cases.
>
> I believe that this default SSP should be a DT property that allows any
> board to determine what default value works best in general.
With that, I think, we are taking DT from describing board/hardware
characteristics to providing default values that software should use.
In any case, if Marc and/or Wolfgang are okay with it, binding
documentation for such a property should be sent to DT maintainers for
review.
>>
>> There are two components in configuring the secondary sample point. It
>> is the transceiver loopback delay and an offset (example half of the bit
>> time in data phase).
>>
>> While the transceiver loopback delay is pretty board dependent (and thus
>> amenable to DT encoding), I am not quite sure the offset can be
>> configured in DT because its not really board dependent.
>>
>> Unfortunately, offset calculation does not seem to be an exact science.
>> There are recommendations ranging from using 50% of bit time to making
>> it same as the sample point configured. This means users who need to
>> change the SSP due to offset variations need to change their DT even
>> without anything changing on their board.
>>
>> Since we have a netlink socket interface to configure sample point, I
>> wonder if that should be extended to configure SSP too (or at least the
>> offset part of SSP)?
>
> Sekhar is right that ideally the user should be able to set the SSP at
> runtime. However, my issue is that based on my experience CAN users
> expect the driver to just work the majority of times. For unique use
> cases where the driver calculated values don't work then the user should
> be able to override it. This should only be done for a very small
> percentage of CAN users. Unless you allow DT to provide a default SSP
> many users of MCAN may find that the default SSP doesn't work and must
> always use runtime overrides to get anything to work. I don't think that
> is a good user experience which is why I don't like the idea.
Fair enough. But not quite sure if CAN users expect CAN-FD to "just
work" without doing any bittiming related setup.
Thanks,
Sekhar
^ permalink raw reply
* RE: [PATCH 4/7] devlink: Adding perm config of link settings
From: Yuval Mintz @ 2017-10-19 6:07 UTC (permalink / raw)
To: Steve Lin, netdev@vger.kernel.org
Cc: Jiri Pirko, davem@davemloft.net, michael.chan@broadcom.com,
linville@tuxdriver.com, gospo@broadcom.com
In-Reply-To: <1508273069-40461-5-git-send-email-steven.lin1@broadcom.com>
> +enum devlink_autoneg_protocol {
> + DEVLINK_AUTONEG_PROTOCOL_IEEE8023BY_BAM,
> + DEVLINK_AUTONEG_PROTOCOL_IEEE8023BY_CONSORTIUM,
> + DEVLINK_AUTONEG_PROTOCOL_IEEE8023BY,
> + DEVLINK_AUTONEG_PROTOCOL_BAM, /* Broadcom
> Autoneg Mode */
> + DEVLINK_AUTONEG_PROTOCOL_CONSORTIUM, /*
> Consortium Autoneg Mode */
> +};
Wouldn't adding BAM as a 'generic' mode of operation be like adding
non-consortium speeds to ethtool API?
[I profess ignorance in this area; For all I know it can be a widely accepted
industry standard]
^ permalink raw reply
* merge conflict between rdma-next and net-next
From: Leon Romanovsky @ 2017-10-19 6:24 UTC (permalink / raw)
To: Doug Ledford, David S. Miller
Cc: RDMA mailing list, linux-netdev, Tariq Toukan, Saeed Mahameed
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
Hi Doug and Dave,
In the absence of linux-next, I want to warn you that there is a trivial
merge conflict between rdma-next and net-next in drivers/net/ethernet/mellanox/mlx4/catas.c
The origin of the merge conflict is the following patch https://patchwork.kernel.org/patch/9986131/
applied to rdma-next. It is part of tree-wide conversion to timer_setup() interface.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [PATCH net v2 2/2] net: fec: Let fec_ptp have its own interrupt routine
From: Andy Duan @ 2017-10-19 6:25 UTC (permalink / raw)
To: Troy Kisky, shawn.guo@linaro.org, netdev@vger.kernel.org,
davem@davemloft.net
Cc: Fabio Estevam, lznuaa@gmail.com, andrew@lunn.ch
In-Reply-To: <006c1086-97c5-2076-de37-c9766f0c499e@boundarydevices.com>
From: Troy Kisky <troy.kisky@boundarydevices.com> Sent: Thursday, October 19, 2017 2:30 AM
>On 10/18/2017 11:10 AM, Troy Kisky wrote:
>> On 10/17/2017 7:30 PM, Andy Duan wrote:
>>> From: Troy Kisky <troy.kisky@boundarydevices.com> Sent: Wednesday,
>>> October 18, 2017 5:34 AM
>>>>>> This is better for code locality and should slightly speed up
>>>>>> normal
>>>> interrupts.
>>>>>>
>>>>>> This also allows PPS clock output to start working for i.mx7. This
>>>>>> is because
>>>>>> i.mx7 was already using the limit of 3 interrupts, and needed another.
>>>>>>
>>>>>> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> v2: made this change independent of any devicetree change so that
>>>>>> old dtbs continue to work.
>>>>>>
>>>>>> Continue to register ptp clock if interrupt is not found.
>>>>>> ---
>>>>>> drivers/net/ethernet/freescale/fec.h | 3 +-
>>>>>> drivers/net/ethernet/freescale/fec_main.c | 25 ++++++----
>>>>>> drivers/net/ethernet/freescale/fec_ptp.c | 82
>>>>>> ++++++++++++++++++--------
>>>>>> -----
>>>>>> 3 files changed, 65 insertions(+), 45 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/ethernet/freescale/fec.h
>>>>>> b/drivers/net/ethernet/freescale/fec.h
>>>>>> index ede1876a9a19..be56ac1f1ac4 100644
>>>>>> --- a/drivers/net/ethernet/freescale/fec.h
>>>>>> +++ b/drivers/net/ethernet/freescale/fec.h
>>>>>> @@ -582,12 +582,11 @@ struct fec_enet_private {
>>>>>> u64 ethtool_stats[0];
>>>>>> };
>>>>>>
>>>>>> -void fec_ptp_init(struct platform_device *pdev);
>>>>>> +void fec_ptp_init(struct platform_device *pdev, int irq_index);
>>>>>> void fec_ptp_stop(struct platform_device *pdev); void
>>>>>> fec_ptp_start_cyclecounter(struct net_device *ndev); int
>>>>>> fec_ptp_set(struct net_device *ndev, struct ifreq *ifr); int
>>>>>> fec_ptp_get(struct net_device *ndev, struct ifreq *ifr); -uint
>>>>>> fec_ptp_check_pps_event(struct fec_enet_private *fep);
>>>>>>
>>>>>>
>>>>>>
>>>>
>/**********************************************************
>>>>>> ******************/
>>>>>> #endif /* FEC_H */
>>>>>> diff --git a/drivers/net/ethernet/freescale/fec_main.c
>>>>>> b/drivers/net/ethernet/freescale/fec_main.c
>>>>>> index 3dc2d771a222..21afabbc560f 100644
>>>>>> --- a/drivers/net/ethernet/freescale/fec_main.c
>>>>>> +++ b/drivers/net/ethernet/freescale/fec_main.c
>>>>>> @@ -1602,10 +1602,6 @@ fec_enet_interrupt(int irq, void *dev_id)
>>>>>> ret = IRQ_HANDLED;
>>>>>> complete(&fep->mdio_done);
>>>>>> }
>>>>>> -
>>>>>> - if (fep->ptp_clock)
>>>>>> - if (fec_ptp_check_pps_event(fep))
>>>>>> - ret = IRQ_HANDLED;
>>>>>> return ret;
>>>>>> }
>>>>>>
>>>>>> @@ -3325,6 +3321,8 @@ fec_probe(struct platform_device *pdev)
>>>>>> struct device_node *np = pdev->dev.of_node, *phy_node;
>>>>>> int num_tx_qs;
>>>>>> int num_rx_qs;
>>>>>> + char irq_name[8];
>>>>>> + int irq_cnt;
>>>>>>
>>>>>> fec_enet_get_queue_num(pdev, &num_tx_qs, &num_rx_qs);
>>>>>>
>>>>>> @@ -3465,18 +3463,27 @@ fec_probe(struct platform_device *pdev)
>>>>>> if (ret)
>>>>>> goto failed_reset;
>>>>>>
>>>>>> + irq_cnt = platform_irq_count(pdev);
>>>>>> + if (irq_cnt > FEC_IRQ_NUM)
>>>>>> + irq_cnt = FEC_IRQ_NUM; /* last for ptp */
>>>>>> + else if (irq_cnt == 2)
>>>>>> + irq_cnt = 1; /* last for ptp */
>>>>>> + else if (irq_cnt <= 0)
>>>>>> + irq_cnt = 1; /* Let the for loop fail */
>>>>>
>>>>> Don't do like this. Don't suppose pps interrupt is the last one.
>>>>
>>>>
>>>> I don't. If the pps interrupt is named, the named interrupt will be
>>>> used. If it is NOT named, the last interrupt is used, if 2
>>>> interrupts, or >3 interrupt are provided.
>>>> Otherwise, no pps interrupt is assumed.
>>>> Fortunately this seems to be true currently.
>>>>
>>> If pps interrupt is not named, then it limit the last one is pps.
>>> We cannot get the pps interrupt based on current chip interrupt define,
>we never know the future chip how to define interrupt.
>>> Although your current implementation can work with current chips, but it is
>not really good solution.
>>>
>>>>
>>>>> And if irq_cnt is 1 like imx28/imx5x, the patch will break fec
>>>>> interrupt
>>>> function.
>>>>
>>>> How ? fec_ptp_init will not be called as bufdesc_ex is 0.
>>>>
>>> Imx28 also support enhanced buffer descriptor, if define the ptp clock in
>dts then bufdesc_ex also can be 1.
>>
>>
>> Only if FEC_QUIRK_HAS_BUFDESC_EX is set, which it is not. Here's the
>> relevant code snippets
>>
>> }, {
>> .name = "imx25-fec",
>> .driver_data = FEC_QUIRK_USE_GASKET |
>FEC_QUIRK_MIB_CLEAR,
>> }, {
>> .name = "imx27-fec",
>> .driver_data = FEC_QUIRK_MIB_CLEAR,
>> }, {
>> .name = "imx28-fec",
>> .driver_data = FEC_QUIRK_ENET_MAC |
>FEC_QUIRK_SWAP_FRAME |
>> FEC_QUIRK_SINGLE_MDIO |
>FEC_QUIRK_HAS_RACC,
>> }, {
>>
>> ....
>> fep->bufdesc_ex = fep->quirks & FEC_QUIRK_HAS_BUFDESC_EX;
>> fep->clk_ptp = devm_clk_get(&pdev->dev, "ptp");
>> if (IS_ERR(fep->clk_ptp)) {
>> fep->clk_ptp = NULL;
>> fep->bufdesc_ex = false;
>> }
>> ______________
>>
>> You could make your way work though, if you remove the pps clock from
>> imx50.dtsi, imx51.dtsi, and imx53.dtsi.
>
>
>Whoops I meant "ptp" clock.
>
>That brings up a question though.
>
>interrupt-names = "int0", "int1", "int2", "pps"
>
>may be more accurate. Is there any desire for me to use "pps" instead ?
>
I agree this named method.
Set the property "interrupt-names" is optional properties that don't break other platforms.
^ permalink raw reply
* pull request: bluetooth-next 2017-10-19
From: Johan Hedberg @ 2017-10-19 6:29 UTC (permalink / raw)
To: davem; +Cc: linux-bluetooth, netdev
[-- Attachment #1: Type: text/plain, Size: 4613 bytes --]
Hi Dave,
Here's the first bluetooth-next pull request targeting the 4.15 kernel
release.
- Multiple fixes & improvements to the hci_bcm driver
- DT improvements, e.g. new local-bd-address property
- Fixes & improvements to ECDH usage. Private key is now generated by
the crypto subsystem.
- gcc-4.9 warning fixes
Please let me know if there are any issues pulling. Thanks.
Johan
---
The following changes since commit 4bc4e64c2cfdafa6b8ecdcc5edf10cc1a147587f:
Merge tag 'batadv-next-for-davem-20171006' of git://git.open-mesh.org/linux-merge (2017-10-06 10:12:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream
for you to fetch changes up to fac72b243cc789bb209e6eca824919b42d98cfe2:
Bluetooth: mark expected switch fall-throughs (2017-10-14 09:25:51 +0200)
----------------------------------------------------------------
Arnd Bergmann (3):
ieee802154: fix gcc-4.9 warnings
Bluetooth: hci_bcm: fix build error without CONFIG_PM
Bluetooth: BT_HCIUART now depends on SERIAL_DEV_BUS
Arvind Yadav (1):
Bluetooth: btmrvl: *_err() and *_info() strings should end with newlines
Gustavo A. R. Silva (1):
Bluetooth: mark expected switch fall-throughs
Hans de Goede (12):
Bluetooth: hci_uart_set_flow_control: Fix NULL deref when using serdev
Bluetooth: hci_bcm: Fix setting of irq trigger type
Bluetooth: hci_bcm: Move bcm_platform_probe call out of bcm_acpi_probe
Bluetooth: hci_bcm: Move platform_get_irq call to bcm_probe
Bluetooth: hci_bcm: Store device pointer instead of platform_device pointer
Bluetooth: hci_bcm: Rename bcm_platform_probe to bcm_get_resources
Bluetooth: hci_bcm: Make acpi_probe get irq from ACPI resources
Bluetooth: hci_bcm: Make suspend/resume functions platform_dev independent
Bluetooth: hci_bcm: Add (runtime)pm support to the serdev driver
Bluetooth: btbcm: Add entry for BCM4356A2 UART bluetooth
Bluetooth: hci_bcm: Add support for BCM2E7E
Revert "Bluetooth: btusb: Add workaround for Broadcom devices without product id"
Ian W MORRISON (3):
Bluetooth: hci_bcm: Correct context of IRQ polarity message
Bluetooth: hci_bcm: Add support for MINIX Z83-4 based devices
Bluetooth: btbcm: Add support for MINIX Z83-4 based devices
Johan Hovold (1):
Bluetooth: avoid silent hci_bcm ACPI PM regression
Kees Cook (1):
Bluetooth: Convert timers to use timer_setup()
Loic Poulain (4):
Bluetooth: btqcomsmd: Add support for BD address setup
dt-bindings: net: document Bluetooth bindings in one place
dt-bindings: soc: qcom: Add local-bd-address property to WCNSS-BT
Bluetooth: btqcomsmd: retrieve BD address from DT property
Marcel Holtmann (1):
Bluetooth: Fix compiler warning with selftest duration calculation
Tudor Ambarus (5):
Bluetooth: move ecdh allocation outside of ecdh_helper
Bluetooth: ecdh_helper - reveal error codes
Bluetooth: selftest - check for errors when computing ZZ
Bluetooth: ecdh_helper - fix leak of private key
Bluetooth: let the crypto subsystem generate the ecc privkey
.../devicetree/bindings/net/bluetooth.txt | 5 +
.../devicetree/bindings/soc/qcom/qcom,wcnss.txt | 8 +
drivers/bluetooth/Kconfig | 3 +-
drivers/bluetooth/bcm203x.c | 2 +-
drivers/bluetooth/bluecard_cs.c | 7 +-
drivers/bluetooth/btbcm.c | 3 +
drivers/bluetooth/btmrvl_sdio.c | 6 +-
drivers/bluetooth/btqcomsmd.c | 45 ++++
drivers/bluetooth/btusb.c | 18 --
drivers/bluetooth/hci_bcm.c | 263 ++++++++++++---------
drivers/bluetooth/hci_bcsp.c | 10 +-
drivers/bluetooth/hci_h5.c | 10 +-
drivers/bluetooth/hci_ldisc.c | 7 +
drivers/bluetooth/hci_ll.c | 2 +-
drivers/bluetooth/hci_qca.c | 17 +-
drivers/net/ieee802154/ca8210.c | 2 +-
net/bluetooth/ecdh_helper.c | 228 +++++++++---------
net/bluetooth/ecdh_helper.h | 9 +-
net/bluetooth/selftest.c | 48 +++-
net/bluetooth/smp.c | 127 ++++++----
20 files changed, 487 insertions(+), 333 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/bluetooth.txt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v7 02/10] arm: dts: sunxi: Restore EMAC changes
From: Maxime Ripard @ 2017-10-19 6:57 UTC (permalink / raw)
To: Corentin Labbe
Cc: Andrew Lunn, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171018185049.GA24584@Red>
[-- Attachment #1: Type: text/plain, Size: 4413 bytes --]
On Wed, Oct 18, 2017 at 08:50:49PM +0200, Corentin Labbe wrote:
> On Wed, Oct 18, 2017 at 06:44:50PM +0200, Andrew Lunn wrote:
> > On Wed, Oct 18, 2017 at 01:44:50PM +0200, Corentin Labbe wrote:
> > > The original dwmac-sun8i DT bindings have some issue on how to handle
> > > integrated PHY and was reverted in last RC of 4.13.
> > > But now we have a solution so we need to get back that was reverted.
> > >
> > > This patch restore arm DT about dwmac-sun8i
> > > This reverts commit fe45174b72ae ("arm: dts: sunxi: Revert EMAC changes")
> > >
> > > Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > ---
> > > arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 9 ++++++++
> > > arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts | 19 +++++++++++++++++
> > > arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts | 19 +++++++++++++++++
> > > arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 7 ++++++
> > > arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 +++++++
> > > arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 +++++++
> > > arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts | 5 +++++
> > > arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 +++++++
> > > arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 22 +++++++++++++++++++
> > > arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts | 16 ++++++++++++++
> > > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 26 +++++++++++++++++++++++
> > > 11 files changed, 147 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> > > index b1502df7b509..6713d0f2b3f4 100644
> > > --- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> > > +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> > > @@ -56,6 +56,8 @@
> > >
> > > aliases {
> > > serial0 = &uart0;
> > > + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
> > > + ethernet0 = &emac;
> > > ethernet1 = &xr819;
> > > };
> > >
> > > @@ -102,6 +104,13 @@
> > > status = "okay";
> > > };
> > >
> > > +&emac {
> > > + phy-handle = <&int_mii_phy>;
> > > + phy-mode = "mii";
> > > + allwinner,leds-active-low;
> > > + status = "okay";
> > > +};
> > > +
> > > &mmc0 {
> > > pinctrl-names = "default";
> > > pinctrl-0 = <&mmc0_pins_a>;
> > > diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
> > > index e1dba9ffa94b..f2292deaa590 100644
> > > --- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
> > > +++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
> > > @@ -52,6 +52,7 @@
> > > compatible = "sinovoip,bpi-m2-plus", "allwinner,sun8i-h3";
> > >
> > > aliases {
> > > + ethernet0 = &emac;
> > > serial0 = &uart0;
> > > serial1 = &uart1;
> > > };
> > > @@ -111,6 +112,24 @@
> > > status = "okay";
> > > };
> > >
> > > +&emac {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&emac_rgmii_pins>;
> > > + phy-supply = <®_gmac_3v3>;
> > > + phy-handle = <&ext_rgmii_phy>;
> > > + phy-mode = "rgmii";
> > > +
> > > + allwinner,leds-active-low;
> > > + status = "okay";
> > > +};
> > > +
> >
> >
> > > +&external_mdio {
> > > + ext_rgmii_phy: ethernet-phy@1 {
> > > + compatible = "ethernet-phy-ieee802.3-c22";
> > > + reg = <0>;
> > > + };
> > > +};
> > > +
> >
> > Hi Corentin
> >
> > I'm wondering about the order of the patches. Does the external_mdio
> > node actually exist at this point? Or only later when other patches
> > are applied?
> >
>
> You are right order of patch are wrong, I need to cut this one in two.
> "Revert²" sunxi-h3-h5.dtsi
> apply mdiomux
> "Revert²" all board nodes
I'm not even sure why you're actually adding them that way. Can't you
just create the new binding file, support it in the driver, and add
the matching DT nodes ?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] spectrum: Convert fib event handlers to use container_of on info arg
From: Jiri Pirko @ 2017-10-19 7:09 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, jiri, idosch
In-Reply-To: <1508364098-29621-1-git-send-email-dsahern@gmail.com>
Thu, Oct 19, 2017 at 12:01:38AM CEST, dsahern@gmail.com wrote:
>Use container_of to convert the generic fib_notifier_info into
>the event specific data structure.
>
>Signed-off-by: David Ahern <dsahern@gmail.com>
>Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* [PATCH net-next] ipv6: let trace_fib6_table_lookup() dereference the fib table
From: Paolo Abeni @ 2017-10-19 7:31 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Steven Rostedt, Ingo Molnar, David Ahern
The perf traces for ipv6 routing code show a relevant cost around
trace_fib6_table_lookup(), even if no trace is enabled. This is
due to the fib6_table de-referencing currently performed by the
caller.
Let's the tracing code pay this overhead, passing to the trace
helper the table pointer. This gives small but measurable
performance improvement under UDP flood.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
include/trace/events/fib6.h | 6 +++---
net/ipv6/route.c | 12 ++++++------
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/trace/events/fib6.h b/include/trace/events/fib6.h
index d60096cddb2a..b34bed17abc7 100644
--- a/include/trace/events/fib6.h
+++ b/include/trace/events/fib6.h
@@ -12,9 +12,9 @@
TRACE_EVENT(fib6_table_lookup,
TP_PROTO(const struct net *net, const struct rt6_info *rt,
- u32 tb_id, const struct flowi6 *flp),
+ struct fib6_table *table, const struct flowi6 *flp),
- TP_ARGS(net, rt, tb_id, flp),
+ TP_ARGS(net, rt, table, flp),
TP_STRUCT__entry(
__field( u32, tb_id )
@@ -34,7 +34,7 @@ TRACE_EVENT(fib6_table_lookup,
TP_fast_assign(
struct in6_addr *in6;
- __entry->tb_id = tb_id;
+ __entry->tb_id = table->tb6_id;
__entry->oif = flp->flowi6_oif;
__entry->iif = flp->flowi6_iif;
__entry->tos = ip6_tclass(flp->flowlabel);
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 2e8842fa6450..d638fd993287 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -945,7 +945,7 @@ static struct rt6_info *ip6_pol_route_lookup(struct net *net,
rcu_read_unlock();
- trace_fib6_table_lookup(net, rt, table->tb6_id, fl6);
+ trace_fib6_table_lookup(net, rt, table, fl6);
return rt;
@@ -1670,7 +1670,7 @@ struct rt6_info *ip6_pol_route(struct net *net, struct fib6_table *table,
if (rt == net->ipv6.ip6_null_entry) {
rcu_read_unlock();
dst_hold(&rt->dst);
- trace_fib6_table_lookup(net, rt, table->tb6_id, fl6);
+ trace_fib6_table_lookup(net, rt, table, fl6);
return rt;
} else if (rt->rt6i_flags & RTF_CACHE) {
if (ip6_hold_safe(net, &rt, true)) {
@@ -1678,7 +1678,7 @@ struct rt6_info *ip6_pol_route(struct net *net, struct fib6_table *table,
rt6_dst_from_metrics_check(rt);
}
rcu_read_unlock();
- trace_fib6_table_lookup(net, rt, table->tb6_id, fl6);
+ trace_fib6_table_lookup(net, rt, table, fl6);
return rt;
} else if (unlikely((fl6->flowi6_flags & FLOWI_FLAG_KNOWN_NH) &&
!(rt->rt6i_flags & RTF_GATEWAY))) {
@@ -1714,7 +1714,7 @@ struct rt6_info *ip6_pol_route(struct net *net, struct fib6_table *table,
}
uncached_rt_out:
- trace_fib6_table_lookup(net, uncached_rt, table->tb6_id, fl6);
+ trace_fib6_table_lookup(net, uncached_rt, table, fl6);
return uncached_rt;
} else {
@@ -1742,7 +1742,7 @@ struct rt6_info *ip6_pol_route(struct net *net, struct fib6_table *table,
}
local_bh_enable();
rcu_read_unlock();
- trace_fib6_table_lookup(net, pcpu_rt, table->tb6_id, fl6);
+ trace_fib6_table_lookup(net, pcpu_rt, table, fl6);
return pcpu_rt;
}
}
@@ -2183,7 +2183,7 @@ static struct rt6_info *__ip6_route_redirect(struct net *net,
rcu_read_unlock();
- trace_fib6_table_lookup(net, rt, table->tb6_id, fl6);
+ trace_fib6_table_lookup(net, rt, table, fl6);
return rt;
};
--
2.13.6
^ permalink raw reply related
* [PATCH net 0/2] net: diag: fix a potential security issue
From: Xin Long @ 2017-10-19 7:32 UTC (permalink / raw)
To: network dev; +Cc: davem, Eric Dumazet, Marcelo Ricardo Leitner, Sabrina Dubroca
This patch is to void the potential security issue that the family
or protocol modules are autoloaded when requesting _diag module by
not requesting _diag module if the family or protocol is not added
or registered in sock_diag and inet_diag.
As the repost of the patch '[PATCH net] sock_diag: request _diag
module only when the family or proto has been registered', this
patchset fixes the compiling errors when INET is not set, and
also split into two patches to make it clear to review.
Xin Long (2):
sock_diag: request _diag module only when the family has been
registered
inet_diag: request _diag module only when the proto has been
registered
include/linux/net.h | 1 +
include/net/protocol.h | 1 +
net/core/sock_diag.c | 21 +++++++++++++--------
net/ipv4/inet_diag.c | 3 ++-
net/ipv4/protocol.c | 6 ++++++
net/socket.c | 5 +++++
6 files changed, 28 insertions(+), 9 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH net 1/2] sock_diag: request _diag module only when the family has been registered
From: Xin Long @ 2017-10-19 7:32 UTC (permalink / raw)
To: network dev; +Cc: davem, Eric Dumazet, Marcelo Ricardo Leitner, Sabrina Dubroca
In-Reply-To: <cover.1508398111.git.lucien.xin@gmail.com>
Now when using 'ss' in iproute, kernel would try to load all _diag
modules. It causes the corresponding family or proto modules to be
loaded as well.
Like after 'ss -a', sctp, dccp, af_packet(if it works as a moudle)
will be loaded.
As these family or proto modules are loaded unexpectly, this might
have some security implications.
This patch is to introduce sock_diag_request_module() in sock_diag
where we only request _diag module when it's corresponding family
has been registered. The fix for inet_diag will be done in later
patch.
Note that we can't just load _diag module without the family or
proto loaded, as some symbols in _diag module are from the family
or proto moudle.
Fixes: 8ef874bfc729 ("sock_diag: Move the sock_ code to net/core/")
Reported-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/linux/net.h | 1 +
net/core/sock_diag.c | 21 +++++++++++++--------
net/socket.c | 5 +++++
3 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/include/linux/net.h b/include/linux/net.h
index d97d80d..6c7cf09 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -225,6 +225,7 @@ enum {
int sock_wake_async(struct socket_wq *sk_wq, int how, int band);
int sock_register(const struct net_proto_family *fam);
void sock_unregister(int family);
+bool sock_is_registered(int family);
int __sock_create(struct net *net, int family, int type, int proto,
struct socket **res, int kern);
int sock_create(int family, int type, int proto, struct socket **res);
diff --git a/net/core/sock_diag.c b/net/core/sock_diag.c
index 217f4e3..643a446 100644
--- a/net/core/sock_diag.c
+++ b/net/core/sock_diag.c
@@ -207,6 +207,15 @@ void sock_diag_unregister(const struct sock_diag_handler *hnld)
}
EXPORT_SYMBOL_GPL(sock_diag_unregister);
+static int sock_diag_request_module(int family)
+{
+ if (!sock_is_registered(family))
+ return -ENOENT;
+
+ return request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
+ NETLINK_SOCK_DIAG, family);
+}
+
static int __sock_diag_cmd(struct sk_buff *skb, struct nlmsghdr *nlh)
{
int err;
@@ -220,8 +229,7 @@ static int __sock_diag_cmd(struct sk_buff *skb, struct nlmsghdr *nlh)
return -EINVAL;
if (sock_diag_handlers[req->sdiag_family] == NULL)
- request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
- NETLINK_SOCK_DIAG, req->sdiag_family);
+ sock_diag_request_module(req->sdiag_family);
mutex_lock(&sock_diag_table_mutex);
hndl = sock_diag_handlers[req->sdiag_family];
@@ -247,8 +255,7 @@ static int sock_diag_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,
case TCPDIAG_GETSOCK:
case DCCPDIAG_GETSOCK:
if (inet_rcv_compat == NULL)
- request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
- NETLINK_SOCK_DIAG, AF_INET);
+ sock_diag_request_module(AF_INET);
mutex_lock(&sock_diag_table_mutex);
if (inet_rcv_compat != NULL)
@@ -281,14 +288,12 @@ static int sock_diag_bind(struct net *net, int group)
case SKNLGRP_INET_TCP_DESTROY:
case SKNLGRP_INET_UDP_DESTROY:
if (!sock_diag_handlers[AF_INET])
- request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
- NETLINK_SOCK_DIAG, AF_INET);
+ sock_diag_request_module(AF_INET);
break;
case SKNLGRP_INET6_TCP_DESTROY:
case SKNLGRP_INET6_UDP_DESTROY:
if (!sock_diag_handlers[AF_INET6])
- request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
- NETLINK_SOCK_DIAG, AF_INET);
+ sock_diag_request_module(AF_INET);
break;
}
return 0;
diff --git a/net/socket.c b/net/socket.c
index c729625..733d657 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2590,6 +2590,11 @@ void sock_unregister(int family)
}
EXPORT_SYMBOL(sock_unregister);
+bool sock_is_registered(int family)
+{
+ return family < NPROTO && rcu_access_pointer(net_families[family]);
+}
+
static int __init sock_init(void)
{
int err;
--
2.1.0
^ permalink raw reply related
* [PATCH net 2/2] inet_diag: request _diag module only when the proto has been registered
From: Xin Long @ 2017-10-19 7:32 UTC (permalink / raw)
To: network dev; +Cc: davem, Eric Dumazet, Marcelo Ricardo Leitner, Sabrina Dubroca
In-Reply-To: <cover.1508398111.git.lucien.xin@gmail.com>
The patch 'sock_diag: request _diag module only when the family has
been registered' fixed a security issue for sock_diag, the same fix
is needed for inet_diag module when requesting _diag module.
Fixes: 305e1e969114 ("[INET]: Let inet_diag and friends autoload")
Reported-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/net/protocol.h | 1 +
net/ipv4/inet_diag.c | 3 ++-
net/ipv4/protocol.c | 6 ++++++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/net/protocol.h b/include/net/protocol.h
index 4fc75f7..bf0dcc2 100644
--- a/include/net/protocol.h
+++ b/include/net/protocol.h
@@ -103,6 +103,7 @@ extern struct inet6_protocol __rcu *inet6_protos[MAX_INET_PROTOS];
int inet_add_protocol(const struct net_protocol *prot, unsigned char num);
int inet_del_protocol(const struct net_protocol *prot, unsigned char num);
+bool inet_proto_is_added(unsigned char num);
int inet_add_offload(const struct net_offload *prot, unsigned char num);
int inet_del_offload(const struct net_offload *prot, unsigned char num);
void inet_register_protosw(struct inet_protosw *p);
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index c9c35b6..1460031 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -27,6 +27,7 @@
#include <net/inet_hashtables.h>
#include <net/inet_timewait_sock.h>
#include <net/inet6_hashtables.h>
+#include <net/protocol.h>
#include <net/netlink.h>
#include <linux/inet.h>
@@ -52,7 +53,7 @@ static DEFINE_MUTEX(inet_diag_table_mutex);
static const struct inet_diag_handler *inet_diag_lock_handler(int proto)
{
- if (!inet_diag_table[proto])
+ if (!inet_diag_table[proto] && inet_proto_is_added(proto))
request_module("net-pf-%d-proto-%d-type-%d-%d", PF_NETLINK,
NETLINK_SOCK_DIAG, AF_INET, proto);
diff --git a/net/ipv4/protocol.c b/net/ipv4/protocol.c
index 32a691b..183386a 100644
--- a/net/ipv4/protocol.c
+++ b/net/ipv4/protocol.c
@@ -77,3 +77,9 @@ int inet_del_offload(const struct net_offload *prot, unsigned char protocol)
return ret;
}
EXPORT_SYMBOL(inet_del_offload);
+
+bool inet_proto_is_added(unsigned char protocol)
+{
+ return !!rcu_access_pointer(inet_protos[protocol]);
+}
+EXPORT_SYMBOL(inet_proto_is_added);
--
2.1.0
^ permalink raw reply related
* RE: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates
From: Ramesh Shanmugasundaram @ 2017-10-19 8:04 UTC (permalink / raw)
To: Sekhar Nori, Marc Kleine-Budde, Franklin S Cooper Jr,
Mario Hüttel, Yang, Wenyou, wg@grandegger.com,
socketcan@hartkopp.net, quentin.schulz@free-electrons.com,
edumazet@google.com, linux-can@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Wenyou Yang, Dong Aisheng, Quadros, Roger
In-Reply-To: <7ba515d9-7710-c152-a55a-f995b7f3d49a@ti.com>
> >>>>>>> On 08/18/2017 02:39 PM, Franklin S Cooper Jr wrote:
> >>>>>>>> During test transmitting using CAN-FD at high bitrates (4 Mbps)
> >>>>>>>> only resulted in errors. Scoping the signals I noticed that
> >>>>>>>> only a single bit was being transmitted and with a bit more
> >>>>>>>> investigation realized the actual MCAN IP would go back to
> >>>>>>>> initialization mode automatically.
> >>>>>>>>
> >>>>>>>> It appears this issue is due to the MCAN needing to use the
> >>>>>>>> Transmitter Delay Compensation Mode as defined in the MCAN
> >>>>>>>> User's Guide. When this mode is used the User's Guide indicates
> >>>>>>>> that the Transmitter Delay Compensation Offset register should
> >>>>>>>> be set. The document mentions that this register should be set
> >>>>>>>> to (1/dbitrate)/2*(Func Clk Freq).
> >>>>>>>>
> >>>>>>>> Additional CAN-CIA's "Bit Time Requirements for CAN FD"
> >>>>>>>> document indicates that this TDC mode is only needed for data
> >>>>>>>> bit rates above 2.5 Mbps.
> >>>>>>>> Therefore, only enable this mode and only set TDCO when the
> >>>>>>>> data bit rate is above 2.5 Mbps.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> >>>>>>>> ---
> >>>>>>>> I'm pretty surprised that this hasn't been implemented already
> >>>>>>>> since the primary purpose of CAN-FD is to go beyond 1 Mbps and
> >>>>>>>> the MCAN IP supports up to 10 Mbps.
> >>>>>>>>
> >>>>>>>> So it will be nice to get comments from users of this driver to
> >>>>>>>> understand if they have been able to use CAN-FD beyond 2.5 Mbps
> >>>>>>>> without this patch.
> >>>>>>>> If they haven't what did they do to get around it if they
> >>>>>>>> needed higher speeds.
> >>>>>>>>
> >>>>>>>> Meanwhile I plan on testing this using a more "realistic" CAN
> >>>>>>>> bus to insure everything still works at 5 Mbps which is the max
> >>>>>>>> speed of my CAN transceiver.
> >>>>>>> ping. Anyone has any thoughts on this?
> >>>>>> I added Dong who authored the m_can driver and Wenyou who added
> >>>>>> the only in-kernel user of the driver for any help.
> >>>>> I tested it on SAMA5D2 Xplained board both with and without this
> >>>>> patch, both work with the 4M bps data bit rate.
> >>>> Thank you for testing this out. Its interesting that you have been
> >>>> able to use higher speeds without this patch. What is the CAN
> >>>> transceiver being used on the SAMA5D2 Xplained board? I tried
> >>>> looking at the schematic but it seems the CAN signals are used on
> >>>> an extension board which I can't find the schematic for. Also do
> >>>> you mind sharing your test setup? Were you doing a short point to
> point test?
> >>>>
> >>>> Thank You,
> >>>> Franklin
> >>> Hello Franklin,
> >>>
> >>> your patch definitely makes sense.
> >>>
> >>> I forgot the TDC in my patches because it was not present in the
> >>> previous driver versions and because I didn't encounter any problems
> >>> when testing it myself.
> >>>
> >>> The error is highly dependent on the hardware (transceiver) setup.
> >>> So it is definitely possible that some people don't encounter errors
> >>> without your patch.
> >>
> >> So the Transmission Delay Compensation feature Value register is
> >> suppose to take into consideration the transceiver delay
> >> automatically and add the value of TDCO on top of that. So why would
> >> TDCO be dependent on the transceiver? I've heard conflicting things
> >> regarding TDC so any clarification on what actually impacts it would be
> appreciated.
> >>
> >> Also part of the issue I'm having is how can we properly configure
> TDCO?
> >> Configuring TDCO is essentially figuring out what Secondary Sample
> >> Point to use. However, it is unclear what value to set SSP to and
> >> which use cases a given SSP will work or doesn't work. I've seen
> >> various recommendations from Bosch on choosing SSP but ultimately it
> >> seems they suggestion "real world testing" to come up with a proper
> >> value. Not setting TDCO causes problems for my device and improperly
> >> setting TDCO causes problems for my device. So its likely any value I
> >> use could end up breaking something for someone else.
> >>
> >> Currently I leaning to a DT property that can be used for setting SSP.
> >> Perhaps use a generic default value and allow individuals to override
> >> it via DT?
> >
> > Sounds reasonable. What's the status of this series?
>
> I have had some offline discussions with Franklin on this, and I am not
> fully convinced that DT is the way to go here (although I don't have the
> agreement with Franklin there).
>
> There are two components in configuring the secondary sample point. It is
> the transceiver loopback delay and an offset (example half of the bit time
> in data phase).
>
> While the transceiver loopback delay is pretty board dependent (and thus
> amenable to DT encoding), I am not quite sure the offset can be configured
> in DT because its not really board dependent.
>
> Unfortunately, offset calculation does not seem to be an exact science.
> There are recommendations ranging from using 50% of bit time to making it
> same as the sample point configured. This means users who need to change
> the SSP due to offset variations need to change their DT even without
> anything changing on their board.
>
> Since we have a netlink socket interface to configure sample point, I
> wonder if that should be extended to configure SSP too (or at least the
> offset part of SSP)?
+1
I also wonder how a default TDCO setting in DT would help. Is the driver going to hard code the Tq settings as well for the most commonly used bitrate? A link up start-up script (using netlink) would help setting a default TDCO along with other params if this is the main concern.
Thanks,
Ramesh
^ permalink raw reply
* [PATCH iproute2] ip maddr: fix filtering by device
From: Michal Kubecek @ 2017-10-19 8:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Petr Vorel, Phil Sutter
Commit 530903dd9003 ("ip: fix igmp parsing when iface is long") uses
variable len to keep trailing colon from interface name comparison. This
variable is local to loop body but we set it in one pass and use it in
following one(s) so that we are actually using (pseudo)random length for
comparison. This became apparent since commit b48a1161f5f9 ("ipmaddr: Avoid
accessing uninitialized data") always initializes len to zero so that the
name comparison is always true. As a result, "ip maddr show dev eth0" shows
IPv4 multicast addresses for all interfaces.
Instead of keeping the length, let's simply replace the trailing colon with
a null byte. The bonus is that we get correct interface name in ma.name.
Fixes: 530903dd9003 ("ip: fix igmp parsing when iface is long")
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
ip/ipmaddr.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/ip/ipmaddr.c b/ip/ipmaddr.c
index 5683f6fa830c..46b86a3a7723 100644
--- a/ip/ipmaddr.c
+++ b/ip/ipmaddr.c
@@ -136,17 +136,18 @@ static void read_igmp(struct ma_info **result_p)
while (fgets(buf, sizeof(buf), fp)) {
struct ma_info *ma;
- size_t len = 0;
if (buf[0] != '\t') {
+ size_t len;
+
sscanf(buf, "%d%s", &m.index, m.name);
len = strlen(m.name);
if (m.name[len - 1] == ':')
- len--;
+ m.name[len - 1] = '\0';
continue;
}
- if (filter.dev && strncmp(filter.dev, m.name, len))
+ if (filter.dev && strcmp(filter.dev, m.name))
continue;
sscanf(buf, "%08x%d", (__u32 *)&m.addr.data, &m.users);
--
2.14.2
^ permalink raw reply related
* Re: usb/net/rt2x00: warning in rt2800_eeprom_word_index
From: Dmitry Vyukov @ 2017-10-19 8:25 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Andrey Konovalov, Helmut Schaa, Kalle Valo, linux-wireless,
netdev, LKML, Kostya Serebryany, syzkaller
In-Reply-To: <CACT4Y+YB7PTCFCjeqwJeGpSxxAh_U6F6UsDKaN4XAx6uL8+pZw@mail.gmail.com>
On Mon, Oct 16, 2017 at 2:19 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Mon, Oct 16, 2017 at 11:40 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> Hi Dmitry
>>
>> On Sat, Oct 14, 2017 at 04:38:03PM +0200, Dmitry Vyukov wrote:
>>> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>>> > Hi
>>> >
>>> > On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
>>> >> I've got the following report while fuzzing the kernel with syzkaller.
>>> >>
>>> >> On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
>>> >>
>>> >> I'm not sure whether this is a bug in the driver, or just a way to
>>> >> report misbehaving device. In the latter case this shouldn't be a
>>> >> WARN() call, since WARN() means bug in the kernel.
>>> >
>>> > This is about wrong EEPROM, which reported 3 tx streams on
>>> > non 3 antenna device. I think WARN() is justified and thanks
>>> > to the call trace I was actually able to to understand what
>>> > happened.
>>> >
>>> > In general I do not think WARN() only means a kernel bug, it
>>> > can be F/W or H/W bug too.
>>>
>>> Hi Stanislaw,
>>>
>>> Printing messages is fine. Printing stacks is fine. Just please make
>>> them distinguishable from kernel bugs and don't kill the whole
>>> possibility of automated Linux kernel testing. That's an important
>>> capability.
>>
>> We do not distinguish between bugs and other problems when WARN() is
>> used in (wireless) drivers, what I think is correct, taking comment from
>> include/asm-generic/bug.h :
>>
>> /*
>> * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
>> * significant issues that need prompt attention if they should ever
>> * appear at runtime. Use the versions with printk format strings
>> * to provide better diagnostics.
>> */
>>
>> Historically we have BUG() to mark the bugs, but usage if it is not
>> recommended as it can kill the system, so for anything that can
>> be recovered in runtime - WARN() is recommended.
>>
>> Perhaps we can introduce another helper like PROBLEM() for marking
>> situations when something is wrong, but it is not a bug. However I'm
>> not even sure at what extent it can be used, since for many cases
>> if not the most, driver author can not tell apriori if the problem
>> is a bug in the driver or HW/FW misbehaviour (or maybe particular
>> issue can happen because of both).
>
> I will write a separate email to LKML.
Sent a mail titled "Distinguishing kernel bugs from invalid inputs" to
LKML. Here is a copy:
https://groups.google.com/forum/#!topic/syzkaller/dGh7qtbu14Q
^ 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