linux1394-devel

[GIT PULL] firewire fixes for v6.17-rc1 kernel

[Takashi S. <o-t...@sa...>]

Hi Linus,

Please accept the following changes from the subsystem.


The following changes since commit 8f5ae30d69d7543eee0d70083daf4de8fe15d585:

  Linux 6.17-rc1 (2025-08-10 19:41:16 +0300)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git tags/firewire-fixes-6.17-rc1

for you to fetch changes up to 0342273e14c25971f2916de2b598db2e9cfeec15:

  firewire: core: reallocate buffer for FCP address handlers when more than 4 are registered (2025-08-03 21:20:15 +0900)

----------------------------------------------------------------
firewire fixes for v6.17-rc1

This set of fixes includes a solution for the issue described in the tag
annotation for v6.17 updates.

The issue involved a potential call to schedule() within an RCU read-side
critical section. The solution applies reference counting to ensure that
handlers which may call schedule() are invoked safely outside of the
critical section.

----------------------------------------------------------------
Takashi Sakamoto (4):
      firewire: core: use reference counting to invoke address handlers safely
      firewire: core: call handler for exclusive regions outside RCU read-side critical section
      firewire: core: call FCP address handlers outside RCU read-side critical section
      firewire: core: reallocate buffer for FCP address handlers when more than 4 are registered

 drivers/firewire/core-transaction.c | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------
 include/linux/firewire.h            |  4 ++++
 2 files changed, 85 insertions(+), 10 deletions(-)


Regards

Takashi Sakamoto

Re: [GIT PULL] firewire updates for v6.17 kernel

[Takashi S. <o-t...@sa...>]

Hi Edmund,

On Fri, Aug 08, 2025 at 01:50:44PM +0000, edmund.raile wrote:
> Dear Mr. Sakamoto,
> thank you for including me in the pull request, I am honored!
> 
> I tested the combination of this pull request and your fix patches [1]
> on arch 6.16.0-1-mainline (based on "Linux 6.16" 038d61fd6422)
> with TI XIO2213B and RME FireFace 800.
> 
> [1] https://lore.kernel.org/lkml/202...@sa.../
> 
> So far audio playback seems perfectly stable:
> days with varying CPU load, compiles, even mprime.
> Suspend also seems fine, even without first powering down / disconnecting
> the FireFace.
> Direct ALSA streaming or pipewire, no issues so far.
> 
> Tested-by: Edmund Raile (edm...@pr...)
> 
> Thank you for keeping FireWire alive and even developing it!

Thanks for your test, however it is my previous proposal. The latest one
is "[PATCH v2 0/4] firewire: core: call address handlers outside RCU
read-side critical section"[1]. The difference between two proposals is
just to use kalloc helpers instead of XArray for FCP handlers allocation,
thus not effects to your device.

Anyway, thanks.

[1] https://lore.kernel.org/lkml/202...@sa.../


Regards

Takashi Sakamoto

Re: [PATCH v2 0/4] firewire: core: call address handlers ouside RCU read-side critical section

[Takashi S. <o-t...@sa...>]

On Sun, Aug 03, 2025 at 09:20:11PM +0900, Takashi Sakamoto wrote:
> Hi,
> 
> This is an updated version of my previous patchset[1].
> 
> In the earlier version, XArray was used to collect FCP address handlers.
> However, in typical system, only a few handlers are registered, and
> using XArray for this purpose was unnecessarily complex and inefficient.
> A simpler and faster approach is more appropriate here.
> 
> In this v2 patchset, the kernel stack is used initially to store up to 4
> handlers. If more than 4 handlers are registered in the system, a buffer
> is dynamically allocated from the kernel heap.
> 
> [1] https://lore.kernel.org/lkml/202...@sa.../
> 
> Takashi Sakamoto (4):
>   firewire: core: use reference counting to invoke address handlers
>     safely
>   firewire: core: call handler for exclusive regions outside RCU
>     read-side critical section
>   firewire: core: call FCP address handlers outside RCU read-side
>     critical section
>   firewire: core: reallocate buffer for FCP address handlers when more
>     than 4 are registered
> 
>  drivers/firewire/core-transaction.c | 91 +++++++++++++++++++++++++----
>  include/linux/firewire.h            |  4 ++
>  2 files changed, 85 insertions(+), 10 deletions(-)
> 
> 
> base-commit: 7061835997daba9e73c723c85bd70bc4c44aef77

Applied to for-linus branch.


Thanks

Takashi Sakamoto

[PATCH v2 4/4] firewire: core: reallocate buffer for FCP address handlers when more than 4 are registered

[Takashi S. <o-t...@sa...>]

The former commit has a limitation that only up to 4 FCP address
handlers could be processed per request. Although it suffices for most
use cases, it is technically a regression.

This commit lifts the restriction by reallocating the buffer from kernel
heap when more than 4 handlers are registered. The allocation is performed
within RCU read-side critical section, thus it uses GCP_ATOMIC flag. The
buffer size is rounded up to the next power of two to align with kmalloc
allocation units.

