Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] mac80211_hwsim: release driver when ieee80211_register_hw fails
From: Johannes Berg @ 2014-10-29 15:31 UTC (permalink / raw)
  To: Junjie Mao
  Cc: Martin Pitt, Fengguang Wu, linux-wireless, netdev, linux-kernel
In-Reply-To: <1414459907-7509-1-git-send-email-eternal.n08@gmail.com>

On Tue, 2014-10-28 at 09:31 +0800, Junjie Mao wrote:
> The driver is not released when ieee80211_register_hw fails in
> mac80211_hwsim_create_radio, leading to the access to the unregistered (and
> possibly freed) device in platform_driver_unregister:

Applied.

johannes

^ permalink raw reply

* Re: [PATCH net-next] net: introduce napi_schedule_irqoff()
From: Alexei Starovoitov @ 2014-10-29 15:26 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1414563627.631.75.camel@edumazet-glaptop2.roam.corp.google.com>

On Tue, Oct 28, 2014 at 11:20 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-10-28 at 22:13 -0700, Alexei Starovoitov wrote:
>
>> tried 50 parallel netperf -t TCP_RR over ixgbe
>> and perf top were tcp stack bits, qdisc locks and netperf itself.
>> What do you see?
>
> You are kidding right ?
>
> If you save 30 nsec ( 2 * 15 nsec) per transaction, and rtt is about 20
> usec, its a 0.15 % gain. Not bad for a trivial patch.

agreed.
I wasn't arguing against the patch at all. Was just curious
what performance gain we'll see. 0.15% is tiny and some might
say the code bloat is not worth it, but imo it's a good one. ack.

> Every atomic op we remove/avoid, every irq masking unmasking we remove,
> every cache line miss or extra bus transaction we remove, TLB miss, is
> the path for better latency.

yes. We're saying the same thing.

^ permalink raw reply

* Re: some failures with vxlan offloads..
From: Tom Herbert @ 2014-10-29 14:59 UTC (permalink / raw)
  To: Or Gerlitz; +Cc: netdev@vger.kernel.org
In-Reply-To: <54508020.1040305@mellanox.com>

On Tue, Oct 28, 2014 at 10:50 PM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> On 10/28/2014 5:36 PM, Tom Herbert wrote:
>>>
>>> I wonder if we have another bug somewhere... when both sides were
>>> offloaded,
>>> >it works even with the mlx4 bug, canyou explain that?is it possible that
>>> > the
>>> >GRO stack somehow covers on the bug when both sides are offloaded and
>>> >GRO/VXLAN comes into play?
>>>
>> Look at the receive side. As I mentioned, if the device is returning
>> checksum-unnecessary and setting csum_level to 1 (inner checksum was
>> validated) then stack won't try to verify the outer checksum. So in
>> this case if outer checksum is incorrect nobody complains about it.
>
>
> OK, I'll look there. Anything that should worries us at that stack trace I
> sent in my initial email of this thread, or you think this is related to the
> mlx4 driver checksum bug?
>
The trace doesn't seem like it would be related to a checksum bug. Do
you only see this with offload enabled?

> Or.
>
>>
>

^ permalink raw reply

* [RFC] use smp_load_acquire()/smp_store_release()
From: Eric Dumazet @ 2014-10-29 14:49 UTC (permalink / raw)
  To: Alexander Duyck; +Cc: netdev, Stephen Ko

Hi Alexander

