From: Michael Hunold <hunold@linuxtv.org>

- update contributors

- documentation update for recent DVB TTUSB driver changes

From: Russell King <rmk+lkml@arm.linux.org.uk>

Russell was unable to correctly migrate this driver to the new
modem-control-signal API because

 TIOCMBIS/TIOCMBIC do not control only the DTR signal, but also the RTS,
 OUT1 and OUT2 signals, or even maybe nothing at all.  Plus, these IOCTLs
 are no longer passed down to the driver.  Instead, drivers should
 implement tiocmget and tiocmset driver methods.

so mark it as broken so as to not break allmodconfig/allyesconfig.

From: Manfred Spraul <manfred@colorfullife.com>

sendfile supports reading from a given start offset for in_file, like
pread.  But for the locks_verify_area call, in_file->f_pos is always used,
even if a start offset is used.  Result: wrong area is checked for
mandatory locks.

From: Andi Kleen <ak@muc.de>

The EFLAGS checking was not correct.  This also fixes some problems with
32bit gdb who would sometimes make the kernel BUG.

From: Chris Wright <chrisw@osdl.org>

Add default hooks for both the dummy and capability code to protect the
XATTR_SECURITY_PREFIX namespace.  These EAs were fully accessible to
unauthorized users, so a user that rebooted from an SELinux kernel to a
default kernel would leave those critical EAs unprotected.

(Acked by Stephen Smalley)

From: Chris Wright <chrisw@osdl.org>

Move the XATTR_SECURITY_PREFIX macro to the xattr.h header so that it's in a
common location.

(Acked by Stephen Smalley)

From: NeilBrown <neilb@cse.unsw.edu.au>

..to access 'mddev' from the inode pointer.  This is already set up for us.

From: NeilBrown <neilb@cse.unsw.edu.au>

We only need it occasionally to map unit number to mddev, and we can use a
linear search for that.  This reduces dependance on MAX_MD_DEVS

From: NeilBrown <neilb@cse.unsw.edu.au>

Move the pointers into mddev.  The reduces dependance on MAX_MD_DEVS.

From: NeilBrown <neilb@cse.unsw.edu.au>

Currently a raid0 superblock is only written when the array is stopped, so a
crash between creation and stop can lose your data.

This patch marks a superblock 'dirty' at creation and forces a dirty
superblock to be written when the array is started.

Previously we would prod the per-array thread at this point, but as it avoids
certain chores when the array is locked, and the array is locked at this
point, that isn't guaranteed to do the right thing.  Instead we prod the
thread whenever the array is unlocked.

Finally, only write the superblock at array stop if it is needed to mark the
array as 'clean'.  raid0 which is never dirty, doesn't need this.

From: NeilBrown <neilb@cse.unsw.edu.au>

Current code calls do_md_stop to clean up if do_md_run fails, but this is

a/ not needed as do_md_run cleans up itself

b/ bad as it could try to clean up after an -EBUSY error !!!

From: NeilBrown <neilb@cse.unsw.edu.au>

Currently if there are two failed drives, and two spares are added, then
recovery starts onto the first spare, but never notices the second spare.  To
cope, we set RECOVERY_NEEDED when recovery finishes so that we re-check.

From: NeilBrown <neilb@cse.unsw.edu.au>

Thanks dann frazier <dannf@hp.com>

From: NeilBrown <neilb@cse.unsw.edu.au>

If the raid1 or raid5 thread gets to run md_check_recovery after the recovery
thread has been interupted, but before do_md_stop completes, a spare drive
can be incorporated into an array befure it is up-to-date.

This patch corrects the relevant test.

From: NeilBrown <neilb@cse.unsw.edu.au>

raid5 rebuild takes stripes so agressively that other access cannot get a
look-in.

With this patch, the rebuild pauses slightly if there is a shortage of
stripes to let other processes have a chance.

akpm: I was worried about starvation due to the harsh semantics of yield() in
2.6.  But Neil has performed specific testing for that and things seem OK. 
If people do note CPU starvation problems we will need to replace the yield()
with a schedule_timeout(1).

From: NeilBrown <neilb@cse.unsw.edu.au>

 Following are 10 patches for md in 2.6.1-lastest.

 1-6 are simple bugfixes that I am confident should be in 2.6.2.

 7 is a bugfix that is fairly important, but could probably do with a
 bit more testing first.  It is not impossible that it could deadlock,
 though I think I have caught and fixed all the problems.

 8-10 are code simplication.

 So maybe 7-10 should only go in -mm for now, but if it is a while
 before 2.6.2, then maybe they can go in a 2.6.2-pre.

From: Mike Tran <mhtran@us.ibm.com>

 If cannot find the device, return error (ENODEV) Otherwise, return success
 (0)

From: Rusty Russell <rusty@rustcorp.com.au>

I *do* want to add a check for a truncated module, since that's probably
the most common case (^C on "make modules_install").  But I don't want to
double the size of module.c with every check I can think of.

tested with:
# bs=0; while [ $bs -lt 3764 ]; do
   dd if=dummy.ko bs=$bs count=1 2>/dev/null | insmod -;
   bs=`expr $bs + 1`;
  done

From: "H. Peter Anvin" <hpa@zytor.com>

RAID6 implementation.  See Kconfig help for usage details.

