* Re: [PATCH 0/3] arm64: dts: r8a7796: Add CAN/CAN FD support
From: Simon Horman @ 2016-11-24 14:32 UTC (permalink / raw)
To: Chris Paterson
Cc: Marc Kleine-Budde, Wolfgang Grandegger, Magnus Damm, Rob Herring,
Mark Rutland, Ramesh Shanmugasundaram,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <HK2PR0601MB1329C747CA5C6B5222C02C3FB7B60-5BHi1SMfQIfsvBovKiDY8NK/flDYrvD0nBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
Hi Chris,
On Thu, Nov 24, 2016 at 02:25:06PM +0000, Chris Paterson wrote:
> Hello Simon,
>
> From: Simon Horman [mailto:horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org]
> Sent: 24 November 2016 10:18
> > Hi Chris,
> >
> > On Thu, Nov 24, 2016 at 10:05:08AM +0000, Chris Paterson wrote:
> > > Hello Simon,
> > >
> > > From: Simon Horman [mailto:horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org]
> > > Sent: 23 November 2016 14:30
> > > > On Wed, Nov 23, 2016 at 02:18:13PM +0100, Marc Kleine-Budde wrote:
> > > > > On 11/23/2016 01:14 PM, Chris Paterson wrote:
...
> > > > Regarding the arch/arm64/boot/dts/renesas/ portion, I would like
> > > > some consideration given to what effect enabling memory above 4Gb
> > > > (64bit
> > > > addressing) would have.
> > >
> > > Can you give me some guidance here? I'm not sure what you're referring
> > > to. As far as I know the DT reg definition here is 64-bit, or are you
> > > referring to DMA usage? If the later, neither CAN driver uses DMA.
> >
> > Sorry for not being clearer.
> >
> > What I would like to know is if there are any problems in the CAN driver or
> > hardware that would prevent it from functioning with memory that requires
> > 64bit addressing present.
> >
> > If the CAN hardware cannot use DMA then DMA doesn't need to be taken
> > into account. But if it DMA could be enabled in future for CAN, for example
> > after some driver enhancements, then it would be good to know if 64bit
> > memory can be supported - if not it would imply DMA cannot be enabled.
>
> Thank you for the clarification.
>
> The CAN interface for r8a7795/6 does not support DMA.
>
> With CAN FD there is currently a H/W issue that means DMA is unusable.
> Potentially this issue could be fixed in the future and DMA support could
> be added to the driver. If this happens I can see no reason why the CAN
> FD IP wouldn't be able to handle DMA transfers when using 64bit
> addressing.
>
> >
> > As for non-DMA mode, will this function if memory above 4G is present?
> > If not then in theory such memory couldn't be enabled if the CAN driver
> > is enabled. This is my main concern.
>
> Yes, it functions fine. We have already tested this with the Renesas
> v3.3.2 BSP with >4Gb memory.
>
> If this is explanation okay for you, I'll proceed with a v2 splitting off
> the DT bindings documentation.
Thanks for the explanation. I think it would be good to proceed with a v2.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* wrong CAN frame order in network layer due to SMP?
From: Alexander Stein @ 2016-11-24 15:49 UTC (permalink / raw)
To: linux-can; +Cc: Daniel Krüger
Hi,
I experienced a rather interesting problem while doing a CAN burst test.
This sends a bunch of CAN frames while each frame has a counter in it and the
receiver checks if the counter are in correct order.
Now I got the error about wrong order:
> Error on MSG ID 0x251. Got counter 141606 and expected 141605
> Error on MSG ID 0x251. Got counter 141605 and expected 141607
> Error on MSG ID 0x251. Got counter 141607 and expected 141606
Here is the corresponding part from "candump -t d -a -x any -l"
> (1479993291.766686) can0 251#00022926
> (1479993291.766574) can0 251#00022925
> (1479993291.766816) can0 251#00022927
And in fact they are ordered wrongly. But the timestamps are correct, e.g. if
you reorder the frame by timestamp the order of counters is ok. This also
shows that the order is wrong on both sockets in the same way!
The used driver is systec_can (downloadable at [1] if you like).
But the driver is not to blame: In the URB complete callback a SKB is created
and passed to network stack by netif_rx.
The timestamp is set by net_timestamp_check() directly at the beginning of
netif_rx_internal() so at this point the frames are still in order.
In enqueue_to_backlog the skb are enqueued in some per_cpu softnet_data. I
don't know the details.
Now per_cpu gave me a hint the problem might be caused by SMP. So I put 7 of
my 8 cores offline:
> for i in $(seq 1 7); do echo 0 > /sys/bus/cpu/devices/cpu${i}/online; done
Repeating the test run resulted in no order problems. My guess is that the USB
interrupt is done on different cores and that gathering the SKBs to be put in
the sockets is somewhat racy.
This is supported by the fact after puttng the core online again:
> for i in $(seq 1 7); do echo 1 > /sys/bus/cpu/devices/cpu${i}/online; done
there are still no order problems. But this again is caused by the fact
(probably a bug in ACPI tables of my local machine) that any CPU put back
online serves no IO-APIC or MSI IRQs. This can easily be checked by calling:
> watch -d -n 1 cat /proc/interrupts
See that interrupts are handled on different CPUs. Put some CPUs (or all but
one) offline and online again. The ones which went offline dont serve any IO-
APIC or MSI IRQs (so including the one for ehci_hcd).
Back to my CAN problem: Only a single core handles USB IRQs and there is
apparently no softnet_data race.
The test about wrong CAN frame ordering was done on kernel 4.8.9-gentoo but I
was also able to reproduce this problem on 3.14.58-gentoo-r1. 3.12.52-gentoo-
r1 apparently does not suffer from that problem, at least 3 tries were without
errors. In buggy kernels this problems occured next to every time.
Any idea what got wrong in the network code about gathering the SKBs
which might result in wrong order?
Best regards,
Alexander
[1] http://www.systec-electronic.com/en/products/industrial-communication/interfaces-and-gateways/can-usb-adapter-usb-canmodul1
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein@systec-electronic.com
Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany
Office: +49 (0) 3765 38600-0
Fax: +49 (0) 3765 38600-4100
Managing Directors:
Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010
^ permalink raw reply
* [PATCH v2 0/2] can: Add r8a7796 support to CAN/CAN FD
From: Chris Paterson @ 2016-11-24 16:11 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Wolfgang Grandegger, Rob Herring, Mark Rutland,
Geert Uytterhoeven, Simon Horman, Ramesh Shanmugasundaram,
linux-can, netdev, devicetree, linux-renesas-soc, Chris Paterson
In-Reply-To: <1479903243-1860-1-git-send-email-chris.paterson2@renesas.com>
This series adds support for r8a7796 to rcar_can and rcar_canfd.
Original series: [PATCH 0/3] arm64: dts: r8a7796: Add CAN/CAN FD support.
Changes since v1:
- Split bindings documentation changes from device tree changes.
- Rebased on renesas-devel-20161123v2-v4.9-rc6.
Chris Paterson (2):
can: rcar_can: Add r8a7796 support
can: rcar_canfd: Add r8a7796 support
Documentation/devicetree/bindings/net/can/rcar_can.txt | 12 +++++++-----
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 12 +++++++-----
2 files changed, 14 insertions(+), 10 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v2 1/2] can: rcar_can: Add r8a7796 support
From: Chris Paterson @ 2016-11-24 16:11 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Wolfgang Grandegger, Rob Herring, Mark Rutland,
Geert Uytterhoeven, Simon Horman, Ramesh Shanmugasundaram,
linux-can-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Chris Paterson
In-Reply-To: <1480003917-3953-1-git-send-email-chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Chris Paterson <chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
Documentation/devicetree/bindings/net/can/rcar_can.txt | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 8d40ab2..06bb7cc 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -10,6 +10,7 @@ Required properties:
"renesas,can-r8a7793" if CAN controller is a part of R8A7793 SoC.
"renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC.
"renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
+ "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
"renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
"renesas,rcar-gen2-can" for a generic R-Car Gen2 compatible device.
"renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
@@ -24,11 +25,12 @@ Required properties:
- pinctrl-0: pin control group to be used for this controller.
- pinctrl-names: must be "default".
-Required properties for "renesas,can-r8a7795" compatible:
-In R8A7795 SoC, "clkp2" can be CANFD clock. This is a div6 clock and can be
-used by both CAN and CAN FD controller at the same time. It needs to be scaled
-to maximum frequency if any of these controllers use it. This is done using
-the below properties.
+Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
+compatible:
+In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
+and can be used by both CAN and CAN FD controller at the same time. It needs to
+be scaled to maximum frequency if any of these controllers use it. This is done
+using the below properties:
- assigned-clocks: phandle of clkp2(CANFD) clock.
- assigned-clock-rates: maximum frequency of this clock.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 related
* [PATCH v2 2/2] can: rcar_canfd: Add r8a7796 support
From: Chris Paterson @ 2016-11-24 16:11 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Wolfgang Grandegger, Rob Herring, Mark Rutland,
Geert Uytterhoeven, Simon Horman, Ramesh Shanmugasundaram,
linux-can, netdev, devicetree, linux-renesas-soc, Chris Paterson
In-Reply-To: <1480003917-3953-1-git-send-email-chris.paterson2@renesas.com>
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
index 22a6f10..788f273 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -5,6 +5,7 @@ Required properties:
- compatible: Must contain one or more of the following:
- "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
- "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
+ - "renesas,r8a7796-canfd" for R8A7796 (R-Car M3) compatible controller.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first, followed by the
@@ -23,11 +24,12 @@ The name of the child nodes are "channel0" and "channel1" respectively. Each
child node supports the "status" property only, which is used to
enable/disable the respective channel.
-Required properties for "renesas,r8a7795-canfd" compatible:
-In R8A7795 SoC, canfd clock is a div6 clock and can be used by both CAN
-and CAN FD controller at the same time. It needs to be scaled to maximum
-frequency if any of these controllers use it. This is done using the
-below properties.
+Required properties for "renesas,r8a7795-canfd" and "renesas,r8a7796-canfd"
+compatible:
+In R8A7795 and R8A7796 SoCs, canfd clock is a div6 clock and can be used by both
+CAN and CAN FD controller at the same time. It needs to be scaled to maximum
+frequency if any of these controllers use it. This is done using the below
+properties:
- assigned-clocks: phandle of canfd clock.
- assigned-clock-rates: maximum frequency of this clock.
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 0/3] arm64: dts: r8a7796: Add CAN/CAN FD support
From: Geert Uytterhoeven @ 2016-11-24 16:41 UTC (permalink / raw)
To: Chris Paterson
Cc: Simon Horman, Marc Kleine-Budde, Wolfgang Grandegger, Magnus Damm,
Rob Herring, Mark Rutland, Ramesh Shanmugasundaram,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <HK2PR0601MB1329C747CA5C6B5222C02C3FB7B60-5BHi1SMfQIfsvBovKiDY8NK/flDYrvD0nBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
Hi Chris,
On Thu, Nov 24, 2016 at 3:25 PM, Chris Paterson
<Chris.Paterson2-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> From: Simon Horman [mailto:horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org]
> Sent: 24 November 2016 10:18
>> On Thu, Nov 24, 2016 at 10:05:08AM +0000, Chris Paterson wrote:
>> > From: Simon Horman [mailto:horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org]
>> > > Regarding the arch/arm64/boot/dts/renesas/ portion, I would like
>> > > some consideration given to what effect enabling memory above 4Gb
>> > > (64bit
>> > > addressing) would have.
>> >
>> > Can you give me some guidance here? I'm not sure what you're referring
>> > to. As far as I know the DT reg definition here is 64-bit, or are you
>> > referring to DMA usage? If the later, neither CAN driver uses DMA.
>>
>> Sorry for not being clearer.
>>
>> What I would like to know is if there are any problems in the CAN driver or
>> hardware that would prevent it from functioning with memory that requires
>> 64bit addressing present.
>>
>> If the CAN hardware cannot use DMA then DMA doesn't need to be taken
>> into account. But if it DMA could be enabled in future for CAN, for example
>> after some driver enhancements, then it would be good to know if 64bit
>> memory can be supported - if not it would imply DMA cannot be enabled.
>
> Thank you for the clarification.
>
> The CAN interface for r8a7795/6 does not support DMA.
>
> With CAN FD there is currently a H/W issue that means DMA is unusable.
Is that issue present on R-Car M3-W, or only on R-Car H3 ES1.x?
> Potentially this issue could be fixed in the future and DMA support could
> be added to the driver. If this happens I can see no reason why the CAN FD
> IP wouldn't be able to handle DMA transfers when using 64bit addressing.
Yep, AFAIK it uses SYS-DMAC, which supports 64-bit addressing.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 0/3] arm64: dts: r8a7796: Add CAN/CAN FD support
From: Chris Paterson @ 2016-11-24 17:12 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Marc Kleine-Budde, Wolfgang Grandegger, Magnus Damm,
Rob Herring, Mark Rutland, Ramesh Shanmugasundaram,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-can@vger.kernel.org
In-Reply-To: <CAMuHMdXO=uFuJCXPjkdYB_CeyfPMqy6cMrOW=s1DZzcJ9Gp33A@mail.gmail.com>
Hello Geert,
From: geert.uytterhoeven@gmail.com
Sent: 24 November 2016 16:42
> Hi Chris,
>
> On Thu, Nov 24, 2016 at 3:25 PM, Chris Paterson
> <Chris.Paterson2@renesas.com> wrote:
> > From: Simon Horman [mailto:horms@verge.net.au]
> > Sent: 24 November 2016 10:18
> >> On Thu, Nov 24, 2016 at 10:05:08AM +0000, Chris Paterson wrote:
> >> > From: Simon Horman [mailto:horms@verge.net.au]
> >> > > Regarding the arch/arm64/boot/dts/renesas/ portion, I would like
> >> > > some consideration given to what effect enabling memory above 4Gb
> >> > > (64bit
> >> > > addressing) would have.
> >> >
> >> > Can you give me some guidance here? I'm not sure what you're
> >> > referring to. As far as I know the DT reg definition here is
> >> > 64-bit, or are you referring to DMA usage? If the later, neither CAN
> driver uses DMA.
> >>
> >> Sorry for not being clearer.
> >>
> >> What I would like to know is if there are any problems in the CAN
> >> driver or hardware that would prevent it from functioning with memory
> >> that requires 64bit addressing present.
> >>
> >> If the CAN hardware cannot use DMA then DMA doesn't need to be
> taken
> >> into account. But if it DMA could be enabled in future for CAN, for
> >> example after some driver enhancements, then it would be good to know
> >> if 64bit memory can be supported - if not it would imply DMA cannot be
> enabled.
> >
> > Thank you for the clarification.
> >
> > The CAN interface for r8a7795/6 does not support DMA.
> >
> > With CAN FD there is currently a H/W issue that means DMA is unusable.
>
> Is that issue present on R-Car M3-W, or only on R-Car H3 ES1.x?
Both
>
> > Potentially this issue could be fixed in the future and DMA support
> > could be added to the driver. If this happens I can see no reason why
> > the CAN FD IP wouldn't be able to handle DMA transfers when using 64bit
> addressing.
>
> Yep, AFAIK it uses SYS-DMAC, which supports 64-bit addressing.
Yep
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-
> m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 0/2] can: Add r8a7796 support to CAN/CAN FD
From: Marc Kleine-Budde @ 2016-11-25 7:19 UTC (permalink / raw)
To: Chris Paterson
Cc: Wolfgang Grandegger, Rob Herring, Mark Rutland,
Geert Uytterhoeven, Simon Horman, Ramesh Shanmugasundaram,
linux-can, netdev, devicetree, linux-renesas-soc
In-Reply-To: <1480003917-3953-1-git-send-email-chris.paterson2@renesas.com>
[-- Attachment #1.1: Type: text/plain, Size: 774 bytes --]
On 11/24/2016 05:11 PM, Chris Paterson wrote:
> This series adds support for r8a7796 to rcar_can and rcar_canfd.
>
> Original series: [PATCH 0/3] arm64: dts: r8a7796: Add CAN/CAN FD support.
>
> Changes since v1:
> - Split bindings documentation changes from device tree changes.
> - Rebased on renesas-devel-20161123v2-v4.9-rc6.
>
>
> Chris Paterson (2):
> can: rcar_can: Add r8a7796 support
> can: rcar_canfd: Add r8a7796 support
Both added to can-next.
Thanks,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: wrong CAN frame order in network layer due to SMP?
From: Oliver Hartkopp @ 2016-11-25 11:46 UTC (permalink / raw)
To: Alexander Stein, linux-can; +Cc: Daniel Krüger
In-Reply-To: <1864402.pXgGBBp51L@ws-stein>
Hello Alexander,
On 11/24/2016 04:49 PM, Alexander Stein wrote:
> Back to my CAN problem: Only a single core handles USB IRQs and there is
> apparently no softnet_data race.
> The test about wrong CAN frame ordering was done on kernel 4.8.9-gentoo but I
> was also able to reproduce this problem on 3.14.58-gentoo-r1. 3.12.52-gentoo-
> r1 apparently does not suffer from that problem, at least 3 tries were without
> errors. In buggy kernels this problems occured next to every time.
>
> Any idea what got wrong in the network code about gathering the SKBs
> which might result in wrong order?
I detected a similar issue in some 3.1x kernel and asked this question:
http://marc.info/?l=linux-can&m=143637774606287&w=2
When you follow the entire discussion at
http://marc.info/?t=143637789700002&r=1&w=2
you will see that they pushed me to implement NAPI on all CAN interfaces
which neither makes no sense for CAN controllers that do not have a RX
FIFO (e.g. sja1000) nor fixes the issue at it's root cause.
Your findings bring up the problem again - good :-)
When you look at the networking guys that like to speed up TCP traffic
and also put skbs into percpu queues that are related to the receiving
socket(!!!) instance then it should be possible to put CAN skbs related
to their CAN interfaces into a percpu queue (to suppress out-of-order
reception).
IMO the difference is not to queue the skbs for a specific socket but
for a specific interface.
The 'endpoint' of CAN frames where they have to be in order is can_rcv()
in af_can.c and not any TCP instance that needs to reassemble the TCP
traffic for a specific socket.
Can you check whether my suggestion with skb_set_hash() in
alloc_can_skb() works for you?
In any way I think we should start a new attempt to make clear that the
skbs have to be in order for a specific interface at can_rcv().
And we need some solution that is enabled by default and fits to the
netdev guys mindset.
Regards,
Oliver
^ permalink raw reply
* CAN Termination API - was Re: Adding new CAN driver
From: Oliver Hartkopp @ 2016-11-25 14:16 UTC (permalink / raw)
To: Ramesh Shanmugasundaram, Kurt Van Dijck
Cc: Kołłątaj, Remigiusz, Alexander Stein,
Marc Kleine-Budde, Uwe Bonnes, linux-can@vger.kernel.org
In-Reply-To: <fc26a0a8-8c15-9b1f-c699-31f83177c431@hartkopp.net>
Hi all,
I would like to pick up the termination API again.
>>> +
>>> + /* array of supported discrete resistor values (Ohm) */
>>> + __u16 term[8];
>
> Do you think 8 resistor values are enough?
>
see below ...
>>> +};
>>> +
>>> +/*
>>> + * CAN termination
>>> + */
>>> +struct can_termination {
>>> + __u16 term;
>>> +};
>>> +
>>> +#define CAN_RESISTOR_INVALID 0x0000U /* indicates no value /
>>> unsupported */
>>> +#define CAN_RESISTOR_DISABLED 0xFFFFU /* indicates disabled
>>> termination */
>>> +
>>> #define CAN_CTRLMODE_LOOPBACK 0x01 /* Loopback mode */
>>> #define CAN_CTRLMODE_LISTENONLY 0x02 /* Listen-only mode */
>>> #define CAN_CTRLMODE_3_SAMPLES 0x04 /* Triple sampling
>>> mode */
>>> @@ -127,6 +153,8 @@ enum {
>>> IFLA_CAN_BERR_COUNTER,
>>> IFLA_CAN_DATA_BITTIMING,
>>> IFLA_CAN_DATA_BITTIMING_CONST,
>>> + IFLA_CAN_TERMINATION,
>>> + IFLA_CAN_TERMINATION_CONST,
>>> __IFLA_CAN_MAX
>>> };
>>>
>>> With this interface the ip tool can get the capabilities of the
>>> termination analogue to the BITTIMING_CONST values.
>>> And it can set the termination with IFLA_CAN_TERMINATION.
>>
>> ACK.
I tried to get into the netlink stuff and I wonder how to make this API
really simple.
By now the netlink interface in linux/drivers/net/can/dev.c looks like:
/*
* CAN netlink interface
*/
static const struct nla_policy can_policy[IFLA_CAN_MAX + 1] = {
[IFLA_CAN_STATE] = { .type = NLA_U32 },
[IFLA_CAN_CTRLMODE] = { .len = sizeof(struct can_ctrlmode) },
[IFLA_CAN_RESTART_MS] = { .type = NLA_U32 },
[IFLA_CAN_RESTART] = { .type = NLA_U32 },
[IFLA_CAN_BITTIMING] = { .len = sizeof(struct can_bittiming) },
[IFLA_CAN_BITTIMING_CONST]
= { .len = sizeof(struct
can_bittiming_const) },
[IFLA_CAN_CLOCK] = { .len = sizeof(struct can_clock) },
[IFLA_CAN_BERR_COUNTER] = { .len = sizeof(struct
can_berr_counter) },
[IFLA_CAN_DATA_BITTIMING]
= { .len = sizeof(struct can_bittiming) },
[IFLA_CAN_DATA_BITTIMING_CONST]
= { .len = sizeof(struct
can_bittiming_const) },
};
To add IFLA_CAN_TERMINATION we would just need
[IFLA_CAN_TERMINATION] = { .type = NLA_U16 },
to enable a defined termination value from 1 to 65534 Ohms where 65535
would be CAN_RESISTOR_DISABLED. In the CAN driver this given value is
checked against the supported list of termination values and switched on
if supported.
To provide a list of possible termination values with
IFLA_CAN_TERMINATION_CONST we need to pass an array of u16 constants to
the userspace.
In opposite to our current netlink messages this array make contain 1..n
constant values - so defining a fixed struct of e.g. 8 entries looks
like a bad design.
But how to provide the array to the netlink interface correctly?
With the netlink type NLA_UNSPEC, NLA_NESTED, NLA_NESTED_COMPAT or
NLA_BINARY??
See http://lxr.linux.no/#linux+v4.8.10/include/net/netlink.h#L160
The current
[IFLA_CAN_DATA_BITTIMING] = { .len = sizeof(struct can_bittiming_const) },
seems to use NLA_UNSPEC which means the .len value is the _minimum_
length value.
Would this mean we can define
[IFLA_CAN_TERMINATION_CONST] = { .len = sizeof(__u16) },
as a minimum length value and provide as much termination values as the
CAN interface supports?
Regards,
Oliver
^ permalink raw reply
* [PATCH] can: peak: Add support for PCAN-USB X6 USB interface
From: Stephane Grosjean @ 2016-11-25 15:20 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can Mailing List, Stephane Grosjean
This adds support for PEAK-System PCAN-USB X6 USB to CAN interface.
The CAN FD adapter PCAN-USB X6 allows the connection of up to 6 CAN FD
or CAN networks to a computer via USB. The interface is installed in an
aluminum profile casing and is shipped in versions with D-Sub connectors
or M12 circular connectors.
The PCAN-USB X6 registers in the USB sub-system as if 3x PCAN-USB-Pro FD
adapters were plugged. So, this patch:
- updates the PEAK_USB entry of the corresponding Kconfig file
- defines and adds the device id. of the PCAN-USB X6 (0x0014) into the
table of supported device ids
- defines and adds the new software structure implementing the PCAN-USB X6,
which is obviously a clone of the software structure implementing the
PCAN-USB Pro FD.
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
---
drivers/net/can/usb/Kconfig | 3 +-
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 +
drivers/net/can/usb/peak_usb/pcan_usb_core.h | 2 +
drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 72 ++++++++++++++++++++++++++++
4 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/usb/Kconfig b/drivers/net/can/usb/Kconfig
index 8483a40..2bc43e2 100644
--- a/drivers/net/can/usb/Kconfig
+++ b/drivers/net/can/usb/Kconfig
@@ -62,7 +62,7 @@ config CAN_KVASER_USB
module will be called kvaser_usb.
config CAN_PEAK_USB
- tristate "PEAK PCAN-USB/USB Pro interfaces for CAN 2.0b/CAN-FD"
+ tristate "PEAK PCAN-USB/USB Pro/X6 interfaces for CAN 2.0b/CAN-FD"
---help---
This driver supports the PEAK-System Technik USB adapters that enable
access to the CAN bus, with repect to the CAN 2.0b and/or CAN-FD
@@ -72,6 +72,7 @@ config CAN_PEAK_USB
PCAN-USB Pro dual CAN 2.0b channels USB adapter
PCAN-USB FD single CAN-FD channel USB adapter
PCAN-USB Pro FD dual CAN-FD channels USB adapter
+ PCAN-USB X6 6x CAN-FD channels USB adapter
(see also http://www.peak-system.com).
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
index c06382c..f3141ca 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
@@ -39,6 +39,7 @@ static struct usb_device_id peak_usb_table[] = {
{USB_DEVICE(PCAN_USB_VENDOR_ID, PCAN_USBPRO_PRODUCT_ID)},
{USB_DEVICE(PCAN_USB_VENDOR_ID, PCAN_USBFD_PRODUCT_ID)},
{USB_DEVICE(PCAN_USB_VENDOR_ID, PCAN_USBPROFD_PRODUCT_ID)},
+ {USB_DEVICE(PCAN_USB_VENDOR_ID, PCAN_USBX6_PRODUCT_ID)},
{} /* Terminating entry */
};
@@ -50,6 +51,7 @@ static const struct peak_usb_adapter *const peak_usb_adapters_list[] = {
&pcan_usb_pro,
&pcan_usb_fd,
&pcan_usb_pro_fd,
+ &pcan_usb_x6,
};
/*
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.h b/drivers/net/can/usb/peak_usb/pcan_usb_core.h
index 506fe50..3cbfb06 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.h
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.h
@@ -27,6 +27,7 @@
#define PCAN_USBPRO_PRODUCT_ID 0x000d
#define PCAN_USBPROFD_PRODUCT_ID 0x0011
#define PCAN_USBFD_PRODUCT_ID 0x0012
+#define PCAN_USBX6_PRODUCT_ID 0x0014
#define PCAN_USB_DRIVER_NAME "peak_usb"
@@ -90,6 +91,7 @@ extern const struct peak_usb_adapter pcan_usb;
extern const struct peak_usb_adapter pcan_usb_pro;
extern const struct peak_usb_adapter pcan_usb_fd;
extern const struct peak_usb_adapter pcan_usb_pro_fd;
+extern const struct peak_usb_adapter pcan_usb_x6;
struct peak_time_ref {
struct timeval tv_host_0, tv_host;
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
index ce44a03..8eb56a4 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
@@ -1132,3 +1132,75 @@ const struct peak_usb_adapter pcan_usb_pro_fd = {
.do_get_berr_counter = pcan_usb_fd_get_berr_counter,
};
+
+/* describes the PCAN-USB X6 adapter */
+static const struct can_bittiming_const pcan_usb_x6_const = {
+ .name = "pcan_usb_x6",
+ .tseg1_min = 1,
+ .tseg1_max = 64,
+ .tseg2_min = 1,
+ .tseg2_max = 16,
+ .sjw_max = 16,
+ .brp_min = 1,
+ .brp_max = 1024,
+ .brp_inc = 1,
+};
+
+static const struct can_bittiming_const pcan_usb_x6_data_const = {
+ .name = "pcan_usb_x6",
+ .tseg1_min = 1,
+ .tseg1_max = 16,
+ .tseg2_min = 1,
+ .tseg2_max = 8,
+ .sjw_max = 4,
+ .brp_min = 1,
+ .brp_max = 1024,
+ .brp_inc = 1,
+};
+
+const struct peak_usb_adapter pcan_usb_x6 = {
+ .name = "PCAN-USB X6",
+ .device_id = PCAN_USBX6_PRODUCT_ID,
+ .ctrl_count = PCAN_USBPROFD_CHANNEL_COUNT,
+ .ctrlmode_supported = CAN_CTRLMODE_FD |
+ CAN_CTRLMODE_3_SAMPLES | CAN_CTRLMODE_LISTENONLY,
+ .clock = {
+ .freq = PCAN_UFD_CRYSTAL_HZ,
+ },
+ .bittiming_const = &pcan_usb_x6_const,
+ .data_bittiming_const = &pcan_usb_x6_data_const,
+
+ /* size of device private data */
+ .sizeof_dev_private = sizeof(struct pcan_usb_fd_device),
+
+ /* timestamps usage */
+ .ts_used_bits = 32,
+ .ts_period = 1000000, /* calibration period in ts. */
+ .us_per_ts_scale = 1, /* us = (ts * scale) >> shift */
+ .us_per_ts_shift = 0,
+
+ /* give here messages in/out endpoints */
+ .ep_msg_in = PCAN_USBPRO_EP_MSGIN,
+ .ep_msg_out = {PCAN_USBPRO_EP_MSGOUT_0, PCAN_USBPRO_EP_MSGOUT_1},
+
+ /* size of rx/tx usb buffers */
+ .rx_buffer_size = PCAN_UFD_RX_BUFFER_SIZE,
+ .tx_buffer_size = PCAN_UFD_TX_BUFFER_SIZE,
+
+ /* device callbacks */
+ .intf_probe = pcan_usb_pro_probe, /* same as PCAN-USB Pro */
+ .dev_init = pcan_usb_fd_init,
+
+ .dev_exit = pcan_usb_fd_exit,
+ .dev_free = pcan_usb_fd_free,
+ .dev_set_bus = pcan_usb_fd_set_bus,
+ .dev_set_bittiming = pcan_usb_fd_set_bittiming_slow,
+ .dev_set_data_bittiming = pcan_usb_fd_set_bittiming_fast,
+ .dev_decode_buf = pcan_usb_fd_decode_buf,
+ .dev_start = pcan_usb_fd_start,
+ .dev_stop = pcan_usb_fd_stop,
+ .dev_restart_async = pcan_usb_fd_restart_async,
+ .dev_encode_msg = pcan_usb_fd_encode_msg,
+
+ .do_get_berr_counter = pcan_usb_fd_get_berr_counter,
+};
--
2.7.4
^ permalink raw reply related
* Re: pull-request: can 2016-11-23
From: David Miller @ 2016-11-25 21:18 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <20161123143430.24985-1-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 23 Nov 2016 15:34:29 +0100
> this is a pull request for net/master.
>
> The patch by Oliver Hartkopp for the broadcast manager (bcm) fixes the CAN-FD
> support, which may cause an out-of-bounds access otherwise.
Pulled, thanks.
^ permalink raw reply
* bind() Host is down listening on j1939 interfaces
From: Cosmo King @ 2016-11-27 5:33 UTC (permalink / raw)
To: linux-can@vger.kernel.org
Hello,
I'm having a bit of trouble getting the j1939 CAN support working on a Freescale i.MX6 UL.
We are running Debian 3.14.52 kernel on armv7l patched with j1939 support as per http://elinux.org/J1939 and also compiled the latest can-utils from git://github.com/kurt-vd/can-utils and test-can-j1939.
We have a real working can interface on can0 that we start like this:
root@dart3:~# ip link set can0 up type can bitrate 250000
And also added a vcan interface for testing just in case:
root@dart3:~# ip link add can2 type vcan
root@dart3:~# ip link set can2 up
root@dart3:~# ifconfig
can0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:16 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:142
can2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:16 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
testj1939 cannot listen on either can0 or can2. The error is: testj1939: bind(): Host is down
root@dart3:~# testj1939 -r can0:
- socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
- bind(, can0:,,, 24);
testj1939: bind(): Host is down
root@dart3:~# testj1939 -r can2:
- socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
- bind(, can2:,,, 24);
testj1939: bind(): Host is down
I tested this same scenario on a Debian VM with 3.18 kernel and vcan and it worked fine. Any suggestions?
Thank you!
Cosmo
^ permalink raw reply
* Re: wrong CAN frame order in network layer due to SMP?
From: Alexander Stein @ 2016-11-28 9:01 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can, Daniel Krüger
In-Reply-To: <153c7653-ab74-fd0c-c605-7bafe5e44297@hartkopp.net>
On Friday 25 November 2016 12:46:08, Oliver Hartkopp wrote:
> Hello Alexander,
>
> On 11/24/2016 04:49 PM, Alexander Stein wrote:
> > Back to my CAN problem: Only a single core handles USB IRQs and there is
> > apparently no softnet_data race.
> > The test about wrong CAN frame ordering was done on kernel 4.8.9-gentoo
> > but I was also able to reproduce this problem on 3.14.58-gentoo-r1.
> > 3.12.52-gentoo- r1 apparently does not suffer from that problem, at least
> > 3 tries were without errors. In buggy kernels this problems occured next
> > to every time.
> >
> > Any idea what got wrong in the network code about gathering the SKBs
> > which might result in wrong order?
>
> I detected a similar issue in some 3.1x kernel and asked this question:
>
> http://marc.info/?l=linux-can&m=143637774606287&w=2
>
> When you follow the entire discussion at
>
> http://marc.info/?t=143637789700002&r=1&w=2
>
> you will see that they pushed me to implement NAPI on all CAN interfaces
> which neither makes no sense for CAN controllers that do not have a RX
> FIFO (e.g. sja1000) nor fixes the issue at it's root cause.
>
> Your findings bring up the problem again - good :-)
Too bad I didn't know of that post earlier, well never searched for it :-/
> When you look at the networking guys that like to speed up TCP traffic
> and also put skbs into percpu queues that are related to the receiving
> socket(!!!) instance then it should be possible to put CAN skbs related
> to their CAN interfaces into a percpu queue (to suppress out-of-order
> reception).
But wouldn't using queues related to sockets result in different orderings in
different sockets? I've yet to find an erroneous rest run with a non-
conforming candump.
Anyway I don't yet fully understand the complete code and/or data flow up to
the socket once netif_rx() is called.
> IMO the difference is not to queue the skbs for a specific socket but
> for a specific interface.
> The 'endpoint' of CAN frames where they have to be in order is can_rcv()
> in af_can.c and not any TCP instance that needs to reassemble the TCP
> traffic for a specific socket.
Sure, TCP can handle OOO pretty fine. Even for UDP this is not a problem at
all. But isn't using raw sockets on ethernet in promiscuous mode a somewhat
similar scenario? Or to put it in another way: Wouldn't tcpdump or wireshark
suffer from the same problem?
> Can you check whether my suggestion with skb_set_hash() in
> alloc_can_skb() works for you?
For ease of use I didn't change alloc_can_skb() but rather used the patched
inlined below. Using this change and (!)
> echo f > /sys/class/net/can0/queues/rx-0/rps_cpus
3 test runs didn't raise any OOO errors.
But shouldn't the hash type be rather PKT_HASH_TYPE_L4? Otherwise
skb_get_hash() doesn't use skb->hash directly (or at all?). I am aware that L4
is semantically wrong though.
> In any way I think we should start a new attempt to make clear that the
> skbs have to be in order for a specific interface at can_rcv().
> And we need some solution that is enabled by default and fits to the
> netdev guys mindset.
It should not only be enabled by default but rather the only solution with no
way to be disabled/wrong.
Best regards,
Alexander
diff --git a/systec_can.c b/systec_can.c
index b6d9b74..51b2bf6 100644
--- a/systec_can.c
+++ b/systec_can.c
@@ -978,6 +978,8 @@ static void systec_can_rx_can_msg(struct systec_can_chan
*chan, u8 *msg_buf)
return;
}
+ skb_set_hash(skb, chan->netdev->ifindex, PKT_HASH_TYPE_L2);
+
/* get size of data part of CAN message */
cf->can_dlc = get_can_dlc(msg->format & USBCAN_DATAFF_DLC);
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein@systec-electronic.com
Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany
Office: +49 (0) 3765 38600-0
Fax: +49 (0) 3765 38600-4100
Managing Directors:
Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010
^ permalink raw reply related
* Write to can chip, to send with remote request (not earlier)
From: Maaike Zijderveld @ 2016-11-28 9:53 UTC (permalink / raw)
To: linux-can@vger.kernel.org
Hello,
I am trying to rewrite old DOS software to Linux for a machine. We use CAN to communicate with the 'master pc'. I have a PC104 board with Intel i82527 ISA CAN Card. We use remote request in the following way: we write a message to the CAN chip (don't broadcast it yet), so when the CAN card receives a remote request, the message will be sent. So the write to the chip isn't followed by a send command.
The i82527 is not very well supported anymore and the Socketcan driver for this card (CC770_isa) doesn't support remote request. So we have several options, one of the options is another CAN card. It looks like for example Peak has some different CAN cards, I expect all with the same chip. Is it possible to do what I just described with the Peak CAN cards and SocketCAN? Or is there possibly another solution?
It has to work this way, because there is not much space left on the Can bus anymore. So the frames only have to be send on a remote request.
Thanks in advance,
Maaike Zijderveld
Moba B.V., P.O. Box 7, 3770 AA Barneveld Stationsweg 117, The Netherlands, Trade register 09042296.
This message is meant for the addressee only and may contain confidential and legally privileged information. Any unauthorised review, use, copying, storage, disclosure or distribution of this E-mail and any attachments is strictly prohibited. If you are not the named recipient or have otherwise received this communication in error, please destroy this message from your system and kindly notify the sender by E-mail. Thank you for your co-operation.
It's time for a new standard. <http://www.moba.net/page/en/Omnia-PX>
^ permalink raw reply
* Re: Write to can chip, to send with remote request (not earlier)
From: Oliver Hartkopp @ 2016-11-28 17:51 UTC (permalink / raw)
To: Maaike Zijderveld, linux-can@vger.kernel.org
In-Reply-To: <3b3e6879fc5a490d9124872e13f0e94b@NLBS117EDAG1.moba-bv.local>
Hello Maaike,
On 11/28/2016 10:53 AM, Maaike Zijderveld wrote:
> I am trying to rewrite old DOS software to Linux for a machine. We use CAN to communicate with the 'master pc'. I have a PC104 board with Intel i82527 ISA CAN Card. We use remote request in the following way: we write a message to the CAN chip (don't broadcast it yet), so when the CAN card receives a remote request, the message will be sent. So the write to the chip isn't followed by a send command.
>
> The i82527 is not very well supported anymore and the Socketcan driver for this card (CC770_isa) doesn't support remote request. So we have several options, one of the options is another CAN card. It looks like for example Peak has some different CAN cards, I expect all with the same chip. Is it possible to do what I just described with the Peak CAN cards and SocketCAN? Or is there possibly another solution?
>
> It has to work this way, because there is not much space left on the Can bus anymore. So the frames only have to be send on a remote request.
using special CAN controller mechanisms to write CAN frames to the CAN
controller that are not sent - but stored to some TX object to perform
RTR answers - is not supported by now.
But there's a solution to perform RTR with every existing CAN controller
(including c770) by using the RTR functionality of the CAN broadcast
manager (BCM).
See example at:
https://github.com/linux-can/can-tests/blob/master/tst-bcm-rtr.c
Regards,
Oliver
^ permalink raw reply
* Re: wrong CAN frame order in network layer due to SMP?
From: Oliver Hartkopp @ 2016-11-28 20:36 UTC (permalink / raw)
To: Alexander Stein; +Cc: linux-can, Daniel Krüger
In-Reply-To: <3312577.WzoMqUrz0A@ws-stein>
On 11/28/2016 10:01 AM, Alexander Stein wrote:
> On Friday 25 November 2016 12:46:08, Oliver Hartkopp wrote:
>> When you look at the networking guys that like to speed up TCP traffic
>> and also put skbs into percpu queues that are related to the receiving
>> socket(!!!) instance then it should be possible to put CAN skbs related
>> to their CAN interfaces into a percpu queue (to suppress out-of-order
>> reception).
>
> But wouldn't using queues related to sockets result in different orderings in
> different sockets? I've yet to find an erroneous rest run with a non-
> conforming candump.
> Anyway I don't yet fully understand the complete code and/or data flow up to
> the socket once netif_rx() is called.
>
/me too
>> IMO the difference is not to queue the skbs for a specific socket but
>> for a specific interface.
>> The 'endpoint' of CAN frames where they have to be in order is can_rcv()
>> in af_can.c and not any TCP instance that needs to reassemble the TCP
>> traffic for a specific socket.
>
> Sure, TCP can handle OOO pretty fine. Even for UDP this is not a problem at
> all. But isn't using raw sockets on ethernet in promiscuous mode a somewhat
> similar scenario? Or to put it in another way: Wouldn't tcpdump or wireshark
> suffer from the same problem?
Hm - I pushed Wireshark and libpcap to remove PF_CAN support and
implement the CAN dissectors based on PF_PACKET:
Wireshark bug/feature request:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12687
libpcap:
https://github.com/the-tcpdump-group/libpcap/commit/93ca5ff7030aaf1219e1de05ec89a68384bfc50b
Wireshark CAN/CANFD dissector:
https://code.wireshark.org/review/#/c/16787/
Commit:
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=7fad354a3e379382368cd1ef67b841315c29e050
But you need to build the latest libpcap & Wireshark to use the
PF_PACKET flavour in Wireshark.
IIRC Wireshark puts the PF_PACKET socket into some special 'tpacket'
mode and I don't know whether this has any impact on frame ordering.
At least you may check for:
https://github.com/linux-can/can-tests/blob/master/tst-packet.c
... if there's a difference between PF_PACKET and PF_CAN with your OOO
setup.
Regards,
Oliver
^ permalink raw reply
* Re: wrong CAN frame order in network layer due to SMP?
From: Alexander Stein @ 2016-11-29 10:30 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can, Daniel Krüger
In-Reply-To: <c9a4e53c-42f8-c982-e701-0259fb1ac67b@hartkopp.net>
Hello Oliver,
On Monday 28 November 2016 21:36:09, Oliver Hartkopp wrote:
> >> IMO the difference is not to queue the skbs for a specific socket but
> >> for a specific interface.
> >> The 'endpoint' of CAN frames where they have to be in order is can_rcv()
> >> in af_can.c and not any TCP instance that needs to reassemble the TCP
> >> traffic for a specific socket.
> >
> > Sure, TCP can handle OOO pretty fine. Even for UDP this is not a problem
> > at
> > all. But isn't using raw sockets on ethernet in promiscuous mode a
> > somewhat
> > similar scenario? Or to put it in another way: Wouldn't tcpdump or
> > wireshark suffer from the same problem?
>
> Hm - I pushed Wireshark and libpcap to remove PF_CAN support and
> implement the CAN dissectors based on PF_PACKET:
>
> Wireshark bug/feature request:
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12687
>
> libpcap:
> https://github.com/the-tcpdump-group/libpcap/commit/93ca5ff7030aaf1219e1de05
> ec89a68384bfc50b
>
> Wireshark CAN/CANFD dissector:
> https://code.wireshark.org/review/#/c/16787/
>
> Commit:
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=7fad
> 354a3e379382368cd1ef67b841315c29e050
>
> But you need to build the latest libpcap & Wireshark to use the
> PF_PACKET flavour in Wireshark.
>
> IIRC Wireshark puts the PF_PACKET socket into some special 'tpacket'
> mode and I don't know whether this has any impact on frame ordering.
>
> At least you may check for:
> https://github.com/linux-can/can-tests/blob/master/tst-packet.c
>
> ... if there's a difference between PF_PACKET and PF_CAN with your OOO
> setup.
Nope, apparently there is no difference. Got similar results.
On a side note: I captured an 30 seconds iperf3 run with wireshark 2.2.2 using
the "ASIX Electronics Corp. AX88179 Gigabit Ethernet" adapter (driver:
ax88179_178a).
AFAICS this driver (well usbnet in the end) doesn't use NAPI either and
therefore unsurprisingly I got OOO of TCP frames.
IMHO this is not acceptable at all.
Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein@systec-electronic.com
Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany
Office: +49 (0) 3765 38600-0
Fax: +49 (0) 3765 38600-4100
Managing Directors:
Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010
^ permalink raw reply
* [PATCH net-next] net: can: usb: kvaser_usb: fix spelling mistake of "outstanding"
From: Colin King @ 2016-11-29 16:27 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, Jimmy Assarsson,
Wolfram Sang, David S . Miller, linux-can, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake "oustanding" to "outstanding" in
comment and dev_dbg message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/can/usb/kvaser_usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index d51e0c4..18cc529 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -459,7 +459,7 @@ struct kvaser_usb {
struct usb_endpoint_descriptor *bulk_in, *bulk_out;
struct usb_anchor rx_submitted;
- /* @max_tx_urbs: Firmware-reported maximum number of oustanding,
+ /* @max_tx_urbs: Firmware-reported maximum number of outstanding,
* not yet ACKed, transmissions on this device. This value is
* also used as a sentinel for marking free tx contexts.
*/
@@ -2027,7 +2027,7 @@ static int kvaser_usb_probe(struct usb_interface *intf,
((dev->fw_version >> 16) & 0xff),
(dev->fw_version & 0xffff));
- dev_dbg(&intf->dev, "Max oustanding tx = %d URBs\n", dev->max_tx_urbs);
+ dev_dbg(&intf->dev, "Max outstanding tx = %d URBs\n", dev->max_tx_urbs);
err = kvaser_usb_get_card_info(dev);
if (err) {
--
2.10.2
^ permalink raw reply related
* Re: wrong CAN frame order in network layer due to SMP?
From: Oliver Hartkopp @ 2016-11-29 19:48 UTC (permalink / raw)
To: Alexander Stein; +Cc: linux-can, Daniel Krüger
In-Reply-To: <5633679.WId9jP25Qd@ws-stein>
Hello Alexander,
On 11/29/2016 11:30 AM, Alexander Stein wrote:
> On Monday 28 November 2016 21:36:09, Oliver Hartkopp wrote:
>> IIRC Wireshark puts the PF_PACKET socket into some special 'tpacket'
>> mode and I don't know whether this has any impact on frame ordering.
>>
>> At least you may check for:
>> https://github.com/linux-can/can-tests/blob/master/tst-packet.c
>>
>> ... if there's a difference between PF_PACKET and PF_CAN with your OOO
>> setup.
>
> Nope, apparently there is no difference. Got similar results.
>
> On a side note: I captured an 30 seconds iperf3 run with wireshark 2.2.2 using
> the "ASIX Electronics Corp. AX88179 Gigabit Ethernet" adapter (driver:
> ax88179_178a).
> AFAICS this driver (well usbnet in the end) doesn't use NAPI either and
> therefore unsurprisingly I got OOO of TCP frames.
> IMHO this is not acceptable at all.
Did you have a TCP socket on the receiving host as endpoint for your
communication?
Maybe this could be named a 'general regression' then. And when this is
fixed our problem hopefully gets fixed too ;-)
Regards,
Oliver
^ permalink raw reply
* Re: wrong CAN frame order in network layer due to SMP?
From: Alexander Stein @ 2016-11-30 7:23 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can, Daniel Krüger
In-Reply-To: <45353231-7efa-7feb-b52d-569a88317cdf@hartkopp.net>
On Tuesday 29 November 2016 20:48:09, Oliver Hartkopp wrote:
> Hello Alexander,
>
> On 11/29/2016 11:30 AM, Alexander Stein wrote:
> > On Monday 28 November 2016 21:36:09, Oliver Hartkopp wrote:
> >> IIRC Wireshark puts the PF_PACKET socket into some special 'tpacket'
> >> mode and I don't know whether this has any impact on frame ordering.
> >>
> >> At least you may check for:
> >> https://github.com/linux-can/can-tests/blob/master/tst-packet.c
> >>
> >> ... if there's a difference between PF_PACKET and PF_CAN with your OOO
> >> setup.
> >
> > Nope, apparently there is no difference. Got similar results.
> >
> > On a side note: I captured an 30 seconds iperf3 run with wireshark 2.2.2
> > using the "ASIX Electronics Corp. AX88179 Gigabit Ethernet" adapter
> > (driver: ax88179_178a).
> > AFAICS this driver (well usbnet in the end) doesn't use NAPI either and
> > therefore unsurprisingly I got OOO of TCP frames.
> > IMHO this is not acceptable at all.
>
> Did you have a TCP socket on the receiving host as endpoint for your
> communication?
Yep. straight iperf3 run. Here is a snippet from the wireshark capture:
82102 0.759823467 192.168.8.7 192.168.8.128 TCP 34564→5201 [ACK] Seq=79054502 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82103 0.759823627 192.168.8.7 192.168.8.128 TCP 34564→5201 [ACK] Seq=79055950 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82104 0.759831475 192.168.8.128 192.168.8.7 TCP 5201→34564 [ACK] Seq=1 Ack=79057398 Win=677760 Len=0 TSval=411321994 TSecr=409657
82105 0.759823818 192.168.8.7 192.168.8.128 TCP 34564→5201 [ACK] Seq=79057398 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82106 0.759823894 192.168.8.7 192.168.8.128 TCP 34564→5201 [ACK] Seq=79058846 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82107 *REF* 192.168.8.128 192.168.8.7 TCP 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321994 TSecr=409657
82108 -0.000012137 192.168.8.7 192.168.8.128 TCP [TCP Out-Of-Order] 34564→5201 [ACK] Seq=78738838 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82109 0.000003981 192.168.8.128 192.168.8.7 TCP [TCP Dup ACK 82107#1] 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321994 TSecr=409657 SLE=78738838 SRE=78740286
82110 -0.000011999 192.168.8.7 192.168.8.128 TCP [TCP Out-Of-Order] 34564→5201 [ACK] Seq=78740286 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82111 0.000007932 192.168.8.128 192.168.8.7 TCP [TCP Dup ACK 82107#2] 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321994 TSecr=409657 SLE=78740286 SRE=78741734
82112 0.000066782 192.168.8.7 192.168.8.128 TCP [TCP Out-Of-Order] 34564→5201 [ACK] Seq=78741734 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82113 0.000069480 192.168.8.128 192.168.8.7 TCP [TCP Dup ACK 82107#3] 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321995 TSecr=409657 SLE=78741734 SRE=78743182
82114 0.000066949 192.168.8.7 192.168.8.128 TCP [TCP Out-Of-Order] 34564→5201 [ACK] Seq=78743182 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82115 0.000071730 192.168.8.128 192.168.8.7 TCP [TCP Dup ACK 82107#4] 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321995 TSecr=409657 SLE=78743182 SRE=78744630
192.168.8.128 is the receiver
192.168.8.128 is the sender
direct connection without any switch
TCP is used
I put a time ref at packet 82107 so you can see more easily the negative relative timestamp of some following packets.
> Maybe this could be named a 'general regression' then. And when this is
> fixed our problem hopefully gets fixed too ;-)
I guess the network guys will also say: Use NAPI. IMHO there shouldn't be an API which allows OOO in the first place.
Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein@systec-electronic.com
Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany
Office: +49 (0) 3765 38600-0
Fax: +49 (0) 3765 38600-4100
Managing Directors:
Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010
^ permalink raw reply
* Re: [PATCH v2 00/12] can: rx-offload: add implmentation and switch flexcan driver to use it
From: Alexander Stein @ 2016-11-30 14:22 UTC (permalink / raw)
To: Marc Kleine-Budde, Daniel Krüger; +Cc: linux-can
In-Reply-To: <1467657137-18891-1-git-send-email-mkl@pengutronix.de>
On Monday 04 July 2016 20:32:05, Marc Kleine-Budde wrote:
> Hello,
>
> this patch takes up the idea to read the CAN frames in IRQ context and send
> them later in NAPI. The first two patches add each an offloading scheme.
>
> The first one is for hardware FIFO based cores, like the flexcan in FIFO
> mode. The second one requires mailboxes with timestamps. The mailboxes are
> read and sorted by timestamp in IRQ context, sending is done later in NAPI
> aswell.
>
> The remaining patches modify the flexcan driver to make use of it. imx6 and
> vf610 SoCs can make use of the 64 mailbox software FIFO, while older SoCs
> still use flexcan's 6 mailbox deep hardware FIFO.
>
> Testing on any flexcan core is highly appreciated.
What is the status of this patchset?
Best regards,
Alexander
^ permalink raw reply
* Re: [PATCH] can: peak: Add support for PCAN-USB X6 USB interface
From: Oliver Hartkopp @ 2016-11-30 17:21 UTC (permalink / raw)
To: Stephane Grosjean, Marc Kleine-Budde; +Cc: linux-can Mailing List
In-Reply-To: <1480087252-32411-1-git-send-email-s.grosjean@peak-system.com>
On 11/25/2016 04:20 PM, Stephane Grosjean wrote:
> This adds support for PEAK-System PCAN-USB X6 USB to CAN interface.
>
> The CAN FD adapter PCAN-USB X6 allows the connection of up to 6 CAN FD
> or CAN networks to a computer via USB. The interface is installed in an
> aluminum profile casing and is shipped in versions with D-Sub connectors
> or M12 circular connectors.
>
> The PCAN-USB X6 registers in the USB sub-system as if 3x PCAN-USB-Pro FD
> adapters were plugged. So, this patch:
>
> - updates the PEAK_USB entry of the corresponding Kconfig file
> - defines and adds the device id. of the PCAN-USB X6 (0x0014) into the
> table of supported device ids
> - defines and adds the new software structure implementing the PCAN-USB X6,
> which is obviously a clone of the software structure implementing the
> PCAN-USB Pro FD.
>
> Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Got my X6 today and was able to instantly use it with your patch :-)
Many thanks,
Oliver
> ---
> drivers/net/can/usb/Kconfig | 3 +-
> drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 +
> drivers/net/can/usb/peak_usb/pcan_usb_core.h | 2 +
> drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 72 ++++++++++++++++++++++++++++
> 4 files changed, 78 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/usb/Kconfig b/drivers/net/can/usb/Kconfig
> index 8483a40..2bc43e2 100644
> --- a/drivers/net/can/usb/Kconfig
> +++ b/drivers/net/can/usb/Kconfig
> @@ -62,7 +62,7 @@ config CAN_KVASER_USB
> module will be called kvaser_usb.
>
> config CAN_PEAK_USB
> - tristate "PEAK PCAN-USB/USB Pro interfaces for CAN 2.0b/CAN-FD"
> + tristate "PEAK PCAN-USB/USB Pro/X6 interfaces for CAN 2.0b/CAN-FD"
> ---help---
> This driver supports the PEAK-System Technik USB adapters that enable
> access to the CAN bus, with repect to the CAN 2.0b and/or CAN-FD
> @@ -72,6 +72,7 @@ config CAN_PEAK_USB
> PCAN-USB Pro dual CAN 2.0b channels USB adapter
> PCAN-USB FD single CAN-FD channel USB adapter
> PCAN-USB Pro FD dual CAN-FD channels USB adapter
> + PCAN-USB X6 6x CAN-FD channels USB adapter
>
> (see also http://www.peak-system.com).
>
> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> index c06382c..f3141ca 100644
> --- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> +++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> @@ -39,6 +39,7 @@ static struct usb_device_id peak_usb_table[] = {
> {USB_DEVICE(PCAN_USB_VENDOR_ID, PCAN_USBPRO_PRODUCT_ID)},
> {USB_DEVICE(PCAN_USB_VENDOR_ID, PCAN_USBFD_PRODUCT_ID)},
> {USB_DEVICE(PCAN_USB_VENDOR_ID, PCAN_USBPROFD_PRODUCT_ID)},
> + {USB_DEVICE(PCAN_USB_VENDOR_ID, PCAN_USBX6_PRODUCT_ID)},
> {} /* Terminating entry */
> };
>
> @@ -50,6 +51,7 @@ static const struct peak_usb_adapter *const peak_usb_adapters_list[] = {
> &pcan_usb_pro,
> &pcan_usb_fd,
> &pcan_usb_pro_fd,
> + &pcan_usb_x6,
> };
>
> /*
> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.h b/drivers/net/can/usb/peak_usb/pcan_usb_core.h
> index 506fe50..3cbfb06 100644
> --- a/drivers/net/can/usb/peak_usb/pcan_usb_core.h
> +++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.h
> @@ -27,6 +27,7 @@
> #define PCAN_USBPRO_PRODUCT_ID 0x000d
> #define PCAN_USBPROFD_PRODUCT_ID 0x0011
> #define PCAN_USBFD_PRODUCT_ID 0x0012
> +#define PCAN_USBX6_PRODUCT_ID 0x0014
>
> #define PCAN_USB_DRIVER_NAME "peak_usb"
>
> @@ -90,6 +91,7 @@ extern const struct peak_usb_adapter pcan_usb;
> extern const struct peak_usb_adapter pcan_usb_pro;
> extern const struct peak_usb_adapter pcan_usb_fd;
> extern const struct peak_usb_adapter pcan_usb_pro_fd;
> +extern const struct peak_usb_adapter pcan_usb_x6;
>
> struct peak_time_ref {
> struct timeval tv_host_0, tv_host;
> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
> index ce44a03..8eb56a4 100644
> --- a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
> +++ b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
> @@ -1132,3 +1132,75 @@ const struct peak_usb_adapter pcan_usb_pro_fd = {
>
> .do_get_berr_counter = pcan_usb_fd_get_berr_counter,
> };
> +
> +/* describes the PCAN-USB X6 adapter */
> +static const struct can_bittiming_const pcan_usb_x6_const = {
> + .name = "pcan_usb_x6",
> + .tseg1_min = 1,
> + .tseg1_max = 64,
> + .tseg2_min = 1,
> + .tseg2_max = 16,
> + .sjw_max = 16,
> + .brp_min = 1,
> + .brp_max = 1024,
> + .brp_inc = 1,
> +};
> +
> +static const struct can_bittiming_const pcan_usb_x6_data_const = {
> + .name = "pcan_usb_x6",
> + .tseg1_min = 1,
> + .tseg1_max = 16,
> + .tseg2_min = 1,
> + .tseg2_max = 8,
> + .sjw_max = 4,
> + .brp_min = 1,
> + .brp_max = 1024,
> + .brp_inc = 1,
> +};
> +
> +const struct peak_usb_adapter pcan_usb_x6 = {
> + .name = "PCAN-USB X6",
> + .device_id = PCAN_USBX6_PRODUCT_ID,
> + .ctrl_count = PCAN_USBPROFD_CHANNEL_COUNT,
> + .ctrlmode_supported = CAN_CTRLMODE_FD |
> + CAN_CTRLMODE_3_SAMPLES | CAN_CTRLMODE_LISTENONLY,
> + .clock = {
> + .freq = PCAN_UFD_CRYSTAL_HZ,
> + },
> + .bittiming_const = &pcan_usb_x6_const,
> + .data_bittiming_const = &pcan_usb_x6_data_const,
> +
> + /* size of device private data */
> + .sizeof_dev_private = sizeof(struct pcan_usb_fd_device),
> +
> + /* timestamps usage */
> + .ts_used_bits = 32,
> + .ts_period = 1000000, /* calibration period in ts. */
> + .us_per_ts_scale = 1, /* us = (ts * scale) >> shift */
> + .us_per_ts_shift = 0,
> +
> + /* give here messages in/out endpoints */
> + .ep_msg_in = PCAN_USBPRO_EP_MSGIN,
> + .ep_msg_out = {PCAN_USBPRO_EP_MSGOUT_0, PCAN_USBPRO_EP_MSGOUT_1},
> +
> + /* size of rx/tx usb buffers */
> + .rx_buffer_size = PCAN_UFD_RX_BUFFER_SIZE,
> + .tx_buffer_size = PCAN_UFD_TX_BUFFER_SIZE,
> +
> + /* device callbacks */
> + .intf_probe = pcan_usb_pro_probe, /* same as PCAN-USB Pro */
> + .dev_init = pcan_usb_fd_init,
> +
> + .dev_exit = pcan_usb_fd_exit,
> + .dev_free = pcan_usb_fd_free,
> + .dev_set_bus = pcan_usb_fd_set_bus,
> + .dev_set_bittiming = pcan_usb_fd_set_bittiming_slow,
> + .dev_set_data_bittiming = pcan_usb_fd_set_bittiming_fast,
> + .dev_decode_buf = pcan_usb_fd_decode_buf,
> + .dev_start = pcan_usb_fd_start,
> + .dev_stop = pcan_usb_fd_stop,
> + .dev_restart_async = pcan_usb_fd_restart_async,
> + .dev_encode_msg = pcan_usb_fd_encode_msg,
> +
> + .do_get_berr_counter = pcan_usb_fd_get_berr_counter,
> +};
>
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: r8a7796: Add CAN support
From: Rob Herring @ 2016-11-30 20:36 UTC (permalink / raw)
To: Chris Paterson
Cc: Simon Horman, Wolfgang Grandegger, Marc Kleine-Budde, Magnus Damm,
Mark Rutland, Ramesh Shanmugasundaram, linux-renesas-soc,
devicetree, linux-arm-kernel, linux-can
In-Reply-To: <1479903279-1950-1-git-send-email-chris.paterson2@renesas.com>
On Wed, Nov 23, 2016 at 12:14:39PM +0000, Chris Paterson wrote:
> Adds CAN controller nodes for r8a7796.
>
> Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
>
> Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
> ---
> .../devicetree/bindings/net/can/rcar_can.txt | 12 +++++----
> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 30 ++++++++++++++++++++++
> 2 files changed, 37 insertions(+), 5 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: r8a7796: Add CAN FD support
From: Rob Herring @ 2016-11-30 20:37 UTC (permalink / raw)
To: Chris Paterson
Cc: Simon Horman, Wolfgang Grandegger, Marc Kleine-Budde, Magnus Damm,
Mark Rutland, Ramesh Shanmugasundaram,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-can-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479903288-2009-1-git-send-email-chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Wed, Nov 23, 2016 at 12:14:48PM +0000, Chris Paterson wrote:
> Adds CAN FD controller node for r8a7796.
>
> Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
>
> Signed-off-by: Chris Paterson <chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> ---
> .../devicetree/bindings/net/can/rcar_canfd.txt | 12 ++++++-----
> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 24 ++++++++++++++++++++++
> 2 files changed, 31 insertions(+), 5 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
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