| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When faced with bogus config ROM read responses from an audio device
that did not support block requests as advertized, libffado's csr1212
code was able to recover when running on top of raw1394 but corrupted
its config ROM cache when running on top of firewire-core.
http://subversion.ffado.org/ticket/299
While the actual cause was a combination of firmware bug of the device
and flaw in csr1212.c of libffado, the much less graceful behavior when
running on firewire-core was obviously due to libraw1394's
firewire-core backend. Hence,
- do not write into the client's buffer if rcode != RCODE_COMPLETE,
- do not copy more data than the actual response contained.
The latter safeguard is not overly effective though. The libraw1394 API
has no means to inform a client about the error case that a responder
node sent less bytes than were requested. (The case that the responder
sent more bytes than requested is covered up by the kernel already.)
Should we synthesize an I/O failure? Does not sound ideal either.
However, such a size mismatch should never happen; the important part of
this change is the RCODE_COMPLETE check.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
|
| |
Requires kernel 2.6.36 or newer at runtime and linux-headers 2.6.36 or newer
at build time.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If multiple cards are installed, firewire-core will emit requests from
nodes on any of the cards to clients. This is not expected by
libraw1394 clients since a raw1394handle_t is bound to a single card
alias port.
On kernel 2.6.36 and newer we can filter out requests from other cards.
Note that we still need to call the response ioctl in order to release
kernel resources associated with an inbound transaction.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The firewire-core (juju) backend of libraw1394 installs address range
mappings on the default ioctl fd, i.e. a file that represents a random
device on the chosen port. It receives incoming requests from any
sender node via this address range mapping. Due to a kernel ABI
limitation, the sender node ID is not known though. So far libraw1394
simply assumed the node ID of the device that provided the default
ioctl fd. This only works if there is only one accessible fd on the
entire bus.
This limitation caused for example libffado to fail to work with
another AV/C or IIDC device attached to the bus, because node IDs of
FCP requests and FCP responses did not match since the latter were
wrong. FCP clients which did not check sender node IDs were seemingly
not affected by this bug. The bug is fixed by a kernel ABI extension
in Linux 2.6.36. This libraw1394 change implements libraw1394's
counterpart to this ABI extension.
Hence this libraw1394 fix requires
- kernel-headers 2.6.36 or later at build time of libraw1394
- kernel 2.6.36 or later at runtime.
Otherwise, libraw1394 simply degrades to the faulty previous behaviour.
Side note: The change of IMPLEMENTED_CDEV_ABI_VERSION to 4 requires
that we fill in struct fw_cdev_allocate.region_end which was added in
the ABI v4.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
| |
Use more uniform names along the lines of abi_has_some_feature(...).
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since linux/firewire-cdev.h header file and libraw1394 sources are
distributed separately, it is wrong to fill in a constant from that
header into the FW_CDEV_IOC_GET_INFO ioctl as the ABI version which
libraw1394 supports. This may not be forward compatible if an old
libraw1394 is compiled with a new kernel header and ran on top of a
kernel that implements new features that require a compatible
userland.
OK, the damage is already done in released versions of libraw1394.
Hence the FW_CDEV_VERSION of the kernel header file is not going to
be updated anymore in future kernel versions. (Only the version
internally to firewire-core will be incremented further.)
But let's remove the buggy usage of FW_CDEV_VERSION nevertheless.
Developers of other firewire-cdev client programs might look at
libraw1394 sources. The libraw1394 sources should not teach them
how to do it wrong.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
because ieee1394_destroy_handle does it too. Otherwise, clients which
rely on the ieee1394 backend behaviour leak memory when running on the
juju backend.
Also add the ability to call fw_iso_shutdown multiple times or before
a successful context initialization. Faulty clients might rely on it
based on ieee1394 backend behaviour.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
|
| |
Also add errno = ENOMEM because it is said that that some malloc
implementations might miss to do so.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When EPOLLHUP event is received in fw_loop_iterate(), it is or'd
with EPOLLERR. The EPOLLHUP event was then overlooked in
handle_device_event() with unpredictable-but-generally bad results.
This problem has been rediscovered several times.
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/13330
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/13779
Reported-by: B.J. Buchalter <bj@mhlabs.com>
Reported-by: Michael Thireos <mthireos@vanteon.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
|
|
| |
This change is essentially cosmetic: Set fields of structs passed to
the kernel via ioctl so that valgrind will not complain about them.
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, comments)
|
| |
|
|
|
|
|
| |
Previously, /dev/fw* and hence files like /dev/fwmonitor were probed
which may have bad effects if the client runs with access privileges.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
| |
Each request allocated a struct request_closure which was never freed.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
|
|
| |
This implements asynchronous streams on juju, i.e. enables
raw1394_async_stream() and raw1394_start_async_stream() to work
with the new firewire kernel stack.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
|
|
|
|
|
| |
This allows raw1394_bandwidth_modify() and raw1394_channel_modify()
to work on juju without write access to the IRM's character device file.
If either the build-time requirement of firewire-cdev header ABI >= v.2
or the runtime requirement of firewire-core ABI >= v.2 is not satisfied,
the code falls back to transactions to the IRM as before.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
|
|
| |
This implements broadcast transactions on juju.
(Broadcast transactions are write transactions to PHY ID 63,
not to be confused with isochronous or asynchronous streams.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
|
| |
by Kristian Hogsberg in an e-mail to the linux1394-devel mailing list
on Feb 3, 2009.
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
| |
|
|
|
|
|
| |
Most of them do this already, only a few missed it.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On 10 Jan, David Moore wrote:
> On Sat, 2009-01-10 at 19:28 +0100, Stefan Richter wrote:
>> @@ -161,14 +160,16 @@ scan_devices(fw_handle_t handle)
...
>> + for (j = 0; j < i; j++)
>> + if (ports[j].card == get_info.card)
>> + continue;
>> +
>
> That continue statement doesn't do what you intended I think.
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Subject: [PATCH] Work without permission to access local node's /dev/fw*
Fix for juju backend:
libraw1394 required write permission to the character device file of
the local node(s) in order to enumerate cards and for a number of
other operations. This forced users to either run applications like
dvgrab and kino with elevated privileges, or to configure write
permission for all /dev/fw* or at least for local nodes' /dev/fw*.
We now use the first accessible file which was found for each card
for as many tasks as possible, instead of the local node's file.
This allows distributors or admins to implement stricter access
rights (default off, e.g. only on for AV/C and IIDC devices)
without sacrificing functionality of said class of applications.
Access to the local node is now only required by low-level tools
like gscanbus.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When performing a lock transaction (such as with fw_lock) under Juju, 4
bytes of the stack gets corrupted. This is because the lock transaction
has 8 bytes of data sent and 4 bytes received. Since the transaction
"length" is specified as 8, handle_device_event() copies 8 bytes into
the destination variable instead of the desired 4, and overflows into
the stack by 4 bytes.
This patch fixes the corruption by adding an extra "out_length" argument
to the send_request() function so that both in_length and out_length can
be specified separately.
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
because they do the same.
We only may want a separate fw_bandwidth_modify() in the future when
firewire-core gains a special ioctl() for that.
(Not runtime-tested, but it looks good to me.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(juju)
Reported by Adrian Knoth: fw_channel_modify() was unable to allocate
some channels which were actually free.
http://marc.info/?l=linux1394-devel&t=122818128900002
This can be easily fixed by replacing fw_channel_modify() by
ieee1394_channel_modify() because this is highlevel enough to work with
Juju as well. We only may want a separate fw_channel_modify() in the
future when firewire-core gains a special ioctl() for that.
Also fix a documentation typo: raw1394_channel_modify() did not show up
in extracted API documentation due to a cut'n'paste typo in raw1394.h.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
| |
|
|
|
|
|
| |
The buffer pointers were uninitialized, leading to segfault in memcpy.
Bug report and initial version of the fix by Adrian Knoth.
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
| |
|
|
|
|
|
|
|
| |
When using strncpy with the exact size of the destination string the
string may end up lacking null termination because the source string is
bigger then the destination.
Signed-off-by: Erik Hovland <erik@hovland.org>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
| |
|
|
|
|
|
|
| |
When an unsigned type is assigned a signed value, the
negatived value is never seen.
Signed-off-by: Erik Hovland <erik@hovland.org>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
| |
|
|
|
|
|
| |
Unsigned values do not return signed values when subtracted
and the right operand is larger then the left operand.
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
| |
|
|
|
| |
Signed-off-by: Erik Hovland <erik@hovland.org>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
While trying to track down some crashes in kino, I found the following problems
with libraw1394:
* There is a DIR* leak in raw1394_set_port().
* Lots of data structures are not fully initialized when calling IEEE1394
ioctl()s. These cause valgrind errors (benign, as valgrind does not know
how to interpret all ioctls. However these also cause kino to crash in
libraw1394. I've added a bunch of memset()s to prevent this problem from
happening.
Forward-ported to libraw1394 git tree by Jarod Wilson.
|
|
|
give them 'fw' names instead of 'juju.'
|
Stefan Richter
Peter Hurley
Jay Fenlason
Dan Dennedy
David Moore
Erik Hovland
Philippe Troin
Dan Dennedy