The memory barriers added in commit
b37c0fbe3f6dfba1f8ad2aed47fb40578a254635
("net: Add memory barriers to prevent possible race in byte queue
limits")

have heavy cost.

It seems we could use smp_load_acquire() and smp_store_release()
instead ?

I'll post a patch later today. I would be interested if someone was able
to test it, as your commit apparently was tested and known to fix a
reproducible race.

Thanks !

^ permalink raw reply

* Re: [PATCH v2 net-next] net: ipv6: Add a sysctl to make optimistic addresses useful candidates
From: Hannes Frederic Sowa @ 2014-10-29 14:37 UTC (permalink / raw)
  To: Erik Kline; +Cc: netdev, davem, ben, lorenzo
In-Reply-To: <1414487474-18201-1-git-send-email-ek@google.com>

On Di, 2014-10-28 at 18:11 +0900, Erik Kline wrote:
> Add a sysctl that causes an interface's optimistic addresses
> to be considered equivalent to other non-deprecated addresses
> for source address selection purposes.  Preferred addresses
> will still take precedence over optimistic addresses, subject
> to other ranking in the source address selection algorithm.
> 
> This is useful where different interfaces are connected to
> different networks from different ISPs (e.g., a cell network
> and a home wifi network).
> 
> The current behaviour complies with RFC 3484/6724, and it
> makes sense if the host has only one interface, or has
> multiple interfaces on the same network (same or cooperating
> administrative domain(s), but not in the multiple distinct
> networks case.
> 
> For example, if a mobile device has an IPv6 address on an LTE
> network and then connects to IPv6-enabled wifi, while the wifi
> IPv6 address is undergoing DAD, IPv6 connections will try use
> the wifi default route with the LTE IPv6 address, and will get
> stuck until they time out.
> 
> Also, because optimistic nodes can receive frames, issue
> an RTM_NEWADDR as soon as DAD starts (with the IFA_F_OPTIMSTIC
> flag appropriately set).  A second RTM_NEWADDR is sent if DAD
> completes (the address flags have changed), otherwise an
> RTM_DELADDR is sent.
> 
> Also: add an entry in ip-sysctl.txt for optimistic_dad.
> 
> Signed-off-by: Erik Kline <ek@google.com>
> ---
>
> [...]
>  
> +static inline bool ipv6_use_optimistic_addr(struct inet6_dev *idev)
> +{
> +#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> +	return idev && idev->cnf.optimistic_dad && idev->cnf.use_optimistic;

Just a small nit: is this idev != NULL check necessary?

Otherwise:
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>

Thanks,
Hannes

^ permalink raw reply

* Re: [PATCH v2 net-next] net: ipv6: Add a sysctl to make optimistic addresses useful candidates
From: Hannes Frederic Sowa @ 2014-10-29 14:34 UTC (permalink / raw)
  To: Erik Kline
  Cc: netdev@vger.kernel.org, David Miller, Ben Hutchings,
	Lorenzo Colitti
In-Reply-To: <CAAedzxptbKLrO_0uPVqXiqOACqNNj9BeeakgB3+t+XxemeN3Sw@mail.gmail.com>

Hi Erik,

On Mi, 2014-10-29 at 18:34 +0900, Erik Kline wrote:
> Given that we spoke about this reduction in the number of netlink messages
> earlier, do you still think it's an issue?

No, it would be nice to have but as this is just a minor detail and
complexity would be too high I am fine with your current solution.

> The end result here is that for listeners on netlink sockets on systems
> that (a) have optimistic dad built-in, (b) have optimistic dad enabled, and
> (c) have use_optimistic set: they'll 2 notifications (with different flags)
> for automatically added addresses on these interfaces.

Ack, I see.

> (Personally, given that we appear to send an RTM_NEWADDR when the address
> gets deprecated (I think), I think sending one on every flag change of
> interest is in keeping with existing behaviour.)

It does make sense, I have no objections.

Bye,
Hannes

^ permalink raw reply

* Re: nfs stalls over loopback interface (no sk_data_ready events?)
From: Jeff Layton @ 2014-10-29 14:21 UTC (permalink / raw)
  To: netdev-u79uwXL29TY76Z2rM5mHXA
  Cc: Christoph Hellwig, Linux NFS Mailing List, Bruce Fields,
	Trond Myklebust
In-Reply-To: <20141027152900.4e81a9d5-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>

On Mon, 27 Oct 2014 15:29:00 -0400
Jeff Layton <jlayton-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org> wrote:

> (sorry for resend -- I got the netdev address wrong)
> 
> Sending this to netdev since I think I've now determined that this is
> not a NFS specific problem. Recently Christoph mentioned that he was
> seeing stalls when running xfstests generic/075 test on NFS over the
> loopback interface with v3.18-rc1-ish kernel.
> 
> The configuration in this case is the nfs server and client on same box
> communicating over the lo interface.
> 
> Here's are tracepoints from a typical request as it's supposed to work:
> 
>        mount.nfs-906   [002] ...1 22711.996969: xprt_transmit: xprt=0xffff8800ce961000 xid=0xa8a34513 status=0
>             nfsd-678   [000] ...1 22711.997082: svc_recv: rq_xid=0xa8a34513 status=164
>             nfsd-678   [000] ..s8 22711.997185: xprt_lookup_rqst: xprt=0xffff8800ce961000 xid=0xa8a34513 status=0
>             nfsd-678   [000] ..s8 22711.997186: xprt_complete_rqst: xprt=0xffff8800ce961000 xid=0xa8a34513 status=140
>             nfsd-678   [000] ...1 22711.997236: svc_send: rq_xid=0xa8a34513 dropme=0 status=144
>             nfsd-678   [000] ...1 22711.997236: svc_process: rq_xid=0xa8a34513 dropme=0 status=144
> 
> ...basically, we send a request to the server. Server picks it up and
> sends the reply, and then the client IDs that reply and processes it.
> This runs along just fine for ~ a minute or so. At some point, the
> client stops seeing replies come in:
> 
>      kworker/2:2-107   [002] ...1 22741.696070: xprt_transmit: xprt=0xffff8800ce961000 xid=0xc3a84513 status=0
>             nfsd-678   [002] .N.1 22741.696917: svc_recv: rq_xid=0xc3a84513 status=208
>             nfsd-678   [002] ...1 22741.699890: svc_send: rq_xid=0xc3a84513 dropme=0 status=262252
>             nfsd-678   [002] ...1 22741.699891: svc_process: rq_xid=0xc3a84513 dropme=0 status=262252
> 
> 
> ...a bit more tracepoint work seems to show that we just stop getting
> sk_data_ready callbacks on the socket at all. I'm not terribly familiar
> with the lower-level socket code, so I figured I'd email here and ask...
> 
> Anyone have insight into why this might be happening?
> 

Looks some change that went into -rc2 has fixed the problem for me.
Christoph, can you confirm that this no longer occurs with -rc2?

-- 
Jeff Layton <jlayton-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH] mac80211_hwsim: release driver when ieee80211_register_hw fails
From: Fengguang Wu @ 2014-10-29 14:14 UTC (permalink / raw)
  To: Junjie Mao
  Cc: Martin Pitt, linux-wireless, netdev, linux-kernel, Dan Carpenter
In-Reply-To: <8638a718ft.fsf@MJJ-LAPTOP.i-did-not-set--mail-host-address--so-tickle-me>

On Wed, Oct 29, 2014 at 06:23:02PM +0800, Junjie Mao wrote:
> I was not familiar with the acquiring/releasing API either, until I met
> with this bug...
> 
> Perhaps we can use static checkers to avoid these issues as early as
> possible. Any suggestions?

CC Dan. His smatch checker might be able (or could be enabled) to
handle the verification of missing device_release_driver() call.

Thanks,
Fengguang

> Martin Pitt <martin.pitt@ubuntu.com> writes:
> 
> > Acked-By: Martin Pitt <martin.pitt@ubuntu.com>
> >
> > Hello Junjie,
> >
> > Junjie Mao [2014-10-28  9:31 +0800]:
> >> The driver is not released when ieee80211_register_hw fails in
> >> mac80211_hwsim_create_radio, leading to the access to the unregistered (and
> >> possibly freed) device in platform_driver_unregister:
> >
> > Many thanks for fixing this! Sorry about that, I don't know these bits
> > very well.
> >
> > Martin

^ permalink raw reply

* Re: spin lock held between 2 process
From: Eric Dumazet @ 2014-10-29 13:39 UTC (permalink / raw)
  To: Chetan C R; +Cc: netdev
In-Reply-To: <CAJ8diHRu+L_kMMfTyPAz+cwTfeQXTOFWm-RBZQzFOp18kO70jQ@mail.gmail.com>

On Wed, 2014-10-29 at 14:32 +0530, Chetan C R wrote:

> Facing this look up issue in 3.4.0 kernel. Any pointers to resolve this issue?
> 

3.4.0 is quite old. You should try newer kernels.

^ permalink raw reply

* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: Florian Westphal @ 2014-10-29 12:23 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20141028.165737.2009356944765978630.davem@davemloft.net>

David Miller <davem@davemloft.net> wrote:
> From: Florian Westphal <fw@strlen.de>
> Date: Sun, 26 Oct 2014 00:38:47 +0200
> 
> > These two patches allow turing on explicit congestion notification
> > based on the destination network.
> > 
> > For example, assuming the default tcp_ecn sysctl '2', the following will
> > enable ecn (tcp_ecn=1 behaviour, i.e. request ecn to be enabled for a
> > tcp connection) for all connections to hosts inside the 192.168.2/24 network:
> > 
> > ip route change 192.168.2.0/24 dev eth0 features ecn
> > 
> > Having a more fine-grained per-route setting can be beneficial for
> > various reasons, for example 1) within data centers, or 2) local ISPs
> > may deploy ECN support for their own video/streaming services [1], etc.
> > 
> > Joint work with Daniel Borkmann, feature suggested by Hannes Frederic Sowa.
> > 
> > The patch to enable this in iproute2 will be posted shortly, it is currently
> > also available here:
> > http://git.breakpoint.cc/cgit/fw/iproute2.git/commit/?h=iproute_features&id=8843d2d8973fb81c78a7efe6d42e3a17d739003e
> > 
> > [1] http://www.ietf.org/proceedings/89/slides/slides-89-tsvarea-1.pdf, p.15
> 
> I don't like how the route metric gives less control than the sysctl.
> 
> If the tcp_ecn cases of '1' and '2' make sense for the sysctl, I do not
> see why they wouldn't make sense for the per-route knob to.
>
> Implement the following policy, if per-route metric is non-zero use it
> instead of the sysctl setting.