The next release of `mdadm' has raid6 userspace support.

From: Davide Libenzi <davidel@xmailserver.org>

The attached patch implements the one-shot support for epoll.  Because of
the way epoll works (hooking f_op->poll()) the ET behavior is not really ET
because it might happen that, while data is still available to read (for
the EPOLLIN case), another chunk will become available triggering another
event.

While those conditions can be easily be handled in userspace, the absolute
triviality of the patch and the avoidance of user/kernel space switches and
f_op->poll() calls, make IMHO worth doing this inside epoll itself.

From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

This patch fixes the error number when invalid file is passed (neother
S_ISBLK nor S_ISREG is true).  We should return -EINVAL.

From: Erik van Konijnenburg <ekonijn@xs4all.nl>

There are two issues here:

- absense of a MODULE_ALIAS_BLOCK in loop.c

- mismatch between the patterns used in the MODULE_ALIAS_BLOCK define and
  the modprobe invokation in request_module.

(acked by Rusty)

From: Pontus Fuchs <pontus.fuchs@tactel.se>

I need the following patch for radeonfb to work on my Asus L5.  See
http://bugs.xfree86.org/show_bug.cgi?id=561 for more info.

(benh confirmed this with ATI).

From: Stephen Rothwell <sfr@canb.auug.org.au>

This is a forward port of a 2.4 driver that has been present in a couple of
(enterprise) distributions for some time.  It works for me :-), I even get
console output :-) This makes the machine almost usable - next we will get
virtual disk.

It has been considerably tidied up, but if you have any further worries
with it, let me know.

From: David Gibson <david@gibson.dropbear.id.au>

Currently the flag indicating whether or not hugepages are allowed below
4GB is not correctly propagated across fork(), which can lead to oopses.
The patch below fixes this.

From: Stephen Rothwell <sfr@canb.auug.org.au>

This patch allows iSeries to come much closer to building.

This is a precurser to my trying to merge the virtual device drivers for
iSeries (console, disk and cdrom).

From: David Gibson <david@gibson.dropbear.id.au>

The patch below fixes a bug in ppc64's 32-bit execve() path.  It duplicates
logic already in the normal fs/exec.c do_execve() to avoid dropping a NULL
mm.  The bprm.mm becomes NULL once the exec passes the "point of no
return".  Without this patch a failure past that point (e.g.  mmap()
failure) will cause an oops, with it just a killed process.

into home.osdl.org:/home/torvalds/v2.5/linux

On Sun, 18 Jan 2004 00:37:44 -0800
Pete Zaitcev <zaitcev@redhat.com> wrote:

> My Magic Control Technology adapter causes an oops in the following way.
> Connect the thing, run "cat < /dev/ttyUSB0", disconnect, kill cat with ^C.
> The result looks like this:

I played with it a little more, and pretty much got everything working,
thus fixing two Fedora bugs.
 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112889
 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113700

This patch is needed for the USB storage subsystem to recognize the
Trumpion MP3 player as a valid USB mass storage.

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=090a ProdID=1200 Rev= 1.00
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=256mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=01 Prot=01 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=   8 Ivl=255ms

After much discussion with the SCSI folks, here's a patch to export
max_sectors as a sysfs attribute.  Turning this down makes some people's
devices more stable, but at a significant cost in performance.  Now, users
can adjust it without recompilation.

This is YAASP (yet another Alan Stern patch).

According to James Bottomley, we need to notify the SCSI midlayer whenever
we issue a driver-initiated device reset.  That can happen in several
places, most notably following a transport error.  This patch adds
code to the reset routine to take care of it.  (Notifying about resets
requested by the midlayer itself is unnecessary but harmless.)

Alan Stern

On 15 Dec 2003, James Bottomley wrote:

> It looks like the driver sent a reset to the device on its own without
> reporting it to the mid-layer.
>
> There's an expecting_cc_ua flag in the scsi_device.  It gets set on
> error recovery actions, or if the device does something to detect or
> trigger a reset (that's the scsi_report_device_reset() and
> scsi_report_bus_reset() API's).
>
> James

I've noticed in 2.6 kernels that HIDIOCGREPORT does not wait for io
completion before returning to the caller. This creates a few unpleasant
issues for userspace:

First, code sequences such as...

        ioctl(fd, HIDIOCGREPORT, &rinfo);
        ioctl(fd, HIDIOCGUSAGE, &uinfo);
        ioctl(fd, HIDIOCGSTRING, &sdesc);

...that used to work in 2.4 now fail in 2.6 if the device takes more
than a few milliseconds to respond to HIDIOCGREPORT. (I'm seeing this
issue on APC UPSes, FWIW.)

Second, userspace code can easily flood the kernel with control messages
since the kernel provides no "backpressure". The result is a lot of
"hid-core.c: control queue full" errors and lost reports.

2.6 hid-core.c appears to submit the request and return immediately.
Although the 2.4 code differs significantly, I traced the call path to
usb-core.c, which seems to block with a timeout, so the code supports my
userspace observation. (Assuming I didn't misread it.)

into home.osdl.org:/home/torvalds/v2.5/linux

Patch from Frank Becker

Crud removal. Updated cerf doc.

The SA CerfPDA/CerfPOD have long been gone. I see no
community activity. The last official release was 2.4.9.

Removed ifdefs for CERF_CPLD (which referred to the PDA/POD), go figure.
Removed keyboard driver.
Removed default configs for PDA/POD.
Removed PDA/POD related LCD stuff.

Patch from Nicolas Pitre

Patch from Tony Lindgren

Following patch adds ARM710T processor support to proc-arm720.S.

The preferred way to add support was discussed on the Linux-arm-kernel
mailing list in December, with a link to the thread here:

http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2003-October/017596.html

NEC ARM710T is used in Psion Windermere architecture, and possibly
other systems.

710T works fine with the 720T functions, except the high_mapping
does not work for vectors_base(). Even if the high bit register is
set, the vectors stay at 0x00000000 instead of 0xffff0000.

Patch from Peter Teichmann

This adds German Umlauts (ÄÖÜäöüß) and some other Characters to the
Acorn 8x8 console font.