* RE: [PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can support
From: Fabrizio Castro @ 2017-12-19 10:17 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Simon Horman, Geert Uytterhoeven, linux-can@vger.kernel.org,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Chris Paterson, Biju Das,
Fabrizio Castro, Wolfgang Grandegger, Rob Herring, Mark Rutland
In-Reply-To: <1510067449-17017-2-git-send-email-fabrizio.castro@bp.renesas.com>
Hello Marc,
does this patch look ok to you?
Thanks,
Fab
> Subject: [PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can support
>
> Document "renesas,can-r8a7743" and "renesas,can-r8a7745" compatible
> strings. Since the fallback compatible string ("renesas,rcar-gen2-can")
> activates the right code in the driver, no driver change is needed.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/net/can/rcar_can.txt | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> index 06bb7cc..94a7f33 100644
> --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
> +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> @@ -2,7 +2,9 @@ Renesas R-Car CAN controller Device Tree Bindings
> -------------------------------------------------
>
> Required properties:
> -- compatible: "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
> +- compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC.
> + "renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC.
> + "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
> "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC.
> "renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC.
> "renesas,can-r8a7791" if CAN controller is a part of R8A7791 SoC.
> @@ -12,7 +14,8 @@ Required properties:
> "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-gen2-can" for a generic R-Car Gen2 or RZ/G1
> + compatible device.
> "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
> When compatible with the generic version, nodes must list the
> SoC-specific version corresponding to the platform first
> --
> 2.7.4
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* [PATCH] flex_can: Fix checking can_dlc
From: Luu An Phu @ 2017-12-19 8:40 UTC (permalink / raw)
To: wg, mkl; +Cc: linux-can, netdev, stefan-gabriel.mirea, phu.luuan
From: "phu.luuan" <phu.luuan@nxp.com>
flexcan_start_xmit should write data to register when can_dlc > 4.
Because can_dlc is data length and it has value from 1 to 8. But CAN data
index has value from 0 to 7. So in case we have data in cf->data[4],
the can_dlc has value is more than 4.
Signed-off-by: Luu An Phu <phu.luuan@nxp.com>
---
drivers/net/can/flexcan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 0626dcf..0e3ff13 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -5,6 +5,7 @@
* Copyright (c) 2009 Sascha Hauer, Pengutronix
* Copyright (c) 2010-2017 Pengutronix, Marc Kleine-Budde <kernel@pengutronix.de>
* Copyright (c) 2014 David Jander, Protonic Holland
+ * Copyright 2017 NXP
*
* Based on code originally by Andrey Volkov <avolkov@varma-el.com>
*
@@ -526,7 +527,7 @@ static int flexcan_start_xmit(struct sk_buff *skb, struct net_device *dev)
data = be32_to_cpup((__be32 *)&cf->data[0]);
flexcan_write(data, &priv->tx_mb->data[0]);
}
- if (cf->can_dlc > 3) {
+ if (cf->can_dlc > 4) {
data = be32_to_cpup((__be32 *)&cf->data[4]);
flexcan_write(data, &priv->tx_mb->data[1]);
}
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] can: rcar_can: document r8a77995 (R-Car D3) compatibility strings
From: Ulrich Hecht @ 2017-12-18 15:51 UTC (permalink / raw)
To: linux-renesas-soc
Cc: linux-can, devicetree, wsa, horms, geert, magnus.damm,
chris.paterson2, ramesh.shanmugasundaram, robh, Ulrich Hecht
In-Reply-To: <1513612297-10173-1-git-send-email-ulrich.hecht+renesas@gmail.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/net/can/rcar_can.txt | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 06bb7cc..f7d0358 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -11,6 +11,7 @@ Required properties:
"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,can-r8a77995" if CAN controller is a part of R8A77995 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.
@@ -25,12 +26,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" 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:
+Required properties for "renesas,can-r8a7795", "renesas,can-r8a7796" and
+"renesas,can-r8a77995" compatible:
+In R8A7795, R8A7796 and R8A77995 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.
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] can: rcar_canfd: document r8a77995 (R-Car D3) compatibility strings
From: Ulrich Hecht @ 2017-12-18 15:51 UTC (permalink / raw)
To: linux-renesas-soc
Cc: linux-can, devicetree, wsa, horms, geert, magnus.damm,
chris.paterson2, ramesh.shanmugasundaram, robh, Ulrich Hecht
In-Reply-To: <1513612297-10173-1-git-send-email-ulrich.hecht+renesas@gmail.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
index 93c3a6a..eeb9fec 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -6,6 +6,7 @@ Required properties:
- "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.
+ - "renesas,r8a77995-canfd" for R8A77995 (R-Car D3) compatible controller.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first, followed by the
@@ -24,12 +25,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" 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:
+Required properties for "renesas,r8a7795-canfd", "renesas,r8a7796-canfd" and
+"renesas,r8a77995-canfd" compatible:
+In R8A7795, R8A7796 and R8A77995 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.
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/2] R-Car D3 (r8a77995) CAN support
From: Ulrich Hecht @ 2017-12-18 15:51 UTC (permalink / raw)
To: linux-renesas-soc
Cc: linux-can, devicetree, wsa, horms, geert, magnus.damm,
chris.paterson2, ramesh.shanmugasundaram, robh, Ulrich Hecht
Hi!
These two patches are the leftovers of the "CAN for D3" series; as far
as I can tell, everything else has been picked up.
This revision fixes a copy/paste error and adds Acks and Reviewed-Bys.
CU
Uli
Ulrich Hecht (2):
can: rcar_can: document r8a77995 (R-Car D3) compatibility strings
can: rcar_canfd: document r8a77995 (R-Car D3) compatibility strings
Documentation/devicetree/bindings/net/can/rcar_can.txt | 13 +++++++------
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 13 +++++++------
2 files changed, 14 insertions(+), 12 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH 1/2] dt-binding: can: mcp2517fd: document device tree bindings
From: kernel-TqfNSX0MhmxHKSADF0wUEw @ 2017-12-17 14:34 UTC (permalink / raw)
To: Patrick Menschel; +Cc: linux-can-u79uwXL29TY76Z2rM5mHXA, devicetree
In-Reply-To: <d79ee9eb-8b36-0086-8d76-ec6bca224fe5-1KBjaw7Xf1+zQB+pC5nmwQ@public.gmane.org>
Hi Patrick!
So I started implementing the GPIO_LIB implementation but
I have hit an issue where I would like to get some feedback.
So in principle the gpiolib works, but only if the device is
not asleep and the clock is enabled, which at this very moment means
that the can interface has to be up and running.
So at this very moment the only option that I see would be to
disable the sleep mode which the device enters after probing until
the can-network interface is enabled (which enables the clock and
start the oscillator) - with SLEEP enabled when GPIOLIB support
is disabled.
This is obviously not optimal from the power perspective…
The other option would be starting the clock and oscillator
as soon as a set_direction* (or reques/free) function is called.
(where I would need to start using locks to avoid race conditions
as well as clock usage counters...).
Which of the above is the preferred solution? Are there other ideas
how I could solve this dilemma?
Martin
> On 05.12.2017, at 19:28, Patrick Menschel <menschel.p-1KBjaw7Xf1+zQB+pC5nmwQ@public.gmane.org> wrote:
>
> Hi Martin,
>
> it depends on the daily usage of those alternate functions.
> I just took a quick glimpse on the datasheet and if you check appendix B table 9-1 , you'll see that some functions are optional because ISO suggested them, not because there is a practical reason for it.
>
> CLKO/SOF does make little to no sense with a higher grade embedded system. CLKO is meant to share the osc with the microcontroller.
>> The CLKO pin provides the clock to the
>> microcontroller.
> SOF makes sense for testing in lab configuration, not for regular operation.
>
> TXCAN also does make little sense as you can only use it in the lab.
>> TXCANOD: TXCAN can be configured as Push-
>> Pull or as Open Drain out
>> put. Open Drain outputs
>> allows the user to connect multiple controllers
>> together to build a CAN network without using a
>> transceiver.
>
> INTOD is initialized as Push/Pull. Configuring it open drain would be processor specific when the microcontroller has limited options for pin-ctrl, e.g. some PICs.
>> INTOD:
>> Interrupt pins Open Drain Mode
>> 1
>> = Open Drain Output
>> 0
>> = Push/Pull Output
>
> To sum it up, I would drop:
> - CLKO/SOF
> - TXCAN
> - INTOD
>
> I would implement higher level functions in a second step for INT0/GPIO0/XSTBY and INT1/GPIO1.
> Such functions can be:
> - power saving via XSTBY
> - RX / TX LEDs via INT0 / INT1
>
> Actually this second step would wait until a request for feature arises.
>
> Regards,
> Patrick
>
> Am 05.12.2017 um 11:26 schrieb Martin Sperl:
>> Hi Patrick!
>>
>>
>> I had a quick look starting to implement gpiolib,
>>
>> but I believe I would need to implement pin-ctrl on top to
>>
>> make the Alternate functions work propperly.
>>
>> I wonder if this effort is really worth it.
>>
>> Martin
>>
--
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: Can: FD: configure transmitter delay
From: Oliver Hartkopp @ 2017-12-16 20:15 UTC (permalink / raw)
To: kernel; +Cc: linux-can
In-Reply-To: <CABC43F0-0119-483E-BBBC-8693946036A9@martin.sperl.org>
Hello Martin,
I took a look at the M_CAN manual e.g. at
https://github.com/hartkopp/M_CAN-User-Manual-History/blob/master/mcan_users_manual_v3212.pdf
and there's a switch in register Data Bit Timing & Prescaler Register
(DBTP) on PDF page 16 and some Transmitter Delay Compensation Offset in
the TDCR register (PDF page 27).
So IMO it looks like we need to introduce some additional netlink
attribute for the Transmitter Delay Compensation in
linux/include/uapi/linux/can/netlink.h , e.g.:
struct can_trx_delay_compensation {
__u8 mode; /* enum off=0, on=1 , auto=2 */
__u8 offset; /* 0 to 127 mtq */
__u8 filter_window_length; /* 0 to 127 mtq */
}
and introduce a new
IFLA_CAN_TRX_DELAY_COMPENSATION,
netlink command.
The idea for struct can_trx_delay_compensation is roughly picked from
the M_CAN register API as I personally would prefer unsigned values to
signed offsets that are suggested in the TDCO value from mcp2517fd.
But this would be just a suggestion.
Any comments/ideas on this?
Best regards,
Oliver
On 12/15/2017 07:31 PM, kernel@martin.sperl.org wrote:
> Maybe one observation that I have made that may be of interest is
> that changing the sample-point from .75 to .80 makes the reception work
> again.
>
> But that only works when the sample points are changed to the same value!
> e.g: sample-point .8 dsample-point .8
>
> Otherwise things show errors and the message is eventually received.
>
> So it seems that the sample-points really becomes sensitive
> (at least on the mcp2517fd) and a different default than .75 may be
> “recommended” when using CanFD.
>
> Martin
>
>
>
>> On 09.12.2017, at 19:48, Martin Sperl <kernel@martin.sperl.org> wrote:
>>
>>
>> As far as I can tell dsample-point is the definition of the first
>> sample point of a data bit (in % of the bit length). It would not
>> define the 2nd sample point that would be defined by
>> transmitter delay.
>>
>> Also how would one parametrize: off, fixed or auto with this
>> parameter(where with auto part of the parameter would be
>> Automatic, but parts would be fixed?
>>
>> I understand we need to come to a common denominator.
>>
>> So maybe it would help summarize the parameters for each
>> Device to figure out what is common.
>>
>> Here the info for the mcp2517fd:
>>
>> bit 17-16 TDCMOD<1:0>: Transmitter Delay Compensation Mode bits; Secondary Sample Point (SSP) 10-11 = Auto; measure delay and add TDCO. 01 = Manual; Don't measure, use TDCV + TDCO from register 00 = TDC Disabled
>> bit 14-8 TDCO<6:0>: Transmitter Delay Compensation Offset bits; Secondary Sample Point (SSP) Two's complement; offset can be positive, zero, or negative. 011 1111 = 63 x TSYSCLK ... 000 0000 = 0 x TSYSCLK ... 111 1111 = –64 x TSYSCLK
>> bit 5-0 TDCV<5:0>: Transmitter Delay Compensation Value bits; Secondary Sample Point (SSP) 11 1111 = 63 x TSYSCLK ... 00 0000 = 0 x TSYSCLK
>>
>> What the microchip reference implementation does is define auto
>> and setting vdco while keeping vdcv=0
>>
>> My initial implementation did set tdc to disabled, but then the
>> communication with (for example) PCAN-usb is failing - have
>> this information from someone who has access to this (which
>> makes it hard for me to reproduce...)
>>
>> Martin
>>
>>> On 09.12.2017, at 19:01, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>>>
>>> Hello Martin,
>>>
>>> we had a discussion on this topic recently which ended here:
>>>
>>> https://marc.info/?l=linux-can&m=150850171310828&w=2
>>>
>>> There was no further discussion since then.
>>>
>>> What is you opinion about using the 'data sample-point' aka dsample-point for transmitter delay configuration?
>>>
>>> $ ip link set can0 type can help
>>> Usage: ip link set DEVICE type can
>>> [ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
>>> [ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
>>> phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
>>>
>>> [ dbitrate BITRATE [ dsample-point SAMPLE-POINT] ] | <<---
>>> [ dtq TQ dprop-seg PROP_SEG dphase-seg1 PHASE-SEG1
>>> dphase-seg2 PHASE-SEG2 [ dsjw SJW ] ]
>>>
>>> Best regards,
>>> Oliver
>>>
>>>> On 12/09/2017 06:01 PM, Martin Sperl wrote:
>>>> Hi!
>>>> The mcp2517fd that I am finishing the driver for has some specific
>>>> settings to configure the transmitter delay which is used with can fd
>>>> frames (essentially it configures 2nd sample point that takes the
>>>> delay /latency of the transceiver into account - can be off, fixed, or
>>>> automatic).
>>>> Compatibility tests have already shown that some can fd communication
>>>> is quite sensitive to these settings - especially between different types
>>>> of devices - which may result in BUS off situations...
>>>> So I am wondering how to best allow for configuration of these
>>>> parameters - module parameters is ugly similarly debugfs or sysfs.
>>>> I guess there must be other fd devices with similar requirements,
>>>> so I wonder how it is handled there...
>>>> Thanks,
>>>> Martin
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-can" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] ip: add vxcan/veth to ip-link man page
From: Stephen Hemminger @ 2017-12-16 18:08 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can, netdev
In-Reply-To: <20171216113857.2397-1-socketcan@hartkopp.net>
On Sat, 16 Dec 2017 12:38:57 +0100
Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> veth and vxcan both create a vitual tunnel between a pair of virtual network
> devices. This patch adds the content for the now supported vxcan netdevices
> and the documentation to create peer devices for vxcan and veth.
>
> Additional remove 'can' that accidently was on the list of link types which
> can be created by 'ip link add' as 'can' devices are real network devices.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied. Thanks for the doing this.
^ permalink raw reply
* [mkl-can-next:j1939 89/121] net/can/j1939/transport.c:1309 j1939_session_fresh_new() error: use kfree_skb() here instead of kfree(skb)
From: Dan Carpenter @ 2017-12-16 12:08 UTC (permalink / raw)
To: kbuild, Kurt Van Dijck, Marc Kleine-Budde; +Cc: kbuild-all, linux-can
tree: https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git j1939
head: 31a3a5b6afa815d144da2d01940e493fb7b625f2
commit: dbdee3fe09a691eb4ddfedd349be5ffe5e866fb9 [89/121] j1939: transport: use common prefix j1939_session{,list}_ for all session{,list} related functions
smatch warnings:
show-warning-context "warning-lines" files
# https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/commit/?id=dbdee3fe09a691eb4ddfedd349be5ffe5e866fb9
git remote add mkl-can-next https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
git remote update mkl-can-next
git checkout dbdee3fe09a691eb4ddfedd349be5ffe5e866fb9
vim +1309 net/can/j1939/transport.c
b99eb71b Kurt Van Dijck 2011-05-23 1285
dbdee3fe Marc Kleine-Budde 2017-08-16 1286 static struct session *j1939_session_fresh_new(int size,
827881d3 Marc Kleine-Budde 2016-09-08 1287 struct sk_buff *rel_skb,
827881d3 Marc Kleine-Budde 2016-09-08 1288 pgn_t pgn)
b99eb71b Kurt Van Dijck 2011-05-23 1289 {
b99eb71b Kurt Van Dijck 2011-05-23 1290 struct sk_buff *skb;
b99eb71b Kurt Van Dijck 2011-05-23 1291 struct j1939_sk_buff_cb *cb;
b99eb71b Kurt Van Dijck 2011-05-23 1292 struct session *session;
b99eb71b Kurt Van Dijck 2011-05-23 1293
b99eb71b Kurt Van Dijck 2011-05-23 1294 /* this SKB is allocated without headroom for CAN skb's.
b99eb71b Kurt Van Dijck 2011-05-23 1295 * This may not pose a problem, this SKB will never
b99eb71b Kurt Van Dijck 2011-05-23 1296 * enter generic CAN functions
b99eb71b Kurt Van Dijck 2011-05-23 1297 */
b99eb71b Kurt Van Dijck 2011-05-23 1298 skb = alloc_skb(size, GFP_ATOMIC);
b99eb71b Kurt Van Dijck 2011-05-23 1299 if (!skb)
b99eb71b Kurt Van Dijck 2011-05-23 1300 return NULL;
b99eb71b Kurt Van Dijck 2011-05-23 1301
15c8a9f1 Marc Kleine-Budde 2017-06-01 1302 cb = j1939_get_cb(skb);
b99eb71b Kurt Van Dijck 2011-05-23 1303 memcpy(cb, rel_skb->cb, sizeof(*cb));
b99eb71b Kurt Van Dijck 2011-05-23 1304 fix_cb(cb);
669cff46 Marc Kleine-Budde 2017-08-16 1305 cb->addr.pgn = pgn;
b99eb71b Kurt Van Dijck 2011-05-23 1306
dbdee3fe Marc Kleine-Budde 2017-08-16 1307 session = j1939_session_new(skb);
b99eb71b Kurt Van Dijck 2011-05-23 1308 if (!session) {
b99eb71b Kurt Van Dijck 2011-05-23 @1309 kfree(skb);
b99eb71b Kurt Van Dijck 2011-05-23 1310 return NULL;
b99eb71b Kurt Van Dijck 2011-05-23 1311 }
b99eb71b Kurt Van Dijck 2011-05-23 1312 session->skb_iif = rel_skb->skb_iif;
b99eb71b Kurt Van Dijck 2011-05-23 1313 skb->dev = rel_skb->dev;
70bbb5ad Marc Kleine-Budde 2016-09-08 1314
b99eb71b Kurt Van Dijck 2011-05-23 1315 /* alloc data area */
b99eb71b Kurt Van Dijck 2011-05-23 1316 skb_put(skb, size);
b99eb71b Kurt Van Dijck 2011-05-23 1317 return session;
b99eb71b Kurt Van Dijck 2011-05-23 1318 }
70bbb5ad Marc Kleine-Budde 2016-09-08 1319
^ permalink raw reply
* [PATCH] ip: add vxcan/veth to ip-link man page
From: Oliver Hartkopp @ 2017-12-16 11:38 UTC (permalink / raw)
To: linux-can, netdev, Stephen Hemminger; +Cc: Oliver Hartkopp
veth and vxcan both create a vitual tunnel between a pair of virtual network
devices. This patch adds the content for the now supported vxcan netdevices
and the documentation to create peer devices for vxcan and veth.
Additional remove 'can' that accidently was on the list of link types which
can be created by 'ip link add' as 'can' devices are real network devices.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
man/man8/ip-link.8.in | 30 +++++++++++++++++++++++++++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index a6a10e57..94ecbece 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -194,6 +194,7 @@ ip-link \- network device configuration
.BR macvlan " | "
.BR macvtap " | "
.BR vcan " | "
+.BR vxcan " | "
.BR veth " | "
.BR vlan " | "
.BR vxlan " |"
@@ -252,9 +253,6 @@ Link types:
.B bond
- Bonding device
.sp
-.B can
-- Controller Area Network interface
-.sp
.B dummy
- Dummy network interface
.sp
@@ -276,6 +274,9 @@ Link types:
.B vcan
- Virtual Controller Area Network interface
.sp
+.B vxcan
+- Virtual Controller Area Network tunnel interface
+.sp
.B veth
- Virtual ethernet interface
.sp
@@ -651,6 +652,29 @@ keyword.
.in -8
+.TP
+VETH, VXCAN Type Support
+For a link of types
+.I VETH/VXCAN
+the following additional arguments are supported:
+
+.BI "ip link add " DEVICE
+.BR type " { " veth " | " vxcan " }"
+[
+.BR peer
+.BI "name " NAME
+]
+
+.in +8
+.sp
+.BR peer
+.BI "name " NAME
+- specifies the virtual pair device name of the
+.I VETH/VXCAN
+tunnel.
+
+.in -8
+
.TP
GRE, IPIP, SIT, ERSPAN Type Support
For a link of types
--
2.15.1
^ permalink raw reply related
* Hallo mein lieber Freund,
From: 62141147 @ 2017-12-16 10:42 UTC (permalink / raw)
To: Recipients
Hallo mein lieber Freund,
Ich schreibe Ihnen diese Post mit schweren Tränen In meinen Augen und großem Kummer in meinem Herzen, Mein Name ist Vera Hollin Kvan, und ich kontaktiere Sie aus meinem Land Indien Ich möchte Ihnen dies sagen, weil ich keine habe andere Option, als Ihnen zu sagen, wie ich berührt wurde, um Sie zu öffnen, ich heiratete mit Herrn Hollin Kvan, der mit der tunesischen Botschaft in Madrid Spanien für neun Jahre arbeitete, bevor er im Jahr 2005 starb.Wir waren seit elf Jahren ohne eine Kind.
Er starb nach einer kurzen Krankheit, die nur fünf Tage dauerte. Seit seinem Tod habe ich beschlossen, nicht wieder zu heiraten. Als mein verstorbener Ehemann lebte, deponierte er die Summe von $ 4,850,000.00USD (vier Millionen achthundertundfünfzigtausend Dollar) in einer Bank hier in Indien. New Delhi die Hauptstadt von Indien, derzeit dieses Geld ist immer noch in der Bank.
Er machte dieses Geld für den Export von Gold aus Madrid Spanien Bergbau-Factary.Kürzlich mein Arzt sagte mir, dass ich nicht für die Dauer von sieben Monaten wegen Krebs Problem dauern würde. Derjenige, der mich am meisten stört, ist meine Schlaganfallkrankheit. Nachdem ich meinen Zustand gekannt habe, habe ich mich entschlossen, Ihnen dieses Geld zu geben, um auf die weniger privilegierten Leute aufzupassen, Sie werden dieses Geld verwenden, wie ich hier unterweisen werde.
Ich möchte, dass Sie 30 Prozent des gesamten Geldes für Ihren persönlichen Gebrauch verwenden, während 70% des Geldes für wohltätige Zwecke, Menschen auf der Straße und Hilfe für das Waisenhaus verwendet werden. Ich bin als Waise aufgewachsen und habe keinen Körper als Familienmitglied, nur um zu enden, dass das Haus Gottes auch erhalten bleibt. Tue dies, damit Gott meine Sünden vergibt und meine Seele annimmt, weil diese Krankheiten mich so sehr gelitten haben. Sobald ich Ihre Antwort erhalten habe, werde ich Ihnen den Kontakt der Bank hier in Delhi Indien geben und ich werde auch den Bankmanager anweisen, Ihnen ein Autoritätsschreiben auszustellen, das Sie als den gegenwärtigen Begünstigten des Geldes in der Bank beweisen wird, wenn Sie versichern mir, dass Sie entsprechend handeln, wie ich es hier dargelegt habe.
In der Hoffnung, Ihre Antwort zu erhalten.
Von Vera Hollin kVan
^ permalink raw reply
* Re: Can: FD: configure transmitter delay
From: kernel @ 2017-12-15 18:31 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can
In-Reply-To: <651BC098-5F9A-4B1A-961F-13240ACFE666@martin.sperl.org>
Maybe one observation that I have made that may be of interest is
that changing the sample-point from .75 to .80 makes the reception work
again.
But that only works when the sample points are changed to the same value!
e.g: sample-point .8 dsample-point .8
Otherwise things show errors and the message is eventually received.
So it seems that the sample-points really becomes sensitive
(at least on the mcp2517fd) and a different default than .75 may be
“recommended” when using CanFD.
Martin
> On 09.12.2017, at 19:48, Martin Sperl <kernel@martin.sperl.org> wrote:
>
>
> As far as I can tell dsample-point is the definition of the first
> sample point of a data bit (in % of the bit length). It would not
> define the 2nd sample point that would be defined by
> transmitter delay.
>
> Also how would one parametrize: off, fixed or auto with this
> parameter(where with auto part of the parameter would be
> Automatic, but parts would be fixed?
>
> I understand we need to come to a common denominator.
>
> So maybe it would help summarize the parameters for each
> Device to figure out what is common.
>
> Here the info for the mcp2517fd:
>
> bit 17-16 TDCMOD<1:0>: Transmitter Delay Compensation Mode bits; Secondary Sample Point (SSP) 10-11 = Auto; measure delay and add TDCO. 01 = Manual; Don't measure, use TDCV + TDCO from register 00 = TDC Disabled
> bit 14-8 TDCO<6:0>: Transmitter Delay Compensation Offset bits; Secondary Sample Point (SSP) Two's complement; offset can be positive, zero, or negative. 011 1111 = 63 x TSYSCLK ... 000 0000 = 0 x TSYSCLK ... 111 1111 = –64 x TSYSCLK
> bit 5-0 TDCV<5:0>: Transmitter Delay Compensation Value bits; Secondary Sample Point (SSP) 11 1111 = 63 x TSYSCLK ... 00 0000 = 0 x TSYSCLK
>
> What the microchip reference implementation does is define auto
> and setting vdco while keeping vdcv=0
>
> My initial implementation did set tdc to disabled, but then the
> communication with (for example) PCAN-usb is failing - have
> this information from someone who has access to this (which
> makes it hard for me to reproduce...)
>
> Martin
>
>> On 09.12.2017, at 19:01, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>>
>> Hello Martin,
>>
>> we had a discussion on this topic recently which ended here:
>>
>> https://marc.info/?l=linux-can&m=150850171310828&w=2
>>
>> There was no further discussion since then.
>>
>> What is you opinion about using the 'data sample-point' aka dsample-point for transmitter delay configuration?
>>
>> $ ip link set can0 type can help
>> Usage: ip link set DEVICE type can
>> [ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
>> [ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
>> phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
>>
>> [ dbitrate BITRATE [ dsample-point SAMPLE-POINT] ] | <<---
>> [ dtq TQ dprop-seg PROP_SEG dphase-seg1 PHASE-SEG1
>> dphase-seg2 PHASE-SEG2 [ dsjw SJW ] ]
>>
>> Best regards,
>> Oliver
>>
>>> On 12/09/2017 06:01 PM, Martin Sperl wrote:
>>> Hi!
>>> The mcp2517fd that I am finishing the driver for has some specific
>>> settings to configure the transmitter delay which is used with can fd
>>> frames (essentially it configures 2nd sample point that takes the
>>> delay /latency of the transceiver into account - can be off, fixed, or
>>> automatic).
>>> Compatibility tests have already shown that some can fd communication
>>> is quite sensitive to these settings - especially between different types
>>> of devices - which may result in BUS off situations...
>>> So I am wondering how to best allow for configuration of these
>>> parameters - module parameters is ugly similarly debugfs or sysfs.
>>> I guess there must be other fd devices with similar requirements,
>>> so I wonder how it is handled there...
>>> Thanks,
>>> Martin
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-can" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] can: gs_usb: fix return value of the "set_bittiming" callback
From: Wolfgang Grandegger @ 2017-12-15 16:12 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can@vger.kernel.org; +Cc: Maximilian Schneider
In-Reply-To: <0f752fcb-64bf-d471-b376-48d4c2cf53c7@pengutronix.de>
Am 15.12.2017 um 14:27 schrieb Marc Kleine-Budde:
> On 12/13/2017 07:52 PM, Wolfgang Grandegger wrote:
>> The "set_bittiming" callback treats a positive return value as error!
>> For that reason "can_changelink()" will quit silently after setting
>> the bittiming values without processing ctrlmode, restart-ms, etc.
>>
>> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>> ---
>> drivers/net/can/usb/gs_usb.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c
>> index 68ac3e8..52907d4 100644
>> --- a/drivers/net/can/usb/gs_usb.c
>> +++ b/drivers/net/can/usb/gs_usb.c
>> @@ -449,7 +449,7 @@ static int gs_usb_set_bittiming(struct net_device *netdev)
>> dev_err(netdev->dev.parent, "Couldn't set bittimings (err=%d)",
>> rc);
>>
>> - return rc;
>> + return rc < 0 ? rc : 0;
>> }
>>
>> static void gs_usb_xmit_callback(struct urb *urb)
>>
>
> I've changed the patch to:
> index 8bf80ad9dc44..3ed2a47e3af0 100644
> --- a/drivers/net/can/usb/gs_usb.c
> +++ b/drivers/net/can/usb/gs_usb.c
> @@ -267,7 +267,7 @@ static int gs_cmd_reset(struct gs_usb *gsusb, struct gs_can *gsdev)
>
> kfree(dm);
>
> - return rc;
> + return (rc > 0) ? 0 : rc;
> }
>
> As some other code in the driver already uses this.
Perfect! Thanks.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] can: gs_usb: fix return value of the "set_bittiming" callback
From: Marc Kleine-Budde @ 2017-12-15 13:27 UTC (permalink / raw)
To: Wolfgang Grandegger, linux-can@vger.kernel.org; +Cc: Maximilian Schneider
In-Reply-To: <7e1d101e-9c10-4067-ab6e-91c4338670d3@grandegger.com>
[-- Attachment #1.1: Type: text/plain, Size: 1552 bytes --]
On 12/13/2017 07:52 PM, Wolfgang Grandegger wrote:
> The "set_bittiming" callback treats a positive return value as error!
> For that reason "can_changelink()" will quit silently after setting
> the bittiming values without processing ctrlmode, restart-ms, etc.
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
> ---
> drivers/net/can/usb/gs_usb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c
> index 68ac3e8..52907d4 100644
> --- a/drivers/net/can/usb/gs_usb.c
> +++ b/drivers/net/can/usb/gs_usb.c
> @@ -449,7 +449,7 @@ static int gs_usb_set_bittiming(struct net_device *netdev)
> dev_err(netdev->dev.parent, "Couldn't set bittimings (err=%d)",
> rc);
>
> - return rc;
> + return rc < 0 ? rc : 0;
> }
>
> static void gs_usb_xmit_callback(struct urb *urb)
>
I've changed the patch to:
index 8bf80ad9dc44..3ed2a47e3af0 100644
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -267,7 +267,7 @@ static int gs_cmd_reset(struct gs_usb *gsusb, struct gs_can *gsdev)
kfree(dm);
- return rc;
+ return (rc > 0) ? 0 : rc;
}
As some other code in the driver already uses this.
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 related
* Re: [PATCH iproute2] ip: add vxcan to help text
From: Oliver Hartkopp @ 2017-12-14 16:47 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: linux-can, netdev
In-Reply-To: <20171213182026.080b503d@xeon-e3>
On 12/14/2017 03:20 AM, Stephen Hemminger wrote:
>> Add missing tag 'vxcan' inside the help text which was missing in commit
>> efe459c76d35f ('ip: link add vxcan support').
>
> Applied. Could you also fix the man page?
>
Sure!
Will take a look and send a patch.
Best,
Oliver
^ permalink raw reply
* Re: [PATCH iproute2] ip: add vxcan to help text
From: Stephen Hemminger @ 2017-12-14 2:20 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can, netdev
In-Reply-To: <20171213202128.4424-1-socketcan@hartkopp.net>
On Wed, 13 Dec 2017 21:21:28 +0100
Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> Add missing tag 'vxcan' inside the help text which was missing in commit
> efe459c76d35f ('ip: link add vxcan support').
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied. Could you also fix the man page?
^ permalink raw reply
* [PATCH iproute2] ip: add vxcan to help text
From: Oliver Hartkopp @ 2017-12-13 20:21 UTC (permalink / raw)
To: linux-can, netdev, Stephen Hemminger; +Cc: Oliver Hartkopp
Add missing tag 'vxcan' inside the help text which was missing in commit
efe459c76d35f ('ip: link add vxcan support').
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
ip/ipaddress.c | 2 +-
ip/iplink.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 8057011e..f150d919 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -74,7 +74,7 @@ static void usage(void)
fprintf(stderr, "CONFFLAG := [ home | nodad | mngtmpaddr | noprefixroute | autojoin ]\n");
fprintf(stderr, "LIFETIME := [ valid_lft LFT ] [ preferred_lft LFT ]\n");
fprintf(stderr, "LFT := forever | SECONDS\n");
- fprintf(stderr, "TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | macvtap |\n");
+ fprintf(stderr, "TYPE := { vlan | veth | vcan | vxcan | dummy | ifb | macvlan | macvtap |\n");
fprintf(stderr, " bridge | bond | ipoib | ip6tnl | ipip | sit | vxlan | lowpan |\n");
fprintf(stderr, " gre | gretap | erspan | ip6gre | ip6gretap | ip6erspan | vti |\n");
fprintf(stderr, " nlmon | can | bond_slave | ipvlan | geneve | bridge_slave |\n");
diff --git a/ip/iplink.c b/ip/iplink.c
index 0a8eb56f..e83f1477 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -109,7 +109,7 @@ void iplink_usage(void)
"\n"
" ip link help [ TYPE ]\n"
"\n"
- "TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | macvtap |\n"
+ "TYPE := { vlan | veth | vcan | vxcan | dummy | ifb | macvlan | macvtap |\n"
" bridge | bond | team | ipoib | ip6tnl | ipip | sit | vxlan |\n"
" gre | gretap | erspan | ip6gre | ip6gretap | ip6erspan |\n"
" vti | nlmon | team_slave | bond_slave | ipvlan | geneve |\n"
--
2.15.1
^ permalink raw reply related
* [PATCH] can: gs_usb: fix return value of the "set_bittiming" callback
From: Wolfgang Grandegger @ 2017-12-13 18:52 UTC (permalink / raw)
To: linux-can@vger.kernel.org; +Cc: Marc Kleine-Budde, Maximilian Schneider
The "set_bittiming" callback treats a positive return value as error!
For that reason "can_changelink()" will quit silently after setting
the bittiming values without processing ctrlmode, restart-ms, etc.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
drivers/net/can/usb/gs_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c
index 68ac3e8..52907d4 100644
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -449,7 +449,7 @@ static int gs_usb_set_bittiming(struct net_device *netdev)
dev_err(netdev->dev.parent, "Couldn't set bittimings (err=%d)",
rc);
- return rc;
+ return rc < 0 ? rc : 0;
}
static void gs_usb_xmit_callback(struct urb *urb)
--
2.7.4
^ permalink raw reply related
* Re: Mailing list archive is down?
From: Robert Schwebel @ 2017-12-11 20:49 UTC (permalink / raw)
To: Rémy DZIEMIASZKO; +Cc: linux-can
In-Reply-To: <e487e3c739bf0fdc9b99e730b42b180f@smile.fr>
On Mon, Dec 11, 2017 at 05:10:32PM +0100, Rémy DZIEMIASZKO wrote:
> I am trying to access the linux-can mailing list archive at
> http://dir.gmane.org/gmane.linux.can
>
> But none of the sub-links seems to work...
>
> - http://news.gmane.org/gmane.linux.can
> - http://blog.gmane.org/gmane.linux.can
>
> Is the server down or I am wrong?
You could use the archive at https://marc.info/?l=linux-can
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Mailing list archive is down?
From: Rémy DZIEMIASZKO @ 2017-12-11 16:10 UTC (permalink / raw)
To: linux-can
Hello,
I am trying to access the linux-can mailing list archive at
http://dir.gmane.org/gmane.linux.can
But none of the sub-links seems to work...
- http://news.gmane.org/gmane.linux.can
- http://blog.gmane.org/gmane.linux.can
Is the server down or I am wrong?
Cheers,
Rémy Dziemiaszko
PS: Sorry, I just subscribed to the mailing list today so maybe this
issue is already known?
^ permalink raw reply
* Re: [PATCH] vxcan: improve handling of missing peer name attribute
From: Marc Kleine-Budde @ 2017-12-11 13:45 UTC (permalink / raw)
To: Oliver Hartkopp, linux-can; +Cc: Serhey Popovych
In-Reply-To: <20171202174852.9618-1-socketcan@hartkopp.net>
[-- Attachment #1.1: Type: text/plain, Size: 871 bytes --]
On 12/02/2017 06:48 PM, Oliver Hartkopp wrote:
> Picking up the patch from Serhey Popovych (commit 191cdb3822e5df6b3c8,
> "veth: Be more robust on network device creation when no attributes").
>
> When the peer name attribute is not provided the former implementation tries
> to register the given device name twice ... which leads to -EEXIST.
> If only one device name is given apply an automatic generated and valid name
> for the peer.
>
> CC: Serhey Popovych <serhe.popovych@gmail.com>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied to can.
tnx,
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: Can: FD: configure transmitter delay
From: Martin Sperl @ 2017-12-09 18:48 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can
In-Reply-To: <eb6253a6-706b-db3b-9701-3eef2e408d9c@hartkopp.net>
As far as I can tell dsample-point is the definition of the first
sample point of a data bit (in % of the bit length). It would not
define the 2nd sample point that would be defined by
transmitter delay.
Also how would one parametrize: off, fixed or auto with this
parameter(where with auto part of the parameter would be
Automatic, but parts would be fixed?
I understand we need to come to a common denominator.
So maybe it would help summarize the parameters for each
Device to figure out what is common.
Here the info for the mcp2517fd:
bit 17-16 TDCMOD<1:0>: Transmitter Delay Compensation Mode bits; Secondary Sample Point (SSP) 10-11 = Auto; measure delay and add TDCO. 01 = Manual; Don't measure, use TDCV + TDCO from register 00 = TDC Disabled
bit 14-8 TDCO<6:0>: Transmitter Delay Compensation Offset bits; Secondary Sample Point (SSP) Two's complement; offset can be positive, zero, or negative. 011 1111 = 63 x TSYSCLK ... 000 0000 = 0 x TSYSCLK ... 111 1111 = –64 x TSYSCLK
bit 5-0 TDCV<5:0>: Transmitter Delay Compensation Value bits; Secondary Sample Point (SSP) 11 1111 = 63 x TSYSCLK ... 00 0000 = 0 x TSYSCLK
What the microchip reference implementation does is define auto
and setting vdco while keeping vdcv=0
My initial implementation did set tdc to disabled, but then the
communication with (for example) PCAN-usb is failing - have
this information from someone who has access to this (which
makes it hard for me to reproduce...)
Martin
> On 09.12.2017, at 19:01, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>
> Hello Martin,
>
> we had a discussion on this topic recently which ended here:
>
> https://marc.info/?l=linux-can&m=150850171310828&w=2
>
> There was no further discussion since then.
>
> What is you opinion about using the 'data sample-point' aka dsample-point for transmitter delay configuration?
>
> $ ip link set can0 type can help
> Usage: ip link set DEVICE type can
> [ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
> [ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
> phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
>
> [ dbitrate BITRATE [ dsample-point SAMPLE-POINT] ] | <<---
> [ dtq TQ dprop-seg PROP_SEG dphase-seg1 PHASE-SEG1
> dphase-seg2 PHASE-SEG2 [ dsjw SJW ] ]
>
> Best regards,
> Oliver
>
>> On 12/09/2017 06:01 PM, Martin Sperl wrote:
>> Hi!
>> The mcp2517fd that I am finishing the driver for has some specific
>> settings to configure the transmitter delay which is used with can fd
>> frames (essentially it configures 2nd sample point that takes the
>> delay /latency of the transceiver into account - can be off, fixed, or
>> automatic).
>> Compatibility tests have already shown that some can fd communication
>> is quite sensitive to these settings - especially between different types
>> of devices - which may result in BUS off situations...
>> So I am wondering how to best allow for configuration of these
>> parameters - module parameters is ugly similarly debugfs or sysfs.
>> I guess there must be other fd devices with similar requirements,
>> so I wonder how it is handled there...
>> Thanks,
>> Martin
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-can" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Can: FD: configure transmitter delay
From: Oliver Hartkopp @ 2017-12-09 18:01 UTC (permalink / raw)
To: Martin Sperl; +Cc: linux-can
In-Reply-To: <B4DF4571-1790-4F09-8DEC-C0812D0F34B1@martin.sperl.org>
Hello Martin,
we had a discussion on this topic recently which ended here:
https://marc.info/?l=linux-can&m=150850171310828&w=2
There was no further discussion since then.
What is you opinion about using the 'data sample-point' aka
dsample-point for transmitter delay configuration?
$ ip link set can0 type can help
Usage: ip link set DEVICE type can
[ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
[ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
[ dbitrate BITRATE [ dsample-point SAMPLE-POINT] ] | <<---
[ dtq TQ dprop-seg PROP_SEG dphase-seg1 PHASE-SEG1
dphase-seg2 PHASE-SEG2 [ dsjw SJW ] ]
Best regards,
Oliver
On 12/09/2017 06:01 PM, Martin Sperl wrote:
> Hi!
>
> The mcp2517fd that I am finishing the driver for has some specific
> settings to configure the transmitter delay which is used with can fd
> frames (essentially it configures 2nd sample point that takes the
> delay /latency of the transceiver into account - can be off, fixed, or
> automatic).
>
> Compatibility tests have already shown that some can fd communication
> is quite sensitive to these settings - especially between different types
> of devices - which may result in BUS off situations...
>
> So I am wondering how to best allow for configuration of these
> parameters - module parameters is ugly similarly debugfs or sysfs.
>
> I guess there must be other fd devices with similar requirements,
> so I wonder how it is handled there...
>
> Thanks,
> Martin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] slip: sl_alloc(): remove unused parameter "dev_t line"
From: Oliver Hartkopp @ 2017-12-09 17:28 UTC (permalink / raw)
To: Marc Kleine-Budde, netdev; +Cc: kernel, linux-can
In-Reply-To: <39d83463-b20d-3739-7e84-f1f51919e9e5@pengutronix.de>
On 12/08/2017 12:22 PM, Marc Kleine-Budde wrote:
> Hello Oliver,
>
> I've the corresponding slcan patch already in my queue.
Excellent :-)
Thanks,
Oliver
>
> Marc
>
> On 12/08/2017 12:18 PM, Marc Kleine-Budde wrote:
>> The first and only parameter of sl_alloc() is unused, so remove it.
>>
>> Fixes: 5342b77c4123 slip: ("Clean up create and destroy")
>> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>> ---
>> drivers/net/slip/slip.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/slip/slip.c b/drivers/net/slip/slip.c
>> index cc63102ca96e..8940417c30e5 100644
>> --- a/drivers/net/slip/slip.c
>> +++ b/drivers/net/slip/slip.c
>> @@ -731,7 +731,7 @@ static void sl_sync(void)
>>
>>
>> /* Find a free SLIP channel, and link in this `tty' line. */
>> -static struct slip *sl_alloc(dev_t line)
>> +static struct slip *sl_alloc(void)
>> {
>> int i;
>> char name[IFNAMSIZ];
>> @@ -809,7 +809,7 @@ static int slip_open(struct tty_struct *tty)
>>
>> /* OK. Find a free SLIP channel to use. */
>> err = -ENFILE;
>> - sl = sl_alloc(tty_devnum(tty));
>> + sl = sl_alloc();
>> if (sl == NULL)
>> goto err_exit;
>>
>>
>
>
^ permalink raw reply
* Can: FD: configure transmitter delay
From: Martin Sperl @ 2017-12-09 17:01 UTC (permalink / raw)
To: linux-can
Hi!
The mcp2517fd that I am finishing the driver for has some specific
settings to configure the transmitter delay which is used with can fd
frames (essentially it configures 2nd sample point that takes the
delay /latency of the transceiver into account - can be off, fixed, or
automatic).
Compatibility tests have already shown that some can fd communication
is quite sensitive to these settings - especially between different types
of devices - which may result in BUS off situations...
So I am wondering how to best allow for configuration of these
parameters - module parameters is ugly similarly debugfs or sysfs.
I guess there must be other fd devices with similar requirements,
so I wonder how it is handled there...
Thanks,
Martin
^ 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