* pull-request: can 2020-12-04 @ 2020-12-04 13:35 Marc Kleine-Budde 2020-12-04 13:35 ` [net 1/3] can: softing: softing_netdev_open(): fix error handling Marc Kleine-Budde ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Marc Kleine-Budde @ 2020-12-04 13:35 UTC (permalink / raw) To: netdev; +Cc: davem, kuba, linux-can, kernel Hello Jakub, hello David, here's a pull request of 3 patches for net/master. Zhang Qilong contributes a patch for the softing driver, which fixes the error handling in the softing_netdev_open() function. Oliver Hartkopp has two patches for the ISOTP CAN protocol and says: | This patch set contains a fix that showed up while implementing the | functional addressing switch suggested by Thomas Wagner. | | Unfortunately the functional addressing switch came in very late but | it is really very simple and already tested. | | I would like to leave it to the maintainers whether the second patch | can still go into the 5.10-rc tree, which is intended for long-term. regards, Marc --- The following changes since commit bbe2ba04c5a92a49db8a42c850a5a2f6481e47eb: Merge tag 'net-5.10-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2020-12-03 13:10:11 -0800) 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-5.10-20201204 for you to fetch changes up to 2e15980d931afa2e51a067ff6adebf5d5b3929b1: can: isotp: add SF_BROADCAST support for functional addressing (2020-12-04 12:49:12 +0100) ---------------------------------------------------------------- linux-can-fixes-for-5.10-20201204 ---------------------------------------------------------------- Oliver Hartkopp (2): can: isotp: isotp_setsockopt(): block setsockopt on bound sockets can: isotp: add SF_BROADCAST support for functional addressing Zhang Qilong (1): can: softing: softing_netdev_open(): fix error handling drivers/net/can/softing/softing_main.c | 9 +++++++-- include/uapi/linux/can/isotp.h | 2 +- net/can/isotp.c | 32 +++++++++++++++++++++++--------- 3 files changed, 31 insertions(+), 12 deletions(-) ^ permalink raw reply [flat|nested] 16+ messages in thread
* [net 1/3] can: softing: softing_netdev_open(): fix error handling 2020-12-04 13:35 pull-request: can 2020-12-04 Marc Kleine-Budde @ 2020-12-04 13:35 ` Marc Kleine-Budde 2020-12-04 13:35 ` [net 2/3] can: isotp: isotp_setsockopt(): block setsockopt on bound sockets Marc Kleine-Budde 2020-12-04 13:35 ` [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing Marc Kleine-Budde 2 siblings, 0 replies; 16+ messages in thread From: Marc Kleine-Budde @ 2020-12-04 13:35 UTC (permalink / raw) To: netdev Cc: davem, kuba, linux-can, kernel, Zhang Qilong, Kurt Van Dijck, Marc Kleine-Budde From: Zhang Qilong <zhangqilong3@huawei.com> If softing_netdev_open() fails, we should call close_candev() to avoid reference leak. Fixes: 03fd3cf5a179d ("can: add driver for Softing card") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Acked-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> Link: https://lore.kernel.org/r/20201202151632.1343786-1-zhangqilong3@huawei.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> --- drivers/net/can/softing/softing_main.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/net/can/softing/softing_main.c b/drivers/net/can/softing/softing_main.c index 9d2faaa39ce4..c9ca8b9fceb9 100644 --- a/drivers/net/can/softing/softing_main.c +++ b/drivers/net/can/softing/softing_main.c @@ -382,8 +382,13 @@ static int softing_netdev_open(struct net_device *ndev) /* check or determine and set bittime */ ret = open_candev(ndev); - if (!ret) - ret = softing_startstop(ndev, 1); + if (ret) + return ret; + + ret = softing_startstop(ndev, 1); + if (ret < 0) + close_candev(ndev); + return ret; } base-commit: bbe2ba04c5a92a49db8a42c850a5a2f6481e47eb -- 2.29.2 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [net 2/3] can: isotp: isotp_setsockopt(): block setsockopt on bound sockets 2020-12-04 13:35 pull-request: can 2020-12-04 Marc Kleine-Budde 2020-12-04 13:35 ` [net 1/3] can: softing: softing_netdev_open(): fix error handling Marc Kleine-Budde @ 2020-12-04 13:35 ` Marc Kleine-Budde 2020-12-04 13:35 ` [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing Marc Kleine-Budde 2 siblings, 0 replies; 16+ messages in thread From: Marc Kleine-Budde @ 2020-12-04 13:35 UTC (permalink / raw) To: netdev Cc: davem, kuba, linux-can, kernel, Oliver Hartkopp, Thomas Wagner, Marc Kleine-Budde From: Oliver Hartkopp <socketcan@hartkopp.net> The isotp socket can be widely configured in its behaviour regarding addressing types, fill-ups, receive pattern tests and link layer length. Usually all these settings need to be fixed before bind() and can not be changed afterwards. This patch adds a check to enforce the common usage pattern. Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Tested-by: Thomas Wagner <thwa1@web.de> Link: https://lore.kernel.org/r/20201203140604.25488-2-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> --- 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/can/isotp.c +++ b/net/can/isotp.c @@ -1157,6 +1157,9 @@ static int isotp_setsockopt(struct socket *sock, int level, int optname, if (level != SOL_CAN_ISOTP) return -EINVAL; + if (so->bound) + return -EISCONN; + switch (optname) { case CAN_ISOTP_OPTS: if (optlen != sizeof(struct can_isotp_options)) -- 2.29.2 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing 2020-12-04 13:35 pull-request: can 2020-12-04 Marc Kleine-Budde 2020-12-04 13:35 ` [net 1/3] can: softing: softing_netdev_open(): fix error handling Marc Kleine-Budde 2020-12-04 13:35 ` [net 2/3] can: isotp: isotp_setsockopt(): block setsockopt on bound sockets Marc Kleine-Budde @ 2020-12-04 13:35 ` Marc Kleine-Budde 2020-12-05 3:44 ` Jakub Kicinski 2 siblings, 1 reply; 16+ messages in thread From: Marc Kleine-Budde @ 2020-12-04 13:35 UTC (permalink / raw) To: netdev Cc: davem, kuba, linux-can, kernel, Oliver Hartkopp, Thomas Wagner, Marc Kleine-Budde From: Oliver Hartkopp <socketcan@hartkopp.net> 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 data units can be send on the specified CAN interface and the given tp.tx_id after bind(). In opposite to normal and extended 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. Suggested-by: Thomas Wagner <thwa1@web.de> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Tested-by: Thomas Wagner <thwa1@web.de> Link: https://lore.kernel.org/r/20201203140604.25488-3-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> --- 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..c55935b64ccc 100644 --- a/include/uapi/linux/can/isotp.h +++ b/include/uapi/linux/can/isotp.h @@ -135,7 +135,7 @@ struct can_isotp_ll_options { #define CAN_ISOTP_FORCE_RXSTMIN 0x100 /* ignore CFs depending on rx stmin */ #define CAN_ISOTP_RX_EXT_ADDR 0x200 /* different rx extended addressing */ #define CAN_ISOTP_WAIT_TX_DONE 0x400 /* wait for tx completion */ - +#define CAN_ISOTP_SF_BROADCAST 0x800 /* 1-to-N functional addressing */ /* default values */ diff --git a/net/can/isotp.c b/net/can/isotp.c index 26bdc3c20b7e..5ce26e568f16 100644 --- a/net/can/isotp.c +++ b/net/can/isotp.c @@ -865,6 +865,14 @@ static int isotp_sendmsg(struct socket *sock, struct msghdr *msg, size_t size) if (!size || size > MAX_MSG_LENGTH) return -EINVAL; + /* take care of a potential SF_DL ESC offset for TX_DL > 8 */ + off = (so->tx.ll_dl > CAN_MAX_DLEN) ? 1 : 0; + + /* does the given data fit into a single frame for SF_BROADCAST? */ + if ((so->opt.flags & CAN_ISOTP_SF_BROADCAST) && + (size > so->tx.ll_dl - SF_PCI_SZ4 - ae - off)) + return -EINVAL; + err = memcpy_from_msg(so->tx.buf, msg, size); if (err < 0) return err; @@ -891,9 +899,6 @@ static int isotp_sendmsg(struct socket *sock, struct msghdr *msg, size_t size) cf = (struct canfd_frame *)skb->data; skb_put(skb, so->ll.mtu); - /* take care of a potential SF_DL ESC offset for TX_DL > 8 */ - off = (so->tx.ll_dl > CAN_MAX_DLEN) ? 1 : 0; - /* check for single frame transmission depending on TX_DL */ if (size <= so->tx.ll_dl - SF_PCI_SZ4 - ae - off) { /* The message size generally fits into a SingleFrame - good. @@ -1016,7 +1021,7 @@ static int isotp_release(struct socket *sock) hrtimer_cancel(&so->rxtimer); /* remove current filters & unregister */ - if (so->bound) { + if (so->bound && (!(so->opt.flags & CAN_ISOTP_SF_BROADCAST))) { if (so->ifindex) { struct net_device *dev; @@ -1052,6 +1057,7 @@ static int isotp_bind(struct socket *sock, struct sockaddr *uaddr, int len) struct net_device *dev; int err = 0; int notify_enetdown = 0; + int do_rx_reg = 1; if (len < CAN_REQUIRED_SIZE(struct sockaddr_can, can_addr.tp)) return -EINVAL; @@ -1066,6 +1072,10 @@ static int isotp_bind(struct socket *sock, struct sockaddr *uaddr, int len) if (!addr->can_ifindex) return -ENODEV; + /* do not register frame reception for functional addressing */ + if (so->opt.flags & CAN_ISOTP_SF_BROADCAST) + do_rx_reg = 0; + lock_sock(sk); if (so->bound && addr->can_ifindex == so->ifindex && @@ -1093,13 +1103,14 @@ static int isotp_bind(struct socket *sock, struct sockaddr *uaddr, int len) ifindex = dev->ifindex; - can_rx_register(net, dev, addr->can_addr.tp.rx_id, - SINGLE_MASK(addr->can_addr.tp.rx_id), isotp_rcv, sk, - "isotp", sk); + if (do_rx_reg) + can_rx_register(net, dev, addr->can_addr.tp.rx_id, + SINGLE_MASK(addr->can_addr.tp.rx_id), + isotp_rcv, sk, "isotp", sk); dev_put(dev); - if (so->bound) { + if (so->bound && do_rx_reg) { /* unregister old filter */ if (so->ifindex) { dev = dev_get_by_index(net, so->ifindex); @@ -1302,7 +1313,7 @@ static int isotp_notifier(struct notifier_block *nb, unsigned long msg, case NETDEV_UNREGISTER: lock_sock(sk); /* remove current filters & unregister */ - if (so->bound) + if (so->bound && (!(so->opt.flags & CAN_ISOTP_SF_BROADCAST))) can_rx_unregister(dev_net(dev), dev, so->rxid, SINGLE_MASK(so->rxid), isotp_rcv, sk); -- 2.29.2 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing 2020-12-04 13:35 ` [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing Marc Kleine-Budde @ 2020-12-05 3:44 ` Jakub Kicinski 2020-12-05 11:26 ` Oliver Hartkopp 0 siblings, 1 reply; 16+ messages in thread From: Jakub Kicinski @ 2020-12-05 3:44 UTC (permalink / raw) To: Marc Kleine-Budde Cc: netdev, davem, linux-can, kernel, Oliver Hartkopp, Thomas Wagner On Fri, 4 Dec 2020 14:35:08 +0100 Marc Kleine-Budde wrote: > From: Oliver Hartkopp <socketcan@hartkopp.net> > > 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 data units can be send on the specified CAN interface and the > given tp.tx_id after bind(). > > In opposite to normal and extended 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. Unclear from this patch what is getting fixed. Looks a little bit like a feature which could be added in a backward compatible way, no? Is it only added for completeness of the ISOTP implementation? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing 2020-12-05 3:44 ` Jakub Kicinski @ 2020-12-05 11:26 ` Oliver Hartkopp 2020-12-05 20:24 ` Marc Kleine-Budde 0 siblings, 1 reply; 16+ messages in thread From: Oliver Hartkopp @ 2020-12-05 11:26 UTC (permalink / raw) To: Jakub Kicinski, Marc Kleine-Budde Cc: netdev, davem, linux-can, kernel, Thomas Wagner 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 <socketcan@hartkopp.net> >> >> 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 data units can be send on the specified CAN interface and the >> given tp.tx_id after bind(). >> >> In opposite to normal and extended 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. > > Unclear from this patch what is getting fixed. Looks a little bit like > a feature which could be added in a backward compatible way, no? > Is it only added for completeness of the ISOTP implementation? > Yes, the latter. It's a very small and simple tested addition and I hope it can still go into the initial upstream process. Many thanks, Oliver ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing 2020-12-05 11:26 ` Oliver Hartkopp @ 2020-12-05 20:24 ` Marc Kleine-Budde 2020-12-05 20:33 ` Jakub Kicinski 0 siblings, 1 reply; 16+ messages in thread From: Marc Kleine-Budde @ 2020-12-05 20:24 UTC (permalink / raw) To: Oliver Hartkopp, Jakub Kicinski Cc: netdev, davem, linux-can, kernel, Thomas Wagner [-- Attachment #1.1: Type: text/plain, Size: 1571 bytes --] On 12/5/20 12:26 PM, Oliver Hartkopp wrote: > > > 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 <socketcan@hartkopp.net> >>> >>> 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 data units can be send on the specified CAN interface and the >>> given tp.tx_id after bind(). >>> >>> In opposite to normal and extended 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. >> >> Unclear from this patch what is getting fixed. Looks a little bit like >> a feature which could be added in a backward compatible way, no? >> Is it only added for completeness of the ISOTP implementation? >> > > Yes, the latter. > > It's a very small and simple tested addition and I hope it can still go > into the initial upstream process. What about the (incremental?) change that Thomas Wagner posted? https://lore.kernel.org/r/20201204135557.55599-1-thwa1@web.de Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing 2020-12-05 20:24 ` Marc Kleine-Budde @ 2020-12-05 20:33 ` Jakub Kicinski 2020-12-05 20:56 ` Marc Kleine-Budde 0 siblings, 1 reply; 16+ messages in thread From: Jakub Kicinski @ 2020-12-05 20:33 UTC (permalink / raw) To: Marc Kleine-Budde Cc: Oliver Hartkopp, netdev, davem, linux-can, kernel, Thomas Wagner On Sat, 5 Dec 2020 21:24:42 +0100 Marc Kleine-Budde wrote: > On 12/5/20 12:26 PM, Oliver Hartkopp wrote: > > 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 <socketcan@hartkopp.net> > >>> > >>> 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 data units can be send on the specified CAN interface and the > >>> given tp.tx_id after bind(). > >>> > >>> In opposite to normal and extended 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. > >> > >> Unclear from this patch what is getting fixed. Looks a little bit like > >> a feature which could be added in a backward compatible way, no? > >> Is it only added for completeness of the ISOTP implementation? > >> > > > > Yes, the latter. > > > > It's a very small and simple tested addition and I hope it can still go > > into the initial upstream process. > > What about the (incremental?) change that Thomas Wagner posted? > > https://lore.kernel.org/r/20201204135557.55599-1-thwa1@web.de That settles it :) This change needs to got into -next and 5.11. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing 2020-12-05 20:33 ` Jakub Kicinski @ 2020-12-05 20:56 ` Marc Kleine-Budde 2020-12-05 21:09 ` Jakub Kicinski 0 siblings, 1 reply; 16+ messages in thread From: Marc Kleine-Budde @ 2020-12-05 20:56 UTC (permalink / raw) To: Jakub Kicinski Cc: Oliver Hartkopp, Thomas Wagner, linux-can, kernel, netdev, davem [-- Attachment #1.1: Type: text/plain, Size: 665 bytes --] 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-thwa1@web.de > > That settles it :) This change needs to got into -next and 5.11. Ok. Can you take patch 1, which is a real fix: https://lore.kernel.org/linux-can/20201204133508.742120-2-mkl@pengutronix.de/ Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing 2020-12-05 20:56 ` Marc Kleine-Budde @ 2020-12-05 21:09 ` Jakub Kicinski 2020-12-05 21:20 ` Marc Kleine-Budde 2020-12-08 12:54 ` Oliver Hartkopp 0 siblings, 2 replies; 16+ messages in thread From: Jakub Kicinski @ 2020-12-05 21:09 UTC (permalink / raw) To: Marc Kleine-Budde Cc: Oliver Hartkopp, Thomas Wagner, linux-can, kernel, netdev, davem 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-thwa1@web.de > > > > That settles it :) This change needs to got into -next and 5.11. > > Ok. Can you take patch 1, which is a real fix: > > https://lore.kernel.org/linux-can/20201204133508.742120-2-mkl@pengutronix.de/ Sure! Applied that one from the ML (I assumed that's what you meant). Thanks! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing 2020-12-05 21:09 ` Jakub Kicinski @ 2020-12-05 21:20 ` Marc Kleine-Budde 2020-12-08 12:54 ` Oliver Hartkopp 1 sibling, 0 replies; 16+ messages in thread From: Marc Kleine-Budde @ 2020-12-05 21:20 UTC (permalink / raw) To: Jakub Kicinski Cc: Oliver Hartkopp, Thomas Wagner, linux-can, kernel, netdev, davem [-- Attachment #1.1: Type: text/plain, Size: 913 bytes --] On 12/5/20 10:09 PM, 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-thwa1@web.de >>> >>> That settles it :) This change needs to got into -next and 5.11. >> >> Ok. Can you take patch 1, which is a real fix: >> >> https://lore.kernel.org/linux-can/20201204133508.742120-2-mkl@pengutronix.de/ > > Sure! Applied that one from the ML (I assumed that's what you meant). Thanks, exactly that one. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing 2020-12-05 21:09 ` Jakub Kicinski 2020-12-05 21:20 ` Marc Kleine-Budde @ 2020-12-08 12:54 ` Oliver Hartkopp 2020-12-08 18:07 ` Jakub Kicinski 1 sibling, 1 reply; 16+ messages in thread From: Oliver Hartkopp @ 2020-12-08 12:54 UTC (permalink / raw) To: Jakub Kicinski, Marc Kleine-Budde Cc: Thomas Wagner, linux-can, kernel, netdev, davem 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-thwa1@web.de >>> >>> That settles it :) This change needs to got into -next and 5.11. >> >> Ok. Can you take patch 1, which is a real fix: >> >> https://lore.kernel.org/linux-can/20201204133508.742120-2-mkl@pengutronix.de/ > > Sure! Applied that one from the ML (I assumed that's what you meant). > I just double-checked this mail and in fact the second patch from Marc's pull request was a real fix too: https://lore.kernel.org/linux-can/20201204133508.742120-3-mkl@pengutronix.de/ Btw. the missing feature which was added for completeness of the ISOTP implementation has now also integrated the improvement suggested by Thomas Wagner: https://lore.kernel.org/linux-can/20201206144731.4609-1-socketcan@hartkopp.net/T/#u Would be cool if it could go into the initial iso-tp contribution as 5.10 becomes a long-term kernel. But I don't want to be pushy - treat it as your like. Many thanks, Oliver ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing 2020-12-08 12:54 ` Oliver Hartkopp @ 2020-12-08 18:07 ` Jakub Kicinski 2020-12-09 7:45 ` Marc Kleine-Budde 0 siblings, 1 reply; 16+ messages in thread From: Jakub Kicinski @ 2020-12-08 18:07 UTC (permalink / raw) To: Oliver Hartkopp Cc: Marc Kleine-Budde, Thomas Wagner, linux-can, kernel, netdev, davem On Tue, 8 Dec 2020 13:54:28 +0100 Oliver Hartkopp wrote: > 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-thwa1@web.de > >>> > >>> That settles it :) This change needs to got into -next and 5.11. > >> > >> Ok. Can you take patch 1, which is a real fix: > >> > >> https://lore.kernel.org/linux-can/20201204133508.742120-2-mkl@pengutronix.de/ > > > > Sure! Applied that one from the ML (I assumed that's what you meant). > > I just double-checked this mail and in fact the second patch from Marc's > pull request was a real fix too: > > https://lore.kernel.org/linux-can/20201204133508.742120-3-mkl@pengutronix.de/ Ack, I thought it was a fix to some existing code but it's a fix to ISO-TP so we should probably get it in before someone start depending on existing behavior - Marc should I apply that one directly, too? > Btw. the missing feature which was added for completeness of the ISOTP > implementation has now also integrated the improvement suggested by > Thomas Wagner: > > https://lore.kernel.org/linux-can/20201206144731.4609-1-socketcan@hartkopp.net/T/#u > > Would be cool if it could go into the initial iso-tp contribution as > 5.10 becomes a long-term kernel. > > But I don't want to be pushy - treat it as your like. I think Linus wants to release 5.10 so that the merge window doesn't overlap with Christmas too much. Let's not push our luck. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing 2020-12-08 18:07 ` Jakub Kicinski @ 2020-12-09 7:45 ` Marc Kleine-Budde 2020-12-10 8:18 ` Oliver Hartkopp 0 siblings, 1 reply; 16+ messages in thread From: Marc Kleine-Budde @ 2020-12-09 7:45 UTC (permalink / raw) To: Jakub Kicinski, Oliver Hartkopp Cc: Thomas Wagner, linux-can, kernel, netdev, davem [-- Attachment #1.1: Type: text/plain, Size: 1473 bytes --] On 12/8/20 7:07 PM, Jakub Kicinski wrote: > On Tue, 8 Dec 2020 13:54:28 +0100 Oliver Hartkopp wrote: >> 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-thwa1@web.de >>>>> >>>>> That settles it :) This change needs to got into -next and 5.11. >>>> >>>> Ok. Can you take patch 1, which is a real fix: >>>> >>>> https://lore.kernel.org/linux-can/20201204133508.742120-2-mkl@pengutronix.de/ >>> >>> Sure! Applied that one from the ML (I assumed that's what you meant). >> >> I just double-checked this mail and in fact the second patch from Marc's >> pull request was a real fix too: >> >> https://lore.kernel.org/linux-can/20201204133508.742120-3-mkl@pengutronix.de/ > > Ack, I thought it was a fix to some existing code but it's a fix to > ISO-TP so we should probably get it in before someone start depending > on existing behavior - Marc should I apply that one directly, too? Yes, please take that patch directly. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing 2020-12-09 7:45 ` Marc Kleine-Budde @ 2020-12-10 8:18 ` Oliver Hartkopp 2020-12-10 9:55 ` Marc Kleine-Budde 0 siblings, 1 reply; 16+ messages in thread From: Oliver Hartkopp @ 2020-12-10 8:18 UTC (permalink / raw) To: Marc Kleine-Budde; +Cc: Thomas Wagner, linux-can Hello Marc, On 09.12.20 08:45, Marc Kleine-Budde wrote: > On 12/8/20 7:07 PM, Jakub Kicinski wrote: >> On Tue, 8 Dec 2020 13:54:28 +0100 Oliver Hartkopp wrote: >>> 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-thwa1@web.de >>>>>> >>>>>> That settles it :) This change needs to got into -next and 5.11. >>>>> >>>>> Ok. Can you take patch 1, which is a real fix: >>>>> >>>>> https://lore.kernel.org/linux-can/20201204133508.742120-2-mkl@pengutronix.de/ >>>> >>>> Sure! Applied that one from the ML (I assumed that's what you meant). >>> >>> I just double-checked this mail and in fact the second patch from Marc's >>> pull request was a real fix too: >>> >>> https://lore.kernel.org/linux-can/20201204133508.742120-3-mkl@pengutronix.de/ >> >> Ack, I thought it was a fix to some existing code but it's a fix to >> ISO-TP so we should probably get it in before someone start depending >> on existing behavior - Marc should I apply that one directly, too? > > Yes, please take that patch directly. The fix is in the net-tree. Do you take this patch https://lore.kernel.org/linux-can/20201206144731.4609-1-socketcan@hartkopp.net/T/#u via linux-can-next then as it is neither in can-next and net-next now ... ? And net-next will be closed soon, I assume. Thanks, Oliver ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing 2020-12-10 8:18 ` Oliver Hartkopp @ 2020-12-10 9:55 ` Marc Kleine-Budde 0 siblings, 0 replies; 16+ messages in thread From: Marc Kleine-Budde @ 2020-12-10 9:55 UTC (permalink / raw) To: Oliver Hartkopp; +Cc: Thomas Wagner, linux-can [-- Attachment #1.1: Type: text/plain, Size: 534 bytes --] On 12/10/20 9:18 AM, Oliver Hartkopp wrote: > Do you take this patch > > https://lore.kernel.org/linux-can/20201206144731.4609-1-socketcan@hartkopp.net/T/#u > > via linux-can-next then as it is neither in can-next and net-next now ... ? done Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-12-10 9:57 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-04 13:35 pull-request: can 2020-12-04 Marc Kleine-Budde 2020-12-04 13:35 ` [net 1/3] can: softing: softing_netdev_open(): fix error handling Marc Kleine-Budde 2020-12-04 13:35 ` [net 2/3] can: isotp: isotp_setsockopt(): block setsockopt on bound sockets Marc Kleine-Budde 2020-12-04 13:35 ` [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing Marc Kleine-Budde 2020-12-05 3:44 ` Jakub Kicinski 2020-12-05 11:26 ` Oliver Hartkopp 2020-12-05 20:24 ` Marc Kleine-Budde 2020-12-05 20:33 ` Jakub Kicinski 2020-12-05 20:56 ` Marc Kleine-Budde 2020-12-05 21:09 ` Jakub Kicinski 2020-12-05 21:20 ` Marc Kleine-Budde 2020-12-08 12:54 ` Oliver Hartkopp 2020-12-08 18:07 ` Jakub Kicinski 2020-12-09 7:45 ` Marc Kleine-Budde 2020-12-10 8:18 ` Oliver Hartkopp 2020-12-10 9:55 ` Marc Kleine-Budde
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).