I think that if we add a u32 route attr for a new ecn switch we might as well
support full override of the sysctl.

I had a discussion with Daniel Borkmann, and we came up with this
proposal:

- add RTAX_ECN
- if RTAX_ECN attribute present, set RTAX_FEATURE_ECN in RTAX_FEATURES
- in kernel, when RTAX_FEATURE_ECN set, use dst_metric(dst, RTAX_ECN).
- else, if RTAX_FEATURE_ECN unset, use the sysctl as fallback.

It would allow things like sysctl_tcp_ecn=1 and
ip route change some_blackhole dev eth0 ecn 0
ip route change some_network dev eth0 ecn 2
ip route change other dev eth0 ecn 1

We could do that, if you prefer.

I tried to come up with a scenario though, where sysctl_tcp_ecn=0, and
then we want to enable 'passive' ecn for incoming connections only on
a particular route without announcing ecn to the peer. I haven't been
able to find any -- I think if you deem 'route to x' safe for ecn it
might as well be enabled for both initiator and responder.  The original
patch would be sufficient for that.

IOW, is 'ecn from a to b but not b to a' a sensible requirement?

sysctl_tcp_ecn=2 seems just to be a convenience solution/intermediate
step to make the stack ecn-aware by default without too much breakage
risk for users (i.e. instead of having sysctl_tcp_ecn=1 as default).

Unrelated to this patch, but I'd like to see sysctl_tcp_ecn=1 as a
default at one point (almost no routers set CE bit at this time, perhaps
that would change if ecn usage is more widespread).

Thanks!

^ permalink raw reply

* [PATCH 1/1 net-next] ipv6: remove assignment in if condition
From: Fabian Frederick @ 2014-10-29 11:57 UTC (permalink / raw)
  To: linux-kernel
  Cc: Fabian Frederick, David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy, netdev

Do assignment before if condition and test !skb like in rawv6_recvmsg()

Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
 net/ipv6/raw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 896af88..075a0fb 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -548,7 +548,8 @@ static int rawv6_push_pending_frames(struct sock *sk, struct flowi6 *fl6,
 	if (!rp->checksum)
 		goto send;
 
-	if ((skb = skb_peek(&sk->sk_write_queue)) == NULL)
+	skb = skb_peek(&sk->sk_write_queue);
+	if (!skb)
 		goto out;
 
 	offset = rp->offset;
-- 
1.9.3

^ permalink raw reply related

* Re: [PATCH] wireless: rt2x00: add new rt2800usb device
From: Stanislaw Gruszka @ 2014-10-29 11:48 UTC (permalink / raw)
  To: Cyril Brulebois
  Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141029111224.GC29720-xazfMhTT2R0@public.gmane.org>

On Wed, Oct 29, 2014 at 12:12:24PM +0100, Cyril Brulebois wrote:
> Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> (2014-10-29):
> > On Tue, Oct 28, 2014 at 04:42:41PM +0100, Cyril Brulebois wrote:
> > > 0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle
> > > 
> > > References: https://bugs.debian.org/766802
> > > Reported-by: Martin Mokrejs <mmokrejs-08dBlVkRsZWoiTQjSSYKZesEoJ4y9sgM@public.gmane.org>
> > 
> > Was this patch tested by reporter? I would rather see Reported-and-tested-by tag :-)
> 
> The reporter confirmed the following trick worked:
> 
>   # echo rt2800usb >> /etc/modules
>   # echo 'install rt2800usb /sbin/modprobe --ignore-install rt2800usb $CMDLINE_OPTS && echo 1b75 a200 > /sys/bus/usb/drivers/rt2800usb/new_id' > /etc/modprobe.d/ralink.conf
>   # modprobe -r rt2800usb ; modprobe rt2800usb

Ok, that's fine .

Acked-by: Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

^ permalink raw reply

* Re: suspend/resume broken on 3.18-rc2
From: Fabio Estevam @ 2014-10-29 11:47 UTC (permalink / raw)
  To: fugang.duan@freescale.com, Anson Huang
  Cc: Frank.Li@freescale.com, Russell King, Shawn Guo,
	netdev@vger.kernel.org
In-Reply-To: <6278a77cdc594b3488b0ebc043f7d17b@BLUPR03MB373.namprd03.prod.outlook.com>

On Wed, Oct 29, 2014 at 3:46 AM, fugang.duan@freescale.com
<fugang.duan@freescale.com> wrote:

> Hi, Fabio,
>
> I test 3.18.0-rc2, and has some problems:
> - most of time, imx6sx-sdb cannot resume back regardless of nfs or SD rootfs, and power key also cannnot resume back.
> - when do "echo core > /sys/power/pm_test", and then do suspend/resume test, console key can wake up system, but no broken issue found in nfs.

Adding Anson in case he could look into this problem from a power
management perspective.

^ permalink raw reply

* Re: [PATCH] wireless: rt2x00: add new rt2800usb device
From: Cyril Brulebois @ 2014-10-29 11:12 UTC (permalink / raw)
  To: Stanislaw Gruszka
  Cc: Helmut Schaa, John W. Linville, linux-wireless, users, netdev,
	linux-kernel
In-Reply-To: <20141029110214.GB2021@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

Stanislaw Gruszka <sgruszka@redhat.com> (2014-10-29):
> On Tue, Oct 28, 2014 at 04:42:41PM +0100, Cyril Brulebois wrote:
> > 0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle
> > 
> > References: https://bugs.debian.org/766802
> > Reported-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
> 
> Was this patch tested by reporter? I would rather see Reported-and-tested-by tag :-)

The reporter confirmed the following trick worked:

  # echo rt2800usb >> /etc/modules
  # echo 'install rt2800usb /sbin/modprobe --ignore-install rt2800usb $CMDLINE_OPTS && echo 1b75 a200 > /sys/bus/usb/drivers/rt2800usb/new_id' > /etc/modprobe.d/ralink.conf
  # modprobe -r rt2800usb ; modprobe rt2800usb

but I'll try and get this patch tested on top of 3.16.x (which is what
we have in Debian at the moment) if that's good enough for you.

