summaryrefslogtreecommitdiffstats
path: root/src/fw.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* add copyright notices; change version to v3.0.0-mcgoron-devv3.0.0-mcgoron-devGravatar Peter McGoron 2022-09-201-0/+1
|
* Implement virtual memory for ARM managerGravatar Peter McGoron 2022-09-201-168/+53
| | | | | | | | | | | | | | | | Instead of allocating memory for address range mappings (ARM) and handling all reads and writes to said memory, the new ARM manager calls a function for each received request with the data, transaction code, and allocation information. The ARM tag manager now must handle validation of memory accesses and retreive/write the data. This allows implementations to use network resources or generated data as memory. The ARM manager no longer automatically sends response packets. It is the responsibility of the user to send response packets using raw1394_send_rw_response(). The interface is not implemented for raw1394 and will probably never be implemented for raw1394. It is for firewire-cdev (modern Linux) only.
* Use <stdint.h> types instead of non-standard typesGravatar Thomas Petazzoni 2016-03-201-3/+3
| | | | | | | | | | | | | | | | | | | The __uint32_t type is not a standard type, and not necessarily provided by all C libraries. However, <stdint.h> provides a set of standard types, which are guaranteed to be available with all C libraries. This patch therefore changes __uint32_t to uint32_t, which allows to fix the compilation with the Musl C library. This patch is already used by the Alpine Linux distribution and the Buildroot build system. Original patch from http://git.alpinelinux.org/cgit/aports/plain/main/libraw1394/fix-types.patch. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Fix memory leak in response handlerGravatar Lee Cewd 2015-04-281-3/+5
| | | | | | | | | | | | | | | | | | A temporarily allocated buffer which is used to pass data from libraw1394's event loop to the Address Range Mapping callback was never freed. This was pointed out by the following valgrind trace: 3067120 (3066560 direct, 560 indirect) bytes in 10952 blocks are definitely lost in loss record 36 of 36 at 0x4029F6F : malloc () by 0x405B1B5 : ??? (in usr/lib/libraw1394.so.11.0.1) by 0x405B492 : ??? (in usr/lib/libraw1394.so.11.0.1) by 0x405BF24 : fw_loop_iterate (in usr/lib/libraw1394.so.11.0.1) by 0x405C197 : ??? (in usr/lib/libraw1394.so.11.0.1) by 0x405D6F8 : fw_write (in usr/lib/libraw1394.so.11.0.1) by 0x405A292 : raw1394_write (in usr/lib/libraw1394.so.11.0.1) by 0x805A0F2 : main (main.cpp:121) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Add raw1394_get_speed() APIGravatar Stefan Richter 2012-06-301-0/+28
| | | | | | | | | | | | | | | | | | | | | | This lets initiators of isochronous streams or asynchronous streams from or to the local node figure out what maximum speed can be configured. Furthermore it can be used to display connection speeds for informative purposes without having to perform topology analysis (in case of 1394a buses) or extensive phy port status queries (in case of 1394b buses). To be in line with other existing libraw1394 APIs which use nodeid_t variables, this API identifies a node only via a card:nodeID tuple which is unsafe against generation changes. A node can only be properly identified by card:generation:nodeID tuples. However, since this new API extension and libraw1394 as a whole is mainly aimed towards existing libraw1394 client code bases rather than new developments, I decided against making this call race free but somewhat more difficult to use in typical existing client code. A unit test for the new call is added to testlibraw as well. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Tweak raw1394_add_config_rom_descriptor() API, add documentation and test caseGravatar Stefan Richter 2012-06-181-16/+15
| | | | | | | | | | | | | | | | | | | | To conform with 'size' arguments of other libraw1394 calls, change the one in raw1394_add_config_rom_descriptor() from quadlets to bytes. This breaks runtime compatibility with potential clients that were written against B.J.'s original patch, hence reorder arguments just to break compatibility also at compile time. Change errno to ENOSYS (function not implemented) when called while running on top of raw1394. Allow &token to be NULL for convenience of clients which don't require raw1394_remove_config_rom_descriptor(). Add exhaustive documentation. Much of it is copied from the documentation of the underlying ioctl. Add example code which doubles as unit test in testlibraw. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Add raw1394_add_config_rom_descriptor() and ↵Gravatar B.J. Buchalter 2012-06-171-0/+35
| | | | | | | | | | | raw1394_remove_config_rom_descriptor() API This adds support of the firewire-core (juju) ABI to add and remove config ROM directories or descriptors. The raw1394 ABI supports similar requests, but for now we leave the two functions unimplemented when running on top of raw1394. Signed-off-by: Benjamin Buchalter <bj@mhlabs.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (whitespace changes)
* Remove unused codeGravatar Stefan Richter 2012-05-251-57/+7
| | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Fix incorrect use of == instead of =.Gravatar Guus Sliepen 2012-02-191-1/+1
| | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Make a symbol staticGravatar Stefan Richter 2012-02-051-1/+1
| | | | | | This symbol should not be exported. Fixes commit db5f202d5d0. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Continue inotify event handling even after failure in one eventGravatar Stefan Richter 2012-02-051-4/+2
| | | | | | | | If read() on the inotify handle gave us several events at once, and handling one of them resulted in whatever error, there is little reason not to try handling the rest of the events. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Process multiple inotify eventsGravatar Peter Hurley 2012-02-051-8/+27
| | | | | | | | | If multiple inotify events are presented, process *all* of them. This can happen when several device adds are pushed simultaneously. handle_inotify() was refactored. Signed-off-by: Peter Hurley <phurley@charter.net> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Reset device fd upon error condition in handle_inotify()Gravatar Peter Hurley 2012-02-051-0/+1
| | | | | | | | If an error is encountered while adding a new device in inotify handling, make sure the fd is marked invalid (-1). Signed-off-by: Peter Hurley <phurley@charter.net> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* retry raw1394_read/write/lock/lock64 with delays after ack-busyGravatar Stefan Richter 2011-10-221-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Applications or higher-level libraries have retry strategies of their own in place, but they don't work too well sometimes. For example, old Panasonic camcorders require pauses in the order of several milliseconds between response of a former transaction and request of the next one, but libavc1394 and libiec61883 retry already after 20 microseconds. This change cures all FCP transaction failures ("send oops") in kino and dvgrab that I was getting with Panasonic NV-DX110. According to reports, Panasonic AG-EZ30 and Grundig Scenos DLC 2000 were affected too. The additional latency in raw1394_read/write/lock/lock64 appears to be the better alternative compared to terminal I/O failures. Besides, a caller of this blocking request API should at least in theory be prepared to cope with transaction durations in the order of a few seconds. IEEE 1394 specifies split transaction timeouts of up to 8 seconds. An application which needs more control should use the non-blocking request API, i.e. raw1394_start_read/write/lock/lock64. We specifically only retry after ack-busy, not after any of the other types of transaction failures that may or may not succeed if retried. This change is only done in the firewire-core backend (a.k.a. juju). The same could be added to the raw1394 backend (a.k.a. linux1394) but is not as important there, perhaps because transaction completion latency in the ieee1394 core very much increases the success rate of existing retry code in libavc1394 and friends. Note, this does not fix every and all FCP transaction problems. There are e.g. certain JVC camcorders which do not properly complete FCP transactions if an application frequently polls for status or requests status right before a control request, even with an order of magnitude greater delays than used in this patch. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Reviewed-by: Dan Dennedy <dan@dennedy.org>
* redirect Config ROM reads into the kernel's ROM cacheGravatar Stefan Richter 2011-08-211-0/+52
| | | | | | | | | | | | | | | | | | | | | | | The kernel already read each node's Configuration ROM and cached it. So let all libraw1394 clients read from that cache instead of having to perform all those transactions all over again. This reduces bus traffic at application start-up and at each bus reset. It also makes all Configuration ROM accesses fool-proof and robust. This together with the kernel patch "firewire: core: handle ack_busy when fetching the Config ROM" lets me use an old Panasonic camcorder which requires us to keep pauses between response and request --- longer than librom1394's retry pause --- with dvgrab (though still with frequent failures of write requests to FCP_COMMAND, i.e. with lots of "send oops" noise in the console and occasionally having to repeat key-presses in interactive mode). For simplicity of implementation, only the blocking raw1394_read() is modified, not the nonblocking raw1394_start_read(). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Dan Dennedy <dan@dennedy.org>
* arm on firewire-core: Remove leftover debug printfsGravatar Stefan Richter 2010-10-201-6/+0
| | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Be more careful when copying response payloads on firewire-coreGravatar Stefan Richter 2010-09-071-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Implement raw1394_(start_)phy_packet_write() on firewire-coreGravatar Stefan Richter 2010-09-071-14/+77
| | | | | | | 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>
* Filter incoming requests per cardGravatar Stefan Richter 2010-09-071-3/+16
| | | | | | | | | | | | | 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>
* Fix FCP and ARM source node ID on firewire-coreGravatar Stefan Richter 2010-09-071-42/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Rename a few kernel ABI testing helpersGravatar Stefan Richter 2010-09-071-4/+4
| | | | | | Use more uniform names along the lines of abi_has_some_feature(...). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Do not use a random FW_CDEV_VERSION as our implemented ABI versionGravatar Stefan Richter 2010-09-071-4/+9
| | | | | | | | | | | | | | | | | | | | | | 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>
* Always imply iso shutdown in fw_destroy_handleGravatar Stefan Richter 2010-09-071-2/+1
| | | | | | | | | | | | 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>
* Add missing malloc failure checksGravatar Stefan Richter 2010-09-071-4/+16
| | | | | | | 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>
* Fix for overlooked device HUP with 'firewire' stackGravatar Peter Hurley 2010-04-171-1/+1
| | | | | | | | | | | | | | 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>
* Initialize unused fields in ioctl argumentsGravatar Jay Fenlason 2009-11-221-0/+1
| | | | | | | | 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)
* Match only /dev/fw[0-9]* as firewire-core device filesGravatar Stefan Richter 2009-05-311-4/+10
| | | | | | | 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>
* Fix memory leaks with async requests on firewire-coreGravatar Stefan Richter 2009-05-301-3/+10
| | | | | | Each request allocated a struct request_closure which was never freed. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Use new async stream ioctlGravatar Stefan Richter 2009-05-301-14/+50
| | | | | | | | 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>
* Use new iso resource allocation ioctlsGravatar Stefan Richter 2009-05-301-0/+95
| | | | | | | | | | | 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>
* Use new broadcast request ioctlGravatar Stefan Richter 2009-05-301-2/+15
| | | | | | | | 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>
* Change the license of the "juju" fw*.[hc] files to LGPL v2.1 as approvedGravatar Dan Dennedy 2009-02-031-13/+3
| | | | | | | 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>
* Set errno = ENOSYS in unimplemented functionsGravatar Stefan Richter 2009-01-121-0/+5
| | | | | | | 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>
* Work without permission to access local node's /dev/fw*Gravatar Stefan Richter 2009-01-101-16/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix stack corruption during juju lock transactionsGravatar David Moore 2008-12-291-13/+19
| | | | | | | | | | | | | | | 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>
* [libraw1394 patch] Unify {ieee1394,fw}_bandwidth_modify()Gravatar Stefan Richter 2008-12-031-49/+0
| | | | | | | | | | | | 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>
* [libraw1394 patch] Fix raw1394_channel_modify() on firewire-coreGravatar Stefan Richter 2008-12-031-49/+0
| | | | | | | | | | | | | | | | | | | (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>
* Fix segfault in juju's handle_arm_requestGravatar Stefan Richter 2008-10-281-0/+2
| | | | | | | 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>
* Makes extra sure strings are not overrun.Gravatar Erik Hovland 2008-10-281-13/+19
| | | | | | | | | 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>
* Make sure that we have the right types.Gravatar Erik Hovland 2008-10-281-4/+4
| | | | | | | | 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>
* Compare unsigned values instead of subtracting them.Gravatar Erik Hovland 2008-10-281-2/+3
| | | | | | | 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>
* Protect against resource leaks.Gravatar Erik Hovland 2008-10-281-1/+3
| | | | | Signed-off-by: Erik Hovland <erik@hovland.org> Signed-off-by: Dan Dennedy <dan@dennedy.org>
* Plug dir leak and initialize data structsGravatar Philippe Troin 2008-07-051-1/+14
| | | | | | | | | | | | | | 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.
* Move the source code files in the juju directory into the src directory andGravatar Dan Dennedy 2008-04-301-0/+1369
give them 'fw' names instead of 'juju.'
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2025-12-07 22:48:20 +0000