The DMA mapping API cannot map on-stack addresses, as explained in
Documentation/DMA-mapping.txt.  Convert the two cases of on-stack packet
payload buffers in firewire-core (payload of lock requests in the bus
manager work and in iso resource management) to slab-allocated memory.

There are a number on-stack buffers for quadlet write or quadlet read
requests in firewire-core and firewire-sbp2.  These are harmless; they
are copied to/ from card driver internal DMA buffers since quadlet
payloads are inlined with packet headers.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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>

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>

This changes the as yet unreleased FW_CDEV_IOC_SEND_STREAM_PACKET ioctl
to generate an fw_cdev_event_response event just like the other two
ioctls for asynchronous request transmission do.  This way, clients get
feedback on successful or unsuccessful transmission.

This also adds input validation for length, tag, channel, sy, speed.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This changes the ioctl() return value of FW_CDEV_IOC_SEND_REQUEST and of
the as yet unreleased FW_CDEV_IOC_SEND_BROADCAST_REQUEST.  They used to
return
	sizeof(struct fw_cdev_send_request *) + data_length

which is obviously a failed attempt to emulate the return value of
raw1394's respective interface which uses write() instead of ioctl().

However, the first summand, as size of a kernel pointer, is entirely
meaningless to clients and the second summand is already known to
clients.  And the result does not resemble raw1394's write() return
code anyway.

So simplify it to a constant non-negative value, i.e. 0.  The only
dangers here would be that future client implementations check for error
by ret != 0 instead of ret < 0 when running on top of an old kernel; or
that current clients interpret ret = 0 or more as failure.  But both are
hypothetical cases which don't justify to return irritating values.

While we touch this code, also remove "& 0x1f" from tcode in the call of
fw_send_request.  The tcode cannot be bigger than 0x1f at this point.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The bus reset handler concurrently frees client->device->node.  Use
device->node_id instead.  This is equivalent to device->node->node_id
while device->generation is current.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The access permissions and ownership or ACL of /dev/fw* character device
files will typically be set based on the device type of the respective
nodes, as obtained by firewire-core from descriptors in the device's
configuration ROM.  An example policy is to deny write permission by
default but grant write permission to files of AV/C video and audio
devices and IIDC video devices.

The FW_CDEV_IOC_ADD_DESCRIPTOR ioctl could be used to partly subvert
such a policy:  Find a device file with relaxed permissions, use the
ioctl to add a descriptor with AV/C marker to the local node's ROM, thus
gain access to the local node's character device file.  (This is only
possible if there are udev scripts installed which actively relax
permissions for known device types and if there is a device of such a
type connected.)

Accessibility of the local node's device file is relevant to host
security if the host contains two or more IEEE 1394 link layer
controllers which are plugged into a single bus.

Therefore change the ABI to deny FW_CDEV_IOC_ADD_DESCRIPTOR if the file
belongs to a remote node.  (This change has no impact on known
implementers of the ABI:  None of them uses the ioctl yet.)

Also clarify the documentation:  The ioctl affects all local nodes, not
just one local node.

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

The as yet unreleased FW_CDEV_IOC_GET_SPEED ioctl puts only a single
integer into the parameter buffer.  We can use ioctl()'s return value
instead.

(Also: Some whitespace change in firewire-cdev.h.)
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Allow userspace and other firewire drivers (fw-ipv4 I'm looking at
you!) to send Asynchronous Transmit Streams as described in 7.8.3 of
release 1.1 of the 1394 Open Host Controller Interface Specification.
Signed-off-by: NJay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (tweaks)

The kernel API documentation says that queue_delayed_work() returns 0
(only) if the work was already queued.  The return codes of
schedule_delayed_work() are not documented but the same.

In init_iso_resource(), the work has never been queued yet, hence we
can assume schedule_delayed_work() to be a guaranteed success there.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Some fixes:
  - Remove stale documentation.
  - Fix a != vs. == thinko that got in the way of channel management.
  - Try bandwidth deallocation even if channel deallocation failed.

A simplification:
  - fw_cdev_allocate_iso_resource.channels is now ordered like
    libdc1394's dc1394_iso_allocate_channel() channels_allowed
    argument.

By the way, I looked closer at cards from NEC, TI, and VIA, and noticed
that they all don't implement IEEE 1394a behaviour which is meant to
deviate from IEEE 1212's notion of lock compare-swap.  This means that
we have to do two lock transactions instead of one in many cases where
one transaction would already succeed on a fully 1394a compliant IRM.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