Signed-off-by: Takashi Sakamoto <o-t...@sa...>
---
 drivers/firewire/core-transaction.c | 36 +++++++++++++++++++++++++----
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/drivers/firewire/core-transaction.c b/drivers/firewire/core-transaction.c
index 7a62c660e912..1d1c2d8f85ae 100644
--- a/drivers/firewire/core-transaction.c
+++ b/drivers/firewire/core-transaction.c
@@ -960,7 +960,7 @@ static void handle_fcp_region_request(struct fw_card *card,
 {
 	struct fw_address_handler *buffer_on_kernel_stack[BUFFER_ON_KERNEL_STACK_SIZE];
 	struct fw_address_handler *handler, **handlers;
-	int tcode, destination, source, i, count;
+	int tcode, destination, source, i, count, buffer_size;
 
 	if ((offset != (CSR_REGISTER_BASE | CSR_FCP_COMMAND) &&
 	     offset != (CSR_REGISTER_BASE | CSR_FCP_RESPONSE)) ||
@@ -983,13 +983,38 @@ static void handle_fcp_region_request(struct fw_card *card,
 
 	count = 0;
 	handlers = buffer_on_kernel_stack;
+	buffer_size = ARRAY_SIZE(buffer_on_kernel_stack);
 	scoped_guard(rcu) {
 		list_for_each_entry_rcu(handler, &address_handler_list, link) {
 			if (is_enclosing_handler(handler, offset, request->length)) {
+				if (count >= buffer_size) {
+					int next_size = buffer_size * 2;
+					struct fw_address_handler **buffer_on_kernel_heap;
+
+					if (handlers == buffer_on_kernel_stack)
+						buffer_on_kernel_heap = NULL;
+					else
+						buffer_on_kernel_heap = handlers;
+
+					buffer_on_kernel_heap =
+						krealloc_array(buffer_on_kernel_heap, next_size,
+							sizeof(*buffer_on_kernel_heap), GFP_ATOMIC);
+					// FCP is used for purposes unrelated to significant system
+					// resources (e.g. storage or networking), so allocation
+					// failures are not considered so critical.
+					if (!buffer_on_kernel_heap)
+						break;
+
+					if (handlers == buffer_on_kernel_stack) {
+						memcpy(buffer_on_kernel_heap, buffer_on_kernel_stack,
+						       sizeof(buffer_on_kernel_stack));
+					}
+
+					handlers = buffer_on_kernel_heap;
+					buffer_size = next_size;
+				}
 				get_address_handler(handler);
-				handlers[count] = handler;
-				if (++count >= ARRAY_SIZE(buffer_on_kernel_stack))
-					break;
+				handlers[count++] = handler;
 			}
 		}
 	}
@@ -1002,6 +1027,9 @@ static void handle_fcp_region_request(struct fw_card *card,
 		put_address_handler(handler);
 	}
 
+	if (handlers != buffer_on_kernel_stack)
+		kfree(handlers);
+
 	fw_send_response(card, request, RCODE_COMPLETE);
 }
 
-- 
2.48.1

[PATCH v2 3/4] firewire: core: call FCP address handlers outside RCU read-side critical section

[Takashi S. <o-t...@sa...>]

The former commit added reference counting to ensure safe invocations of
address handlers. Unlike the exclusive-region address handlers, all FCP
address handlers should be called on receiving an FCP request.

This commit uses the part of kernel stack to collect address handlers up
to 4 within the section, then invoke them outside of the section.
Reference counting ensures that each handler remains valid and safe to
call.

Lifting the limitation of supporting only 4 handlers is left for future
work.

Signed-off-by: Takashi Sakamoto <o-t...@sa...>
---
 drivers/firewire/core-transaction.c | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/firewire/core-transaction.c b/drivers/firewire/core-transaction.c
index a742971c65fa..7a62c660e912 100644
--- a/drivers/firewire/core-transaction.c
+++ b/drivers/firewire/core-transaction.c
@@ -950,13 +950,17 @@ static void handle_exclusive_region_request(struct fw_card *card,
 	put_address_handler(handler);
 }
 
+// To use kmalloc allocator efficiently, this should be power of two.
+#define BUFFER_ON_KERNEL_STACK_SIZE	4
+
 static void handle_fcp_region_request(struct fw_card *card,
 				      struct fw_packet *p,
 				      struct fw_request *request,
 				      unsigned long long offset)
 {
-	struct fw_address_handler *handler;
-	int tcode, destination, source;
+	struct fw_address_handler *buffer_on_kernel_stack[BUFFER_ON_KERNEL_STACK_SIZE];
+	struct fw_address_handler *handler, **handlers;
+	int tcode, destination, source, i, count;
 
 	if ((offset != (CSR_REGISTER_BASE | CSR_FCP_COMMAND) &&
 	     offset != (CSR_REGISTER_BASE | CSR_FCP_RESPONSE)) ||
@@ -977,18 +981,27 @@ static void handle_fcp_region_request(struct fw_card *card,
 		return;
 	}
 
+	count = 0;
+	handlers = buffer_on_kernel_stack;
 	scoped_guard(rcu) {
 		list_for_each_entry_rcu(handler, &address_handler_list, link) {
 			if (is_enclosing_handler(handler, offset, request->length)) {
 				get_address_handler(handler);
-				handler->address_callback(card, request, tcode, destination, source,
-							  p->generation, offset, request->data,
-							  request->length, handler->callback_data);
-				put_address_handler(handler);
+				handlers[count] = handler;
+				if (++count >= ARRAY_SIZE(buffer_on_kernel_stack))
+					break;
 			}
 		}
 	}
 
+	for (i = 0; i < count; ++i) {
+		handler = handlers[i];
+		handler->address_callback(card, request, tcode, destination, source,
+					  p->generation, offset, request->data,
+					  request->length, handler->callback_data);
+		put_address_handler(handler);
+	}
+
 	fw_send_response(card, request, RCODE_COMPLETE);
 }
 
-- 
2.48.1

[PATCH v2 2/4] firewire: core: call handler for exclusive regions outside RCU read-side critical section

[Takashi S. <o-t...@sa...>]

The previous commit added reference counting to ensure safe invocations of
address handlers.

This commit moves the invocation of handlers for exclusive regions outside
of the RCU read-side critical section. The address handler for the
requested region is selected within the critical section, then invoked
outside of it.

Signed-off-by: Takashi Sakamoto <o-t...@sa...>
---
 drivers/firewire/core-transaction.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/firewire/core-transaction.c b/drivers/firewire/core-transaction.c
index 29ca9f3f14ce..a742971c65fa 100644
--- a/drivers/firewire/core-transaction.c
+++ b/drivers/firewire/core-transaction.c
@@ -935,17 +935,19 @@ static void handle_exclusive_region_request(struct fw_card *card,
 	scoped_guard(rcu) {
 		handler = lookup_enclosing_address_handler(&address_handler_list, offset,
 							   request->length);
-		if (handler) {
+		if (handler)
 			get_address_handler(handler);
-			handler->address_callback(card, request, tcode, destination, source,
-						  p->generation, offset, request->data,
-						  request->length, handler->callback_data);
-			put_address_handler(handler);
-		}
 	}
 
-	if (!handler)
+	if (!handler) {
 		fw_send_response(card, request, RCODE_ADDRESS_ERROR);
+		return;
+	}
+
+	// Outside the RCU read-side critical section. Without spinlock. With reference count.
+	handler->address_callback(card, request, tcode, destination, source, p->generation, offset,
+				  request->data, request->length, handler->callback_data);
+	put_address_handler(handler);
 }
 
 static void handle_fcp_region_request(struct fw_card *card,
-- 
2.48.1

[PATCH v2 1/4] firewire: core: use reference counting to invoke address handlers safely

[Takashi S. <o-t...@sa...>]

The lifetime of address handler has been managed by linked list and RCU.
This approach was introduced in commit 35202f7d8420 ("firewire: remove
global lock around address handlers, convert to RCU"). The invocations of
address handler are performed within RCU read-side critical sections.

In commit 57e6d9f85fff ("firewire: ohci: use workqueue to handle events
of AR request/response contexts"), the invocations are in a workqueue
context. The approach still imposes limitation that sleeping is not
allowed within RCU read-side critical sections. However, since sleeping
is not permitted within RCU read-side critical sections, this approach
still has a limitation.

This commit adds reference counting to decouple handler invocation from
handler discovery. The linked list and RCU is used to discover the
handlers, while the reference counting is used to invoke them safely.

Signed-off-by: Takashi Sakamoto <o-t...@sa...>
---
 drivers/firewire/core-transaction.c | 32 +++++++++++++++++++++++++++--
 include/linux/firewire.h            |  4 ++++
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/firewire/core-transaction.c b/drivers/firewire/core-transaction.c
index d28477d84697..29ca9f3f14ce 100644
--- a/drivers/firewire/core-transaction.c
+++ b/drivers/firewire/core-transaction.c
@@ -550,6 +550,23 @@ const struct fw_address_region fw_unit_space_region =
 	{ .start = 0xfffff0000900ULL, .end = 0x1000000000000ULL, };
 #endif  /*  0  */
 
+static void complete_address_handler(struct kref *kref)
+{
+	struct fw_address_handler *handler = container_of(kref, struct fw_address_handler, kref);
+
+	complete(&handler->done);
+}
+
+static void get_address_handler(struct fw_address_handler *handler)
+{
+	kref_get(&handler->kref);
+}
+
+static int put_address_handler(struct fw_address_handler *handler)
+{
+	return kref_put(&handler->kref, complete_address_handler);
+}
+
 /**
  * fw_core_add_address_handler() - register for incoming requests
  * @handler:	callback
@@ -596,6 +613,8 @@ int fw_core_add_address_handler(struct fw_address_handler *handler,
 		if (other != NULL) {
 			handler->offset += other->length;
 		} else {
+			init_completion(&handler->done);
+			kref_init(&handler->kref);
 			list_add_tail_rcu(&handler->link, &address_handler_list);
 			ret = 0;
 			break;
@@ -621,6 +640,9 @@ void fw_core_remove_address_handler(struct fw_address_handler *handler)
 		list_del_rcu(&handler->link);
 
 	synchronize_rcu();
+
+	if (!put_address_handler(handler))
+		wait_for_completion(&handler->done);
 }
 EXPORT_SYMBOL(fw_core_remove_address_handler);
 
@@ -913,10 +935,13 @@ static void handle_exclusive_region_request(struct fw_card *card,
 	scoped_guard(rcu) {
 		handler = lookup_enclosing_address_handler(&address_handler_list, offset,
 							   request->length);
-		if (handler)
+		if (handler) {
+			get_address_handler(handler);
 			handler->address_callback(card, request, tcode, destination, source,
 						  p->generation, offset, request->data,
 						  request->length, handler->callback_data);
+			put_address_handler(handler);
+		}
 	}
 
 	if (!handler)
@@ -952,10 +977,13 @@ static void handle_fcp_region_request(struct fw_card *card,
 
 	scoped_guard(rcu) {
 		list_for_each_entry_rcu(handler, &address_handler_list, link) {
-			if (is_enclosing_handler(handler, offset, request->length))
+			if (is_enclosing_handler(handler, offset, request->length)) {
+				get_address_handler(handler);
 				handler->address_callback(card, request, tcode, destination, source,
 							  p->generation, offset, request->data,
 							  request->length, handler->callback_data);
+				put_address_handler(handler);
+			}
 		}
 	}
 
diff --git a/include/linux/firewire.h b/include/linux/firewire.h
index cceb70415ed2..d38c6e538e5c 100644
--- a/include/linux/firewire.h
+++ b/include/linux/firewire.h
@@ -341,7 +341,11 @@ struct fw_address_handler {
 	u64 length;
 	fw_address_callback_t address_callback;
 	void *callback_data;
+
+	// Only for core functions.
 	struct list_head link;
+	struct kref kref;
+	struct completion done;
 };
 
 struct fw_address_region {
-- 
2.48.1

[PATCH v2 0/4] firewire: core: call address handlers ouside RCU read-side critical section

[Takashi S. <o-t...@sa...>]

Hi,

This is an updated version of my previous patchset[1].

In the earlier version, XArray was used to collect FCP address handlers.
However, in typical system, only a few handlers are registered, and
using XArray for this purpose was unnecessarily complex and inefficient.
A simpler and faster approach is more appropriate here.

In this v2 patchset, the kernel stack is used initially to store up to 4
handlers. If more than 4 handlers are registered in the system, a buffer
is dynamically allocated from the kernel heap.

[1] https://lore.kernel.org/lkml/202...@sa.../

Takashi Sakamoto (4):
  firewire: core: use reference counting to invoke address handlers
    safely
  firewire: core: call handler for exclusive regions outside RCU
    read-side critical section
  firewire: core: call FCP address handlers outside RCU read-side
    critical section
  firewire: core: reallocate buffer for FCP address handlers when more
    than 4 are registered

 drivers/firewire/core-transaction.c | 91 +++++++++++++++++++++++++----
 include/linux/firewire.h            |  4 ++
 2 files changed, 85 insertions(+), 10 deletions(-)


base-commit: 7061835997daba9e73c723c85bd70bc4c44aef77
-- 
2.48.1

[GIT PULL] firewire updates for v6.17 kernel

[Takashi S. <o-t...@sa...>]

Hi Linus,

Please apply the changes from FireWire subsystem to your tree.

This update completes the removal of tasklet usage from the subsystem.
The bottom halves for all 1394 OHCI DMA contexts are now handled by
standard workqueues.

Based on observations from tracepoints events added between v6.10 and
v6.11, the replacement appears to function as intended. However, an
issue remains where 'schedule()' may be invoked within an RCU read-side
critical section. A proposed fix for this issue has been submitted and is
currently under review and testing. As the fix is still recent, it has
been excluded from this PR, and will be sent after the release of
v6.17-rc1.


The following changes since commit 19272b37aa4f83ca52bdf9c16d5d81bdd1354494:

  Linux 6.16-rc1 (2025-06-08 13:44:43 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git tags/firewire-updates-6.17

for you to fetch changes up to 95a042a0c8ecd3c1e886648f6f6ab9c7e4403db9:

  firewire: ohci: reduce the size of common context structure by extracting members into AT structure (2025-07-12 21:52:16 +0900)

----------------------------------------------------------------
firewire updates for v6.17

This update replaces the remaining tasklet usage in the FireWire subsystem
with workqueue for asynchronous packet transmission. With this change,
tasklets are now fully eliminated from the subsystem.

Asynchronous packet transmission is used for serial bus topology
management as well as for the operation of the SBP-2 protocol driver
(firewire-sbp2). To ensure reliability during low-memory conditions, the
associated workqueue is created with the WQ_MEM_RECLAIM flag, allowing it
to participate in memory reclaim paths. Other attributes are aligned with
those used for isochronous packet handling, which was migrated to
workqueues in v6.12.

The workqueues are sleepable and support preemptible work items, making
them more suitable for real-time workloads that benefit from timely task
preemption at the system level.

There remains an issue where 'schedule()' may be called within an RCU
read-side critical section, due to a direct replacement of
'tasklet_disable_in_atomic()' with 'disable_work_sync()'. A proposed fix
for this has been posted[1], and is currently under review and testing.
It is expected to be sent upstream later.

 [1] https://lore.kernel.org/lkml/202...@sa.../

----------------------------------------------------------------
Takashi Sakamoto (8):
      firewire: ohci: correct code comments about bus_reset tasklet
      firewire: ohci: use from_work() macro to expand parent structure of work_struct
      firewire: core: use from_work() macro to expand parent structure of work_struct
      firewire: core: allocate workqueue for AR/AT request/response contexts
      firewire: ohci: use workqueue to handle events of AR request/response contexts
      firewire: ohci: use workqueue to handle events of AT request/response contexts
      firewire: core: minor code refactoring to localize table of gap count
      firewire: ohci: reduce the size of common context structure by extracting members into AT structure

 drivers/firewire/core-card.c        |  59 +++++++++++++++++++++++++++++++++++++++--------------------
 drivers/firewire/core-cdev.c        |   3 +--
 drivers/firewire/core-device.c      |  15 +++++----------
 drivers/firewire/core-transaction.c |   7 ++++---
 drivers/firewire/net.c              |   4 ++--
 drivers/firewire/ohci.c             | 162 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------------------------------------------------------------------
 include/linux/firewire.h            |  12 ++++++++++--
 7 files changed, 146 insertions(+), 116 deletions(-)


Regards

Takashi Sakamoto

[PATCH 3/3] firewire: core: call FCP address handlers outside RCU read-side critical section

[Takashi S. <o-t...@sa...>]

The previous commit added reference counting to ensure safe invocations of
address handlers.

This commit moves the invocation of FCP address handlers outside of the
RCU read critical section. Unlike the exclusive-region address handlers,
all FCP address handlers should be called on receiving an FCP request.
An XArray is used to collect the FCP address handlers during the RCU
read-side critical section, after which they are invoked. Reference
counting ensures that each FCP address handler is called safely.

Signed-off-by: Takashi Sakamoto <o-t...@sa...>
---
 drivers/firewire/core-transaction.c | 30 +++++++++++++++++++++++------
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/firewire/core-transaction.c b/drivers/firewire/core-transaction.c
index a742971c65fa..c5408c83709c 100644
--- a/drivers/firewire/core-transaction.c
+++ b/drivers/firewire/core-transaction.c
@@ -956,13 +956,14 @@ static void handle_fcp_region_request(struct fw_card *card,
 				      unsigned long long offset)
 {
 	struct fw_address_handler *handler;
+	DEFINE_XARRAY_ALLOC(handlers);
 	int tcode, destination, source;
+	unsigned long id;
 
 	if ((offset != (CSR_REGISTER_BASE | CSR_FCP_COMMAND) &&
 	     offset != (CSR_REGISTER_BASE | CSR_FCP_RESPONSE)) ||
 	    request->length > 0x200) {
 		fw_send_response(card, request, RCODE_ADDRESS_ERROR);
-
 		return;
 	}
 
@@ -973,22 +974,39 @@ static void handle_fcp_region_request(struct fw_card *card,
 	if (tcode != TCODE_WRITE_QUADLET_REQUEST &&
 	    tcode != TCODE_WRITE_BLOCK_REQUEST) {
 		fw_send_response(card, request, RCODE_TYPE_ERROR);
+		return;
+	}
 
+	// Reserve an entry outside the RCU read-side critical section to cover most cases.
+	id = 0;
+	if (xa_reserve(&handlers, id, GFP_KERNEL) < 0) {
+		fw_send_response(card, request, RCODE_CONFLICT_ERROR);
 		return;
 	}
 
 	scoped_guard(rcu) {
 		list_for_each_entry_rcu(handler, &address_handler_list, link) {
 			if (is_enclosing_handler(handler, offset, request->length)) {
-				get_address_handler(handler);
-				handler->address_callback(card, request, tcode, destination, source,
-							  p->generation, offset, request->data,
-							  request->length, handler->callback_data);
-				put_address_handler(handler);
+				// FCP is used for purposes unrelated to significant system
+				// resources (e.g. storage or networking), so allocation
+				// failures are not considered so critical.
+				void *ptr = xa_store(&handlers, id, handler, GFP_ATOMIC);
+				if (!xa_is_err(ptr)) {
+					++id;
+					get_address_handler(handler);
+				}
 			}
 		}
 	}
 
+	xa_for_each(&handlers, id, handler) {
+		// Outside the RCU read-side critical section. Without spinlock. With reference count.
+		handler->address_callback(card, request, tcode, destination, source, p->generation,
+					  offset, request->data, request->length, handler->callback_data);
+		put_address_handler(handler);
+	}
+
+	xa_destroy(&handlers);
 	fw_send_response(card, request, RCODE_COMPLETE);
 }
 
-- 
2.48.1

[PATCH 2/3] firewire: core: call handler for exclusive regions outside RCU read-side critical section

[Takashi S. <o-t...@sa...>]

The previous commit added reference counting to ensure safe invocations of
address handlers.

This commit moves the invocation of handlers for exclusive regins outside
of the RCU read-side critical section. The address handler for the
requested region is selected within the critical section, then invoked
outside of it.

Signed-off-by: Takashi Sakamoto <o-t...@sa...>
---
 drivers/firewire/core-transaction.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/firewire/core-transaction.c b/drivers/firewire/core-transaction.c
index 29ca9f3f14ce..a742971c65fa 100644
--- a/drivers/firewire/core-transaction.c
+++ b/drivers/firewire/core-transaction.c
@@ -935,17 +935,19 @@ static void handle_exclusive_region_request(struct fw_card *card,
 	scoped_guard(rcu) {
 		handler = lookup_enclosing_address_handler(&address_handler_list, offset,
 							   request->length);
-		if (handler) {
+		if (handler)
 			get_address_handler(handler);
-			handler->address_callback(card, request, tcode, destination, source,
-						  p->generation, offset, request->data,
-						  request->length, handler->callback_data);
-			put_address_handler(handler);
-		}
 	}
 
-	if (!handler)
+	if (!handler) {
 		fw_send_response(card, request, RCODE_ADDRESS_ERROR);
+		return;
+	}
+
+	// Outside the RCU read-side critical section. Without spinlock. With reference count.
+	handler->address_callback(card, request, tcode, destination, source, p->generation, offset,
+				  request->data, request->length, handler->callback_data);
+	put_address_handler(handler);
 }
 
 static void handle_fcp_region_request(struct fw_card *card,
-- 
2.48.1

[PATCH 1/3] firewire: core: use reference counting to invoke address handlers safely

[Takashi S. <o-t...@sa...>]

The lifetime of address handler has been managed by linked list and RCU.
This approach was introduced in commit 35202f7d8420 ("firewire: remove
global lock around address handlers, convert to RCU"). The invocations of
address handler are performed within RCU read-side critical sections.

In commit 57e6d9f85fff ("firewire: ohci: use workqueue to handle events
of AR request/response contexts"), the invocations are in a workqueue
context. The approach still imposes limitation that sleeping is not
allowed within RCU read-side critical sections.

However, since sleeping is not permitted within RCU read-side
critical sections, this approach still has a limitation.

This commit adds reference counting to decouple handler invocation from
handler discovery. The linked list and RCU is used to discover the
handlers, while the reference counting is used to invoke them safely.

Signed-off-by: Takashi Sakamoto <o-t...@sa...>
---
 drivers/firewire/core-transaction.c | 32 +++++++++++++++++++++++++++--
 include/linux/firewire.h            |  4 ++++
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/firewire/core-transaction.c b/drivers/firewire/core-transaction.c
index d28477d84697..29ca9f3f14ce 100644
--- a/drivers/firewire/core-transaction.c
+++ b/drivers/firewire/core-transaction.c
@@ -550,6 +550,23 @@ const struct fw_address_region fw_unit_space_region =
 	{ .start = 0xfffff0000900ULL, .end = 0x1000000000000ULL, };
 #endif  /*  0  */
 
+static void complete_address_handler(struct kref *kref)
+{
+	struct fw_address_handler *handler = container_of(kref, struct fw_address_handler, kref);
+
+	complete(&handler->done);
+}
+
+static void get_address_handler(struct fw_address_handler *handler)
+{
+	kref_get(&handler->kref);
+}
+
+static int put_address_handler(struct fw_address_handler *handler)
+{
+	return kref_put(&handler->kref, complete_address_handler);
+}
+
 /**
  * fw_core_add_address_handler() - register for incoming requests
  * @handler:	callback
@@ -596,6 +613,8 @@ int fw_core_add_address_handler(struct fw_address_handler *handler,
 		if (other != NULL) {
 			handler->offset += other->length;
 		} else {
+			init_completion(&handler->done);
+			kref_init(&handler->kref);
 			list_add_tail_rcu(&handler->link, &address_handler_list);
 			ret = 0;
 			break;
@@ -621,6 +640,9 @@ void fw_core_remove_address_handler(struct fw_address_handler *handler)
 		list_del_rcu(&handler->link);
 
 	synchronize_rcu();
+
+	if (!put_address_handler(handler))
+		wait_for_completion(&handler->done);
 }
 EXPORT_SYMBOL(fw_core_remove_address_handler);
 
@@ -913,10 +935,13 @@ static void handle_exclusive_region_request(struct fw_card *card,
 	scoped_guard(rcu) {
 		handler = lookup_enclosing_address_handler(&address_handler_list, offset,
 							   request->length);
-		if (handler)
+		if (handler) {
+			get_address_handler(handler);
 			handler->address_callback(card, request, tcode, destination, source,
 						  p->generation, offset, request->data,
 						  request->length, handler->callback_data);
+			put_address_handler(handler);
+		}
 	}
 
 	if (!handler)
@@ -952,10 +977,13 @@ static void handle_fcp_region_request(struct fw_card *card,
 
 	scoped_guard(rcu) {
 		list_for_each_entry_rcu(handler, &address_handler_list, link) {
-			if (is_enclosing_handler(handler, offset, request->length))
+			if (is_enclosing_handler(handler, offset, request->length)) {
+				get_address_handler(handler);
 				handler->address_callback(card, request, tcode, destination, source,
 							  p->generation, offset, request->data,
 							  request->length, handler->callback_data);
+				put_address_handler(handler);
+			}
 		}
 	}
 
diff --git a/include/linux/firewire.h b/include/linux/firewire.h
index cceb70415ed2..d38c6e538e5c 100644
--- a/include/linux/firewire.h
+++ b/include/linux/firewire.h
@@ -341,7 +341,11 @@ struct fw_address_handler {
 	u64 length;
 	fw_address_callback_t address_callback;
 	void *callback_data;
+
+	// Only for core functions.
 	struct list_head link;
+	struct kref kref;
+	struct completion done;
 };
 
 struct fw_address_region {
-- 
2.48.1

[PATCH 0/3] firewire: core: call address handlers ouside RCU read-side critical section

[Takashi S. <o-t...@sa...>]

Hi,

After applying the patch that replaces tasklet usage with workqueue [1],
I realized there is a corner case where schedule() is called within an
RCU read-side critical section when handling asynchronous transaction
from local node to itself.

The mechanism is:

fw_send_request()
->ohci_send_request()
  ->at_context_transmit()
    ->handle_local_reuest()                       [to local node]
      ...
      ->fw_core_handle_request()
        ->handle_{exclusive,fcp}_region_request() [under RCU read locking]
          ->fw_send_response()
            ->ohci_send_response()
              ->at_context_transmit()
                ->handle_local_reuest()           [to local node]
                  ...
                  ->fw_core_handle_response()
                    ->ohci_cancel_packet()        [for request packet]
                      ->disable_work_sync()
                        ->schedule()

Previously, when cancelling the request subaction of a transaction,
'tasklet_disable_in_atomic()' was used. However, this function is now
deprecated, as you know. It has been replaced with disable_work_sync()
which requires that the workqueue be allowed to sleep when invoking the
address handler.

The purpose of this patch series is to move the invocation of address
handlers outside the RCU read-side critical section. Reference counting
is newly added to ensure safe invocation outside the section.

[1] https://lore.kernel.org/lkml/202...@sa.../



Takashi Sakamoto (3):
  firewire: core: use reference counting to invoke address handlers
    safely
  firewire: core: call handler for exclusive regions outside RCU
    read-side critical section
  firewire: core: call FCP address handlers outside RCU read-side
    critical section

 drivers/firewire/core-transaction.c | 66 +++++++++++++++++++++++++----
 include/linux/firewire.h            |  4 ++
 2 files changed, 61 insertions(+), 9 deletions(-)


Regards

Takashi Sakamoto
-- 
2.48.1

Re: Possible regression with the FW643 chipset

[AreYouLoco? <are...@pa...>]

So looking at your previous mail output Takashi-san

Capabilities: [4c] MSI: Enable-

So seems like in your case quirk=0x10 seems to be applied. That disables MSI capability. That was found in other thread to be coherent solution to all mentioned problems me and other users had. Even hot-plug works correctly with that quirk.

Did you apply quirk yourself manually in co fig and forgot. Or the kernel applied it by itself? Is it really applied in your case?

Looking at the code in master the quirk suppose to be applied only to FW643 hw rev6 or pci id 6 or some sort. And I believe it is needed in general for that chip. (So ANY_PCI_ID as other quirks are set for other chipsets.)

Possibly needed for other LSI (Agere) chips as well. Not only FW643.

So for me its solved for now.

But just looking for proper solution upstream.

On June 20, 2025 1:12:49 PM UTC, Takashi Sakamoto <o-t...@sa...> wrote:
>Hi,
>
>On Fri, Jun 20, 2025 at 08:52:42AM +0930, Jonathan Woithe wrote:
>> Alternatively, are there any FW643 users who have no problem with device
>> detection under a 6.12.x (or later) kernel?  If so this would conclusively
>> rule out a kernel issue.
>
>I can not regenerate the issue with the kernel modules provided by the
>stock kernel in Ubuntu 25.04 amd64 (v6.14). The machine consists of
>
>* ASUSTeK COMPUTER INC. TUF GAMING X570-PLUS
>* AMD Ryzen™ 7 5700G with Radeon™ Graphics × 16
>
>
>```
>$ dpkg -S /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/*
>linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/firewire-core.ko.zst
>linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/firewire-net.ko.zst
>linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/firewire-ohci.ko.zst
>linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/firewire-sbp2.ko.zst
>linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/nosy.ko.zst
>
>$ sudo lspci -vvnn
>06:00.0 FireWire (IEEE 1394) [0c00]: LSI Corporation FW643 [TrueFire] PCIe 1394b Controller [11c1:5901] (rev 06) (prog-if 10 [OHCI])
>        Subsystem: LSI Corporation FW643 [TrueFire] PCIe 1394b Controller [11c1:5900]
>        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>        Latency: 0, Cache Line Size: 64 bytes
>        Interrupt: pin A routed to IRQ 40
>        IOMMU group: 20
>        Region 0: Memory at fc600000 (64-bit, non-prefetchable) [size=4K]
>        Capabilities: [44] Power Management version 3
>                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
>                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
>        Capabilities: [4c] MSI: Enable- Count=1/1 Maskable- 64bit+
>                Address: 0000000000000000  Data: 0000
>        Capabilities: [60] Express (v1) Endpoint, IntMsgNum 0
>                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 <64us
>                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0W TEE-IO-
>                DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+
>                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>                        MaxPayload 128 bytes, MaxReadReq 512 bytes
>                DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend-
>                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us
>                        ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
>                LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
>                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                LnkSta: Speed 2.5GT/s, Width x1
>                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>        Capabilities: [100 v1] Advanced Error Reporting
>                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
>                        ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr-
>                        PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked-
>                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
>                        ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr-
>                        PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked-
>                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
>                        ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr-
>                        PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked-
>                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CorrIntErr- HeaderOF-
>                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ CorrIntErr- HeaderOF-
>                AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
>                        MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
>                HeaderLog: 00000000 00000000 00000000 00000000
>        Capabilities: [140 v1] Virtual Channel
>                Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
>                Arb:    Fixed- WRR32- WRR64- WRR128-
>                Ctrl:   ArbSelect=Fixed
>                Status: InProgress-
>                VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>                        Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
>                        Status: NegoPending- InProgress-
>                VC1:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>                        Ctrl:   Enable- ID=1 ArbSelect=Fixed TC/VC=00
>                        Status: NegoPending- InProgress-
>        Capabilities: [170 v1] Device Serial Number 12-34-56-10-12-30-00-86
>        Kernel driver in use: firewire_ohci
>        Kernel modules: firewire_ohci
>
>```
>
>My Phonic FireFly 808 Universal is detected successfully even after the
>reported steps.
>
>
>Thanks
>
>Takashi Sakamoto
>
>
>_______________________________________________
>mailing list lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linux1394-devel

Re: [PATCH] firewire: ohci: reduce the size of common context structure by extracting members into AT structure

[Takashi S. <o-t...@sa...>]

On Thu, Jul 10, 2025 at 10:19:16PM +0900, Takashi Sakamoto wrote:
> In commit 386a4153a2c1 ("firewire: ohci: cache the context run bit"), a
> running member was added to the context structure to cache the running
> state of a given DMA context. Although this member is accessible from IR,
> IT, and AT contexts, it is currently used only by the AT context.
> 
> Additionally, the context structure includes a work item, which is also
> used by the AT context. Both members are unnecessary for IR and IT
> contexts.
> 
> This commit refactors the code by moving these two members into a new
> structure specific to AT context.
> 
> Signed-off-by: Takashi Sakamoto <o-t...@sa...>
> ---
>  drivers/firewire/ohci.c | 92 ++++++++++++++++++++++-------------------
>  1 file changed, 49 insertions(+), 43 deletions(-)

Applied to for-next branch.


Thanks

Takashi Sakamoto

[PATCH] firewire: ohci: reduce the size of common context structure by extracting members into AT structure

[Takashi S. <o-t...@sa...>]

In commit 386a4153a2c1 ("firewire: ohci: cache the context run bit"), a
running member was added to the context structure to cache the running
state of a given DMA context. Although this member is accessible from IR,
IT, and AT contexts, it is currently used only by the AT context.

Additionally, the context structure includes a work item, which is also
used by the AT context. Both members are unnecessary for IR and IT
contexts.

This commit refactors the code by moving these two members into a new
structure specific to AT context.

Signed-off-by: Takashi Sakamoto <o-t...@sa...>
---
 drivers/firewire/ohci.c | 92 ++++++++++++++++++++++-------------------
 1 file changed, 49 insertions(+), 43 deletions(-)

diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
index 709a714fd5c8..5d8301b0f3aa 100644
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -128,7 +128,6 @@ struct context {
 	int total_allocation;
 	u32 current_bus;
 	bool running;
-	bool flushing;
 
 	/*
 	 * List of page-sized buffers for storing DMA descriptors.
@@ -157,8 +156,12 @@ struct context {
 	int prev_z;
 
 	descriptor_callback_t callback;
+};
 
+struct at_context {
+	struct context context;
 	struct work_struct work;
+	bool flushing;
 };
 
 struct iso_context {
@@ -204,8 +207,8 @@ struct fw_ohci {
 
 	struct ar_context ar_request_ctx;
 	struct ar_context ar_response_ctx;
-	struct context at_request_ctx;
-	struct context at_response_ctx;
+	struct at_context at_request_ctx;
+	struct at_context at_response_ctx;
 
 	u32 it_context_support;
 	u32 it_context_mask;     /* unoccupied IT contexts */
@@ -1178,9 +1181,9 @@ static void context_retire_descriptors(struct context *ctx)
 
 static void ohci_at_context_work(struct work_struct *work)
 {
-	struct context *ctx = from_work(ctx, work, work);
+	struct at_context *ctx = from_work(ctx, work, work);
 
-	context_retire_descriptors(ctx);
+	context_retire_descriptors(&ctx->context);
 }
 
 static void ohci_isoc_context_work(struct work_struct *work)
@@ -1382,17 +1385,17 @@ struct driver_data {
  * Must always be called with the ochi->lock held to ensure proper
  * generation handling and locking around packet queue manipulation.
  */
-static int at_context_queue_packet(struct context *ctx,
-				   struct fw_packet *packet)
+static int at_context_queue_packet(struct at_context *ctx, struct fw_packet *packet)
 {
-	struct fw_ohci *ohci = ctx->ohci;
+	struct context *context = &ctx->context;
+	struct fw_ohci *ohci = context->ohci;
 	dma_addr_t d_bus, payload_bus;
 	struct driver_data *driver_data;
 	struct descriptor *d, *last;
 	__le32 *header;
 	int z, tcode;
 
-	d = context_get_descriptors(ctx, 4, &d_bus);
+	d = context_get_descriptors(context, 4, &d_bus);
 	if (d == NULL) {
 		packet->ack = RCODE_SEND_ERROR;
 		return -1;
@@ -1422,7 +1425,7 @@ static int at_context_queue_packet(struct context *ctx,
 		ohci1394_at_data_set_destination_id(header,
 						    async_header_get_destination(packet->header));
 
-		if (ctx == &ctx->ohci->at_response_ctx) {
+		if (ctx == &ohci->at_response_ctx) {
 			ohci1394_at_data_set_rcode(header, async_header_get_rcode(packet->header));
 		} else {
 			ohci1394_at_data_set_destination_offset(header,
@@ -1511,17 +1514,17 @@ static int at_context_queue_packet(struct context *ctx,
 		return -1;
 	}
 
-	context_append(ctx, d, z, 4 - z);
+	context_append(context, d, z, 4 - z);
 
-	if (ctx->running)
-		reg_write(ohci, CONTROL_SET(ctx->regs), CONTEXT_WAKE);
+	if (context->running)
+		reg_write(ohci, CONTROL_SET(context->regs), CONTEXT_WAKE);
 	else
-		context_run(ctx, 0);
+		context_run(context, 0);
 
 	return 0;
 }
 
-static void at_context_flush(struct context *ctx)
+static void at_context_flush(struct at_context *ctx)
 {
 	// Avoid dead lock due to programming mistake.
 	if (WARN_ON_ONCE(current_work() == &ctx->work))
@@ -1540,12 +1543,13 @@ static int handle_at_packet(struct context *context,
 			    struct descriptor *d,
 			    struct descriptor *last)
 {
+	struct at_context *ctx = container_of(context, struct at_context, context);
+	struct fw_ohci *ohci = ctx->context.ohci;
 	struct driver_data *driver_data;
 	struct fw_packet *packet;
-	struct fw_ohci *ohci = context->ohci;
 	int evt;
 
-	if (last->transfer_status == 0 && !READ_ONCE(context->flushing))
+	if (last->transfer_status == 0 && !READ_ONCE(ctx->flushing))
 		/* This descriptor isn't done yet, stop iteration. */
 		return 0;
 
@@ -1579,7 +1583,7 @@ static int handle_at_packet(struct context *context,
 		break;
 
 	case OHCI1394_evt_missing_ack:
-		if (READ_ONCE(context->flushing))
+		if (READ_ONCE(ctx->flushing))
 			packet->ack = RCODE_GENERATION;
 		else {
 			/*
@@ -1601,7 +1605,7 @@ static int handle_at_packet(struct context *context,
 		break;
 
 	case OHCI1394_evt_no_status:
-		if (READ_ONCE(context->flushing)) {
+		if (READ_ONCE(ctx->flushing)) {
 			packet->ack = RCODE_GENERATION;
 			break;
 		}
@@ -1698,13 +1702,14 @@ static void handle_local_lock(struct fw_ohci *ohci,
 	fw_core_handle_response(&ohci->card, &response);
 }
 
-static void handle_local_request(struct context *ctx, struct fw_packet *packet)
+static void handle_local_request(struct at_context *ctx, struct fw_packet *packet)
 {
+	struct fw_ohci *ohci = ctx->context.ohci;
 	u64 offset, csr;
 
-	if (ctx == &ctx->ohci->at_request_ctx) {
+	if (ctx == &ohci->at_request_ctx) {
 		packet->ack = ACK_PENDING;
-		packet->callback(packet, &ctx->ohci->card, packet->ack);
+		packet->callback(packet, &ohci->card, packet->ack);
 	}
 
 	offset = async_header_get_offset(packet->header);
@@ -1712,54 +1717,55 @@ static void handle_local_request(struct context *ctx, struct fw_packet *packet)
 
 	/* Handle config rom reads. */
 	if (csr >= CSR_CONFIG_ROM && csr < CSR_CONFIG_ROM_END)
-		handle_local_rom(ctx->ohci, packet, csr);
+		handle_local_rom(ohci, packet, csr);
 	else switch (csr) {
 	case CSR_BUS_MANAGER_ID:
 	case CSR_BANDWIDTH_AVAILABLE:
 	case CSR_CHANNELS_AVAILABLE_HI:
 	case CSR_CHANNELS_AVAILABLE_LO:
-		handle_local_lock(ctx->ohci, packet, csr);
+		handle_local_lock(ohci, packet, csr);
 		break;
 	default:
-		if (ctx == &ctx->ohci->at_request_ctx)
-			fw_core_handle_request(&ctx->ohci->card, packet);
+		if (ctx == &ohci->at_request_ctx)
+			fw_core_handle_request(&ohci->card, packet);
 		else
-			fw_core_handle_response(&ctx->ohci->card, packet);
+			fw_core_handle_response(&ohci->card, packet);
 		break;
 	}
 
-	if (ctx == &ctx->ohci->at_response_ctx) {
+	if (ctx == &ohci->at_response_ctx) {
 		packet->ack = ACK_COMPLETE;
-		packet->callback(packet, &ctx->ohci->card, packet->ack);
+		packet->callback(packet, &ohci->card, packet->ack);
 	}
 }
 
-static void at_context_transmit(struct context *ctx, struct fw_packet *packet)
+static void at_context_transmit(struct at_context *ctx, struct fw_packet *packet)
 {
+	struct fw_ohci *ohci = ctx->context.ohci;
 	unsigned long flags;
 	int ret;
 
-	spin_lock_irqsave(&ctx->ohci->lock, flags);
+	spin_lock_irqsave(&ohci->lock, flags);
 
-	if (async_header_get_destination(packet->header) == ctx->ohci->node_id &&
-	    ctx->ohci->generation == packet->generation) {
-		spin_unlock_irqrestore(&ctx->ohci->lock, flags);
+	if (async_header_get_destination(packet->header) == ohci->node_id &&
+	    ohci->generation == packet->generation) {
+		spin_unlock_irqrestore(&ohci->lock, flags);
 
 		// Timestamping on behalf of the hardware.
-		packet->timestamp = cycle_time_to_ohci_tstamp(get_cycle_time(ctx->ohci));
+		packet->timestamp = cycle_time_to_ohci_tstamp(get_cycle_time(ohci));
 
 		handle_local_request(ctx, packet);
 		return;
 	}
 
 	ret = at_context_queue_packet(ctx, packet);
-	spin_unlock_irqrestore(&ctx->ohci->lock, flags);
+	spin_unlock_irqrestore(&ohci->lock, flags);
 
 	if (ret < 0) {
 		// Timestamping on behalf of the hardware.
-		packet->timestamp = cycle_time_to_ohci_tstamp(get_cycle_time(ctx->ohci));
+		packet->timestamp = cycle_time_to_ohci_tstamp(get_cycle_time(ohci));
 
-		packet->callback(packet, &ctx->ohci->card, packet->ack);
+		packet->callback(packet, &ohci->card, packet->ack);
 	}
 }
 
@@ -2138,8 +2144,8 @@ static void bus_reset_work(struct work_struct *work)
 	// FIXME: Document how the locking works.
 	scoped_guard(spinlock_irq, &ohci->lock) {
 		ohci->generation = -1; // prevent AT packet queueing
-		context_stop(&ohci->at_request_ctx);
-		context_stop(&ohci->at_response_ctx);
+		context_stop(&ohci->at_request_ctx.context);
+		context_stop(&ohci->at_response_ctx.context);
 	}
 
 	/*
@@ -2683,7 +2689,7 @@ static void ohci_send_response(struct fw_card *card, struct fw_packet *packet)
 static int ohci_cancel_packet(struct fw_card *card, struct fw_packet *packet)
 {
 	struct fw_ohci *ohci = fw_ohci(card);
-	struct context *ctx = &ohci->at_request_ctx;
+	struct at_context *ctx = &ohci->at_request_ctx;
 	struct driver_data *driver_data = packet->driver_data;
 	int ret = -ENOENT;
 
@@ -3767,13 +3773,13 @@ static int pci_probe(struct pci_dev *dev,
 	if (err < 0)
 		return err;
 
-	err = context_init(&ohci->at_request_ctx, ohci,
+	err = context_init(&ohci->at_request_ctx.context, ohci,
 			   OHCI1394_AsReqTrContextControlSet, handle_at_packet);
 	if (err < 0)
 		return err;
 	INIT_WORK(&ohci->at_request_ctx.work, ohci_at_context_work);
 
-	err = context_init(&ohci->at_response_ctx, ohci,
+	err = context_init(&ohci->at_response_ctx.context, ohci,
 			   OHCI1394_AsRspTrContextControlSet, handle_at_packet);
 	if (err < 0)
 		return err;
-- 
2.48.1

Re: [PATCH] firewire: ohci: Initialize payload_bus to avoid uninitialized use warning

[Takashi S. <o-t...@sa...>]

Hi,

On Thu, Jul 10, 2025 at 01:09:06PM +0530, Purva Yeshi wrote:
> Fix Smatch-detected error:
> drivers/firewire/ohci.c:1514 at_context_queue_packet()
> error: uninitialized symbol 'payload_bus'.
> 
> Smatch reports a potential uninitialized use of 'payload_bus' in
> at_context_queue_packet(). If packet->payload_length is zero, the
> variable may not be set before reaching the dma_unmap_single() call,
> which could lead to undefined behavior.
> 
> Initialize 'payload_bus' to 0 to ensure it has a defined value in all
> code paths, preventing any uninitialized access.
> 
> Signed-off-by: Purva Yeshi <pur...@gm...>

In my opinion, we should pay enough attention to the value of
'packet->payload_mapped' variable when considering the issue.

```
$ cat -n drivers/firewire/ohci.c
     ...
1385 static int at_context_queue_packet(struct context *ctx,
1386                                    struct fw_packet *packet)
1387 {
1388         struct fw_ohci *ohci = ctx->ohci;
1389         dma_addr_t d_bus, payload_bus;
     ...
1474         if (packet->payload_length > 0) {
1475                 if (packet->payload_length > sizeof(driver_data->inline_data)) {
1476                         payload_bus = dma_map_single(ohci->card.device,
                             ...
1485                         packet->payload_mapped  = true;
1486                 } else {
                             ...
1489                         payload_bus = d_bus + 3 * sizeof(*d);
1490                 }
                     ...
1496         } else {
                    ...
1499         }
             ...
1506         if (ohci->generation != packet->generation) {
1507                 if (packet->payload_mapped)
1508                         dma_unmap_single(ohci->card.device, payload_bus,
1509                                          packet->payload_length, DMA_TO_DEVICE);
                     ...
1512         }

Unless the variable has true, the dma_unmap_single() is never called,
thus the issue does not occur.


Thanks

Takashi Sakamoto

Re: Fwd: Adding timeouts to device access?

[AreYouLoco? <are...@pa...>]

I think I got it!

I got interested in firewire-ohci quirks and my dmesg reported 0x0 for quirks by default.

And when reading thru:
<https://github.com/torvalds/linux/blob/1f988d0788f50d8464f957e793fab356e2937369/drivers/firewire/ohci.c#L330>

It seems that it should apply 0x4 and 0x10 so 0x14. I've created:
/etc/modprobe.d/firewire-ohci-quirks.conf
options firewire-ohci quirks=0x14

And now it seems to work fine each time. And also hot-plug started to work!

So the issue is that quirks that suppose to be applied are not for some reason.

Could someone verify this on their end?!

On July 5, 2025 4:11:06 PM UTC, AreYouLoco? via linux1394-devel <lin...@li...> wrote:
>Just to note I am on exact same kernel version.
>
>Takashi さん tried to reproduce it on 6.14 and couldn't.
>
>I think I am going to try some cutting edge distro like Arch with newer kernel and see there. Kernel 6.15 from experimental Debian repo didnt boot for me.
>
>There were reports and from my own experience that it worked before on older kernels presumably 6.5.something.
>
>
>On July 3, 2025 4:58:59 AM UTC, "‍小太" <no...@ko...e> wrote:
>>On Thu, 3 Jul 2025 at 04:43, AreYouLoco? <are...@pa...> wrote:
>>
>>> Hi,
>>>
>>> I am observing similar problems reported already to the list also with
>>> Agere but with FW643 and FW643E chipsets.
>>>
>>> Similarity here is OPs probes with unloading firewire-ohci. I am doing
>>> same attempts to restore detection of devices. And truely I couldn't find a
>>> pattern what combination works. And sometimes modprobe -r firewire-ohci
>>> hangs for me as well and also normal reboot in that case hangs as well.
>>>
>>> I just do 10seconds power button then.
>>>
>>> So there seem to be some pattern with Agere chipsets not cooperating.
>>>
>>> May I ask OP: which kernel version are you on?
>>>
>>
>>It's been happening for at least half a year now so it's not a recent issue
>>by any means - I've just been too lazy to debug it given how infrequently
>>it occurs for me
>>
>>But my current kernel version is 6.12.32
>>
>>$ uname -a
>>Linux home.kota.moe 6.12.32-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.32-1
>>(2025-06-07) x86_64 GNU/Linux

Re: Fwd: Adding timeouts to device access?

[AreYouLoco? <are...@pa...>]

Just to note I am on exact same kernel version.

Takashi さん tried to reproduce it on 6.14 and couldn't.

I think I am going to try some cutting edge distro like Arch with newer kernel and see there. Kernel 6.15 from experimental Debian repo didnt boot for me.

There were reports and from my own experience that it worked before on older kernels presumably 6.5.something.


On July 3, 2025 4:58:59 AM UTC, "‍小太" <no...@ko...e> wrote:
>On Thu, 3 Jul 2025 at 04:43, AreYouLoco? <are...@pa...> wrote:
>
>> Hi,
>>
>> I am observing similar problems reported already to the list also with
>> Agere but with FW643 and FW643E chipsets.
>>
>> Similarity here is OPs probes with unloading firewire-ohci. I am doing
>> same attempts to restore detection of devices. And truely I couldn't find a
>> pattern what combination works. And sometimes modprobe -r firewire-ohci
>> hangs for me as well and also normal reboot in that case hangs as well.
>>
>> I just do 10seconds power button then.
>>
>> So there seem to be some pattern with Agere chipsets not cooperating.
>>
>> May I ask OP: which kernel version are you on?
>>
>
>It's been happening for at least half a year now so it's not a recent issue
>by any means - I've just been too lazy to debug it given how infrequently
>it occurs for me
>
>But my current kernel version is 6.12.32
>
>$ uname -a
>Linux home.kota.moe 6.12.32-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.32-1
>(2025-06-07) x86_64 GNU/Linux

Re: Fwd: Adding timeouts to device access?

[AreYouLoco? <are...@pa...>]

Hi,

I am observing similar problems reported already to the list also with Agere but with FW643 and FW643E chipsets.

Similarity here is OPs probes with unloading firewire-ohci. I am doing same attempts to restore detection of devices. And truely I couldn't find a pattern what combination works. And sometimes modprobe -r firewire-ohci hangs for me as well and also normal reboot in that case hangs as well.

I just do 10seconds power button then.

So there seem to be some pattern with Agere chipsets not cooperating.

May I ask OP: which kernel version are you on?


On June 29, 2025 2:01:19 PM UTC, Takashi Sakamoto <o-t...@sa...> wrote:
>Hi,
>
>On Sun, Jun 29, 2025 at 02:32:49PM +1000, 小太 wrote:
>> The Firewire adapter is an old HP HI349 PCIe card (lspci info below), and
>> it's connected to an M-Audio Profire 610 audio interface.
>> CPU is a AMD 3960X on a TRX40 PRO WIFI motherboard
>
>This is the first time I've been involved with Agere FW533. Anyway
>thanks for the information.
>
>> The hardware generally only stops responding when lights or exhaust fans
>> are turned off on the same electrical circuit as the computer, but it's
>> very infrequent. Perhaps from EMI or a voltage spike...?
>> I originally had a generic chinese adapter (don't have lspci details,
>> sorry) that I swapped out because it was a much more frequent issue on that
>> one, and it mostly went away with the HP adapter.
>> 
>> After the failure occurs, I have to power cycle the computer a few times
>> before everything is working again (for both fw0 and fw1 devices to be
>> detected).
>> If I don't keep on power cycling until it works again, but instead:
>>  1. Disconnect the Profire 610 (fw1)
>>  2. Immediately power cycle
>>  3. --> The Firewire adapter (fw0) gets detected fine
>>  4. Unload firewire_ohci (modprobe -r firewire_ohci)
>>  5. Reconnect the Profire 610
>>  6. Load firewire_ohci (modprobe firewire_ohci)
>>  7. --> The Firewire adapter is not detected at all
>>  8. Unload firewire_ohci again (modprobe -r firewire_ohci)
>>  9. Disconnect the Profire 610
>>  10. Load firewire_ohci again (modprobe firewire_ohci)
>>  11. --> The Firewire adapter is detected again
>> 
>> If I mess around with the combination of reloading the firewire_ohci
>> module, connecting/disconnecting the Profire 610, and probing things with
>> FFADO, eventually a modprobe hangs indefinitely on wait_for_completion() in
>> the kernel with the dmesg logs in my original message.
>> Sometimes it even prevents systemd from powering off the computer (because
>> it's waiting for modprobe to exit from a SIGKILL...), which is why I wanted
>> to update the driver
>
>Two kernel messages are in your first post. The first one records that
>the system does not execute interrupt service routine for hardIRQ which
>should be triggered against any command request to transfer asynchronous packet
>when retrieving the detected node device. The second one records that the
>reference count of fw_card instance could not reach zero even if waiting so
>long when modprobe(8) executes the delete_module system call.
>
>I guess the cause of later message is the lost of hardIRQ in the first
>message, however, I would like you to compare timestamps for these
>messages.
>
>
>Thanks
>
>Takashi Sakamoto
>
>
>_______________________________________________
>mailing list lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linux1394-devel

Re: Fwd: Adding timeouts to device access?

[Takashi S. <o-t...@sa...>]

Hi,

On Mon, Jun 30, 2025 at 12:10:15AM +1000, ‍小太 wrote:
> On Mon, 30 Jun 2025 at 00:01, Takashi Sakamoto <o-t...@sa...>
> wrote:
> 
> >
> > Two kernel messages are in your first post. The first one records that
> > the system does not execute interrupt service routine for hardIRQ which
> > should be triggered against any command request to transfer asynchronous
> > packet
> > when retrieving the detected node device. The second one records that the
> > reference count of fw_card instance could not reach zero even if waiting so
> > long when modprobe(8) executes the delete_module system call.
> >
> 
> Would it make sense to convert the wait_for_completion()
> to wait_for_completion_timeout() in either case?
> Potentially could leak a reference count, but it's better than a hung task
> that prevents system shutdown...
> 
> 
> >
> > I guess the cause of later message is the lost of hardIRQ in the first
> > message, however, I would like you to compare timestamps for these
> > messages.
> 
> 
> IIRC the two backtraces came from two completely different boots of the
> kernel with different failure symptoms.
> So probably unrelated to each other (except for the non-responsive hardware)

Hm, these are independent...

If that's the case, the issue might be partly due to how the userspace
application is written. Typically, it is written not to call close(2) to
the file descriptor of FireWire character device even if either any
operations to it returns -ENODEV or it never receives the response of
asynchronous transaction.

The replacement by the kernel API to wait for any event with timeout is
a simple solution, if we can ignore the apparent leak of system resources.
Indeed, it is not preferable, you know.

I think what we should do now is to identify/estimate the cause of
the issue, especially for the incomplete transaction. At present, the
transaction service of Linux kernel relies on the corresponding
functionality on 1394 OHCI hardware. We assume that the hardware
notifies the completion of transaction (including both transmission
errors and timeout) by triggering IRQ (precisely the corresponding
software driver operates the hardware to work so).

If we need any software timeout to finish the transaction, it means that
the combination of hardware (I mean the 1394 OHCI hardware, AMD PCIe Root
Complex, AMD IO Hub, and so on) is enough lazy in the point. For
example, I know an issue related to the critical quirk of PCIe AMD Ryzen
PCIe functionality and the extention card with ASM108x/VT630x. AMD Ryzen
machine has a concern to handle old hardware. I guess that your issue is
similar to this kind of issue, somehow.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/firewire/ohci.c?id=ac9184fbb847


Regards

Takashi Sakamoto

Re: Fwd: Adding timeouts to device access?

[Takashi S. <o-t...@sa...>]

Hi,

On Sun, Jun 29, 2025 at 02:32:49PM +1000, 小太 wrote:
> The Firewire adapter is an old HP HI349 PCIe card (lspci info below), and
> it's connected to an M-Audio Profire 610 audio interface.
> CPU is a AMD 3960X on a TRX40 PRO WIFI motherboard

This is the first time I've been involved with Agere FW533. Anyway
thanks for the information.

> The hardware generally only stops responding when lights or exhaust fans
> are turned off on the same electrical circuit as the computer, but it's
> very infrequent. Perhaps from EMI or a voltage spike...?
> I originally had a generic chinese adapter (don't have lspci details,
> sorry) that I swapped out because it was a much more frequent issue on that
> one, and it mostly went away with the HP adapter.
> 
> After the failure occurs, I have to power cycle the computer a few times
> before everything is working again (for both fw0 and fw1 devices to be
> detected).
> If I don't keep on power cycling until it works again, but instead:
>  1. Disconnect the Profire 610 (fw1)
>  2. Immediately power cycle
>  3. --> The Firewire adapter (fw0) gets detected fine
>  4. Unload firewire_ohci (modprobe -r firewire_ohci)
>  5. Reconnect the Profire 610
>  6. Load firewire_ohci (modprobe firewire_ohci)
>  7. --> The Firewire adapter is not detected at all
>  8. Unload firewire_ohci again (modprobe -r firewire_ohci)
>  9. Disconnect the Profire 610
>  10. Load firewire_ohci again (modprobe firewire_ohci)
>  11. --> The Firewire adapter is detected again
> 
> If I mess around with the combination of reloading the firewire_ohci
> module, connecting/disconnecting the Profire 610, and probing things with
> FFADO, eventually a modprobe hangs indefinitely on wait_for_completion() in
> the kernel with the dmesg logs in my original message.
> Sometimes it even prevents systemd from powering off the computer (because
> it's waiting for modprobe to exit from a SIGKILL...), which is why I wanted
> to update the driver

Two kernel messages are in your first post. The first one records that
the system does not execute interrupt service routine for hardIRQ which
should be triggered against any command request to transfer asynchronous packet
when retrieving the detected node device. The second one records that the
reference count of fw_card instance could not reach zero even if waiting so
long when modprobe(8) executes the delete_module system call.

I guess the cause of later message is the lost of hardIRQ in the first
message, however, I would like you to compare timestamps for these
messages.


Thanks

Takashi Sakamoto

Re: Fwd: Adding timeouts to device access?

[Takashi S. <o-t...@sa...>]

Hi,

I'm sorry to be late for reply, however I was traveling.

On Mon, Jun 23, 2025 at 05:53:47PM +1000, ‍小太 wrote:
> Hello, I tried sending an email (see below) to
> lin...@li... a few days ago but it hasn't showed
> up on the archive:
> https://sourceforge.net/p/linux1394/mailman/linux1394-devel/?viewmonth=202506
> Is it awaiting moderation or got dropped as spam? Did I send it wrong?

The moderation of list is kind of outside what I usually deal with,
unforntunately. Additionally, the moderators of list is inactive so long.

> ---------- Forwarded message ---------
> From: ‍小太 <no...@ko...e>
> Date: Fri, 20 Jun 2025 at 19:23
> Subject: Re: Adding timeouts to device access?
> To: <lin...@li...>
> 
> 
> On Fri, 20 Jun 2025 at 19:17, ‍小太 <no...@ko...e> wrote:
> 
> > Hello, I've been trying to debug an odd issue with my hardware where it
> > sometimes just stops responding (hardware failure is my guess at the
> > moment).
> > This resulted in hung tasks in the kernel that sometimes even prevents the
> > OS from cleanly shutting down
> >
> > In particular, I believe these lines are prone to hanging indefinitely in
> > the event the hardware fails to respond:
> >  -
> > https://github.com/torvalds/linux/blob/75f5f23f8787c5e184fcb2fbcd02d8e9317dc5e7/drivers/firewire/core-card.c#L753
> >  -
> > https://github.com/torvalds/linux/blob/75f5f23f8787c5e184fcb2fbcd02d8e9317dc5e7/drivers/firewire/core-transaction.c#L433
> >
> > Would it make sense to turn these into wait_for_completion_timeout() or
> > even wait_for_completion_interruptible_timeout() instead?
> > If so, some questions:
> >  - What would be a reasonable timeout value? 1 second? Less?
> >  - If fw_run_transaction() times out, what should it
> > return? RCODE_CANCELLED?
> >
> 
> Whoops, I was meant to include the hung task logs but forgot. Here they are
>
> (Snip)

Would I ask you the situation facing the issue? Especially, what kind of
1394 OHCI hardware you used.


Thanks

Takashi Sakamoto

Re: Possible regression with the FW643 chipset

[AreYouLoco? <are...@pa...>]

So here it happened again. Kernel 6.12.32-rt-amd64 (Debian Trixie):

Here is log after soft reboot:
```

areyouloco@studio:~$ sudo dmesg -w | grep -i firewire
[    1.120409] firewire_ohci 0000:03:00.0: added OHCI v1.10 device as 
card 0, 8 IR + 8 IT contexts, quirks 0x0, physUB
[   17.057643]  libahci sha256_ssse3 sha1_ssse3 xhci_pci libata xhci_hcd 
ehci_pci iTCO_wdt sdhci_pci intel_pmc_bxt firewire_ohci ehci_hcd cqhci 
iTCO_vendor_support aesni_intel tg3 sdhci firewire_core scsi_mod 
gf128mul usbcore watchdog thunderbolt crypto_simd i2c_i801 mmc_core 
libphy cryptd i2c_smbus crc_itu_t lpc_ich scsi_common usb_common video wmi

```

And thats it related to firewire. Notice. No mention of fw0 or OHCI 
device added. Now I do:

```

areyouloco@studio:~$ sudo modprobe -r firewire_ohci
areyouloco@studio:~$ sudo modprobe -r firewire_core
areyouloco@studio:~$ sleep 2
areyouloco@studio:~$ sudo modprobe firewire-ohci

```

And then in dmesg I get:

```

[  141.661165] firewire_ohci 0000:03:00.0: removing fw-ohci device
[  141.661261] firewire_ohci 0000:03:00.0: removed fw-ohci device
[  155.721784] firewire_ohci 0000:03:00.0: added OHCI v1.10 device as 
card 0, 8 IR + 8 IT contexts, quirks 0x0, physUB
[  156.245972] firewire_core 0000:03:00.0: created device fw0: GUID 
003ee1fffe873194, S800
[  156.245992] firewire_core 0000:03:00.0: phy config: new root=ffc1, 
gap_count=5
[  159.293474] firewire_core 0000:03:00.0: created device fw1: GUID 
000ff2050000145b, S400

```

This is all I got for now. For firewire-ohci module in my kernel I see 
parameter possible to set:
"parm:           debug:Verbose logging, deprecated in v6.11 kernel or 
later. (default = 0, AT/AR events = 1, self-IDs = 2, IRQs = 4, or a 
combination, or all = -1) (int)"

Is it still a way to debug further? I've read somewhere there was a 
replacement for this debug parameter via some calls.

Machine is MacBook Pro Mid-2012 13''.

But I also got other MBP and some full-size PCIe card also with that 
same chipset. On the other MBP behavior is similar I didn't check with 
PC yet. I might do that if requested. Hope it helps anyhow.

I am getting kernel 6.15 to try out.

On 6/20/25 3:12 PM, Takashi Sakamoto wrote:
> Hi,
>
> On Fri, Jun 20, 2025 at 08:52:42AM +0930, Jonathan Woithe wrote:
>> Alternatively, are there any FW643 users who have no problem with device
>> detection under a 6.12.x (or later) kernel?  If so this would conclusively
>> rule out a kernel issue.
> I can not regenerate the issue with the kernel modules provided by the
> stock kernel in Ubuntu 25.04 amd64 (v6.14). The machine consists of
>
> * ASUSTeK COMPUTER INC. TUF GAMING X570-PLUS
> * AMD Ryzen™ 7 5700G with Radeon™ Graphics × 16
>
>
> ```
> $ dpkg -S /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/*
> linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/firewire-core.ko.zst
> linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/firewire-net.ko.zst
> linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/firewire-ohci.ko.zst
> linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/firewire-sbp2.ko.zst
> linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/nosy.ko.zst
>
> $ sudo lspci -vvnn
> 06:00.0 FireWire (IEEE 1394) [0c00]: LSI Corporation FW643 [TrueFire] PCIe 1394b Controller [11c1:5901] (rev 06) (prog-if 10 [OHCI])
>          Subsystem: LSI Corporation FW643 [TrueFire] PCIe 1394b Controller [11c1:5900]
>          Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>          Latency: 0, Cache Line Size: 64 bytes
>          Interrupt: pin A routed to IRQ 40
>          IOMMU group: 20
>          Region 0: Memory at fc600000 (64-bit, non-prefetchable) [size=4K]
>          Capabilities: [44] Power Management version 3
>                  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
>                  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
>          Capabilities: [4c] MSI: Enable- Count=1/1 Maskable- 64bit+
>                  Address: 0000000000000000  Data: 0000
>          Capabilities: [60] Express (v1) Endpoint, IntMsgNum 0
>                  DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 <64us
>                          ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0W TEE-IO-
>                  DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+
>                          RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>                          MaxPayload 128 bytes, MaxReadReq 512 bytes
>                  DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend-
>                  LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us
>                          ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
>                  LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
>                          ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                  LnkSta: Speed 2.5GT/s, Width x1
>                          TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>          Capabilities: [100 v1] Advanced Error Reporting
>                  UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
>                          ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr-
>                          PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked-
>                  UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
>                          ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr-
>                          PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked-
>                  UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
>                          ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr-
>                          PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked-
>                  CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CorrIntErr- HeaderOF-
>                  CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ CorrIntErr- HeaderOF-
>                  AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
>                          MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
>                  HeaderLog: 00000000 00000000 00000000 00000000
>          Capabilities: [140 v1] Virtual Channel
>                  Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
>                  Arb:    Fixed- WRR32- WRR64- WRR128-
>                  Ctrl:   ArbSelect=Fixed
>                  Status: InProgress-
>                  VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>                          Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>                          Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
>                          Status: NegoPending- InProgress-
>                  VC1:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>                          Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>                          Ctrl:   Enable- ID=1 ArbSelect=Fixed TC/VC=00
>                          Status: NegoPending- InProgress-
>          Capabilities: [170 v1] Device Serial Number 12-34-56-10-12-30-00-86
>          Kernel driver in use: firewire_ohci
>          Kernel modules: firewire_ohci
>
> ```
>
> My Phonic FireFly 808 Universal is detected successfully even after the
> reported steps.
>
>
> Thanks
>
> Takashi Sakamoto
>
>
> _______________________________________________
> mailing list lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux1394-devel

Re: Possible regression with the FW643 chipset

[AreYouLoco? <are...@pa...>]

Hi Takashi,

Bit its not pci firewire controller itself not getting detected but root /dev/fw0 sometimes wont appear and thus connected devices /dev/fw1 /dev/fw2 because of that.

Please if you could check dmesg log few times if GUID for device is there in dmesg. Cold boot and soft boot might be a difference here.

Good that you have this chipset around. Hope you can reproduce it.

Cheers

On June 20, 2025 1:12:49 PM UTC, Takashi Sakamoto <o-t...@sa...> wrote:
>Hi,
>
>On Fri, Jun 20, 2025 at 08:52:42AM +0930, Jonathan Woithe wrote:
>> Alternatively, are there any FW643 users who have no problem with device
>> detection under a 6.12.x (or later) kernel?  If so this would conclusively
>> rule out a kernel issue.
>
>I can not regenerate the issue with the kernel modules provided by the
>stock kernel in Ubuntu 25.04 amd64 (v6.14). The machine consists of
>
>* ASUSTeK COMPUTER INC. TUF GAMING X570-PLUS
>* AMD Ryzen™ 7 5700G with Radeon™ Graphics × 16
>
>
>```
>$ dpkg -S /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/*
>linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/firewire-core.ko.zst
>linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/firewire-net.ko.zst
>linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/firewire-ohci.ko.zst
>linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/firewire-sbp2.ko.zst
>linux-modules-extra-6.14.0-15-generic: /lib/modules/6.14.0-15-generic/kernel/drivers/firewire/nosy.ko.zst
>
>$ sudo lspci -vvnn
>06:00.0 FireWire (IEEE 1394) [0c00]: LSI Corporation FW643 [TrueFire] PCIe 1394b Controller [11c1:5901] (rev 06) (prog-if 10 [OHCI])
>        Subsystem: LSI Corporation FW643 [TrueFire] PCIe 1394b Controller [11c1:5900]
>        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>        Latency: 0, Cache Line Size: 64 bytes
>        Interrupt: pin A routed to IRQ 40
>        IOMMU group: 20
>        Region 0: Memory at fc600000 (64-bit, non-prefetchable) [size=4K]
>        Capabilities: [44] Power Management version 3
>                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
>                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
>        Capabilities: [4c] MSI: Enable- Count=1/1 Maskable- 64bit+
>                Address: 0000000000000000  Data: 0000
>        Capabilities: [60] Express (v1) Endpoint, IntMsgNum 0
>                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 <64us
>                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0W TEE-IO-
>                DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+
>                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>                        MaxPayload 128 bytes, MaxReadReq 512 bytes
>                DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend-
>                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us
>                        ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
>                LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
>                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                LnkSta: Speed 2.5GT/s, Width x1
>                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>        Capabilities: [100 v1] Advanced Error Reporting
>                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
>                        ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr-
>                        PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked-
>                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
>                        ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr-
>                        PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked-
>                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
>                        ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr-
>                        PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked-
>                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CorrIntErr- HeaderOF-
>                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ CorrIntErr- HeaderOF-
>                AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
>                        MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
>                HeaderLog: 00000000 00000000 00000000 00000000
>        Capabilities: [140 v1] Virtual Channel
>                Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
>                Arb:    Fixed- WRR32- WRR64- WRR128-
>                Ctrl:   ArbSelect=Fixed
>                Status: InProgress-
>                VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>                        Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
>                        Status: NegoPending- InProgress-
>                VC1:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>                        Ctrl:   Enable- ID=1 ArbSelect=Fixed TC/VC=00
>                        Status: NegoPending- InProgress-
>        Capabilities: [170 v1] Device Serial Number 12-34-56-10-12-30-00-86
>        Kernel driver in use: firewire_ohci
>        Kernel modules: firewire_ohci
>
>```
>
>My Phonic FireFly 808 Universal is detected successfully even after the
>reported steps.
>
>
>Thanks
>
>Takashi Sakamoto
>
>
>_______________________________________________
>mailing list lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linux1394-devel