netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net 0/1] pull-request: can 2023-02-07
@ 2023-02-07 14:05 Marc Kleine-Budde
  2023-02-07 14:05 ` [PATCH net] can: j1939: do not wait 250 ms if the same addr was already claimed Marc Kleine-Budde
  0 siblings, 1 reply; 3+ messages in thread
From: Marc Kleine-Budde @ 2023-02-07 14:05 UTC (permalink / raw)
  To: netdev; +Cc: davem, kuba, linux-can, kernel

Hello Jakub, hello David,

this is a pull request of 1 patch for net/master.

The patch is from Devid Antonio Filoni and fixes an address claiming
problem in the J1939 CAN protocol.

regards,
Marc

---
The following changes since commit 811d581194f7412eda97acc03d17fc77824b561f:

  net: USB: Fix wrong-direction WARNING in plusb.c (2023-02-06 09:59:35 +0000)

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-6.2-20230207

for you to fetch changes up to 4ae5e1e97c44f4654516c1d41591a462ed62fa7b:

  can: j1939: do not wait 250 ms if the same addr was already claimed (2023-02-07 15:00:22 +0100)

----------------------------------------------------------------
linux-can-fixes-for-6.2-20230207

----------------------------------------------------------------
Devid Antonio Filoni (1):
      can: j1939: do not wait 250 ms if the same addr was already claimed

 net/can/j1939/address-claim.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)



^ permalink raw reply	[flat|nested] 3+ messages in thread

* [PATCH net] can: j1939: do not wait 250 ms if the same addr was already claimed
  2023-02-07 14:05 [PATCH net 0/1] pull-request: can 2023-02-07 Marc Kleine-Budde
@ 2023-02-07 14:05 ` Marc Kleine-Budde
  2023-02-08  5:30   ` patchwork-bot+netdevbpf
  0 siblings, 1 reply; 3+ messages in thread
From: Marc Kleine-Budde @ 2023-02-07 14:05 UTC (permalink / raw)
  To: netdev
  Cc: davem, kuba, linux-can, kernel, Devid Antonio Filoni,
	Oleksij Rempel, stable, Marc Kleine-Budde

From: Devid Antonio Filoni <devid.filoni@egluetechnologies.com>

The ISO 11783-5 standard, in "4.5.2 - Address claim requirements", states:
  d) No CF shall begin, or resume, transmission on the network until 250
     ms after it has successfully claimed an address except when
     responding to a request for address-claimed.

But "Figure 6" and "Figure 7" in "4.5.4.2 - Address-claim
prioritization" show that the CF begins the transmission after 250 ms
from the first AC (address-claimed) message even if it sends another AC
message during that time window to resolve the address contention with
another CF.

As stated in "4.4.2.3 - Address-claimed message":
  In order to successfully claim an address, the CF sending an address
  claimed message shall not receive a contending claim from another CF
  for at least 250 ms.

As stated in "4.4.3.2 - NAME management (NM) message":
  1) A commanding CF can
     d) request that a CF with a specified NAME transmit the address-
        claimed message with its current NAME.
  2) A target CF shall
     d) send an address-claimed message in response to a request for a
        matching NAME

Taking the above arguments into account, the 250 ms wait is requested
only during network initialization.

Do not restart the timer on AC message if both the NAME and the address
match and so if the address has already been claimed (timer has expired)
or the AC message has been sent to resolve the contention with another
CF (timer is still running).

Signed-off-by: Devid Antonio Filoni <devid.filoni@egluetechnologies.com>
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/all/20221125170418.34575-1-devid.filoni@egluetechnologies.com
Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 net/can/j1939/address-claim.c | 40 +++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/net/can/j1939/address-claim.c b/net/can/j1939/address-claim.c
index f33c47327927..ca4ad6cdd5cb 100644
--- a/net/can/j1939/address-claim.c
+++ b/net/can/j1939/address-claim.c
@@ -165,6 +165,46 @@ static void j1939_ac_process(struct j1939_priv *priv, struct sk_buff *skb)
 	 * leaving this function.
 	 */
 	ecu = j1939_ecu_get_by_name_locked(priv, name);
+
+	if (ecu && ecu->addr == skcb->addr.sa) {
+		/* The ISO 11783-5 standard, in "4.5.2 - Address claim
+		 * requirements", states:
+		 *   d) No CF shall begin, or resume, transmission on the
+		 *      network until 250 ms after it has successfully claimed
+		 *      an address except when responding to a request for
+		 *      address-claimed.
+		 *
+		 * But "Figure 6" and "Figure 7" in "4.5.4.2 - Address-claim
+		 * prioritization" show that the CF begins the transmission
+		 * after 250 ms from the first AC (address-claimed) message
+		 * even if it sends another AC message during that time window
+		 * to resolve the address contention with another CF.
+		 *
+		 * As stated in "4.4.2.3 - Address-claimed message":
+		 *   In order to successfully claim an address, the CF sending
+		 *   an address claimed message shall not receive a contending
+		 *   claim from another CF for at least 250 ms.
+		 *
+		 * As stated in "4.4.3.2 - NAME management (NM) message":
+		 *   1) A commanding CF can
+		 *      d) request that a CF with a specified NAME transmit
+		 *         the address-claimed message with its current NAME.
+		 *   2) A target CF shall
+		 *      d) send an address-claimed message in response to a
+		 *         request for a matching NAME
+		 *
+		 * Taking the above arguments into account, the 250 ms wait is
+		 * requested only during network initialization.
+		 *
+		 * Do not restart the timer on AC message if both the NAME and
+		 * the address match and so if the address has already been
+		 * claimed (timer has expired) or the AC message has been sent
+		 * to resolve the contention with another CF (timer is still
+		 * running).
+		 */
+		goto out_ecu_put;
+	}
+
 	if (!ecu && j1939_address_is_unicast(skcb->addr.sa))
 		ecu = j1939_ecu_create_locked(priv, name);
 

base-commit: 811d581194f7412eda97acc03d17fc77824b561f
-- 
2.39.1



^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH net] can: j1939: do not wait 250 ms if the same addr was already claimed
  2023-02-07 14:05 ` [PATCH net] can: j1939: do not wait 250 ms if the same addr was already claimed Marc Kleine-Budde
@ 2023-02-08  5:30   ` patchwork-bot+netdevbpf
  0 siblings, 0 replies; 3+ messages in thread
From: patchwork-bot+netdevbpf @ 2023-02-08  5:30 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: netdev, davem, kuba, linux-can, kernel, devid.filoni, o.rempel, stable

Hello:

This patch was applied to netdev/net.git (master)
by Marc Kleine-Budde <mkl@pengutronix.de>:

On Tue,  7 Feb 2023 15:05:14 +0100 you wrote:
> From: Devid Antonio Filoni <devid.filoni@egluetechnologies.com>
> 
> The ISO 11783-5 standard, in "4.5.2 - Address claim requirements", states:
>   d) No CF shall begin, or resume, transmission on the network until 250
>      ms after it has successfully claimed an address except when
>      responding to a request for address-claimed.
> 
> [...]

Here is the summary with links:
  - [net] can: j1939: do not wait 250 ms if the same addr was already claimed
    https://git.kernel.org/netdev/net/c/4ae5e1e97c44

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-02-08  5:30 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-07 14:05 [PATCH net 0/1] pull-request: can 2023-02-07 Marc Kleine-Budde
2023-02-07 14:05 ` [PATCH net] can: j1939: do not wait 250 ms if the same addr was already claimed Marc Kleine-Budde
2023-02-08  5:30   ` patchwork-bot+netdevbpf

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