This patch tries to check the return value of kmalloc taking the necesary
action to solve the problem.

> > Ultracam was derived from ibmcam and probably copied the list of
> > parameters too. IBM cameras have this parameter, and use it.
>
> This means that it says "MODULE_PARM(lighting, "i");" and there is no
> variable called lightening.  The new module code is stricter about
> this.  Someone please fix.

Here is the patch for 2.5.53. It removes parameters that have no use
in the ultracam driver (and they were broken anyway).

Attached is a patch leveraging some of the new generic dma stuff:

- Replaces dma mapping calls in usbcore with generic equivalents.
   This is a minor code shrink (which we'd hoped could happen).

- Pass dma mask along, so net drivers can notice it'd be good to
   set NETIF_F_HIGHDMA; or scsi ones can set highmem_io.  (Some
   Intel EHCI setups are able to support this kind of DMA.)

- Updates one net driver (usbnet) to set NETIF_F_HIGHDMA when
   appropriate, mostly as an example (since I can't test this).

- Provides Documentation/usb/dma.txt, describing current APIs.
   (Unchanged by this patch, except dma mask visibility.)

- Converted another info() to dev_info(), and likewise a couple
   dbg() to dev_dbg() conversions in the modified routine.

The number of FIXMEs was conserved: the generic API doesn't yet
fix the error reporting bugs in the PCI-specific mapping API.

This is to access the private pointer in struct usb_serial

[PATCH] USB: fix up the usb-serial drivers due to the removal of the struct usb_serial_port private pointer.

The struct device pointer should be used instead.

The ActiveSync USB "protocol" seems to be the same for all WinCE
devices seen so far. So it seems reasonable to pre-emptively support
all devices which work with ActiveSync.

This patch removes a now unnecessary debug line taht broke compilation
when debugging was enabled.

This patch allows the scanner driver to accept devices with more than
one interface. That's needed by some multi-function periphals (e.g.
scanner+printer).

Orginally from Vojtech Pavlik (16th June 2002 via email), to fix my
'broken' USB joypad, Fully tested in both 2.4.x and 2.5.52 (and
2.5.52-bk).

the fast case with a pushf/popf, by having the kernel debug trap
set the TIF_SINGLESTEP flag and causing the return path to dtrt.

boot_cpu_data should contain the common capabilities of all cpus in the
system. identify_cpu [arch/i386/kernel/cpu/common.c] tries to enforce
that. But right now, the SMP trampoline code [arch/i386/kernel/head.S]
overwrites boot_cpu_data when the secondary cpus are started, i.e.
boot_cpu_data contains the capabilities from the last cpu that booted :-(

The attached patch adds a new, __initdata variable for the asm code.

Restore the accidentally dropped code to handle "init=xxx"

This fixes a hang in change_page_attr() that occured with mem=nopentium.

Make sure a non large page kernel mapping is handled correctly.
Previously the page reference counter was handled incorrectly in this
case.

Also hardens change_page_attr against bogus addresses.  You get an
EINVAL now.

"mem=nopentium" would clear the PSE bit in boot_cpu_data, but the CPU
detection later would overwrite it again from CPUID.

The large pages would be correctly disabled, but cpu_has_pse was lying.

This patch makes sure it stays clear when the option is given.

I also took the liberty to remove these obnoxious cpu capability
printks who give no use information (the data can be either gotten
from CPUID in user space in raw form or from /proc/cpuinfo processed)

According to Intel's recommendation, 'rep;nop; should be called before
testing if the lock variable was modified (i.e. rep nop;cmp;jcc). The
current implementation does it the wrong way around: first test, then
wait, then branch. I've asked Asit Mallik from Intel, and he recommended
to change it.

It should be at least consistent: Right now, spinlock uses
'cmp;rep nop;jcc', rwlock uses 'rep nop;cmp;jcc'

into home.transmeta.com:/home/torvalds/v2.5/linux

use a #include mechanism for generic implementations of the pci_
API in terms of the dma_ one

into home.transmeta.com:/home/torvalds/v2.5/linux

into kroah.com:/home/linux/linux/BK/gregkh-2.5

This patch (originally from Sergey Vlasov) adds support for scanners
with only one bulk-in endpoint. It's needed by all the GT-6801 based
scanners like the Artec Ultima 2000 or some of the Mustek BearPaws.

This patch adds additional vendor and product ids for Nikon, Mustek,
Plustek, Genius, Epson, Canon, Umax, Hewlett-Packard, Benq, Agfa,
and Minolta scanners. The entries for Benq, Genius and Plustek
scanners have been updated.

I've also increased the version number to 0.4.9 and brought the
version numbers in scanner.c and scanner.h in sync.

 > ... usb-storage gets unhappy when
 > it decides (why?  and unsuccessfully) to reset high speed
 > devices.  ...

I don't know if that problem is resolved, but this patch
makes the question moot by handling an earlier error correctly.

The patch updates an incorrect test, so a short read will now
be treated as one.  Please merge.

This lets storage behave again.  As in, "mkfs -c" then copy
about 8 GB around, then 'dbench'.

device DMA now (see <linux/pci.h> for the compat wrapper).

add dma_ API to mirror pci_ DMA API but phrased to use struct
device instead of struct pci_dev.

See Documentation/DMA-API.txt for details

 - printk is not an acceptable substitute for errors
 - fix indentation of mtrr_close()
 - fix duplicate mtrr "release" fn pointer initializer

Patch from Christoph Hellwig <hch@lst.de>

remove unused macro MAP_ALIGN()