Mraw,
KiBi.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH 2/2] xen-netback: Remove __GFP_COLD
From: Wei Liu @ 2014-10-29 11:05 UTC (permalink / raw)
  To: David Vrabel; +Cc: netdev, xen-devel, Ian Campbell, Wei Liu, Zoltan Kiss
In-Reply-To: <1414510171-12853-3-git-send-email-david.vrabel@citrix.com>

On Tue, Oct 28, 2014 at 03:29:31PM +0000, David Vrabel wrote:
> From: Zoltan Kiss <zoltan.kiss@linaro.org>
> 
> This flag is unnecessary, it came from some old code.
> 
> Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Zoltan Kiss <zoltan.kiss@linaro.org>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: Wei Liu <wei.liu2@citrix.com>

> ---
>  drivers/net/xen-netback/netback.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 25f4c06..730252c 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1550,7 +1550,7 @@ static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct sk_buff *s
>  		unsigned int len;
>  
>  		BUG_ON(i >= MAX_SKB_FRAGS);
> -		page = alloc_page(GFP_ATOMIC|__GFP_COLD);
> +		page = alloc_page(GFP_ATOMIC);
>  		if (!page) {
>  			int j;
>  			skb->truesize += skb->data_len;
> -- 
> 1.7.10.4

^ permalink raw reply

* Re: [PATCH 1/2] xen-netback: Disable NAPI after disabling interrupts
From: Wei Liu @ 2014-10-29 11:05 UTC (permalink / raw)
  To: David Vrabel; +Cc: netdev, xen-devel, Ian Campbell, Wei Liu, Zoltan Kiss
In-Reply-To: <1414510171-12853-2-git-send-email-david.vrabel@citrix.com>

On Tue, Oct 28, 2014 at 03:29:30PM +0000, David Vrabel wrote:
> From: Zoltan Kiss <zoltan.kiss@linaro.org>
> 
> Otherwise the interrupt handler still calls napi_complete. Although it
> won't schedule NAPI again as either NAPI_STATE_DISABLE or
> NAPI_STATE_SCHED is set, it is just unnecessary, and it makes more
> sense to do this way.
> 
> Signed-off-by: Zoltan Kiss <zoltan.kiss@linaro.org>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: Wei Liu <wei.liu2@citrix.com>

> ---
>  drivers/net/xen-netback/interface.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index 895fe84..a6a32d3 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -235,10 +235,10 @@ static void xenvif_down(struct xenvif *vif)
>  
>  	for (queue_index = 0; queue_index < num_queues; ++queue_index) {
>  		queue = &vif->queues[queue_index];
> -		napi_disable(&queue->napi);
>  		disable_irq(queue->tx_irq);
>  		if (queue->tx_irq != queue->rx_irq)
>  			disable_irq(queue->rx_irq);
> +		napi_disable(&queue->napi);
>  		del_timer_sync(&queue->credit_timeout);
>  	}
>  }
> -- 
> 1.7.10.4

^ permalink raw reply

* Re: [PATCH] wireless: rt2x00: add new rt2800usb device
From: Stanislaw Gruszka @ 2014-10-29 11:02 UTC (permalink / raw)
  To: Cyril Brulebois
  Cc: Helmut Schaa, John W. Linville, linux-wireless, users, netdev,
	linux-kernel
In-Reply-To: <1414510961-28920-1-git-send-email-kibi@debian.org>

On Tue, Oct 28, 2014 at 04:42:41PM +0100, Cyril Brulebois wrote:
> 0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle
> 
> References: https://bugs.debian.org/766802
> Reported-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>

Was this patch tested by reporter? I would rather see Reported-and-tested-by tag :-)

Stanislaw

^ permalink raw reply

* [PATCH 7/7] can: m_can: workaround for transmit data less than 4 bytes
From: Dong Aisheng @ 2014-10-29 10:45 UTC (permalink / raw)
  To: linux-can
  Cc: netdev, varkabhadram, mkl, linux-arm-kernel, socketcan, b29396,
	wg
In-Reply-To: <1414579527-31100-1-git-send-email-b29396@freescale.com>

We meet an IC issue that we have to write the full 8 bytes (whatever
value for the second word) in Message RAM to avoid bit error for transmit
data less than 4 bytes.

Without the workaround, we can easily see the following errors:
root@imx6qdlsolo:~# ip link set can0 up type can bitrate 1000000
[   66.882520] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
root@imx6qdlsolo:~# cansend can0 123#112233
[   66.935640] m_can 20e8000.can can0: Bit Error Uncorrected

Signed-off-by: Dong Aisheng <b29396@freescale.com>
---
 drivers/net/can/m_can/m_can.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 219e0e3..f2d9ebe 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1058,10 +1058,19 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
 	m_can_fifo_write(priv, 0, M_CAN_FIFO_ID, id);
 	m_can_fifo_write(priv, 0, M_CAN_FIFO_DLC, can_len2dlc(cf->len) << 16);
 
-	for (i = 0; i < cf->len; i += 4)
+	for (i = 0; i < cf->len; i += 4) {
 		m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4),
 				 *(u32 *)(cf->data + i));
 
