Patch "firewire: core: use long bus reset on gap count error" has been added to the 5.15-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    firewire: core: use long bus reset on gap count error

to the 5.15-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     firewire-core-use-long-bus-reset-on-gap-count-error.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 9496274cade92894a6e09d793bdddd1a5945b371
Author: Takashi Sakamoto <o-takashi@xxxxxxxxxxxxx>
Date:   Thu Feb 29 22:17:37 2024 +0900

    firewire: core: use long bus reset on gap count error
    
    [ Upstream commit d0b06dc48fb15902d7da09c5c0861e7f042a9381 ]
    
    When resetting the bus after a gap count error, use a long rather than
    short bus reset.
    
    IEEE 1394-1995 uses only long bus resets. IEEE 1394a adds the option of
    short bus resets. When video or audio transmission is in progress and a
    device is hot-plugged elsewhere on the bus, the resulting bus reset can
    cause video frame drops or audio dropouts. Short bus resets reduce or
    eliminate this problem. Accordingly, short bus resets are almost always
    preferred.
    
    However, on a mixed 1394/1394a bus, a short bus reset can trigger an
    immediate additional bus reset. This double bus reset can be interpreted
    differently by different nodes on the bus, resulting in an inconsistent gap
    count after the bus reset. An inconsistent gap count will cause another bus
    reset, leading to a neverending bus reset loop. This only happens for some
    bus topologies, not for all mixed 1394/1394a buses.
    
    By instead sending a long bus reset after a gap count inconsistency, we
    avoid the doubled bus reset, restoring the bus to normal operation.
    
    Signed-off-by: Adam Goldman <adamg@xxxxxxxxx>
    Link: https://sourceforge.net/p/linux1394/mailman/message/58741624/
    Signed-off-by: Takashi Sakamoto <o-takashi@xxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/firewire/core-card.c b/drivers/firewire/core-card.c
index be195ba834632..d446a72629414 100644
--- a/drivers/firewire/core-card.c
+++ b/drivers/firewire/core-card.c
@@ -500,7 +500,19 @@ static void bm_work(struct work_struct *work)
 		fw_notice(card, "phy config: new root=%x, gap_count=%d\n",
 			  new_root_id, gap_count);
 		fw_send_phy_config(card, new_root_id, generation, gap_count);
-		reset_bus(card, true);
+		/*
+		 * Where possible, use a short bus reset to minimize
+		 * disruption to isochronous transfers. But in the event
+		 * of a gap count inconsistency, use a long bus reset.
+		 *
+		 * As noted in 1394a 8.4.6.2, nodes on a mixed 1394/1394a bus
+		 * may set different gap counts after a bus reset. On a mixed
+		 * 1394/1394a bus, a short bus reset can get doubled. Some
+		 * nodes may treat the double reset as one bus reset and others
+		 * may treat it as two, causing a gap count inconsistency
+		 * again. Using a long bus reset prevents this.
+		 */
+		reset_bus(card, card->gap_count != 0);
 		/* Will allocate broadcast channel after the reset. */
 		goto out;
 	}




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux