| Age | Commit message (Collapse) | Author |
|---|
|
Currently, core files do not contain the mmapped memory of the video1394
or dv1394 devices, which contain the actual video input, making it
impossible to analyse the cause of abnormal program termination for
image analysis or (de)compression software. Fix that.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Also affects users of the rawiso ioctl API of raw1394.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Convert ieee1394 from nopage to fault.
Remove redundant vma range checks (correct resource range check is retained).
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Torsten Kaiser wrote:
> Looking that calltrace upwards, it seems replacing the
> memset(dma->sglist,...) with sg_init_table(...) would fix the BUG_ON()
> as that inits the SG_MAGIC.
Tested-by: Torsten Kaiser <just.for.lkml@googlemail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Most drivers need to set length and offset as well, so may as well fold
those three lines into one.
Add sg_assign_page() for those two locations that only needed to set
the page, where the offset/length is set outside of the function context.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
Commits
58b053e4ce9d2fc3023645c1b96e537c72aa8d9a ("Update arch/ to use sg helpers")
45711f1af6eff1a6d010703b4862e0d2b9afd056 ("[SG] Update drivers to use sg helpers")
fa05f1286be25a8ce915c5dd492aea61126b3f33 ("Update net/ to use sg helpers")
converted many files to use the scatter gather helpers without ensuring
that the necessary headerfile <linux/scatterlist> is included. This
happened to work for ia64, powerpc, sparc64 and x86 because they
happened to drag in that file via their <asm/dma-mapping.h>.
On most of the others this probably broke.
Instead of increasing the header file spider web I choose to include
<linux/scatterlist.h> directly into the affectes files.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Remove unnecessary includes, add missing includes.
Use forward type declarations for some structs.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
|
|
when attempting to find the 'last' part of the dma region continue the
search from where we left off, instead of starting the search over.
Signed-off-by: Jim Westfall <jwestfall@surrealistic.net>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
|
|
This patch contains fixes by LIndent.
Signed-off-by: Jens-Michael Hoffmann <jensmh@gmx.de>
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
|
|
Lots of this patch is trivial code cleanups (static vars were being
intialized to 0, etc).
There's also some fixes for ISO transmits (max buffer handling).
Aswell, we have a few fixes to disable IRM capabilites correctly. We've
also disabled, by default some generally unused EXPORT symbols for the
sake of cleanliness in the kernel. However, instead of removing them
completely, we felt it necessary to have a config option that allowed
them to be enabled for the many projects outside of the main kernel tree
that use our API for driver development.
The primary reason for this patch is to revert a MODE6->MODE10 RBC
conversion patch from the SCSI maintainers. The new conversions handled
directly in the scsi layer do not seem to work for SBP2. This patch
reverts to our old working code so that users can enjoy using Firewire
disks and dvd drives again.
We are working with the SCSI maintainers to resolve this issue outside
of the main kernel tree. We'll merge the patch once the SCSI layer's
handling of the MODE10 conversion is working for us.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
