this is the two byte offset patch to kaweth for 2.5
to prevent MIPS crashing and speed up other arches.

I have a USB 5-in-1 Card Reader, that will read CF and SM and SD/MMC.
Under Linux it appears as three SCSI devices.
For today, the report is on the CF part.

The CF part works fine under ordinary usb-storage SCSI simulation,
with one small problem: 8 and 32 MB cards, that are detected as
having 15872 and 63488 sectors by other readers, are detected as
having 15873 and 63489 sectors by this Feiya reader
(0x090c / 0x1132).
In the good old days probably nobody would have noticed, but these
days the partition reading code also wants to read the last sector.
This results in the SCSI code taking the device off line:

[USB storage does a READ_10, which fails since the sector is past
the end of the disk. Then it tries a READ_6 and nothing ever happens,
probably because the device does not support READ_6. Then the
error handler does an abort which triggers some bugs in scsiglue.c
and transport.c, then the error handler does a device reset, then
a host reset, then a bus reset, and finally the device is taken offline.]

The patch below does not address any bugs in the SCSI error code
(a big improvement would be just to rip it all out - this error code
never achieves anything useful but has crashed many a machine)
and does not fix the USB code either.
It just adds a flag to the unusual_devices section mentioning that
this device (my revision is 1.00) has this bug.

Without the patch the kernel crashes, or insmod usb-storage hangs.
With the patch the CF part of the device works perfectly.

(Another change is to only print "Fixing INQUIRY data" when
really something is changed, not when the data was OK already.)

Andries

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

Thanks to David Brownell for pointing out the problem here.

This patch appears not to be in 2.5.32, but applies cleanly.

The following patch fixes 3 problems in USB:

1. Don't pci_map buffers when we know we're not going to pass them
   to a device.

   This was first noticed on ARM (no surprises here); the root hub
   code, rh_call_control(), placed data into the buffer and then
   called usb_hcd_giveback_urb().  This function called
   pci_unmap_single() on this region which promptly destroyed the
   data that rh_call_control() had placed there.  This lead to a
   corrupted device descriptor and the "too many configurations"
   message.

2. If controller->hcca is NULL, don't try to dereference it.

3. If we free the root hub (in ohci-hcd.c or uhci-hcd.c), don't
   leave a dangling pointer around to trip us up in usb_disconnect().
   EHCI appears to get this right.

if a new edge happened while we were still processing the previous
one.

Then, if a _third_ edge came in, it would actually cause a reentrant
irq handler invocation, because the original INPROGRESS bit was now
lost.

This was actually seen on IDE in PIO mode.

Thanks to Rusty "trivial" Russell

Unify the PCI device ID constants used by AGP with the normal Linux ones.

create_elf_tables in fs/binfmt_elf.c now sets up the list of aux table
entries in a buffer on the kernel stack before copying it to the user
stack.

Unfortunately, while the buffer is big enough for most architectures, it
isn't big enough on PPC, which uses 5 extra aux table entries (put on
with ARCH_DLINFO).  The following patch increases the buffer to be big
enough for PPC.  (Note that each aux table entry uses two elements of
the elf_info array.)

to the bottom of the aux table.

into au1.ibm.com:/fuego/paulus/kernel/for-linus-ppc

  one more adapter, changed company name and forgotten flag

This patch cleans up some messy parts of this driver, and
was pleasantly painless.

      - gets rid of ED dma hashtables
         * less memory needed
         * also less (+faster) code
         * ... rewrites all ED scheduling ops, they now use
           cpu addresses, like EHCI and UHCI do already

      - simplifies ED scheduling (no dma hashtables)
         * control and bulk lists are now doubly linked
         * periodic tree still singly linked; driver uses a
           new CPU view "shadow" of the hardware framelist
         * previous periodic code was cryptic, almost read-only
         * simpler tree code for EDs with {branch,period}

      - bugfixes periodic scheduling
         * when CONFIG_USB_BANDWIDTH, checks per-frame load
           against the limit; no more dodgey accounting
         * handles iso period != 1; interrupt and iso schedule
           EDs with the same routine (HW sees special TDs)
         * credit usbfs with bandwidth for endpoints, not URBs

      - adds driverfs output (when CONFIG_USB_DEBUG)
         * resembles EHCI:  'async' (control+bulk) and
           'periodic' (interrupt+iso) files show schedules
         * shows only queue heads (EDs) just now (*)

      - has minor text and code cleanups, etc

Now that this logic has morphed into more comprehensible
form, I know what to borrow into the EHCI code!


     (*) It shows TDs on the td_list, but this patch won't
         put them there.  A queue fault handling update will.

This patch fixes the recently broken software eject of media.  At least, it
should.  I'm back to having compile problems again, but the fix should
be pretty self-evident.

 * keep watchdog on shorter leash, and just do
   standard irq processing when it barks.  this
   means I can use a somewhat iffy vt8235 mobo.

 * updates to the driverfs debug output, including
   using S_IRUGO so anyone can gawk.

 * some updates, mostly to use a new hcd_to_bus(),
   so this version also compiles on a (slightly
   patched) 2.4.20-pre5 kernel.  (*)