+		/* FIXME: we meet an IC issue that we have to write the full 8
+		 * bytes (whatever value for the second word) in Message RAM to
+		 * avoid bit error for transmit data less than 4 bytes
+		 */
+		if (cf->len <= 4)
+			m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4 + 1),
+					 0x0);
+	}
+
 	can_put_echo_skb(skb, dev, 0);
 
 	if (priv->can.ctrlmode & CAN_CTRLMODE_FD) {
-- 
1.9.1

^ permalink raw reply related

* [PATCH 6/7] can: m_can: update to support CAN FD features
From: Dong Aisheng @ 2014-10-29 10:45 UTC (permalink / raw)
  To: linux-can
  Cc: mkl, wg, varkabhadram, netdev, socketcan, b29396,
	linux-arm-kernel
In-Reply-To: <1414579527-31100-1-git-send-email-b29396@freescale.com>

Bosch M_CAN is CAN FD capable device.
This patch implements the CAN FD features include up to 64 bytes
payload and bitrate switch function.

Signed-off-by: Dong Aisheng <b29396@freescale.com>
---
 drivers/net/can/m_can/m_can.c | 138 +++++++++++++++++++++++++++++++++---------
 1 file changed, 110 insertions(+), 28 deletions(-)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 6160b9c..219e0e3 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -105,14 +105,36 @@ enum m_can_mram_cfg {
 	MRAM_CFG_NUM,
 };
 
+/* Fast Bit Timing & Prescaler Register (FBTP) */
+#define FBTR_FBRP_MASK		0x1f
+#define FBTR_FBRP_SHIFT		16
+#define FBTR_FTSEG1_SHIFT	8
+#define FBTR_FTSEG1_MASK	(0xf << FBTR_FTSEG1_SHIFT)
+#define FBTR_FTSEG2_SHIFT	4
+#define FBTR_FTSEG2_MASK	(0x7 << FBTR_FTSEG2_SHIFT)
+#define FBTR_FSJW_SHIFT		0
+#define FBTR_FSJW_MASK		0x3
+
 /* Test Register (TEST) */
 #define TEST_LBCK	BIT(4)
 
 /* CC Control Register(CCCR) */
-#define CCCR_TEST	BIT(7)
-#define CCCR_MON	BIT(5)
-#define CCCR_CCE	BIT(1)
-#define CCCR_INIT	BIT(0)
+#define CCCR_TEST		BIT(7)
+#define CCCR_CMR_MASK		0x3
+#define CCCR_CMR_SHIFT		10
+#define CCCR_CMR_CANFD		0x1
+#define CCCR_CMR_CANFD_BRS	0x2
+#define CCCR_CMR_CAN		0x3
+#define CCCR_CME_MASK		0x3
+#define CCCR_CME_SHIFT		8
+#define CCCR_CME_CAN		0
+#define CCCR_CME_CANFD		0x1
+#define CCCR_CME_CANFD_BRS	0x2
+#define CCCR_TEST		BIT(7)
+#define CCCR_MON		BIT(5)
+#define CCCR_CCE		BIT(1)
+#define CCCR_INIT		BIT(0)
+#define CCCR_CANFD		0x10
 
 /* Bit Timing & Prescaler Register (BTP) */
 #define BTR_BRP_MASK		0x3ff
@@ -204,6 +226,7 @@ enum m_can_mram_cfg {
 
 /* Rx Buffer / FIFO Element Size Configuration (RXESC) */
 #define M_CAN_RXESC_8BYTES	0x0
+#define M_CAN_RXESC_64BYTES	0x777
 
 /* Tx Buffer Configuration(TXBC) */
 #define TXBC_NDTB_OFF		16
@@ -211,6 +234,7 @@ enum m_can_mram_cfg {
 
 /* Tx Buffer Element Size Configuration(TXESC) */
 #define TXESC_TBDS_8BYTES	0x0
+#define TXESC_TBDS_64BYTES	0x7
 
 /* Tx Event FIFO Con.guration (TXEFC) */
 #define TXEFC_EFS_OFF		16
@@ -219,11 +243,11 @@ enum m_can_mram_cfg {
 /* Message RAM Configuration (in bytes) */
 #define SIDF_ELEMENT_SIZE	4
 #define XIDF_ELEMENT_SIZE	8
-#define RXF0_ELEMENT_SIZE	16
-#define RXF1_ELEMENT_SIZE	16
+#define RXF0_ELEMENT_SIZE	72
+#define RXF1_ELEMENT_SIZE	72
 #define RXB_ELEMENT_SIZE	16
 #define TXE_ELEMENT_SIZE	8
-#define TXB_ELEMENT_SIZE	16
+#define TXB_ELEMENT_SIZE	72
 
 /* Message RAM Elements */
 #define M_CAN_FIFO_ID		0x0
@@ -231,11 +255,17 @@ enum m_can_mram_cfg {
 #define M_CAN_FIFO_DATA(n)	(0x8 + ((n) << 2))
 
 /* Rx Buffer Element */
+/* R0 */
 #define RX_BUF_ESI		BIT(31)
 #define RX_BUF_XTD		BIT(30)
 #define RX_BUF_RTR		BIT(29)
+/* R1 */
+#define RX_BUF_ANMF		BIT(31)
+#define RX_BUF_EDL		BIT(21)
+#define RX_BUF_BRS		BIT(20)
 
 /* Tx Buffer Element */
+/* R0 */
 #define TX_BUF_XTD		BIT(30)
 #define TX_BUF_RTR		BIT(29)
 
@@ -327,11 +357,12 @@ static inline void m_can_disable_all_interrupts(const struct m_can_priv *priv)
 	m_can_write(priv, M_CAN_ILE, 0x0);
 }
 
-static void m_can_read_fifo(const struct net_device *dev, struct can_frame *cf,
+static void m_can_read_fifo(const struct net_device *dev, struct canfd_frame *cf,
 			    u32 rxfs)
 {
 	struct m_can_priv *priv = netdev_priv(dev);
 	u32 id, fgi;
+	int i;
 
 	/* calculate the fifo get index for where to read data */
 	fgi = (rxfs & RXFS_FGI_MASK) >> RXFS_FGI_OFF;
@@ -341,15 +372,23 @@ static void m_can_read_fifo(const struct net_device *dev, struct can_frame *cf,
 	else
 		cf->can_id = (id >> 18) & CAN_SFF_MASK;
 
+	if (id & RX_BUF_ESI) {
+		cf->flags |= CANFD_ESI;
+		netdev_dbg(dev, "ESI Error\n");
+	}
+
 	if (id & RX_BUF_RTR) {
 		cf->can_id |= CAN_RTR_FLAG;
 	} else {
 		id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
-		cf->can_dlc = get_can_dlc((id >> 16) & 0x0F);
-		*(u32 *)(cf->data + 0) = m_can_fifo_read(priv, fgi,
-							 M_CAN_FIFO_DATA(0));
-		*(u32 *)(cf->data + 4) = m_can_fifo_read(priv, fgi,
-							 M_CAN_FIFO_DATA(1));
+		cf->len = can_dlc2len(get_canfd_dlc((id >> 16) & 0x0F));
+
+		if (id & RX_BUF_BRS)
+			cf->flags |= CANFD_BRS;
+
+		for (i = 0; i < cf->len; i += 4)
+			*(u32 *)(cf->data + i) =
+				m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA(i / 4));
 	}
 
 	/* acknowledge rx fifo 0 */
@@ -361,7 +400,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota)
 	struct m_can_priv *priv = netdev_priv(dev);
 	struct net_device_stats *stats = &dev->stats;
 	struct sk_buff *skb;
-	struct can_frame *frame;
+	struct canfd_frame *frame;
 	u32 pkts = 0;
 	u32 rxfs;
 
@@ -375,7 +414,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota)
 		if (rxfs & RXFS_RFL)
 			netdev_warn(dev, "Rx FIFO 0 Message Lost\n");
 
-		skb = alloc_can_skb(dev, &frame);
+		skb = alloc_canfd_skb(dev, &frame);
 		if (!skb) {
 			stats->rx_dropped++;
 			return pkts;
@@ -384,7 +423,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota)
 		m_can_read_fifo(dev, frame, rxfs);
 
 		stats->rx_packets++;
-		stats->rx_bytes += frame->can_dlc;
+		stats->rx_bytes += frame->len;
 
 		netif_receive_skb(skb);
 
@@ -744,10 +783,23 @@ static const struct can_bittiming_const m_can_bittiming_const = {
 	.brp_inc = 1,
 };
 
+static const struct can_bittiming_const m_can_data_bittiming_const = {
+	.name = KBUILD_MODNAME,
+	.tseg1_min = 2,		/* Time segment 1 = prop_seg + phase_seg1 */
+	.tseg1_max = 16,
+	.tseg2_min = 1,		/* Time segment 2 = phase_seg2 */
+	.tseg2_max = 8,
+	.sjw_max = 4,
+	.brp_min = 1,
+	.brp_max = 32,
+	.brp_inc = 1,
+};
+
 static int m_can_set_bittiming(struct net_device *dev)
 {
 	struct m_can_priv *priv = netdev_priv(dev);
 	const struct can_bittiming *bt = &priv->can.bittiming;
+	const struct can_bittiming *dbt = &priv->can.data_bittiming;
 	u16 brp, sjw, tseg1, tseg2;
 	u32 reg_btp;
 
@@ -758,7 +810,17 @@ static int m_can_set_bittiming(struct net_device *dev)
 	reg_btp = (brp << BTR_BRP_SHIFT) | (sjw << BTR_SJW_SHIFT) |
 			(tseg1 << BTR_TSEG1_SHIFT) | (tseg2 << BTR_TSEG2_SHIFT);
 	m_can_write(priv, M_CAN_BTP, reg_btp);
-	netdev_dbg(dev, "setting BTP 0x%x\n", reg_btp);
+
+	if (priv->can.ctrlmode & CAN_CTRLMODE_FD) {
+		brp = dbt->brp - 1;
+		sjw = dbt->sjw - 1;
+		tseg1 = dbt->prop_seg + dbt->phase_seg1 - 1;
+		tseg2 = dbt->phase_seg2 - 1;
+		reg_btp = (brp << FBTR_FBRP_SHIFT) | (sjw << FBTR_FSJW_SHIFT) |
+				(tseg1 << FBTR_FTSEG1_SHIFT) |
+				(tseg2 << FBTR_FTSEG2_SHIFT);
+		m_can_write(priv, M_CAN_FBTP, reg_btp);
+	}
 
 	return 0;
 }
@@ -778,8 +840,8 @@ static void m_can_chip_config(struct net_device *dev)
 
 	m_can_config_endisable(priv, true);
 
-	/* RX Buffer/FIFO Element Size 8 bytes data field */
-	m_can_write(priv, M_CAN_RXESC, M_CAN_RXESC_8BYTES);
+	/* RX Buffer/FIFO Element Size 64 bytes data field */
+	m_can_write(priv, M_CAN_RXESC, M_CAN_RXESC_64BYTES);
 
 	/* Accept Non-matching Frames Into FIFO 0 */
 	m_can_write(priv, M_CAN_GFC, 0x0);
@@ -788,8 +850,8 @@ static void m_can_chip_config(struct net_device *dev)
 	m_can_write(priv, M_CAN_TXBC, (1 << TXBC_NDTB_OFF) |
 		    priv->mcfg[MRAM_TXB].off);
 
-	/* only support 8 bytes firstly */
-	m_can_write(priv, M_CAN_TXESC, TXESC_TBDS_8BYTES);
+	/* support 64 bytes payload */
+	m_can_write(priv, M_CAN_TXESC, TXESC_TBDS_64BYTES);
 
 	m_can_write(priv, M_CAN_TXEFC, (1 << TXEFC_EFS_OFF) |
 		    priv->mcfg[MRAM_TXE].off);
@@ -804,7 +866,8 @@ static void m_can_chip_config(struct net_device *dev)
 		    RXFC_FWM_1 | priv->mcfg[MRAM_RXF1].off);
 
 	cccr = m_can_read(priv, M_CAN_CCCR);
-	cccr &= ~(CCCR_TEST | CCCR_MON);
+	cccr &= ~(CCCR_TEST | CCCR_MON | (CCCR_CMR_MASK << CCCR_CMR_SHIFT) |
+		(CCCR_CME_MASK << CCCR_CME_SHIFT));
 	test = m_can_read(priv, M_CAN_TEST);
 	test &= ~TEST_LBCK;
 
@@ -816,6 +879,9 @@ static void m_can_chip_config(struct net_device *dev)
 		test |= TEST_LBCK;
 	}
 
+	if (priv->can.ctrlmode & CAN_CTRLMODE_FD)
+		cccr |= CCCR_CME_CANFD_BRS << CCCR_CME_SHIFT;
+
 	m_can_write(priv, M_CAN_CCCR, cccr);
 	m_can_write(priv, M_CAN_TEST, test);
 
@@ -880,11 +946,13 @@ static struct net_device *alloc_m_can_dev(void)
 
 	priv->dev = dev;
 	priv->can.bittiming_const = &m_can_bittiming_const;
+	priv->can.data_bittiming_const = &m_can_data_bittiming_const;
 	priv->can.do_set_mode = m_can_set_mode;
 	priv->can.do_get_berr_counter = m_can_get_berr_counter;
 	priv->can.ctrlmode_supported = CAN_CTRLMODE_LOOPBACK |
 					CAN_CTRLMODE_LISTENONLY |
-					CAN_CTRLMODE_BERR_REPORTING;
+					CAN_CTRLMODE_BERR_REPORTING |
+					CAN_CTRLMODE_FD;
 
 	return dev;
 }
@@ -967,8 +1035,9 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
 				    struct net_device *dev)
 {
 	struct m_can_priv *priv = netdev_priv(dev);
-	struct can_frame *cf = (struct can_frame *)skb->data;
-	u32 id;
+	struct canfd_frame *cf = (struct canfd_frame *)skb->data;
+	u32 id, cccr;
+	int i;
 
 	if (can_dropped_invalid_skb(dev, skb))
 		return NETDEV_TX_OK;
@@ -987,11 +1056,24 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
 
 	/* message ram configuration */
 	m_can_fifo_write(priv, 0, M_CAN_FIFO_ID, id);
-	m_can_fifo_write(priv, 0, M_CAN_FIFO_DLC, cf->can_dlc << 16);
-	m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
-	m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
+	m_can_fifo_write(priv, 0, M_CAN_FIFO_DLC, can_len2dlc(cf->len) << 16);
+
+	for (i = 0; i < cf->len; i += 4)
+		m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4),
+				 *(u32 *)(cf->data + i));
+
 	can_put_echo_skb(skb, dev, 0);
 
