I sent:

[GIT PULL] firewire updates for v6.12
https://lore.kernel.org/lkml/20240921031421.GA227826@workstation.local/

The batch of changes includes the followwing:

- Replacing tasklet with usual workqueue for isochronous context
- Replacing IDR with XArray
- Utilizing guard macro where possible
- Printing deprecation warning when enabling debug parameter of
firewire-ohci module

Additionally, it includes a single patch for sound subsystem which the
subsystem maintainer acked:

- Switching to nonatomic PCM operation

In FireWire subsystem, tasklet has been used as the bottom half of 1394
OHCi hardIRQ so long. In the recent kernel updates, BH workqueue has
been available, and some developers have proposed replacing tasklet with
BH workqueue. While it is fortunate that developers are still considering
the legacy subsystem, a simple replacement is not necessarily suitable.

As a first step towards dropping tasklet, I've investigated the
feasibility for 1394 OHCI isochronous context, and concluded that usual
workqueue is available. In the context, the batch of packets is processed
in the specific queue, thus the timing jitter caused by task scheduling is
not so critical. Additionally, DMA transmission can be scheduled
per-packet basis, therefore the context can be sleep between the operation
of transmissions. Furthermore, in-kernel protocol implementation involves
some CPU-bound tasks, which can sometimes consumes CPU time so long. These
characteristics suggest that usual workqueue is suitable, through BH
workqueues are not.

The replacement with usual workqueue allows unit drivers to process the
content of packets in non-atomic context. It brings some reliefs to some
drivers in sound subsystem that spin-lock is not mandatory anymore during
isochronous packet processing.

Need sponsors:

* #1080372 RFS: libhinoko/1.0.3-1 [ITP] -- I/O library for IEEE 1394 isochronous communication
** https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080372
** https://mentors.debian.net/package/libhinoko/
* #1081809 RFS: libhitaki/0.2.1-3 [ITP] -- Library to operate ALSA HwDep device for ALSA firewire stack
** https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081809
** https://mentors.debian.net/package/libhitaki/
* #1081810 RFS: linux-firewire-utils/0.5.1-2 [ITP] -- Linux FireWire utilities
** https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081810
** https://mentors.debian.net/package/linux-firewire-utils/

Phew.

I believe BH workqueue is not necessarily required for the purpose:

[RFT][PATCH 0/5] firewire: use sleepable workqueue to handle 1394 OHCI IT/IR context events
https://lore.kernel.org/lkml/20240901110642.154523-1-o-takashi@sakamocchi.jp/

Unexpectedly, I can easily replace tasklet with workqueue for 1394 OHCI IR/IT contexts in v6.11 kernel, at least for userspace application. Hm.

[PATCH] firewire: core: update fw_device outside of device_find_child()

https://lore.kernel.org/lkml/20240820132132.28839-1-o-takashi@sakamocchi.jp/

I believe it reasonable to separate updating from finding here.

Completed.

[PATCH 0/5] firewire: core: use XArray to maintain client resources

https://lore.kernel.org/lkml/20240812235210.28458-1-o-takashi@sakamocchi.jp/

As a first step.

[PATCH 0/2] firewire: core: use XArray to maintain firewire device nodes:

https://lore.kernel.org/lkml/20240812014251.165492-1-o-takashi@sakamocchi.jp/

I'm working to replace usage of IDR with XArray. I was a bit puzzled that DEFINE_XARRAY_ALLOC() and xa_init() are not equivalent. In my opinion, the naming scheme of XArray functions should be reconsidered. It easily confuse me.

Phew.

[PATCH 00/17] firewire: core/ohci: use guard macro for any type of lock primitives
https://lore.kernel.org/lkml/20240804130225.243496-1-o-takashi@sakamocchi.jp/T/#m3f70c1329301dc504d310a8f71c778061868772b

Oh, the usage of IDR should be replaced with XArray... Since when?

Phew

I'm surprised to see my protocol analyzer operational again.

Need some KUnit tests to check serializer/deserializer of data in payload of isochronous packet for various CIP format. However, the current implementation is tight-coupled to low-level hardware operations and procedures for complicated device-dependent protocols. Mmm.

Posted: [GIT PULL] firewire updates for v6.11
https://lore.kernel.org/linux-kernel/20240720084730.GA59546@workstation.local/T/#u

There are many line changes for FireWire subsystem, while there is no
functional change for practical use. The most of changes are for code
refactoring, some KUnit tests to added helper functions, and new
tracepoints events for both the core functions and 1394 OHCI driver.

The tracepoints events now cover the verbose logging enabled by debug
parameter of firewire-ohci kernel module. The parameter would be removed
in any future timing, thus it is now deprecated.

Hm. I'm investigating to replace the local implementation to maintain blocks in the allocated memory region mapped for DMA purpose with common dma_pool. However, it does not allows to pick up an arbitrary count of blocks at once for continuous memory region. It just connect returned block to the tail of local list, and has no mechanism to keep maintained blocks as continuous.
Typically, this kind of framework requires mechanism to suppress fragmentation, but it has nothing. I prefer its simplicity, but a bit inconvenient for my purpose...

Being straightforward is not necessarily more adequate than being simple.

As I said.