* [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
* Re: pull-request: can 2017-12-08
From: David Miller @ 2017-12-08 19:54 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <20171208155817.9364-1-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Fri, 8 Dec 2017 16:58:11 +0100
> this is a pull request of 6 patches for net/master.
>
> Martin Kelly provides 5 patches for various USB based CAN drivers, that
> properly cancel the URBs on adapter unplug, so that the driver doesn't
> end up in an endless loop. Stephane Grosjean provides a patch to restart
> the tx queue if zero length packages are transmitted.
Pulled, thanks Marc.
^ permalink raw reply
* [PATCH 2/6] can: ems_usb: cancel urb on -EPIPE and -EPROTO
From: Marc Kleine-Budde @ 2017-12-08 15:58 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Martin Kelly, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20171208155817.9364-1-mkl@pengutronix.de>
From: Martin Kelly <mkelly@xevo.com>
In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect
(-EPIPE and -EPROTO).
This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/ems_usb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/can/usb/ems_usb.c b/drivers/net/can/usb/ems_usb.c
index b3d02759c226..b00358297424 100644
--- a/drivers/net/can/usb/ems_usb.c
+++ b/drivers/net/can/usb/ems_usb.c
@@ -288,6 +288,8 @@ static void ems_usb_read_interrupt_callback(struct urb *urb)
case -ECONNRESET: /* unlink */
case -ENOENT:
+ case -EPIPE:
+ case -EPROTO:
case -ESHUTDOWN:
return;
--
2.15.0
^ permalink raw reply related
* [PATCH 6/6] can: peak/pcie_fd: fix potential bug in restarting tx queue
From: Marc Kleine-Budde @ 2017-12-08 15:58 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Stephane Grosjean, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20171208155817.9364-1-mkl@pengutronix.de>
From: Stephane Grosjean <s.grosjean@peak-system.com>
Don't rely on can_get_echo_skb() return value to wake the network tx
queue up: can_get_echo_skb() returns 0 if the echo array slot was not
occupied, but also when the DLC of the released echo frame was 0.
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/peak_canfd/peak_canfd.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/can/peak_canfd/peak_canfd.c b/drivers/net/can/peak_canfd/peak_canfd.c
index 85268be0c913..55513411a82e 100644
--- a/drivers/net/can/peak_canfd/peak_canfd.c
+++ b/drivers/net/can/peak_canfd/peak_canfd.c
@@ -258,21 +258,18 @@ static int pucan_handle_can_rx(struct peak_canfd_priv *priv,
/* if this frame is an echo, */
if ((rx_msg_flags & PUCAN_MSG_LOOPED_BACK) &&
!(rx_msg_flags & PUCAN_MSG_SELF_RECEIVE)) {
- int n;
unsigned long flags;
spin_lock_irqsave(&priv->echo_lock, flags);
- n = can_get_echo_skb(priv->ndev, msg->client);
+ can_get_echo_skb(priv->ndev, msg->client);
spin_unlock_irqrestore(&priv->echo_lock, flags);
/* count bytes of the echo instead of skb */
stats->tx_bytes += cf_len;
stats->tx_packets++;
- if (n) {
- /* restart tx queue only if a slot is free */
- netif_wake_queue(priv->ndev);
- }
+ /* restart tx queue (a slot is free) */
+ netif_wake_queue(priv->ndev);
return 0;
}
--
2.15.0
^ permalink raw reply related
* [PATCH 5/6] can: usb_8dev: cancel urb on -EPIPE and -EPROTO
From: Marc Kleine-Budde @ 2017-12-08 15:58 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Martin Kelly, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20171208155817.9364-1-mkl@pengutronix.de>
From: Martin Kelly <mkelly@xevo.com>
In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect
(-EPIPE and -EPROTO).
This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/usb_8dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/can/usb/usb_8dev.c b/drivers/net/can/usb/usb_8dev.c
index d000cb62d6ae..27861c417c94 100644
--- a/drivers/net/can/usb/usb_8dev.c
+++ b/drivers/net/can/usb/usb_8dev.c
@@ -524,6 +524,8 @@ static void usb_8dev_read_bulk_callback(struct urb *urb)
break;
case -ENOENT:
+ case -EPIPE:
+ case -EPROTO:
case -ESHUTDOWN:
return;
--
2.15.0
^ permalink raw reply related
* [PATCH 4/6] can: kvaser_usb: cancel urb on -EPIPE and -EPROTO
From: Marc Kleine-Budde @ 2017-12-08 15:58 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Martin Kelly, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20171208155817.9364-1-mkl@pengutronix.de>
From: Martin Kelly <mkelly@xevo.com>
In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect
(-EPIPE and -EPROTO).
This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/kvaser_usb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index f95945915d20..63587b8e6825 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1326,6 +1326,8 @@ static void kvaser_usb_read_bulk_callback(struct urb *urb)
case 0:
break;
case -ENOENT:
+ case -EPIPE:
+ case -EPROTO:
case -ESHUTDOWN:
return;
default:
--
2.15.0
^ permalink raw reply related
* [PATCH 3/6] can: esd_usb2: cancel urb on -EPIPE and -EPROTO
From: Marc Kleine-Budde @ 2017-12-08 15:58 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Martin Kelly, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20171208155817.9364-1-mkl@pengutronix.de>
From: Martin Kelly <mkelly@xevo.com>
In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect
(-EPIPE and -EPROTO).
This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/esd_usb2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/can/usb/esd_usb2.c b/drivers/net/can/usb/esd_usb2.c
index 9fdb0f0bfa06..c6dcf93675c0 100644
--- a/drivers/net/can/usb/esd_usb2.c
+++ b/drivers/net/can/usb/esd_usb2.c
@@ -393,6 +393,8 @@ static void esd_usb2_read_bulk_callback(struct urb *urb)
break;
case -ENOENT:
+ case -EPIPE:
+ case -EPROTO:
case -ESHUTDOWN:
return;
--
2.15.0
^ permalink raw reply related
* [PATCH 1/6] can: mcba_usb: cancel urb on -EPROTO
From: Marc Kleine-Budde @ 2017-12-08 15:58 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Martin Kelly, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20171208155817.9364-1-mkl@pengutronix.de>
From: Martin Kelly <mkelly@xevo.com>
When we unplug the device, we can see both -EPIPE and -EPROTO depending
on exact timing and what system we run on. If we continue to resubmit
URBs, they will immediately fail, and they can cause stalls, especially
on slower CPUs.
Fix this by not resubmitting on -EPROTO, as we already do on -EPIPE.
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/mcba_usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/can/usb/mcba_usb.c b/drivers/net/can/usb/mcba_usb.c
index ef417dcddbf7..8d8c2086424d 100644
--- a/drivers/net/can/usb/mcba_usb.c
+++ b/drivers/net/can/usb/mcba_usb.c
@@ -593,6 +593,7 @@ static void mcba_usb_read_bulk_callback(struct urb *urb)
case -ENOENT:
case -EPIPE:
+ case -EPROTO:
case -ESHUTDOWN:
return;
--
2.15.0
^ permalink raw reply related
* pull-request: can 2017-12-08
From: Marc Kleine-Budde @ 2017-12-08 15:58 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel
Hello David,
this is a pull request of 6 patches for net/master.
Martin Kelly provides 5 patches for various USB based CAN drivers, that
properly cancel the URBs on adapter unplug, so that the driver doesn't
end up in an endless loop. Stephane Grosjean provides a patch to restart
the tx queue if zero length packages are transmitted.
regards,
Marc
---
The following changes since commit 195bd525d5f6e338b948d9a6b25bfaae86291353:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf (2017-12-07 16:22:51 -0500)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-4.15-20171208
for you to fetch changes up to 91785de6f94b58c3fb6664609e3682f011bd28d2:
can: peak/pcie_fd: fix potential bug in restarting tx queue (2017-12-08 10:51:53 +0100)
----------------------------------------------------------------
linux-can-fixes-for-4.15-20171208
----------------------------------------------------------------
Martin Kelly (5):
can: mcba_usb: cancel urb on -EPROTO
can: ems_usb: cancel urb on -EPIPE and -EPROTO
can: esd_usb2: cancel urb on -EPIPE and -EPROTO
can: kvaser_usb: cancel urb on -EPIPE and -EPROTO
can: usb_8dev: cancel urb on -EPIPE and -EPROTO
Stephane Grosjean (1):
can: peak/pcie_fd: fix potential bug in restarting tx queue
drivers/net/can/peak_canfd/peak_canfd.c | 9 +++------
drivers/net/can/usb/ems_usb.c | 2 ++
drivers/net/can/usb/esd_usb2.c | 2 ++
drivers/net/can/usb/kvaser_usb.c | 2 ++
drivers/net/can/usb/mcba_usb.c | 1 +
drivers/net/can/usb/usb_8dev.c | 2 ++
6 files changed, 12 insertions(+), 6 deletions(-)
^ 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