pull-request: can 2020-12-04

pull-request: can 2020-12-04

[Marc Kleine-Budde]

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(-)

[net 1/3] can: softing: softing_netdev_open(): fix error handling

[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

[net 2/3] can: isotp: isotp_setsockopt(): block setsockopt on bound sockets

[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

[net 3/3] can: isotp: add SF_BROADCAST support for functional addressing

[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

Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing

[Jakub Kicinski]

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?

Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing

[Oliver Hartkopp]

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

Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing

[Marc Kleine-Budde]

[-- 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 --]

Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing

[Jakub Kicinski]

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.

Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing

[Marc Kleine-Budde]

[-- 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 --]

Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing

[Jakub Kicinski]

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!

Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing

[Marc Kleine-Budde]

[-- 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 --]

Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing

[Oliver Hartkopp]

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

Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing

[Jakub Kicinski]

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.

Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing

[Marc Kleine-Budde]

[-- 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 --]

Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing

[Oliver Hartkopp]

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

Re: [net 3/3] can: isotp: add SF_BROADCAST support for functional addressing

[Marc Kleine-Budde]

[-- 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 --]