summaryrefslogtreecommitdiffstats
path: root/src/Makefile.am
diff options
context:
space:
mode:
authorGravatar Stefan Richter 2010-09-05 01:32:16 +0200
committerGravatar Stefan Richter 2010-09-07 11:48:18 +0200
commit7416da61128cfc880ba2c4cf38cb4e2e22904e74 (patch)
tree98206c3225944ca5439b7ae4e42955ffea71d88d /src/Makefile.am
parentImplement raw1394_(start_)phy_packet_write() on firewire-core (diff)
Be more careful when copying response payloads on firewire-core
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>
Diffstat (limited to 'src/Makefile.am')
0 files changed, 0 insertions, 0 deletions
='/libraw1394/commit/debian/rules?id=85a071ce64f2999082c8e8fb6797a6429b9f5ec2&follow=1'>Re-add the pdf buildGravatar bencollins 1-0/+1 2003-07-13Update Debian files.Gravatar bencollins 4-25/+73 2003-07-13Ok, the Debian package was way out of sync with upstreamGravatar bencollins 1-1/+1 2003-07-13Ooops...libtool works a bit different than I thought, but atleast it worksGravatar bencollins 2-6/+1 2003-07-13Generate and install the pdf in the Debian package.Gravatar bencollins 3-3/+4 2003-07-13Don't run configure at the end of autogen.sh. Also, remove autom4te.cache.Gravatar bencollins 1-1/+1 2003-07-13Update Debian maintainerGravatar bencollins 1-1/+2 2003-07-13Update Debian changelog.Gravatar bencollins 1-0/+8 2003-07-13File doesn't really seem needed. The NEWS file gives a good overview, andGravatar bencollins 1-4/+0 2003-07-13Fix compiler warnings.Gravatar bencollins 4-12/+22 2003-07-13Updates from 0.10.0 release.Gravatar bencollins 4-5/+14 2003-04-23add libtoolize to bootstrapGravatar ddennedy 1-1/+10 2003-04-21added Dan Maas' rawiso docsGravatar ddennedy 1-32/+295 2003-04-07new_handle_on_port() error path fix from Jim RadfordGravatar dmaas 1-1/+3 2003-03-26add raw1394_new_handle_on_port() convenience functionGravatar dmaas 2-1/+41 2003-02-22Updates for new rawiso ioctl interface.Gravatar bencollins 3-37/+125 2003-01-15add iso_xmit_sync() and iso_xmit_write(); clean up iso handling a bitGravatar dmaas 5-39/+161 2003-01-15implement tag matching for rawiso receptionGravatar dmaas 3-4/+12 2003-01-06back out previous commit - don't drop the legacy API just yetGravatar dmaas 6-173/+130 2003-01-05emulate legacy ISO reception API on top of new rawiso APIGravatar dmaas 7-131/+174 2002-12-24update iso API for multi-channel reception and new packet buffer layoutGravatar dmaas 4-123/+236 2002-12-20oops, irq_interval needs to be signedGravatar anonymous 1-1/+1 2002-12-20dmaas - renamed exported arm definitions into the raw1394_ namespace; brought...Gravatar anonymous 3-124/+48 2002-12-16rawiso updates:Gravatar dmaas 3-18/+25 2002-11-18fix cplusplus extern C blockGravatar ddennedy 1-4/+4 2002-11-18merged rawiso branchGravatar ddennedy 7-6/+488