The present inline documentation of the fw_send_request() in-kernel API
refers to userland code that is not applicable to kernel drivers at all.
Reported-by: NBen Gamari <bgamari.foss@gmail.com>

While we are at fixing the whole documentation of fw_send_request(),
also improve the rest of firewire-core's kerneldoc comments:
  - Add a bit of text concerning fw_run_transaction()'s call parameters.
  - Append () to function names and tab-align parameter descriptions as
    suggested by the example in Documentation/kernel-doc-nano-HOWTO.txt.
  - Remove kerneldoc markers from comments on static functions.
  - Remove outdated parameter descriptions at build_tree().
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The driver match strategy was:
  - Match vendor/model/specifier/version of the unit directory.
  - If that was a miss, match vendor from the root directory and
    model/specifier/version of the unit directory.

This was inconsistent with how the modalias string was constructed
until recently (take vendor/model from root directory and specifier/
version from unit directory).  It was also inconsistent with how it is
done since the parent commit:
  - Use vendor/model/specifier/version of the unit directory if possible,
  - fall back to one or more of vendor/model/specifier/version from the
    root directory depending on which ones are not present at the unit
    directory.

Fix this inconsistency by sharing the ROM scanner function between
modalias printer function and driver match function.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The modalias string of devices that represent units on a FireWire node
did not show Module_ID entries within unit directories.  This was
because firewire-core searched only the root directory of the
configuration ROM for a Model_ID entry.

We now search first the root directory, then the unit directory.  IOW
honor a unit directory's Model_ID if present, otherwise fall back to the
root directory's model ID (if present).

Furthermore, apply the same change to Vendor_ID.  This had the same
issue but it was less apparent because most devices provide Vendor_ID
only in the root directory.

And finally, also use this strategy for the remaining two IDs in the
modalias, Specifier_ID and Version.  It does not actually make sense to
look for them elsewhere than in the unit directory because they are
mandatory there.  However, a uniform search order simplifies the
implementation and has no adverse affect in practice.

Side notes:
  - The older counterpart of this, nodemgr.c of ieee1394, looked for
    Vendor_ID first in the root directory, then in the unit directory,
    and for Model_ID only in the unit directory.
  - There is a single mainline driver which requires Vendor_ID and
    Model_ID --- the firedtv driver.  This one worked because FireDTVs
    provide Vendor_ID in the root directory and Model_ID identically in
    root directory and unit directory.
  - Apart from firedtv, there are currently no drivers known to me
    (including userspace drivers) that look at the Vendor_ID or Model_ID
    of the modalias.
Reported-by: NMaciej Żenczykowski <zenczykowski@gmail.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

according to what it really does.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

If a device exposes a sparsely populated configuration ROM,
firewire-core's sysfs interface and character device file interface
showed random data in the gaps between config ROM blocks.  Fix this by
zero-initialization of the config ROM reader's scratch buffer.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The stack size of 16 was artificially chosen and may be too small in
extreme cases.  A device won't be accessible then.

Since it doesn't really matter to the slab allocator whether we ask for
1088 bytes or 2048 bytes of scratch memory, just allocate 2048 bytes for
the sum of temporary config ROM image and stack, and we will never ever
overflow the stack (because there simply can't be more stack items than
ROM entries).
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

It never happened yet, but better safe than sorry:  If a device's config
ROM contains a block which overlaps the boundary at 0xfffff00007ff, just
ignore that one block instead of refusing to add the device
representation.  That way, upper layers (kernelspace or userspace
drivers) might still be able to use the device to some degree.

That's better than total inaccessibility of the device.  Worse, the core
would have logged only a generic "giving up on config rom" message which
could only be debugged by feeding a firewire-ohci debug logging session
through a config ROM interpreter, IOW would likely remain undiagnosed.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The Panasonic AG-DV2500 tape deck contains an invalid entry in its
configuration ROM root directory:  A leaf pointer with the undefined key
ID 0 and an offset that points way out of the standard config ROM area.
This caused firewire-core to dismiss the device with the generic log
message "giving up on config rom for node id...", after which it was of
course impossible to access the tape deck with dvgrab or any other
program.  https://bugzilla.redhat.com/show_bug.cgi?id=449252#c29