+	if (priv->can.ctrlmode & CAN_CTRLMODE_FD) {
+		cccr = m_can_read(priv, M_CAN_CCCR);
+		cccr &= ~(CCCR_CMR_MASK << CCCR_CMR_SHIFT);
+		if (cf->flags & CANFD_BRS
+			cccr |= CCCR_CMR_CANFD_BRS << CCCR_CMR_SHIFT;
+		else
+			cccr |= CCCR_CMR_CANFD << CCCR_CMR_SHIFT;
+		m_can_write(priv, M_CAN_CCCR, cccr);
+	}
+
 	/* enable first TX buffer to start transfer  */
 	m_can_write(priv, M_CAN_TXBTIE, 0x1);
 	m_can_write(priv, M_CAN_TXBAR, 0x1);
-- 
1.9.1


^ permalink raw reply related

* [PATCH 5/7] can: clear ctrlmode when close candev
From: Dong Aisheng @ 2014-10-29 10:45 UTC (permalink / raw)
  To: linux-can
  Cc: netdev, varkabhadram, mkl, linux-arm-kernel, socketcan, b29396,
	wg
In-Reply-To: <1414579527-31100-1-git-send-email-b29396@freescale.com>

Currently priv->ctrlmode is not cleared when close_candev, so next time
the driver will still use this value to set controller even user
does not set any ctrl mode.
e.g.
Step 1. ip link set can0 up type can0 bitrate 1000000 loopback on
Controller will be in loopback mode
Step 2. ip link set can0 down
Step 3. ip link set can0 up type can0 bitrate 1000000
Controller will still be set to loopback mode in driver due to saved
priv->ctrlmode.

This patch clears priv->ctrlmode when the CAN interface is closed,
and set it to correct mode according to next user setting.

Signed-off-by: Dong Aisheng <b29396@freescale.com>
---
 drivers/net/can/dev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 02492d2..1fce485 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -671,6 +671,7 @@ void close_candev(struct net_device *dev)
 
 	del_timer_sync(&priv->restart_timer);
 	can_flush_echo_skb(dev);
+	priv->ctrlmode = 0;
 }
 EXPORT_SYMBOL_GPL(close_candev);
 
