On Mon, Dec 07, 2015 at 08:37:22AM +0100, Clemens Ladisch wrote:
Jonathan Woithe wrote:
On Mon, Dec 07, 2015 at 11:05:21AM +0900, Takashi Sakamoto wrote:
Furthermore, 0x0010 is not always true because the address range which drivers allocate on the controller is different depending on situation.
In general that's true. For the FF400 at least though the non-nodeID component is effectively hard coded on other systems.
That's just because this value happens to be the first free address in the FireWire address space.
It's hardcoded (in the way I subsequently detailed) on at least one other (non-Linux) system: when that particular FF400 register is written the upper 16 bits are a node ID and the lower 16 bits are unconditionally set to 0x0001. That's not to say that this is the best way, but it's what's done on that system, with all the caveats that this implies.
In the above system there is no explicit consideration of what addresses happen to be free. The address which is chosen does not appear to be the lowest free address: there would be plenty unused addresses below it in general.
If you had other FireWire devices whose drivers allocated addresses, you would see different values.
For this reason (that is, other drivers/devices grabbing the resulting address range) the methodology I detailed above for choosing the target address is perhaps not the most appropriate for Linux. Takashi S's tests indicate that there is no hidden functionality controlled by the lower 16 bits of this register so we are free to adopt our own address selection philosphy.
(Maybe even for multiple FF devices, but the driver might be able to share the range for all devices.)
The multiple FF400 case would, I expect, be disambiguated by the inclusion of the node ID in the register value (and hense the address listened to).
Regards jonathan