The fix is to simply ignore this invalid ROM entry and proceed to read
the valid rest of the ROM.  There is a catch though:  When the kernel
later iterates over the ROM, it would be nasty having to check again for
such too large ROM offsets.  Therefore we manipulate the defective or
unsupported ROM entry to become a harmless immediate entry that won't
have any side effects later (an entry with the value 0x00000000).

Reported-by: George Chriss
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Several config ROM related functions only peek at the ROM cache; mark
their arguments as const pointers.  Ditto fw_device.config_rom and
fw_unit.directory, as the memory behind them is meant to be write-once.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Witespace and comment changes, and a different way to say i + 1 < end.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The core (sysfs attributes), the firedtv driver, and possible future
drivers all read strings from some configuration ROM directory.  Factor
out the generic code from show_text_leaf() into a new helper function,
modified slightly to handle arbitrary buffer sizes.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Let attribute group vectors be declared "const".  We'd
like to let most attribute metadata live in read-only
sections... this is a start.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This extra check will avoid Broadcast_Channel register related traffic
to many IIDC, SBP-2, and AV/C devices which aren't IRMC or have a
max_rec < 8 (i.e. support < 512 bytes async payload).  This avoids a
little bit of traffic after bus reset and is even more careful with
devices which don't implement this CSR.

The assumption is that no other protocol than IP over 1394 uses the
broadcast channel for streams.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The IP-over-1394 driver will add child devices beneath card devices
which are not of type fw_device.  Hence firewire-core's callbacks in
device_for_each_child() and device_find_child() need to check for the
device type now.

Initial version written by Jay Fenlason.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Retrieval of an fw_unit's parent is a common pattern in high-level code.
Wrap it up as device = fw_parent_device(unit).
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The source files of firewire-core, firewire-ohci, firewire-sbp2, i.e.
 "drivers/firewire/fw-*.c"
are renamed to
 "drivers/firewire/core-*.c",
 "drivers/firewire/ohci.c",
 "drivers/firewire/sbp2.c".

The old fw- prefix was redundant to the directory name.  The new core-
prefix distinguishes the files according to which driver they belong to.

This change comes a little late, but still before further firewire
drivers are added as anticipated RSN.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The three header files of firewire-core, i.e.
 "drivers/firewire/fw-device.h",
 "drivers/firewire/fw-topology.h",
 "drivers/firewire/fw-transaction.h",
are replaced by
 "drivers/firewire/core.h",
 "include/linux/firewire.h".

The latter includes everything which a firewire high-level driver (like
firewire-sbp2) needs besides linux/firewire-constants.h, while core.h
contains the rest which is needed by firewire-core itself and by low-
level drivers (card drivers) like firewire-ohci.

High-level drivers can now also reside outside of drivers/firewire
without having to add drivers/firewire to the header file search path in
makefiles.  At least the firedtv driver will be such a driver.

I also considered to spread the contents of core.h over several files,
one for each .c file where the respective implementation resides.  But
it turned out that most core .c files will end up including most of the
core .h files.  Also, the combined core.h isn't unreasonably big, and it
will lose more of its contents to linux/firewire.h anyway soon when more
firewire drivers are added.  (IP-over-1394, firedtv, and there are plans
for one or two more.)

Furthermore, fw-ohci.h is renamed to ohci.h.  The name of core.h and
ohci.h is chosen with regard to name changes of the .c files in a
follow-up change.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Include required headers which were only indirectly included.
Remove unused includes and an unused constant.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Due to AV/C protocol extensions, FireDTV devices need a vendor-specific
driver.  But their configuration ROM features a vendor ID only in the
root directory, not in the unit directory.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

That way, the new firedtv driver will be able to use a single ID table
in builds against ieee1394 core and/or against firewire core.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NStefan Richter <stefanr@s5r6.in-berlin.de>

Cache the test result of whether a device implements BROADCAST_CHANNEL.
This minimizes traffic on the bus after each bus reset.  A majority of
devices does not implement BROADCAST_CHANNEL.

Remove busy retries; just rely on the hardware to retry requests to busy
responders.  Remove unnecessary log messages.