-- 
1.9.1

^ permalink raw reply related

* [PATCH 4/7] can: m_can: add a bit delay after setting CCCR_INIT bit
From: Dong Aisheng @ 2014-10-29 10:45 UTC (permalink / raw)
  To: linux-can
  Cc: netdev, varkabhadram, mkl, linux-arm-kernel, socketcan, b29396,
	wg
In-Reply-To: <1414579527-31100-1-git-send-email-b29396@freescale.com>

The spec mentions there may be a delay until the value written to
INIT can be read back due to the synchronization mechanism between the
two clock domains. But it does not indicate the exact clock cycles needed.
The 5us delay is a test value and seems ok.

Without the delay, CCCR.CCE bit may fail to be set and then the
initialization fail sometimes when do repeatly up and down.

Signed-off-by: Dong Aisheng <b29396@freescale.com>
---
 drivers/net/can/m_can/m_can.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index e4ef146..6160b9c 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -296,6 +296,7 @@ static inline void m_can_config_endisable(const struct m_can_priv *priv,
 	if (enable) {
 		/* enable m_can configuration */
 		m_can_write(priv, M_CAN_CCCR, cccr | CCCR_INIT);
+		udelay(5);
 		/* CCCR.CCE can only be set/reset while CCCR.INIT = '1' */
 		m_can_write(priv, M_CAN_CCCR, cccr | CCCR_INIT | CCCR_CCE);
 	} else {
-- 
1.9.1

^ permalink raw reply related

* [PATCH 3/7] can: m_can: add .ndo_change_mtu function
From: Dong Aisheng @ 2014-10-29 10:45 UTC (permalink / raw)
  To: linux-can
  Cc: netdev, varkabhadram, mkl, linux-arm-kernel, socketcan, b29396,
	wg
In-Reply-To: <1414579527-31100-1-git-send-email-b29396@freescale.com>

Use common can_change_mtu function.

Signed-off-by: Dong Aisheng <b29396@freescale.com>
---
 drivers/net/can/m_can/m_can.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 2784423..e4ef146 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1002,6 +1002,7 @@ static const struct net_device_ops m_can_netdev_ops = {
 	.ndo_open = m_can_open,
 	.ndo_stop = m_can_close,
 	.ndo_start_xmit = m_can_start_xmit,
+	.ndo_change_mtu = can_change_mtu,
 };
 
 static int register_m_can_dev(struct net_device *dev)
-- 
1.9.1

^ permalink raw reply related

* [PATCH 2/7] can: m_can: fix the incorrect error messages
From: Dong Aisheng @ 2014-10-29 10:45 UTC (permalink / raw)
  To: linux-can
  Cc: netdev, varkabhadram, mkl, linux-arm-kernel, socketcan, b29396,
	wg
In-Reply-To: <1414579527-31100-1-git-send-email-b29396@freescale.com>

Fix a few error messages.

Signed-off-by: Dong Aisheng <b29396@freescale.com>
---
 drivers/net/can/m_can/m_can.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 8692848..2784423 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -606,14 +606,14 @@ static int m_can_handle_state_errors(struct net_device *dev, u32 psr)
 
 	if ((psr & PSR_EP) &&
 	    (priv->can.state != CAN_STATE_ERROR_PASSIVE)) {
-		netdev_dbg(dev, "entered error warning state\n");
+		netdev_dbg(dev, "entered error passive state\n");
 		work_done += m_can_handle_state_change(dev,
 						       CAN_STATE_ERROR_PASSIVE);
 	}
 
 	if ((psr & PSR_BO) &&
 	    (priv->can.state != CAN_STATE_BUS_OFF)) {
-		netdev_dbg(dev, "entered error warning state\n");
+		netdev_dbg(dev, "entered error bus off state\n");
 		work_done += m_can_handle_state_change(dev,
 						       CAN_STATE_BUS_OFF);
 	}
@@ -625,7 +625,7 @@ static void m_can_handle_other_err(struct net_device *dev, u32 irqstatus)
 {
 	if (irqstatus & IR_WDI)
 		netdev_err(dev, "Message RAM Watchdog event due to missing READY\n");
-	if (irqstatus & IR_BEU)
+	if (irqstatus & IR_ELO)
 		netdev_err(dev, "Error Logging Overflow\n");
 	if (irqstatus & IR_BEU)
 		netdev_err(dev, "Bit Error Uncorrected\n");
-- 
1.9.1

^ permalink raw reply related

* [PATCH 1/7] can: m_can: fix possible sleep in napi poll
From: Dong Aisheng @ 2014-10-29 10:45 UTC (permalink / raw)
  To: linux-can
  Cc: mkl, wg, varkabhadram, netdev, socketcan, b29396,
	linux-arm-kernel

The m_can_get_berr_counter function can sleep and it may be called in napi poll function.
Rework it to fix the following warning.
root@imx6qdlsolo:~# cangen can0 -f -L 12 -D 112233445566778899001122
[ 1846.017565] m_can 20e8000.can can0: entered error warning state
[ 1846.023551] ------------[ cut here ]------------
[ 1846.028216] WARNING: CPU: 0 PID: 560 at kernel/locking/mutex.c:867 mutex_trylock+0x218/0x23c()
[ 1846.036889] DEBUG_LOCKS_WARN_ON(in_interrupt())
[ 1846.041263] Modules linked in:
[ 1846.044594] CPU: 0 PID: 560 Comm: cangen Not tainted 3.17.0-rc4-next-20140915-00010-g032d018-dirty #477
[ 1846.054033] Backtrace:
[ 1846.056557] [<80012448>] (dump_backtrace) from [<80012728>] (show_stack+0x18/0x1c)
[ 1846.064180]  r6:809a07ec r5:809a07ec r4:00000000 r3:00000000
[ 1846.069966] [<80012710>] (show_stack) from [<806c9ee0>] (dump_stack+0x8c/0xa4)
[ 1846.077264] [<806c9e54>] (dump_stack) from [<8002aa78>] (warn_slowpath_common+0x70/0x94)
[ 1846.085403]  r6:806cd1b0 r5:00000009 r4:be1d5c20 r3:be07b0c0
[ 1846.091204] [<8002aa08>] (warn_slowpath_common) from [<8002aad4>] (warn_slowpath_fmt+0x38/0x40)
[ 1846.099951]  r8:8119106c r7:80515aa4 r6:be027000 r5:00000001 r4:809d1df4
[ 1846.106830] [<8002aaa0>] (warn_slowpath_fmt) from [<806cd1b0>] (mutex_trylock+0x218/0x23c)
[ 1846.115141]  r3:80851c88 r2:8084fb74
[ 1846.118804] [<806ccf98>] (mutex_trylock) from [<80515aa4>] (clk_prepare_lock+0x14/0xf4)
[ 1846.126859]  r8:00000040 r7:be1d5cec r6:be027000 r5:be255800 r4:be027000
[ 1846.133737] [<80515a90>] (clk_prepare_lock) from [<80517660>] (clk_prepare+0x14/0x2c)
[ 1846.141583]  r5:be255800 r4:be027000
[ 1846.145272] [<8051764c>] (clk_prepare) from [<8041ff14>] (m_can_get_berr_counter+0x20/0xd4)
[ 1846.153672]  r4:be255800 r3:be07b0c0
[ 1846.157325] [<8041fef4>] (m_can_get_berr_counter) from [<80420428>] (m_can_poll+0x310/0x8fc)
[ 1846.165809]  r7:bd4dc540 r6:00000744 r5:11300000 r4:be255800
[ 1846.171590] [<80420118>] (m_can_poll) from [<8056a468>] (net_rx_action+0xcc/0x1b4)
[ 1846.179204]  r10:00000101 r9:be255ebc r8:00000040 r7:be7c3208 r6:8097c100 r5:be7c3200
[ 1846.187192]  r4:0000012c
[ 1846.189779] [<8056a39c>] (net_rx_action) from [<8002deec>] (__do_softirq+0xfc/0x2c4)
[ 1846.197568]  r10:00000101 r9:8097c088 r8:00000003 r7:8097c080 r6:40000001 r5:8097c08c
[ 1846.205559]  r4:00000020
[ 1846.208144] [<8002ddf0>] (__do_softirq) from [<8002e194>] (do_softirq+0x7c/0x88)
[ 1846.215588]  r10:00000000 r9:bd516a60 r8:be18ce00 r7:00000000 r6:be255800 r5:8056c0ec
[ 1846.223578]  r4:60000093
[ 1846.226163] [<8002e118>] (do_softirq) from [<8002e288>] (__local_bh_enable_ip+0xe8/0x10c)
[ 1846.234386]  r4:00000200 r3:be1d4000
[ 1846.238036] [<8002e1a0>] (__local_bh_enable_ip) from [<8056c108>] (__dev_queue_xmit+0x314/0x6b0)
[ 1846.246868]  r6:be255800 r5:bd516a00 r4:00000000 r3:be07b0c0
[ 1846.252645] [<8056bdf4>] (__dev_queue_xmit) from [<8056c4b8>] (dev_queue_xmit+0x14/0x18)

Signed-off-by: Dong Aisheng <b29396@freescale.com>
---
 drivers/net/can/m_can/m_can.c | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 10d571e..8692848 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -481,11 +481,23 @@ static int m_can_handle_lec_err(struct net_device *dev,
 	return 1;
 }
 
+static int __m_can_get_berr_counter(const struct net_device *dev,
+				    struct can_berr_counter *bec)
+{
+	struct m_can_priv *priv = netdev_priv(dev);
+	unsigned int ecr;
+
+	ecr = m_can_read(priv, M_CAN_ECR);
+	bec->rxerr = (ecr & ECR_REC_MASK) >> ECR_REC_SHIFT;
+	bec->txerr = ecr & ECR_TEC_MASK;
+
+	return 0;
+}
+
 static int m_can_get_berr_counter(const struct net_device *dev,
 				  struct can_berr_counter *bec)
 {
 	struct m_can_priv *priv = netdev_priv(dev);
-	unsigned int ecr;
 	int err;
 
 	err = clk_prepare_enable(priv->hclk);
@@ -498,9 +510,7 @@ static int m_can_get_berr_counter(const struct net_device *dev,
 		return err;
 	}
 
-	ecr = m_can_read(priv, M_CAN_ECR);
-	bec->rxerr = (ecr & ECR_REC_MASK) >> ECR_REC_SHIFT;
-	bec->txerr = ecr & ECR_TEC_MASK;
+	__m_can_get_berr_counter(dev, bec);
 
 	clk_disable_unprepare(priv->cclk);
 	clk_disable_unprepare(priv->hclk);
@@ -544,7 +554,7 @@ static int m_can_handle_state_change(struct net_device *dev,
 	if (unlikely(!skb))
 		return 0;
 
-	m_can_get_berr_counter(dev, &bec);
+	__m_can_get_berr_counter(dev, &bec);
 
 	switch (new_state) {
 	case CAN_STATE_ERROR_ACTIVE:
-- 
1.9.1


^ permalink raw reply related

* YOUR URGENT ASSISTANCE NEEDED
From: LADY ROSE BANDA @ 2014-10-29 10:32 UTC (permalink / raw)

In-Reply-To: <925190213.82277.1414578567451.JavaMail.yahoo@jws100133.mail.ne1.yahoo.com>

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: MRS._LADY_ROSE BANDA.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 16473 bytes --]

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox