Hi Alejandro,
we added IFF_ECHO these days on suggestion of Dave Miller - and the
IFF_LOWER_UP/IFF_DORMANT were already there at that time.
I don't know if there ioctls are still used for retrieving these flags
as I assume this is done via netlink interface today.
At least there is enough s
:2016 transport protocol")
Cc: Marc Kleine-Budde
Signed-off-by: Oliver Hartkopp
---
net/can/isotp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/can/isotp.c b/net/can/isotp.c
index 430976485d95..15ea1234d457 100644
--- a/net/can/isotp.c
+++ b/net/can/isotp.
[8] 2D 08 09 0A 0B 0C 0D 0E
| can0 TX B E 713 [8] 2E 0F 00 01 02 03 04 05
Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol")
Link: https://lore.kernel.org/r/20210218215434.1708249-2-...@pengutronix.de
Cc: Oliver Hartkopp
Signed-off-by: Marc Kleine-Budde
---
net
t) from [<809c6584>]
(sch_direct_xmit+0xcc/0x264) r10:834e5600 r9: r8: r7:82b44000 r6:82ab1f00
r5:834e5600 r4:83f27400
| [<809c64b8>] (sch_direct_xmit) from [<809c6c0c>] (__qdisc_run+0x4f0/0x534)
To fix this problem, only set skb ownership to sockets which have sti
0 r4:834e5600
| [<80972408>] (dev_hard_start_xmit) from [<809c6584>]
(sch_direct_xmit+0xcc/0x264) r10:834e5600 r9: r8: r7:82b44000 r6:82ab1f00
r5:834e5600 r4:83f27400
| [<809c64b8>] (sch_direct_xmit) from [<809c6c0c>] (__qdisc_run+0x4f0/0x534)
To fix th
Hello Oleksij,
nice cleanup - and I like the removal of the notifier in af_can.c :-)
Two questions/hints from my side:
On 12.02.21 13:52, Oleksij Rempel wrote:
diff --git a/drivers/net/can/dev/dev.c b/drivers/net/can/dev/dev.c
index d9281ae853f8..912401788d93 100644
--- a/drivers/net/can/dev/
On 04.02.21 04:15, David Ahern wrote:
On 2/3/21 12:04 PM, Oliver Hartkopp wrote:
My only fault was, that I did not send the patch for iproute2-next at
the time when the len8_dlc patches were in net-next, right?
yes
Now that I know about iproute2-next, I will do better next time.
Can
On 03.02.21 16:47, David Ahern wrote:
On 2/2/21 10:30 AM, Oliver Hartkopp wrote:
On 02.02.21 16:35, David Ahern wrote:
On 2/2/21 3:48 AM, Oliver Hartkopp wrote:
Are you sure this patch is correctly assigned to iproute2-next?
IMO it has to be applied to iproute2 as the functionality is
On 02.02.21 16:35, David Ahern wrote:
On 2/2/21 3:48 AM, Oliver Hartkopp wrote:
Are you sure this patch is correctly assigned to iproute2-next?
IMO it has to be applied to iproute2 as the functionality is already in
v5.11 which is in rc6 right now.
new features land in iproute2-next
Hello David,
On 29.01.21 16:50, David Ahern wrote:
On 1/25/21 3:40 AM, Oliver Hartkopp wrote:
The len8_dlc element is filled by the CAN interface driver and used for CAN
frame creation by the CAN driver when the CAN_CTRLMODE_CC_LEN8_DLC flag is
supported by the driver and enabled via netlink
-by: Oliver Hartkopp
---
ip/iplink_can.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ip/iplink_can.c b/ip/iplink_can.c
index 735ab941..6a26f3ff 100644
--- a/ip/iplink_can.c
+++ b/ip/iplink_can.c
@@ -35,10 +35,11 @@ static void print_usage(FILE *f)
"\t[ one-shot
Hi Vincent,
On 12.01.21 14:05, Vincent Mailhol wrote:
This driver supports the ES581.4, ES582.1 and ES584.1 interfaces from
ETAS GmbH (https://www.etas.com/en/products/es58x.php).
(..)
diff --git a/drivers/net/can/usb/etas_es58x/es58x_fd.c
b/drivers/net/can/usb/etas_es58x/es58x_fd.c
new fil
On 14.01.21 10:16, Vincent MAILHOL wrote:
On Tue. 14 Jan 2021 at 17:23, Oliver Hartkopp wrote:
On 14.01.21 02:59, Vincent MAILHOL wrote:
On Tue. 14 Jan 2021 at 06:14, Marc Kleine-Budde wrote:
If the length paramter in len2dlc() exceeds the size of the len2dlc array, we
return 0xF. This
On 14.01.21 02:59, Vincent MAILHOL wrote:
On Tue. 14 Jan 2021 at 06:14, Marc Kleine-Budde wrote:
If the length paramter in len2dlc() exceeds the size of the len2dlc array, we
return 0xF. This is equal to the last 16 members of the array.
This patch removes these members from the array, use
Initialize the sockaddr_can structure to prevent a data leak to user space.
Suggested-by: Cong Wang
Reported-by: syzbot+057884e2f453e8afe...@syzkaller.appspotmail.com
Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol")
Signed-off-by: Oliver Hartkopp
---
net/can/i
On 12.01.21 10:12, Marc Kleine-Budde wrote:
On 1/12/21 10:04 AM, Oliver Hartkopp wrote:
Initialize the sockaddr_can structure to prevent a data leak to user space.
Suggested-by: Cong Wang
Reported-by: syzbot+057884e2f453e8afe...@syzkaller.appspotmail.com
Signed-off-by: Oliver Hartkopp
On 12.01.21 01:17, Cong Wang wrote:
On Mon, Jan 11, 2021 at 11:33 AM Jakub Kicinski wrote:
Looks like a AF_CAN socket:
r0 = socket(0x1d, 0x2, 0x6)
getsockname$packet(r0, &(0x7f000100)={0x11, 0x0, 0x0, 0x1, 0x0, 0x6,
@broadcast}, &(0x7f00)=0x14)
Right, it seems we need a mem
Initialize the sockaddr_can structure to prevent a data leak to user space.
Suggested-by: Cong Wang
Reported-by: syzbot+057884e2f453e8afe...@syzkaller.appspotmail.com
Signed-off-by: Oliver Hartkopp
---
net/can/isotp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/can/isotp.c b/net
-by: Oliver Hartkopp
---
ip/iplink_can.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ip/iplink_can.c b/ip/iplink_can.c
index 735ab941..6a26f3ff 100644
--- a/ip/iplink_can.c
+++ b/ip/iplink_can.c
@@ -35,10 +35,11 @@ static void print_usage(FILE *f)
"\t[ one-shot
n a common indention every line in the CAN info output now
ends with eight spaces on the next line. While commit 36e584ad8af6
fixed the '-details' option, the '-statistics' option now works too.
Signed-off-by: Oliver Hartkopp
---
ip/iplink_can.c | 60 +++
Hello Hillf,
On 21.12.20 06:40, Hillf Danton wrote:
Sun, 20 Dec 2020 11:24:13 -0800
syzbot found the following issue on:
HEAD commit:5e60366d Merge tag 'fallthrough-fixes-clang-5.11-rc1' of g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=179a22875
On 20.12.20 15:37, Oleksij Rempel wrote:
Hello Oliver,
On Sun, Dec 20, 2020 at 02:18:27PM +0100, Oliver Hartkopp wrote:
Hello Oleksij,
I assume there is some ndev->ml_priv value set - but not from a CAN
netdevice.
it is kind of CAN device :)
No, it is not.
Team and bonding devi
Hello Oleksij,
I assume there is some ndev->ml_priv value set - but not from a CAN
netdevice.
What was the reason to fiddle with the 'priv' stuff in
j1939_netdev_notify() before checking if it was a CAN device?
Would this patch fix the issue then?
diff --git a/net/can/j1939/main.c b/net/ca
On 05.12.20 22:09, Jakub Kicinski wrote:
On Sat, 5 Dec 2020 21:56:33 +0100 Marc Kleine-Budde wrote:
On 12/5/20 9:33 PM, Jakub Kicinski wrote:
What about the (incremental?) change that Thomas Wagner posted?
https://lore.kernel.org/r/20201204135557.55599-1-th...@web.de
That settles it :) Th
addressing this socket does not
register a CAN-ID for reception which would be needed for a 1-to-1
ISOTP connection with a segmented bi-directional data transfer.
Sending SFs on this socket is therefore a TX-only 'broadcast' operation.
Signed-off-by: Oliver Hartkopp
Signed-off-by: Thomas Wa
On 05.12.20 04:44, Jakub Kicinski wrote:
On Fri, 4 Dec 2020 14:35:08 +0100 Marc Kleine-Budde wrote:
From: Oliver Hartkopp
When CAN_ISOTP_SF_BROADCAST is set in the CAN_ISOTP_OPTS flags the CAN_ISOTP
socket is switched into functional addressing mode, where only single frame
(SF) protocol
second patch
can still go into the 5.10-rc tree, which is intended for long-term.
Oliver Hartkopp (2):
can-isotp: block setsockopt on bound sockets
can-isotp: add SF_BROADCAST support for functional addressing
include/uapi/linux/can/isotp.h | 2 +-
net/can/isotp.c| 32
.
Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol")
Tested-by: Thomas Wagner
Signed-off-by: Oliver Hartkopp
---
net/can/isotp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/can/isotp.c b/net/can/isotp.c
index d78ab13bd8be..26bdc3c20b7e 100644
--- a/net/c
Signed-off-by: Oliver Hartkopp
---
include/uapi/linux/can/isotp.h | 2 +-
net/can/isotp.c| 29 -
2 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/include/uapi/linux/can/isotp.h b/include/uapi/linux/can/isotp.h
index 7793b26aa154..c5
Hello Jeroen,
On 02.12.20 16:37, Jeroen Hofstee wrote:
On 12/2/20 3:35 PM, Oliver Hartkopp wrote:
Do we agree that in one-shot mode both the tx_errors and the
arbitration_lost counters are increased in the arbitration-lost case?
At least this would fit to the Kvaser USB behaviour.
I
Hi Jeroen,
On 27.11.20 12:09, Jeroen Hofstee wrote:
On 11/27/20 11:30 AM, Marc Kleine-Budde wrote:
On 11/27/20 10:59 AM, Jeroen Hofstee wrote:
Losing arbitration is normal in a CAN-bus network, it means that a
higher priority frame is being send and the pending message will be
retried later. H
On 27.11.20 12:09, Jeroen Hofstee wrote:
Hi,
On 11/27/20 11:30 AM, Marc Kleine-Budde wrote:
On 11/27/20 10:59 AM, Jeroen Hofstee wrote:
Losing arbitration is normal in a CAN-bus network, it means that a
higher priority frame is being send and the pending message will be
retried later. Hence
On 27.11.20 10:48, Marc Kleine-Budde wrote:
/* Check for bugs in CAN protocol implementations using af_can.c:
* 'rcv' will be NULL if no matching list item was found for removal.
+* As this case may potentially happen when closing a socket while
+* the notifier f
yzbot+381d06e0c8eaacb87...@syzkaller.appspotmail.com
Reported-by: syzbot+d0ddd88c9a7432f04...@syzkaller.appspotmail.com
Reported-by: syzbot+76d62d3b8162883c7...@syzkaller.appspotmail.com
Signed-off-by: Oliver Hartkopp
---
net/can/af_can.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --
On 26.11.20 11:48, Marc Kleine-Budde wrote:
On 11/26/20 5:51 AM, Pankaj Sharma wrote:
Add support for mcan bit timing and control mode according to bosch mcan IP
version 3.3.0
The mcan version read from the Core Release field of CREL register would be
33. Accordingly the properties are to be
Hi Dmitry,
On 25.11.20 19:48, Dmitry Vyukov wrote:
On Wed, Nov 25, 2020 at 5:04 PM Oliver Hartkopp wrote:
This seems to be very seldom but it does not break anything.
Would removing the WARN(1) or replacing it with pr_warn() be ok to close
this issue?
Yes, this is the intended way to
Hello all,
AFAICS the problems are caused by the WARN() statement here:
https://elixir.bootlin.com/linux/v5.10-rc4/source/net/can/af_can.c#L546
The idea was to check whether CAN protocol implementations work
correctly on their filter lists.
With the fault injection it seem like we're getting
Hi Marc,
On 11.11.20 10:59, Oliver Hartkopp wrote:
Support the Classical CAN raw DLC functionality to send and receive DLC
values from 9 .. 15 on various Classical CAN capable CAN network drivers:
- sja1000
I got a PCAN-ExpressCard34 to work on my old 2008 Sony Vaio again to
test the
Support the Classical CAN raw DLC functionality to send and receive DLC
values from 9 .. 15 on various Classical CAN capable CAN network drivers:
- sja1000
- gs_usb
- pcan_usb
- pcan_usb_fd
- usb_8dev
Signed-off-by: Oliver Hartkopp
Tested-by: Oliver Hartkopp
Link: https://lore.kernel.org/r
On 10.11.20 16:50, Marc Kleine-Budde wrote:
On 11/10/20 11:18 AM, Oliver Hartkopp wrote:
I still think, that can_frame_set_cc_len() makes more sense. See my just posted
patches for illustration.
Yep. Your patches look fine!
Just remove my patches 7 & 8 and apply your suggestions ins
he DLC from the payload length
Suggested-by: Vincent Mailhol
Signed-off-by: Oliver Hartkopp
---
Documentation/networking/can.rst | 2 +-
drivers/net/can/dev.c | 8
drivers/net/can/flexcan.c | 4 ++--
drivers/net/can/ifi
name and make clear which of the former uses was a plain
length (-> 'len') or a data length code (-> 'dlc') value.
Signed-off-by: Oliver Hartkopp
---
drivers/net/can/at91_can.c| 14
drivers/net/can/c_can/c_can.c |
ame creation by the CAN driver when the CAN_CTRLMODE_CC_LEN8_DLC flag is
supported by the driver and enabled via netlink configuration interface.
Reported-by: Vincent Mailhol
Signed-off-by: Oliver Hartkopp
---
include/uapi/linux/can.h | 38
include/uapi/linux/ca
The macro was always used together with can_dlc2len() which sanitizes the
given dlc value on its own.
Signed-off-by: Oliver Hartkopp
---
drivers/net/can/flexcan.c | 2 +-
drivers/net/can/peak_canfd/peak_canfd.c | 2 +-
drivers/net/can/spi/mcp251xfd/mcp251xfd
can_get_cc_dlc: get the data length code for Classical CAN raw DLC access
can_get_cc_len: get len and len8_dlc value for Classical CAN raw DLC access
Signed-off-by: Oliver Hartkopp
---
include/linux/can/dev.h | 28
1 file changed, 28 insertions(+)
diff --git a
some data structures and flags.
Signed-off-by: Oliver Hartkopp
---
Documentation/networking/can.rst | 68
1 file changed, 52 insertions(+), 16 deletions(-)
diff --git a/Documentation/networking/can.rst b/Documentation/networking/can.rst
index 4895b0dd2714..f8dae662e
Classical CAN DLC values
- move CAN_CTRLMODE_CC_LEN8_DLC at the end of ctrlmode_supported defs
Oliver Hartkopp (8):
can: add optional DLC element to Classical CAN frame structure
can: rename get_can_dlc() macro with can_cc_dlc2len()
can: remove obsolete get_canfd_dlc() macro
can: replace can_d
On 10.11.20 08:46, Marc Kleine-Budde wrote:
On 11/10/20 7:55 AM, Oliver Hartkopp wrote:
I would suggest something like
u8 can_get_cc_len(const u32 ctrlmode, struct can_frame *cf, u8 dlc)
that still returns the 'len' element, so that we can replace
can_cc_dlc2len() with can_get_cc
The get_can_dlc() macro is used to ensure the payload length information of
the Classical CAN frame to be max 8 bytes (the CAN_MAX_DLEN).
Rename the macro and use the correct constant in preparation of the len/dlc
cleanup for Classical CAN frames.
Signed-off-by: Oliver Hartkopp
---
drivers/net
Support the Classical CAN raw DLC functionality to send and receive DLC
values from 9 .. 15 on various Classical CAN capable USB network drivers:
- gs_usb
- pcan_usb
- pcan_usb_fd
- usb_8dev
Tested-by: Oliver Hartkopp
Signed-off-by: Oliver Hartkopp
---
drivers/net/can/usb/gs_usb.c
On 09.11.20 21:12, Marc Kleine-Budde wrote:
On 11/9/20 4:36 PM, Oliver Hartkopp wrote:
Support the Classical CAN raw DLC functionality to send and receive DLC
values from 9 .. 15 on various Classical CAN capable USB network drivers:
- gs_usb
- pcan_usb
- pcan_usb_fd
- usb_8dev
Tested-by
On 09.11.20 15:50, Vincent MAILHOL wrote:
On Mon. 9 Nov 2020 at 19:26, Oliver Hartkopp wrote:
The extension of struct can_frame with the len8_dlc element and the
can_dlc naming issue required an update of the documentation.
Additionally introduce the term 'Classical CAN' whic
name and make clear which of the former uses was a plain
length (-> 'len') or a data length code (-> 'dlc') value.
Signed-off-by: Oliver Hartkopp
---
drivers/net/can/at91_can.c| 14
drivers/net/can/c_can/c_can.c |
Hi Vincent,
On 09.11.20 13:59, Vincent MAILHOL wrote:
On Mon. 9 Nov 2020 at 19:26, Oliver Hartkopp wrote:
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index b2e8df8e4cb0..72671184a7a2 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -183,12 +183,12
ame creation by the CAN driver when the CAN_CTRLMODE_CC_LEN8_DLC flag is
supported by the driver and enabled via netlink configuration interface.
Reported-by: Vincent Mailhol
Signed-off-by: Oliver Hartkopp
---
include/uapi/linux/can.h | 38
include/uapi/linux/ca
or various CAN USB adapters as reference
Changes in v5:
- rename CAN FD related can_len2dlc and can_dlc2len helpers so that they
fit to the renamed can_cc_dlc2len helper for Classical CAN
(suggested by Vincent Mailhol)
Oliver Hartkopp (8):
can: add optional DLC element to Classical CAN
The macro was always used together with can_dlc2len() which sanitizes the
given dlc value on its own.
Signed-off-by: Oliver Hartkopp
---
drivers/net/can/flexcan.c | 2 +-
drivers/net/can/peak_canfd/peak_canfd.c | 2 +-
drivers/net/can/spi/mcp251xfd/mcp251xfd
Support the Classical CAN raw DLC functionality to send and receive DLC
values from 9 .. 15 on various Classical CAN capable USB network drivers:
- gs_usb
- pcan_usb
- pcan_usb_fd
- usb_8dev
Tested-by: Oliver Hartkopp
Signed-off-by: Oliver Hartkopp
---
drivers/net/can/usb/gs_usb.c
The get_can_dlc() macro is used to ensure the payload length information of
the Classical CAN frame to be max 8 bytes (the CAN_MAX_DLEN).
Rename the macro and use the correct constant in preparation of the len/dlc
cleanup for Classical CAN frames.
Signed-off-by: Oliver Hartkopp
---
drivers/net
can_get_len8_dlc: get value to fill len8_dlc at frame reception time
can_get_cc_dlc: get DLC value to be written into CAN controller
Signed-off-by: Oliver Hartkopp
---
include/linux/can/dev.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/linux/can/dev.h b
he DLC from the payload length
Suggested-by: Vincent Mailhol
Signed-off-by: Oliver Hartkopp
---
Documentation/networking/can.rst | 2 +-
drivers/net/can/dev.c | 8
drivers/net/can/flexcan.c | 4 ++--
drivers/net/can/ifi
some data structures and flags.
Signed-off-by: Oliver Hartkopp
---
Documentation/networking/can.rst | 68
1 file changed, 52 insertions(+), 16 deletions(-)
diff --git a/Documentation/networking/can.rst b/Documentation/networking/can.rst
index 4895b0dd2714..f8dae662e
On 09.11.20 11:26, Oliver Hartkopp wrote:
Introduce improved DLC handling for Classic CAN with introduces a new
element 'len8_dlc' to the struct can_frame and additionally rename
the 'can_dlc' element to 'len' as it represents a plain payload le
can_get_len8_dlc: get value to fill len8_dlc at frame reception time
can_get_cc_dlc: get DLC value to be written into CAN controller
Signed-off-by: Oliver Hartkopp
---
include/linux/can/dev.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/linux/can/dev.h b
name and make clear which of the former uses was a plain
length (-> 'len') or a data length code (-> 'dlc') value.
Signed-off-by: Oliver Hartkopp
---
drivers/net/can/at91_can.c| 14
drivers/net/can/c_can/c_can.c |
The get_can_dlc() macro is used to ensure the payload length information of
the Classical CAN frame to be max 8 bytes (the CAN_MAX_DLEN).
Rename the macro and use the correct constant in preparation of the len/dlc
cleanup for Classical CAN frames.
Signed-off-by: Oliver Hartkopp
---
drivers/net
some data structures and flags.
Signed-off-by: Oliver Hartkopp
---
Documentation/networking/can.rst | 68
1 file changed, 52 insertions(+), 16 deletions(-)
diff --git a/Documentation/networking/can.rst b/Documentation/networking/can.rst
index ff05cbd05e0d..e17c6427b
or various CAN USB adapters as reference
Oliver Hartkopp (7):
can: add optional DLC element to Classical CAN frame structure
can: rename get_can_dlc() macro with can_get_cc_len()
can: remove obsolete get_canfd_dlc() macro
can: replace can_dlc as variable/element for payload length
can: upda
ame creation by the CAN driver when the CAN_CTRLMODE_CC_LEN8_DLC flag is
supported by the driver and enabled via netlink configuration interface.
Reported-by: Vincent Mailhol
Signed-off-by: Oliver Hartkopp
---
include/uapi/linux/can.h | 38
include/uapi/linux/ca
Support the Classical CAN raw DLC functionality to send and receive DLC
values from 9 .. 15 on various Classican CAN capable USB network drivers:
- gs_usb
- pcan_usb
- pcan_usb_fd
- usb_8dev
Tested-by: Oliver Hartkopp
Signed-off-by: Oliver Hartkopp
---
drivers/net/can/usb/gs_usb.c
The macro was always used together with can_dlc2len() which sanitizes the
given dlc value on its own.
Signed-off-by: Oliver Hartkopp
---
drivers/net/can/flexcan.c | 2 +-
drivers/net/can/peak_canfd/peak_canfd.c | 2 +-
drivers/net/can/spi/mcp251xfd/mcp251xfd
On 04.11.20 17:02, Jakub Kicinski wrote:
On Wed, 4 Nov 2020 15:59:25 +0100 Oliver Hartkopp wrote:
On 04.11.20 09:16, Eric Dumazet wrote:
So skb_orphan(skb) in CAN before calling netif_rx() is better IMO.
Unfortunately you missed the answer from Vincent, why skb_orphan() does
not work
Hello Eric,
On 04.11.20 09:16, Eric Dumazet wrote:
On Wed, Nov 4, 2020 at 2:21 AM Jakub Kicinski wrote:
On Tue, 3 Nov 2020 23:06:14 +0100 Marc Kleine-Budde wrote:
From: Vincent Mailhol
If a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but
not always, the case), t
On 22.10.20 18:14, Jakub Kicinski wrote:
On Wed, 21 Oct 2020 13:20:16 +0200 Oliver Hartkopp wrote:
On 21.10.20 07:21, Dinghao Liu wrote:
When rtnl_configure_link() fails, peer needs to be
freed just like when register_netdevice() fails.
Signed-off-by: Dinghao Liu
Acked-by: Oliver
On 21.10.20 07:21, Dinghao Liu wrote:
When rtnl_configure_link() fails, peer needs to be
freed just like when register_netdevice() fails.
Signed-off-by: Dinghao Liu
Acked-by: Oliver Hartkopp
Btw. as the vxcan.c driver bases on veth.c the same issue can be found
there!
At this point
On 19.10.20 08:28, Marc Kleine-Budde wrote:
On 10/18/20 10:46 AM, Oliver Hartkopp wrote:
Oh, answering myself ...
On 17.10.20 21:13, Oliver Hartkopp wrote:
On 16.10.20 21:36, Marc Kleine-Budde wrote:
On 2/14/20 1:09 PM, Oleksij Rempel wrote:
Hi all,
any comments on this patch?
I&#
Oh, answering myself ...
On 17.10.20 21:13, Oliver Hartkopp wrote:
On 16.10.20 21:36, Marc Kleine-Budde wrote:
On 2/14/20 1:09 PM, Oleksij Rempel wrote:
Hi all,
any comments on this patch?
I'm going to take this patch now for 5.10Comments?
Yes.
Removing the sk reference will
On 16.10.20 21:36, Marc Kleine-Budde wrote:
On 2/14/20 1:09 PM, Oleksij Rempel wrote:
Hi all,
any comments on this patch?
I'm going to take this patch now for 5.10Comments?
Yes.
Removing the sk reference will lead to the effect, that you will receive
the CAN frames you have sent on
16:06
À : Wolfgang Grandegger ; Stéphane Grosjean
Cc : Marc Kleine-Budde ; David S. Miller ; Jakub Kicinski
; Andri Yngvason ; Oliver Hartkopp ;
linux-...@vger.kernel.org ; netdev@vger.kernel.org ;
kernel-janit...@vger.kernel.org
Objet : [PATCH net] can: peak_usb: add range checking in decode
enable the CAN_ISOTP option or not.
Signed-off-by: Geert Uytterhoeven
Acked-by: Oliver Hartkopp
Yes, when you are so deep into it that PDU becomes a word like dog or
cat ;-)
Thanks,
Oliver
---
net/can/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/can/Kco
On 12.10.20 10:30, Marc Kleine-Budde wrote:
On 10/12/20 10:11 AM, Oliver Hartkopp wrote:
On 12.10.20 10:05, Marc Kleine-Budde wrote:
On 10/12/20 9:43 AM, Oliver Hartkopp wrote:
As pointed out by Jakub Kicinski here:
http://lore.kernel.org/r/20201009175751.5c540...@kicinski-fedora
On 12.10.20 10:05, Marc Kleine-Budde wrote:
On 10/12/20 9:43 AM, Oliver Hartkopp wrote:
As pointed out by Jakub Kicinski here:
http://lore.kernel.org/r/20201009175751.5c540...@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com
this patch addresses the remarked issues:
- remove empty line in
GFP_ATOMIC instead of gfp_any() in soft hrtimer context
The version strings in the CAN subsystem are removed by a separate patch.
Signed-off-by: Oliver Hartkopp
---
include/uapi/linux/can/isotp.h | 1 -
net/can/Kconfig| 3 ++-
net/can/isotp.c| 14 +++---
3 files
As pointed out by Jakub Kicinski here:
http://lore.kernel.org/r/20201009175751.5c540...@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com
this patch removes the obsolete version information of the different
CAN protocols and the AF_CAN core module.
Signed-off-by: Oliver Hartkopp
---
include/linux
On 11.10.20 17:44, Jakub Kicinski wrote:
On Sun, 11 Oct 2020 11:24:07 +0200 Oliver Hartkopp wrote:
diff --git a/net/can/isotp.c b/net/can/isotp.c
index e6ff032b5426..22187669c5c9 100644
--- a/net/can/isotp.c
+++ b/net/can/isotp.c
@@ -79,6 +79,8 @@ MODULE_LICENSE("Dual BS
GFP_KERNEL instead of gfp_any() in soft hrtimer context
- make use of pr_fmt() [suggested my Marc Kleine-Budde]
The version strings in the CAN subsystem are removed by a separate patch.
Signed-off-by: Oliver Hartkopp
---
include/uapi/linux/can/isotp.h | 1 -
net/can/Kconfig| 3 ++-
net
As pointed out by Jakub Kicinski here:
http://lore.kernel.org/r/20201009175751.5c540...@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com
this patch removes the obsolete version information of the different
CAN protocols and the AF_CAN core module.
Signed-off-by: Oliver Hartkopp
---
include/linux
imer context
The version strings in the CAN subsystem are removed by a separate patch.
Signed-off-by: Oliver Hartkopp
---
include/uapi/linux/can/isotp.h | 4 +---
net/can/Kconfig| 3 ++-
net/can/isotp.c| 14 +++---
3 files changed, 10 insertions(+), 11 delet
As pointed out by Jakub Kicinski here:
https://marc.info/?l=linux-can&m=160229286216008
this patch removes the obsolete version information of the different
CAN protocols and the AF_CAN core module.
Signed-off-by: Oliver Hartkopp
---
include/linux/can/core.h | 7 ---
include/net/n
On 10.10.20 02:57, Jakub Kicinski wrote:
On Wed, 7 Oct 2020 23:31:50 +0200 Marc Kleine-Budde wrote:
From: Oliver Hartkopp
CAN Transport Protocols offer support for segmented Point-to-Point
communication between CAN nodes via two defined CAN Identifiers.
As CAN frames can only transport a
On 10.10.20 17:44, Jakub Kicinski wrote:
On Sat, 10 Oct 2020 16:29:06 +0200 Oliver Hartkopp wrote:
diff --git a/net/can/Kconfig b/net/can/Kconfig
index 25436a715db3..021fe03a8ed6 100644
--- a/net/can/Kconfig
+++ b/net/can/Kconfig
@@ -55,6 +55,19 @@ config CAN_GW
source "net/can/
On 06.10.20 22:27, Marc Kleine-Budde wrote:
On 9/28/20 10:04 PM, Oliver Hartkopp wrote:
CAN Transport Protocols offer support for segmented Point-to-Point
communication between CAN nodes via two defined CAN Identifiers.
As CAN frames can only transport a small amount of data bytes
(max. 8
Wrong URL for the initial commit m(
https://github.com/hartkopp/can-isotp-modules/commit/ec109096fd72c0f286316d0084494582939626e5
Sorry
On 06.10.20 09:19, Oliver Hartkopp wrote:
Hello Marc,
this code had its initial commit on Nov 5th 2008:
https://github.com/hartkopp/can-isotp/blob/master
all.
When there are no objections I would be happy to get the patch into
linux-can-next for this merge window phase and continue the further
development (if any) inside the kernel.
Best,
Oliver
On 28.09.20 22:04, Oliver Hartkopp wrote:
CAN Transport Protocols offer support for segmented Point
h.
Signed-off-by: Vincent Mailhol
Acked-by: Oliver Hartkopp
Thanks Vincent!
---
include/uapi/linux/can/raw.h | 3 +++
net/can/raw.c| 4
2 files changed, 7 insertions(+)
diff --git a/include/uapi/linux/can/raw.h b/include/uapi/linux/can/raw.h
index 6a11d308eb5c..33
transport longer PDUs as needed e.g. for
vehicle diagnosis (UDS, ISO 14229) or IP-over-CAN traffic.
This protocol driver implements data transfers according to
ISO 15765-2:2016 for 'classic' CAN and CAN FD frame types.
Signed-off-by: Oliver Hartkopp
---
MAINTAINERS|
from can_remove_proc() if can proc_dir
does not exists.
Signed-off-by: Zhang Changzhong
Acked-by: Oliver Hartkopp
Thanks!
---
net/can/proc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/can/proc.c b/net/can/proc.c
index e6881bf..077af42 100644
--- a/net/can
On 30.06.20 07:53, Michael Walle wrote:
[+ Oliver]
Hi Joakim,
Am 2020-06-30 04:42, schrieb Joakim Zhang:
-Original Message-
From: Michael Walle
Sent: 2020年6月30日 2:18
To: linux-...@vger.kernel.org; netdev@vger.kernel.org;
linux-ker...@vger.kernel.org
Cc: Wolfgang Grandegger ; Marc K
On 22/10/2019 19.28, Eric Dumazet wrote
On 10/22/19 9:42 AM, Stephen Hemminger wrote:
Why not fix fq_codel to return the same errors as other qdisc?
I believe the same problem would happen with any qdisc not doing tail drops.
Do we really want to enforce all qdisc to have a common drop st
According to Marc the original patch has already been applied by Dave.
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=473d924d7d46cb57aa4c1863261d18366af345af
Thanks for the support & sorry for the noise!
Best regards,
Oliver
On 30/07/2019 08.43, Oliver Hart
1 - 100 of 335 matches
Mail list logo
