(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>
The ieee1394 version of raw1394_read_cycle_timer() fell over the cliff
in "First cut at integrating juju". This brings it back and adds a juju
version of it.
Also correct a typo in the inline documentation: s/get/read/
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.
This would be returned when the callback doesn't have enough data to
create a complete packet. This can occur when the xmit buffers are
bigger than the buffers supplying the data. It is not nescessarily an
error, because there are enough packets in the xmit buffer. This
response could give the data supplyer more time to fill the intermediate
buffer without losing any packets.
Signed-off-by: Pieter Palmers <pieterp@joow.be>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@161 53a565d1-3bb7-0310-b661-cf11e63c67ab
is already mentioned in doc/libraw1394.sgml but an existing comment about
raw1394_iso_xmit_init may be misleading.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@158 53a565d1-3bb7-0310-b661-cf11e63c67ab
(addition of functions raw1394_arm_get_buf raw1394_arm_set_buf to get and set buffers of mapped address ranges)
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@137 53a565d1-3bb7-0310-b661-cf11e63c67ab
Stefan Richter
Erik Hovland
Dan Dennedy
Philippe Troin
Dan Dennedy
Dan Dennedy
ddennedy
bencollins
weihs