Ronald Bultje [Wed, 20 Aug 2003 07:30:34 +0000 (00:30 -0700)]
[PATCH] Big zoran driver update
This is a patch for the video4linux unified zoran driver that has been
in the kernel since 2.4.5 or so.
It fixes the compile issues in the current 2.6.0-test3 unified zoran
driver (current one doesn't compile at all), and also updates its
version to what we have in CVS. This adds support for new cards (e.g.
LML33R10 from LinuxMediaLabs and DC30+ from Pinnacle), fixes bugs in
cards that were already supported and generally improves capture
reliability. Changes per file (in detail) are given below.
i2c-id.h:
add some new IDs for new i2c drivers
pci_ids.h:
add PCI IDs for each of the supported cards if it has any
saa7111.c, saa7110.c, adv7175.c, bt819.c, saa7185.c, bt856.c:
update to whatever we've got in our CVS. For most, these are just
"easiness" fixes that either add some better debug output, or that make
maintainance for both 2.6.x and 2.4.x simpler for me. There's also some
specific changes. E.g., in saa7110.c, we enable the VCR mode bits so we
get a better image from VCR input. In all of them, we make debugging an
insmod option rather than a compile-time option (this makes debugging
for users a *lot* easier). Point is that I just want our latest CVS in
here. Maintainance is going to be a personal horror-story if it's not.
vpx3220.c, saa7114.c, adv7170.c:
new i2c ones (for respectively DC10/DC30, LML33R10 and again LML33R10)
zr36067.c:
removed, the driver is now spread over multiple source files.
zoran*.[ch], zr36057.h
spread-out source files. Also fixes lots of bugs, can't even start
naming them all, you don't want that, neither do I. Just assume that it
works better than it used to - it does.
Nice things that aren't in the old driver: much more stable, supports
DC30+, supports LML33R10, has proper locking/semaphores, supports
multiple opens without races now, adapted to new i2c subsystem, v4l2
support, Xv (hardware-scaled) overlay support, and a lot more.
Oh, and this one actually compiles.
videocodec.[ch], zr360{16,50,60}.[ch]:
new sublayer for the driver to unify how we handle the zr36060 chip
(DC10(+)/LML33/LML33R10/Buz) and the zr36050/zr36016 (DC30(+)).
MAINTAINERS:
add me as maintainer (I am).
Kconfig:
add new cards, plus improve the descriptions.
Makefile:
d'oh.
Zoran:
documentation update.
Others:
I don't think there are any.
Greg has gone over the i2c changes a long time ago, he agreed on all of
them. Gerd is supposed to take care of the v4l part, he has never
complained about any of them. Stability is good, we've fixed most issues
(there's still some out there, but nothing serious), lots better than in
the old driver. Also, the cards work much better than with the old
driver.
Albert Cahalan [Wed, 20 Aug 2003 04:53:41 +0000 (21:53 -0700)]
[PATCH] IO port bitmap cleanups, x86-64 oops fix
This patch brings x86-64 and i386 closer together, eliminating an oops
that LTP test ioperm02.c causes on x86-64. An IO port permission bitmap
must be followed by an extra 0xff.
(Add comments to that effect, to avoid the problem in the future).
Trond Myklebust [Wed, 20 Aug 2003 04:35:45 +0000 (21:35 -0700)]
[PATCH] Support dentry revalidation under open(".")
link_path_walk() currently treats the special filenames ".", ".."
and "/" differently in that it does not call down to the filesystem in
order to revalidate the cached dentry, but just assumes that it is
fine.
For most filesystems this is OK, but it the case of the stateless
NFS, this means that it circumvents path staleness detection, and the
attribute+data cache revalidation code on such common commands as
opendir(".").
This change provides a way to do such revalidation for NFS without
impacting other filesystems.
Note: the failure to revalidate the path here does not result in a
call to d_invalidate() unlike (all?) other calls to d_revalidate(). It
only results in an ESTALE error being returned to the caller.
- set owner field on tty ldisc
- allocate network device objects with alloc_netdev
- use list_head macros and put locking around list of devices
- convert to seq_file for /proc
- use change_mtu hook rather than guessing at mtu changes
When doing the audit for this change, it was obvious that several drivers
allocate but never free the net_device.
This fixes these drivers. This patch is riskier than the earlier
ones, because it isn't just a simple substitution and maybe there
is a reason they never free.
[NET]: free_netdev - free network device on last class_device_usage
This patch adds the free_netdev function and associated
changes so that net_device structures are not freed until
last reference to the network device class is released.
Russell King [Tue, 19 Aug 2003 20:46:33 +0000 (21:46 +0100)]
[ARM] Remove redundant CONFIG_DEBUG_INFO.
ARM had CONFIG_DEBUG_INFO for ages. Unfortunately, the new
CONFIG_DEBUG_INFO was rather blindly applied across all architectures.
This removes the duplication from the ARM architecture.
Simon Evans [Tue, 19 Aug 2003 04:08:44 +0000 (21:08 -0700)]
[PATCH] blkmtd for 2.6
This updates the blkmtd driver with the latest which has been in the MTD
CVS for quite a while. It is a rewrite from the 2.4 version to work
with the new block layer changes.
Arnd Bergmann [Tue, 19 Aug 2003 03:33:51 +0000 (20:33 -0700)]
[PATCH] correct local_dec on some architectures
A small bug in local.h apparently got copied a few times.
I noticed this because I copied the same bug to s390.
This patch should fix the occurrences in BK, but there
are others that are not merged yet, e.g. ppc64 in -mm3.
Adam Belay [Tue, 19 Aug 2003 03:14:46 +0000 (20:14 -0700)]
[PATCH] Fix awe PnP probing
This is a rewrite of the awe_wave detection code that will allow this
driver to be compiled. It moves detection functions to a common
location at the end of the file and makes the code driver-model
compatible. Also it fixes a bug in which the driver could possibly
write to incorrect ports when using isapnp cards.
Unfortunantly I do not currently have an AWE32 to test these changes so
I could only check for compilation and driver registration.
Andi Kleen [Tue, 19 Aug 2003 03:06:09 +0000 (20:06 -0700)]
[PATCH] Fix ugly hole in x86-64 interrupt gates
There was a quite nasty long standing bug in the x86-64 port. The
interrupt gates had a DPL of 3, allowing user space to trigger any
interrupt. I have not found a way to exploit it this to crash the
kernel, but it definitely shouldn't happen. It could e.g. cause
problems with drivers that do not handle shared interrupt properly.
This also broke some programs who assumed that int <random number>
causes a signal.
Linus Torvalds [Tue, 19 Aug 2003 03:02:21 +0000 (20:02 -0700)]
The default ARCH_SI_BAND_T should be "int", since that is what
Linux historically has had. Only x86-64 uses anything else, so
make the special case be _there_.
Marc Zyngier [Tue, 19 Aug 2003 02:34:16 +0000 (19:34 -0700)]
[PATCH] EISA bus update
- Don't leave resource name uninitialized if CONFIG_EISA_NAME is not set.
- Print root device bus_id (so we know which bridge is probed).
- From Zwane Mwaikambo : Add a release method to virtual root, so it
stays quiet if probing fails (because some pci-eisa bridge have been
found before).
Andrew Morton [Tue, 19 Aug 2003 01:34:11 +0000 (18:34 -0700)]
[PATCH] loop: fix module unload oops
From: Peter Osterlund <petero2@telia.com>
It oopses on module unload in the kobject layer due to misordered destruction
of things.
And we need to initialise the unplug timer in blk_alloc_queue(), because we
kill that timer in blk_alloc_queue()'s companion function,
blk_cleanup_queue().
Andrew Morton [Tue, 19 Aug 2003 01:33:30 +0000 (18:33 -0700)]
[PATCH] Fix SELinux avc_log_lock
From: Stephen Smalley <sds@epoch.ncsc.mil>
This patch fixes a bug in the SELinux access vector cache code, which was
incorrectly using spin_lock_irq rather than spin_lock_irqsave for the
avc_log_lock. As this code can be called from hardirq (e.g. from the
file_send_sigiotask hook), we need irqsave/restore here.
Currently, a writepage() which detects that it is writing outside i_size (due
to concurrent truncate) will abandon the write, returning -EIO.
The return value will bogusly cause an error to be recorded in the
address_space. So convert all those writepage() instances to return zero in
this case.
Andrew Morton [Tue, 19 Aug 2003 01:32:46 +0000 (18:32 -0700)]
[PATCH] async write errors: report truncate and io errors on
From: Oliver Xymoron <oxymoron@waste.org>
These patches add the infrastructure for reporting asynchronous write errors
to block devices to userspace. Error which are detected due to pdflush or VM
writeout are reported at the next fsync, fdatasync, or msync on the given
file, and on close if the error occurs in time.
We do this by propagating any errors into page->mapping->error when they are
detected. In fsync(), msync(), fdatasync() and close() we return that error
and zero it out.
The Open Group say close() _may_ fail if an I/O error occurred while reading
from or writing to the file system. Well, in this implementation close() can
return -EIO or -ENOSPC. And in that case it will succeed, not fail - perhaps
that is what they meant.
There are three patches in this series and testing has only been performed
with all three applied.