• Stefan Richter's avatar
    firewire: core: check for 1394a compliant IRM, fix inaccessibility of Sony camcorder · 10389536
    Stefan Richter authored
    Per IEEE 1394 clause 8.4.2.3, a contender for the IRM role shall check
    whether the current IRM complies to 1394a-2000 or later.  If not force a
    compliant node (e.g. itself) to become IRM.  This was implemented in the
    older ieee1394 driver but not yet in firewire-core.
    
    An older Sony camcorder (Sony DCR-TRV25) which implements 1394-1995 IRM
    but neither 1394a-2000 IRM nor BM was now found to cause an
    interoperability bug:
      - Camcorder becomes root node when plugged in, hence gets IRM role.
      - firewire-core successfully contends for BM role, proceeds to perform
        gap count optimization and resets the bus.
      - Sony camcorder ignores presence of a BM (against the spec, this is
        a firmware bug), performs its idea of gap count optimization and
        resets the bus.
      - Preceding two steps are repeated endlessly, bus never settles,
        regular I/O is practically impossible.
    http://thread.gmane.org/gmane.linux.kernel.firewire.user/3913
    
    This is an interoperability regression from the old to the new drivers.
    Fix it indirectly by adding the 1394a IRM check.  The spec suggests
    three and a half methods to determine 1394a compliance of a remote IRM;
    we choose the method of testing the Config_ROM.Bus_Info.generation
    field.  This is data that firewire-core should have readily available at
    this point, i.e. does not require extra I/O.
    
    Reported-by: Clemens Ladisch <clemens@ladisch.de> (missing 1394a check)
    Reported-by: H. S. <hs.samix@gmail.com> (issue with Sony DCR-TRV25)
    Tested-by: default avatarH. S. <hs.samix@gmail.com>
    
    Cc: <stable@kernel.org> # .32.x and newer
    Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    10389536
core-card.c 15.7 KB