Rename the flag is_irm to broadcast_channel_allocated to better reflect
its meaning.  Reset the flag earlier in fw_core_handle_bus_reset.

Pass the generation down as a call parameter; that way generation can't
be newer than card->broadcast_channel_allocated and device->node_id.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This patch adds the ISO broadcast channel support that is required of a
1394a IRM.  In specific, if the local device the IRM, it allocates ISO
channel 31 and sets the broadcast channel register of all devices on the
local bus to BROADCAST_CHANNEL_INITIAL | BROADCAST_CHANNEL_VALID to indicate
that channel 31 can be use for broadcast messages.

One minor complication is that on startup the local device may become IRM
before all the devices on the bus have been enumerated by the stack.  Therefore
we have to keep a "the local device is IRM" flag and possibly set the
broadcast channel register of new devices at enumeration time.
Signed-off-by: NJay Fenlason <fenlason@redhat.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Standardize on  if (err)
                        handle_error;
           and  if (ret < 0)
                        handle_error;

Don't call a variable err if we store values in it which mean success.
Also, offset some return statements by a blank line since this how we do
it in drivers/firewire.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

reread_bus_info_block() only gets to see devices whose config_rom_length
is at least 6 (ROM header, bus info block, root directory header).
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

type
    function_name(parameters);

is nice to look at but was not used consistently.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

So far it is only taken in non-atomic contexts.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This adds a client_list_lock, which only protects the device's
client_list, so that future versions of the driver can call code that
takes the card->lock while holding the client_list_lock.  Adding this
lock is much simpler than adding __ versions of all the functions that
the future version may need.  The one ordering issue is to make sure
code never takes the client_list_lock with card->lock held.  Since
client_list_lock is only used in three places, that isn't hard.
Signed-off-by: NJay Fenlason <fenlason@redhat.com>

Update fill_bus_reset_event() accordingly.  Include linux/spinlock.h.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This fixes a regression by "firewire: keep highlevel drivers attached
during brief connection loss":  There were 2 seconds unnecessary waiting
added to the shutdown procedure of each controller.

We use card->link as status flag to signal the device handler that there
is no use to wait for a come-back.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

There are situations when nodes vanish from the bus and come back
quickly thereafter:
  - When certain bus-powered hubs are plugged in,
  - when certain devices are plugged into 6-port hubs,
  - when certain disk enclosures are switched from self-power to bus
    power or vice versa and break the daisy chain during the transition,
  - when the user plugs a cable out and quickly plugs it back in, e.g.
    to reorder a daisy chain (works on Mac OS X if done quickly enough),
  - when certain hubs temporarily malfunction during high bus traffic.

Until now, firewire-core reported affected nodes as lost to the
highlevel drivers (firewire-sbp2 and userspace drivers).  We now delay
the destruction of device representations until after at least two
seconds after the last bus reset.  If a "new" device is detected in this
period whose bus information block and root directory header match that
of a device which is pending for deletion, we resurrect that device and
send update calls to highlevel drivers.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Due to commit 2831fe6f, "driver core:
create a private portion of struct device", device_initialize() can no
longer be called from atomic contexts.

We now defer it until after config ROM probing.  This requires changes
to the bus manager code because this may use a device before it was
probed.
Reported-by: NJay Fenlason <fenlason@redhat.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Take a reference to the card whenever fw_card_bm_work() is scheduled on
that card and release it when the work is done.  This allows us to
remove the cancel_delayed_work_sync() in fw_core_remove_card().
Signed-off-by: NJay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (patch update)

Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Share code between fw_send_request + wait_for_completion callers.
Signed-off-by: NJay Fenlason <fenlason@redhat.com>

Addendum:
Removes an unnecessary struct and an ununsed retry loop.
Calls it fw_run_transaction() instead of fw_send_request_sync().
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Acked-by: NKristian Høgsberg <krh@redhat.com>

This is a functionally equivalent replacement of the current reference
counting of struct fw_card instances.  It only converts it to common
idioms as suggested by Kristian Høgsberg:
  - struct kref replaces atomic_t as the counter.
  - wait_for_completion is used to wait for all card users to complete.

BTW, it may make sense to count card->flush_timer and card->work as
card users too.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>