I've been chasing problems on a KT333 based system, with
the 8253 southbridge and EHCI 1.0 (!), and this fixes at
least some of them:

   - locking updates:
      * a few routines weren't protected right
      * less irqsave thrashing for schedule lock

   - adds a watchdog timer that should fire when the
     STS_IAA interrupt seems to be missing.

   - gives ports back to companion UHCI/OHCI on rmmod

   - re-enables faulted QH only after all its completion
     callbacks have done their work

   - removes an oops I've seen when usb-storage unlinks
     stuff.  (it seemed confused about error handling, but
     that's not a reason to oops.)

   - minor cleanup:  deadcode rm, etc

Right now the watchdog just barks, and that mechanism might
go away (or into the shared hcd code).  Sometimes the issue
it reports seems to clear up by itself, but sometimes not...

Two weeks ago I sent this patch to the listed USB storage maintainer
(mdharm-usb@one-eyed-alien.net) and have not yet heard back. The
attached patch adds support for the Lexar USB CF Reader identified by
id_product 0xb002, version 0x0113 (which is the version I have). This
patch is against the 2.4.19 kernel, sorry if this is the wrong address
to send this stuff to. Thanks.

The trace at the end of the message shows the init failure.

This patch has some small UHCI bugfixes

   - on submit error, frees memory and (!) returns error code
   - root hub should disconnect only once
   - pci pool code shouldn't be given GFP_DMA
   - uses del_timer_sync(), which behaves on SMP, not del_timer()

and cleanups:

   - use container_of
   - doesn't replicate so much hcd state
   - no such status -ECONNABORTED
   - uses bus_name in procfs, not "hc0", "hc1" etc

Another UHCI patch.  I'm sending this since Dan said he was going to
start teaching "uhci-hcd" how to do control and interrupt queueing,
and this may help.  Granted it checks out (I didn't test the part
that has a chance to break, though it "looks right"), I think it
should get merged in at some point.  What it does:

   - updates and adds some comments/docs
   - gets rid of a "magic number" calling convention, instead passing
     an explicit flag UHCI_PTR_DEPTH or UHCI_PTR_BREADTH (self-doc :)
   - deletes bits of unused/dead code
   - updates the append-to-qh code:
       * start using list_for_each() ... clearer than handcrafted
         loops, and it prefetches too.  Lots of places should get
         updated to do this, IMO.
       * re-orders some stuff to fix a sequencing problem
       * adds ascii-art to show how the urb queueing is done
         (based on some email Johannes sent me recently)

That sequencing problem is that when splicing a QH between A and B,
it currently splices A-->QH before QH-->B ... so that if the HC is
looking at that chunk of schedule at that time, everything starting
at B will be ignored during the rest of that frame.  (Since the QH
is initted to have UHCI_PTR_TERM next, stopping the schedule scan.)

I said "problem" not "bug" since in the current code it would probably
(what does that "PIIX bug" do??) just reduce control/bulk throughput.
That's because the logic is only appending towards the  end of each
frame's schedule, where the FSBR loopback kicks in.

This removes list_t, which is a gratuitous typedef for a "struct
list_head".  Unless there is good reason, the kernel doesn't usually
typedef, as typedefs cannot be predeclared unlike structs.

Frankly, I'm amazed the kernel worked for long without this.

Every linker script thinks the section is called .data.percpu.
Without this patch, every CPU ends up sharing the same "per-cpu"
variable.

This might explain the wierd per-cpu problem reports from Andrew and
Dave, and also that nagging feeling that I'm an idiot...

 This makes daemonize() call reparent_to_init() itself, as long
suggested for 2.5, and fixes the callers so they don't call it again.
Also fixes callers which set current->tty to NULL themselves (also
no longer neccessary).

This sets child_reaper to the idle thread upon creation, so that
ksoftirqd's reparent_to_init call doesn't get the swapper as parent.

RELOC_HIDE got miscompiled on gcc3.1/x86-64 in the access to softirq.c's per
cpu variables.  This fixes the problem.

Clearly to hide the relocation the addition needs to be done after the
value obfuscation, not before.

I don't know if it triggers on other architectures (x86-64 is especially
stressf here because it has negative kernel addresses), but seems like the
right thing to do.

Teach usb/storage/sddr09.c how to return less than a full page of sense
data.

In sd.c we call MODE SENSE (6) in order to find out whether the
device is write protected. The info we need is in byte 2, the
header of the MODE SENSE answer, but in the request we have to
specify (i) what page(s) we want, and (ii) how many bytes we want.

Long ago we asked for 12 bytes from page 1 (Daniel Roche, 1.3.35).
Matthew Dharm made this 8 bytes from page 3F (all pages), patch-2.4.0-test8.
In patch-2.4.10 the 8 was increased to 255.

I found on the one hand devices that only react to page 0
(the vendor page), and return an error for page 3F.
And on the other hand devices that are unable to handle requests
for more bytes than they actually have.

So, it seems that the cautious way to ask for MODE SENSE data is
to first ask for the header only, see how much is available,
and then ask for everything.

The patch below first separates out the MODE SENSE call,
and then tries it three times: on all pages (3F), only the first
four bytes; on the vendor page (0), only the first four bytes;
on all pages (3F), 255 bytes.

This should be at least as robust as our current code.
I tried it on 8 SCSI devices (of which 2 fail under 2.5.33)
and found no problems.

A patch from Martin Bligh which cleans up the open-coded uses of
mem_map for ia32.  Basically it replaces

mem_map + pagenr

with

pfn_to_page(pagenr)

in lots of places.  Because mem_map[] doesn't work like that with
discontigmem.

It also fixes a bug in bad_range, that happens to work for contig mem
systems, but is incorrect.  Tested both with and without discontigmem
support.

 - All the support macros which assume a linear mem_map[] have been
   wrapped in !CONFIG_DISCONTIGMEM.  pfn_to_page, page_to_pfn,
   page_to_phys, pmd_page, kern_addr_valid.

 - Move some initialsation macros into setup.h so they can be used in
   the i386 discontig.c (INITRD_START, INITRD_SIZE).

 - Alternate version of the bootmem allocator

 - add i386 discontig support and numaq support.

 - Pull the middle out of one_highpage_init() so that the i386 NUMA
   patch can call it on a per-page basis.

 - Move a few lines out of mem_init() into the new
   set_max_mapnr_init(), which the i386 NUMA code requires.