I sent.

[GIT PULL] firewire updates for v6.14
https://lore.kernel.org/lkml/20250126091107.GA129560@workstation.local/T/#u

Great.

https://bsky.app/profile/mrmidi.bsky.social/post/3lg4lvby3h22r

It's the week for -rc7 (just after returning from year-end vacation)

Hm, July 2020.

https://lore.kernel.org/lkml/20200720150715.624520-1-vaibhavgupta40@gmail.com/

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.