On Sun, 16 Aug 2015 14:15:09 +0200, Stefan Richter wrote:
On Aug 16 Takashi Iwai wrote:
On Sat, 15 Aug 2015 12:15:54 +0200, Stefan Richter wrote:
On Aug 13 Takashi Sakamoto wrote:
On Aug 13 2015 15:31, Takashi Iwai wrote:
On Thu, 13 Aug 2015 02:19:59 +0200, Takashi Sakamoto wrote:
- generation = port->parent->generation;
- smp_rmb(); /* node_id vs. generation */
Why this barrier is needed?
Oops. I forgot to refine it after copying from the other place. Exactly, it's not need here.
- fw_send_request(port->parent->card, &port->transaction, type,
port->parent->node_id, generation,port->parent->max_speed, port->addr,port->buf, port->len, async_midi_port_callback,port);+}
The barrier is normally needed because:
[there is a dependency between node_ID and generation and]
- The node_ID:generation tuple is accessed in the Linux firewire stack in a lockless manner:
[...]
Thanks, that clarifies. But wouldn't it be more helpful to have some macro than open-coding at each place?
I agree that a cooked-up accessor via <linux/firewire.h> would be good, but I have no immediate idea how that accessor should look like. Looking at the various uses of fw_send_request [http://lxr.free-electrons.com/ident?i=fw_send_request], it's clear that this API between protocol drivers and firewire-core is quite low-level and flexible by nature. In particular, the different users of the API take node_id:generation from different sources.ยน
Argh, I somehow expected that the accesses are done in more or less in the same struct or device object. Then it'll be tricky, indeed.
As mentioned, another way would be to fuse node_id:generation into a single atomic datum throughout all firewire drivers. I.e. instead of ensuring the proper access order everytime, just access both data simultaneously everytime. Not having tried this yet, I am not sure which way would be more readable.
Yeah, having a common tuple might things a bit easier to manage, I suppose. But I'm not familiar with the firewire code in general, so don't count this as a serious evaluation at all ;)
thanks,
Takashi