DMA must be halted before we DMA-unmap and free the DMA buffer.  Since
we cannot rely on the client to stop the context before it closes the
fd, we have to reorder fw_iso_buffer_destroy vs. fw_iso_context_destroy.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

All of these functions are entered with IRQs enabled.
Hence the unconditional spin_unlock_irq can be used.

Function:                  Caller context:
    dequeue_event()            client process, via read(2)
    fill_bus_reset_event()     fw-device.c update worqueue job
    release_client_resource()  client process, via ioctl(2)
    fw_device_op_release()     client process, via close(2)
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Make the size check of ioctl_send_request and
ioctl_send_broadcast_request speed dependent.  Also change the error
return code from -EINVAL to -EIO to distinguish this from other errors
concerning the ioctl parameters.

Another payload size limit for which we don't check here though is the
remote node's Bus_Info_Block.max_rec.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

We don't want random users write to Memory Space (e.g. PCs with physical
DMA filters down) or to core CSRs like Reset_Start.

This does not protect SBP-2 target CSRs.  But properly behaving SBP-2
targets ignore broadcast write requests to these registers, and the
maximum damage which can happen with laxer targets is DOS.  But there
are ways to create DOS situations anyway if there are devices with weak
device file permissions (like audio/video devices) present at the same
bus as an SBP-2 target.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Write transactions to the broadcast node ID are a convenient way to
trigger functions of multiple nodes at once.  IIDC is a protocol which
can make use of this if multiple cameras with same command_regs_base are
connected at the same bus.

Based on
    Date: Wed, 10 Sep 2008 11:32:16 -0400
    From: Jay Fenlason <fenlason@redhat.com>
    Subject: [patch] SEND_BROADCAST_REQUEST
Changes:  ioctl_send_request() and ioctl_send_broadcast_request() now
share code.  Broadcast speed corrected to S100.  Check for proper tcode.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

While the speed of asynchronous transactions is automatically chosen by
the kernel, the speed of isochronous streams has to be chosen by the
initiating client.

In case of 1394a bus topologies, the maximum possible speed could be
figured out with some effort by evaluation of the remote node's link
speed field in the config ROM, the local node's link speed field, and
the PHY speeds and topologic information in the local node's or IRM's
topology map CSR.  However, this does not work in case of 1394b buses.

Hence add an ioctl to export the maximum speed which the kernel already
determined.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This adds ioctls for allocation and deallocation of a channel or/and
bandwidth without auto-reallocation and without auto-deallocation.

The benefit of these ioctls is that libraw1394-style isochronous
resource management can be implemented without write access to the IRM's
character device file.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Based on
    Date: Tue, 18 Nov 2008 11:41:27 -0500
    From: Jay Fenlason <fenlason@redhat.com>
    Subject: [Patch V4] Add ISO resource management support
with several changes to the ABI and implementation.  Only the part of
the ABI which enables auto-reallocation and auto-deallocation is
included here.

This implements ioctls for kernel-assisted allocation of isochronous
channels and isochronous bandwidth.  The benefits are:
  - The client does not have to have write access to the /dev/fw* device
    corresponding to the IRM.
  - The client does not have to perform reallocation after bus resets.
  - Channel and bandwidth are deallocated by the kernel if the file is
    closed before the client deallocated the resources.  Thus resources
    are released even if the client crashes.

It is anticipated that future in-kernel code (firewire-core IRM code;
the firewire port of firedtv), will use the fw-iso.c portions of this
code too.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Tested-by: NDavid Moore <dcm@acm.org>

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

to indicate that they are specializations of struct event or of struct
client_resource, respectively.

struct response was both an event and a client_resource; it is now split
into struct outbound_transaction_resource and ~_event in order to
document more explicitly which types of client resources exist.

struct request and struct_request_event are renamed to struct
inbound_transaction_resource and ~_event because requests and responses
occur in outbound and in inbound transactions.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The lifetime of struct client instances must be longer than the lifetime
of any client resource.

This fixes a possible race between fw_device_op_release and transaction
completions.  It also prepares for new ioctls for isochronous resource
management which will involve delayed processing of client resources.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Reviewed-by: NDavid Moore <dcm@acm.org>

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>

"ret" is the new "retval".
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Like before my commit 1415d918,
fw_core_add_address_handler() does not align the address region now.
Instead the caller is required to pass valid parameters.

Since one of the callers of fw_core_add_address_handler() is the cdev
userspace interface, we now check for valid input.  If the client is
buggy, we give it a hint with -EINVAL.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The current code uses a linked list and a counter for storing
resources and the corresponding handle numbers.  By changing to an idr
we can be safe from counter wrap-around giving two resources the same
handle.

