1. 05 Jun, 2009 2 commits
  2. 01 Jun, 2009 2 commits
    • Stefan Richter's avatar
      firewire: core: add sysfs attribute for easier udev rules · 0210b66d
      Stefan Richter authored
      This adds the attribute /sys/bus/firewire/devices/fw[0-9]+/units.  It
      can be used in udev rules like the following ones:
      
      # IIDC devices: industrial cameras and some webcams
      SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x00010?*", GROUP="video"
      
      # AV/C devices: camcorders, set-top boxes, TV sets, audio devices, ...
      SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x010001*", GROUP="video"
      
      Background:
      
      firewire-core manages two device types:
        - fw_device is a FireWire node.  A character device file is associated
          with it.
        - fw_unit is a unit directory on a node.  Each fw_device may have 0..n
          children of type fw_unit.  The units tell us what kinds of protocols
          a node implements.
      
      We want to set ownership or ACLs or permissions of the character device
      file of an fw_device, or/and create symlinks to it, based on available
      protocols.  Until now udev rules had to look at the fw_unit devices and
      then modify their parent's character device file accordingly.  This is
      problematic for two reasons:  1) It happens sometime after the creation
      of the fw_device, 2) an access policy may require that information from
      all children is evaluated before a decision about the parent is made.
      
      Problem 1) can ultimately not be avoided since this is the nature of
      FireWire nodes:  They may add or remove unit directories at any point in
      time.
      
      However, we can still help userland a lot by providing the protocol type
      information of all units in a summary sysfs attribute directly at the
      fw_device.  This way,
         - the information is immediately available at the affected device
           when userspace goes about to handle an ADD or CHANGE event of the
           fw_device,
         - with most policies, it won't be necessary anymore to dig through
           child attributes.
      
      The new attribute is called "units".  It contains space-separated tuples
      of specifier_id and version of each present unit.  The delimiter within
      tuples is a colon.  Specifier_id and version are printed as 0x%06x.
      
      Here is an example of a node which implements an IPv4 unit and an IPv6
      unit:  $ cat /sys/bus/firewire/devices/fw2/units
      0x00005e:0x000001 0x00005e:0x000002
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      0210b66d
    • Stefan Richter's avatar
      firewire: core: check for missing struct update at build time, not run time · e5333db9
      Stefan Richter authored
      struct fw_attribute_group.attrs.[] must have enough room for all
      attributes.  This can and should be checked at build time.
      
      Our previous check at run time was a little late and not reliable since
      most of the time less than the available attributes are populated.
      
      Furthermore, omit an increment of an index at its last usage.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      e5333db9
  3. 17 May, 2009 1 commit
    • Stefan Richter's avatar
      firewire: core: improve check for local node · 92368890
      Stefan Richter authored
      My recently added test for a device being local in fw-cdev.c got it
      slightly wrong:  Comparisons of node IDs are only valid if the
      generation is current, which I forgot to check.  Normally, serialization
      by card->lock takes care of this, but a device in FW_DEVICE_GONE state
      will necessarily have a wrong generation and invalid node_id.
      
      The "is it local?" check is made 100% correct and simpler now by means
      of a struct fw_device flag which is set at fw_device creation.
      
      Besides the fw-cdev site which was to be fixed, there is another site
      which can make use of the new flag, and an RFC-2734 driver will benefit
      from it too.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      92368890
  4. 27 Mar, 2009 1 commit
  5. 24 Mar, 2009 34 commits