This was suggested by many people, Randy Dunlap being the most vocal :)

Thanks to Dave Jones for pointing this out.

Thanks to Dave Jones for pointing this out.

Thanks to Dave Jones for pointing this out.

This patch removes the (often troublesome) usb_stor_transfer_length()
function.

We've finally gotten all the command initiators to send the correct values
in the srb->request_bufflen field, so this is no longer needed.

There are probably some sanity checks that can also be removed now, but
that's for a later patch.

I wrote this a while back, finally debugged it.  This covers
some functionality that 2.5 newly demands of all HCDs:  control
requests can be queued.  (Example:  a user mode driver can talk
on one interface, and a kernel mode one can talk on another,
no need to handshake about who can make control requests.)

The good news is that all the HCDs seem (light testing) to do
the right things ... until some of the requests (intentionally)
trigger routine faults (like protocol stalls) which the HCDs
need to recover from.  At that point, uhci-hcd started acting
confused (it's got newish queueing code); details will come
separately.  The other two HCDs acted fine.  I had expected more
trouble there, maybe it'll show up later on.

OK here's the version that without the kernel version #ifdef
that helped the backport ... it fixes the build by restoring
the "debug support only if CONFIG_USB_DEBUG" semantics.

this is the 2.5 version of the 2.4 fix
  - proper freeing of skbs

this diff is agains the latest linux-2.5;
set mac address at dev->open()
(as per Jeff Garzik :-)

Same as the previous email, just against latest linux-2.5 tree.  Sorry
about the diffs - i can't sync with usb-2.5.

More Zaurii.  That model will be interesting from the
perspective of "usb gadget drivers", lots of flexible
endpoints are available.

These don't affect the hang I'm hunting for, but paranoia
argues the patch is better integrated than not:

- prevent resubmit-from-completion looping in_irq if the
   transfers complete really fast.  (likely never seen, but...)

- grab ehci lock before reading irq status; should be harmless
   except in one host error cleanup-after-death

Various archs (i386, m68k, s390, s390x, m68k, parisc, um, x86_64)
implement kernel_text_address.  Put this in kernel/extable.c, and the
module iteration inside module.c.

Other than cleanliness, this finally allows the module list and lock
to be static to kernel/module.c (you didn't think I actually cared
about those archs did you?)

It also drops the module->init_size to zero when it's discarded, so
bounds checking is simplified (and the /proc/modules size statistic
will be more accurate, too).

The declaration of `module_frob_arch_sections' in moduleloader.h (and
the definitions in most of the module.c files) are inconsistent with the
definition in the PPC's module.c -- in the latter the first two
arguments are not declared `const', whereas everyplace else they are.

PS.  secstrings can be modded to: if an arch can't handle discarding
     init, it simply renames the .init sections.

Oops in fb_set_cmap caused by palette_cmap.transp uninitialized.

By inspection, fb_blank appears to have the same problem.

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

This removes the agpgart assumption that memory is contiguous.

[Forward port of a 2.4 patch that got applied last month -- DJ] 
 
AGP/DRM currently assume that GATT entries can be converted
to physical addresses with a simple mask.  Additionally, agpgart
assumes in a couple places that the mask is ~0xfff, i.e., that
all the GART control bits are in the low 12 bits.  Both assumptions
are bogus, so:
  
Make agp_memory.memory[] (exported from agpgart to DRM) contain physical
addresses, not GATT entries.
  
DRM assumes agp_memory contains GATT entries, and it converts them to
physical addresses with "paddr = agp_memory.memory[i] & mask".  460GX
requires both a shift and a mask, so exporting plain physical addresses
and a mask of ~0UL allows agpgart to add 460GX support without requiring
DRM interface changes.

- global loops_per_jiffy, x86 cpu_khz and x86
   fast_gettimeoffset_quotient can only be safely adjusted on UP
- x86 per-CPU loops_per_jiffy does not depend on TSC
- save reference values so that rounding errors do not accumulate

Clean up searching code for best frequency multiplier, and add a
safety check. Also, SAFE_FREQ wasn't used.

The "get current speed" algorithm wasn't aware of the disable/enable bit,
and the policy verification function wasn't aware of the N44 / O17
bug. Also, some unused code is removed.

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

into kernel.bkbits.net:/home/davem/net-2.5

into kernel.bkbits.net:/home/davem/sparc-2.5

1. All the memory barriers are SMP-only avoiding unnecessary overhead on UP.
2, My forward porting merge of the rt_rcu patch dropped two changes in
   rt_intern_hash() in around 2.5.43 that ordered the writes while
   inserting a dst entry at the start of a hash chain. The dst entry updates
   must be visible to other (weakly ordered) CPUs before it is inserted.
   The necessary smp_wmb()s are added.
3. Comments to go with the write ordering.

into tetrachloride.(none):/mnt/stuff/kernel/2.5/agpgart