Furthermore, the deallocation ioctls now check whether the resource to
be freed is of the intended type.
Signed-off-by: NJay Fenlason <fenlason@redhat.com>

Some rework by Stefan R:
  - The idr API documentation says we get an ID within 0...0x7fffffff.
    Hence we can rest assured that idr handles fit into cdev handles.
  - Fix some races.  Add a client->in_shutdown flag for this purpose.
  - Add allocation retry to add_client_resource().
  - It is possible to use idr_for_each() in fw_device_op_release().
  - Fix ioctl_send_response() regression.
  - Small style changes.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Unlink the client from the fw_device earlier in order to prevent bus
reset events being added to client->event_list during shutdown.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The behaviour of fw-transaction.c::fw_send_request is ill-defined for
any other tcodes than read/ write/ lock request tcodes.  Therefore
prevent requests with wrong tcodes from entering the transaction layer.

Maybe fw_send_request should check them itself, but I am not inclined to
change it and fw_fill_request from void-valued functions to ones which
return error codes and pass those up.  Besides, maybe fw_send_request is
going to support one more tcode than ioctl_send_request in the future
(TCODE_STREAM_DATA).
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>

Reported by Jay Fenlason:  ioctl() did not return as intended
  - the size of data read into ioctl_send_request,
  - the number of datagrams enqueued by ioctl_queue_iso.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Reported by Jay Fenlason:
The iso packet control accessors in fw-cdev.c had bogus masks.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Recently, a bug having to do with the alignment of transaction response
data was fixed.  However, some apps such as libdc1394 relied on the
presence of that bug in order to function correctly.  In order to stay
compatible with old versions of those apps, this patch preserves the bug
in cases where it is harmless to normal operation (such as the single
quadlet read) due to a simple duplication of data.  This guarantees
maximum compatability for those users who are using the old app with the
fixed kernel.
Signed-off-by: NDavid Moore <dcm@acm.org>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

There will be 4 padding bytes in struct fw_cdev_event_response on some platforms
The member:__u32 data will point to these padding bytes. While queue the
response and data in complete_transaction in fw-cdev.c, it will queue like this:
|response(excluding padding bytes)|4 padding bytes|4 padding bytes|data.
It queue 4 extra bytes. That is to say it use "&response + sizeof(response)"
while other place of kernel and userspace library use "&response + offsetof
(typeof(response), data)". So it will lost the last 4 bytes of data. This patch
can fix it while not changing the struct definition.
Signed-off-by: NJiSheng Zhang <jszhang3@mail.ustc.edu.cn>

This fixes responses to outbound block read requests on 64bit architectures.
Tested on i686, x86-64, and x86-64 with i686 userland, using firecontrol and
gscanbus.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Callers of fill_bus_reset_event() have to take card->lock.  Otherwise
access to node data may oops if node removal is in progress.

A lockless alternative would be

-	event->local_node_id = card->local_node->node_id;
+	tmp = fw_node_get(card->local_node);
+	event->local_node_id = tmp->node_id;
+	fw_node_put(tmp);

and ditto with the other node pointers which fill_bus_reset_event()
accesses.  But I went the locked route because one of the two callers
already holds the lock.  As a bonus, we don't need the memory barrier
anymore because device->generation and device->node_id are written in
a card->lock protected section.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NKristian Høgsberg <krh@redhat.com>

If userspace ignores the POLLERR bit from poll(), and only attempts to
read() the device when POLLIN is set, it can still make ioctl() calls on
a device that has been removed from the system.  The node_id and
generation returned by GET_INFO will be outdated, but INITIATE_BUS_RESET
would still cause a bus reset, and GET_CYCLE_TIMER will return data.
And if you guess the correct generation to use, you can send requests to
a different device on the bus, and get responses back.

This patch prevents open, ioctl, compat_ioctl, and mmap against shutdown
devices.
Signed-off-by: NJay Fenlason <fenlason@redhat.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

When a device changes its configuration ROM, it announces this with a
bus reset.  firewire-core has to check which node initiated a bus reset
and whether any unit directories went away or were added on this node.

Tested with an IOI FWB-IDE01AB which has its link-on bit set if bus
power is available but does not respond to ROM read requests if self
power is off.  This implements
  - recognition of the units if self power is switched on after fw-core
    gave up the initial attempt to read the config ROM,
  - shutdown of the units when self power is switched off.

Also tested with a second PC running Linux/ieee1394.  When the eth1394
driver is inserted and removed on that node, fw-core now notices the
addition and removal of the IPv4 unit on the ieee1394 node.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>