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

It is nice that blkdev_ioctl calls blk_ioctl itself, but unfortunately
it does that only if driver's ioctl returns -EINVAL - and IDE returns
-EIO :-(

Patch below is tested for disks - I do not have IDE floppy nor IDE tape.

of something arch-dependent and usually less. 

We may want to do value limiting in generic_fillattr() if people
end up caring.

This is the pid-max patch, the one i sent for 2.5.31 was botched.  I
have removed the 'once' debugging stupidity - now PIDs start at 0 again.
Also, for an unknown reason the previous patch missed the hunk that had
the declaration of 'DEFAULT_PID_MAX' which made it not compile ...

This contains Daniel's suggested fix that allows a parent to
PTRACE_ATTACH to a child it forked.  That fixes the incorrect BUG_ON()
assert that Ogawa's patch was intended to fix, and we thus undo Ogawa's
patch.

I've tested various ptrace uses and they appear to work just fine.

A now-happy Yopy user sent me these IDs.

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

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

We want do so on all architectures for consistency, and i386 will need
the preprocessing soon anyway.

My previous patch added procs i2c_fill_inode and i2c_dir_fill_inode that
Al Viro deemed unnecessary.  i2c developers are in contact with Al to
get the latest scoop.  Meantime lets reverse the change before he flies
off at me about procfs abuse.

Tthis one seems to have been around since 2.5.31 and nobody has fixed it
yet...

BTW, while merging aio from 2.5 to 2.4 and fixing and porting the libaio
(in particular thanks to one of Ben's testcases that was checkin for
this specific case) I found this bug in 2.5

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 home.transmeta.com:/home/torvalds/v2.5/linux

	OK, before the next bunch of gendisk merges, here comes a couple
of 2.5 IDE cleanups.

	a) exclusion between rereading partition tables and open() is done
in fs/block_dev.c these days, so homegrown one in ide.c is redundant - that
code _never_ blocks now.  Removed, just as it had been done with counterparts
in other drivers.

	b) blk_ioctl() calls are done in blkdev_ioctl() now; driver doesn't
need to handle them.  Again, removed as it had been done in all other drivers.

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.