Sean Young [Fri, 28 May 2004 23:59:46 +0000 (01:59 +0200)]
[WATCHDOG] v2.6.6 sc520_wdt.c-patch2
This patch also removes the cbar usage which is unnecessary. The MMCR is
always available at 0xfffef000; there is no need to use the cbar register
(if mmcr aliasing is enabled, then the MMCR is _also_ available at
another address set by CBAR).
Wim Van Sebroeck [Fri, 28 May 2004 23:46:05 +0000 (01:46 +0200)]
[WATCHDOG] v2.6.6 sc520_wdt.c-patch1
Clean-up (general stuff: comments, keep module parameters together, ...)
Added clear definitions for the Watchdog Timer Control Register bits
Made start, stop and keepalive return 0 if successful
Fixed nowayout behaviour so that it is consistent with other watchdog drivers
Fixed release behaviour so that it is consistent with other watchdog drivers
Added wdt_set_heartbeat function to set the timeout/heartbeat of the watchdog
Made sure that memory remapping (wdtmrctl) is done before misc_register is started
MMCR_BASE_DEFAULT was wrong (Bug 2497 reported by Sean Young)
Alexey Fisher [Fri, 28 May 2004 06:48:49 +0000 (23:48 -0700)]
[PATCH] I2C: add max1619 driver
This is a driver for "Remote/Local Temperature Sensor with Dual-Alarm Outputs
and SMBus Serial Interface" MAX1619. I found this chip an my Laptop SAMSUNG
NV5000. Daryng I use Linux cooling didn't worked at all, naw with this
driwer it's working. I hope this will be usefool for ather too.
I didn't hade any expiriens with programming, but i didn't wont to wait wann
some body make it vor me. Jean halped me correrct any mysteiks wich i made.
Thanks Jaen :)
Jean Delvare [Fri, 28 May 2004 06:47:51 +0000 (23:47 -0700)]
[PATCH] I2C: i2c-parport: support the ADM1031 evaluation board
The following patch adds support for the ADM1030 and ADM1031 evaluation
boards to the i2c-parport and i2c-parport-light drivers. They are almost
compatible with the already supported ADM1025 and ADM1032 boards, except
that the ADM1032 board needs some pins to be set high to draw its power,
while the same pins power up heating resistors on the ADM1031 board. I
considered it was a bit dangerous to do that by default, so I ended up
with two different device definitions, one with powering pins set, and
one with these pins cleared.
Luiz Capitulino [Fri, 28 May 2004 06:37:08 +0000 (23:37 -0700)]
[PATCH] PCI: fix pci/probe.c possible NULL pointer.
In drivers/pci/probe.c::pci_scan_bridge() the call for pci_alloc_child_bus()
can return NULL, but it is not handled by the function (detected by
Coverity's checker).
The patch bellow fix that returning `max' if we got the NULL, but
I do not know if it is right. I guess it is, because in that case
the function will act in the same way as with `pass != 0'.
Todd Rimmer [Fri, 28 May 2004 06:36:07 +0000 (23:36 -0700)]
[PATCH] PCI: Add InfiniCon PCI ID to pci_ids.h
We would like to have the InfiniCon PCI Vendor ID added to pci_ids.h
Below is a context diff, which would would greatly appreciate if you
applied and included in future kernel releases.
Ian Abbott [Fri, 28 May 2004 06:28:41 +0000 (23:28 -0700)]
[PATCH] USB: ftdi_sio throttling fix
This patch fixes throttling problems in the ftdi_sio driver for the
2.6 kernel. The old throttling mechanism (unlinking the read urb)
often failed to work, and even it did work, would lose any data
held in the transfer buffer. The new mechanism presented here is
based on what the whitehead driver does (defer processing and
resubmitting of the read urb until unthrottled).
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Alan Stern [Fri, 28 May 2004 06:28:14 +0000 (23:28 -0700)]
[PATCH] USB: Use normal return codes for several routines in hub.c
This patch changes the return codes used by hub_port_wait_reset(),
hub_port_reset(), and hub_port_debounce() in hub.c. I couldn't stand the
{-1=error, 0=okay, 1=disconnect} scheme; the meanings seemed arbitrary and
I constantly forgot which number stood for what status. The revised code
uses normal negative error codes, including -ENOTCONN to indicate device
disconnected, or 0 for success.
Todd Poynor [Fri, 28 May 2004 06:13:30 +0000 (23:13 -0700)]
[PATCH] Fix for leave-runtime-suspended-devices-off-at-system-resume.patch
A patch to fix my previous
leave-runtime-suspended-devices-off-at-system-resume patch; the new
changes save a copy of power.power_state in order to know whether to
resume a device, independently of mods to that field by a driver suspend
routine. This fixes 2.6.7-rc1-mm1 in the same fashion as the updated
2.6.6 patch sent previously.
Todd Poynor [Fri, 28 May 2004 03:04:44 +0000 (20:04 -0700)]
[PATCH] Leave runtime suspended devices off at system resume
Currently all devices are resumed at system resume time, including any
that were individually powered off ("at runtime") prior to the system
suspend. In certain cases it can be nice to force back on individually
suspended devices, such as the display, but hopefully this policy can be
left up to userspace power managers; the kernel should probably honor
the settings previously made by userspace/drivers. This seems
preferable to requiring a power-conscious system to re-suspend devices
after a system resume; furthermore, for certain platforms (such as
XScale PXA27X) there can be disastrous consequences of powering up
devices when the system is in a state incompatible with operation of the
device.
Suggested patch does this:
(1) At system resume, checks power_state to see if the device was
suspended prior to system suspend, and skips powering on the device if
so.
(2) Does not re-suspend an already-suspended device at system suspend
(using a different method than is currently employed, which reorders the
list, see #3).
(3) Preserves the active/off device list order despite the above changes
to suspend/resume behavior, to avoid dependency problems that tend to
occur when the list is reordered.
Todd Poynor [Fri, 28 May 2004 03:04:18 +0000 (20:04 -0700)]
[PATCH] Device runtime suspend/resume fixes
(1) Set device power state at runtime resume (as is done for runtime
suspend) so that a later suspend does not think the device is still
suspended (refusing to suspend it again).
(2) Move devices from the active list to the off list only when
suspending all devices as part of a system suspend, not for runtime
suspend. This matches the resume code, which only moves devices from
off to active during system resume, such that runtime resume currently
doesn't move the suspended device back to the active list. (This also
avoids reordering the device list for runtime suspends; the list is in
order of registration and suspend/resume works best that way -- granted,
more sweeping improvements in how device dependencies are accounted for
in the suspend/resume order are also needed someday.)
Runtime device suspend/resume is in some cases used frequently on
battery-powered embedded devices, to save additional power and to handle
device power state interactions with overall system power state on
certain platforms.
[PATCH] ppc32: Fix typo in USB sleep code on intrepid based laptops
This fixes a typo in the low level platform code that puts to sleep and
wakes up the USB cell. This fixes a problem when pmdisk is used on
those machines (pmdisk patch not merged yet, soon maybe...)
Jeff Garzik [Thu, 27 May 2004 12:22:20 +0000 (08:22 -0400)]
[netdrvr ixgb] massive update
Since Intel agreed to submit further updates via broken-up patches
like they do currently (and admirably) for e1000 and e100, I agreed
to merge this update to bring the driver up to speed.
Contributed by: Ayyappan.Veeraiyan@intel.com
Changes:
Features implemented
* Support for new 850nm adapters.
* Copyright notice updated to include year 2004.
* Fix for "ixgb does not maintain non-default MTU setting across a
link loss" issue - When link loss happens in non-default MTU
environment, driver will incorrectly operate with default 1500 MTU
setting.
* Netpoll support added
* Ethtool support - status functionality, FlowControl interface,
Checksum interface, TSO and Scatter Gather interfaces
* Race condition fix - Race condition (TX path) exists between
ixgb_xmit_frame and clean_tx_irq routines in handling the queue.
* Removed dead code segments (#if 0)
Performance improvement features
* Mod operator usage is removed - used to cause performance
problems in non-IA architecture based machines
* Multiple ICR register read in ISR is avoided
* RS bit set on only 'end of packet' TX descriptors - to avoid
multiple writebacks by controller for packets with multiple descriptors.
* RX descriptors prefetch is done - improved 1500 MTU TX
performance
All relevant e1000 driver cleanups ported to ixgb
* Valid error propagation in functions ixgb_up, ixgb_probe,
ixgb_open.
* NAPI code cleanups
* u8, u16 and u32 data types are changed to uint8_t, uint16_t and
uint32_t respectively. We use these types on our shared code for
multiple OSes and also to make it uniform with e1000 driver.
* Some functions in ixgb_main.c are moved to different location -
This enables easy porting of e1000 bug fixes to ixgb
Andrew Morton [Thu, 27 May 2004 11:33:27 +0000 (07:33 -0400)]
[PATCH] net/sk98lin: correct buggy VPD in ASUS MB
From: Jeff Lightfoot <jeffml@pobox.com>
The following patch to net/sk98lin/skvpd.c was put together by Marc Bouget,
mbouget at club-internet.fr.
This patch works around a corrupt EEPROM (VPD?) in the ASUS K8V Deluxe SE
motherboard ethernet chipset and allows the network driver to work
correctly. We have written to ASUS and the sk98lin maintainers but have
not heard anything back.
Roger Luethi [Thu, 27 May 2004 11:07:51 +0000 (07:07 -0400)]
[PATCH] via-rhine: Whitespace clean-up
- Switch to 8 char tabs.
- Remove kernel log pointer to the scyld web site -- it's
a) fairly irrelevant by now and
b) gone.
- Remove Emacs Voodoo.
- More white space clean up, mostly coding style.
Roger Luethi [Thu, 27 May 2004 11:07:33 +0000 (07:07 -0400)]
[PATCH] via-rhine: Fix force media
Lucas Nussbaum and Dirk Koeppen each found independently that the code
for forcing media options in via-rhine is borked and suggested the fix
below. I've been sitting on this way too long because there is more
badness in the immediate vicinity which needs a bigger surgery.
The second hunk fixes a braino I managed to introduce myself.
Don Fry [Thu, 27 May 2004 10:07:05 +0000 (06:07 -0400)]
[PATCH] pcnet32: fix for patch 8 le16_to_cpu
Joe Perches pointed out an error in patch 8. As I looked at the results
closer 3 out of 4 looked correct. This fixes the output for the last
case. Output is now the same on IA32 and PPC64 hardware.
Stefan Rompf [Thu, 27 May 2004 09:51:22 +0000 (05:51 -0400)]
[netdrvr b44] always restore PCI config on resume
the Broadcom BCM4401 driver restores pci configuration on resume only when the
device is up. On my notebook, this leads to a failure when the device is down
during the S3 cycle. Short solution for now: Always restore pci config.
Kevin Curtis [Thu, 27 May 2004 09:24:17 +0000 (05:24 -0400)]
[netdrvr wan] farsync driver update
1) Provides support for new FarSync cards T1U, T2U, T4U and TE1
2) Provides support for an E1 interface
3) Provides support for a variant of X.21 that allows transmit and
receive clocks
4) Provide a raw socket interface directly to the data from the line.
5) Improves performance with less time in interrupts and more in BH's
Don Fry [Thu, 27 May 2004 09:12:31 +0000 (05:12 -0400)]
[PATCH] pcnet32: avoid timeout with tcpdump
This patch avoids a timeout when entering/exiting promiscuous mode with
tcpdump. All pending xmit operations are flushed and if the queue is
full the timeout will occur. The wake_queue avoids that timeout.
Tested ppc64 and ia32.
Don Fry [Thu, 27 May 2004 09:12:15 +0000 (05:12 -0400)]
[PATCH] pcnet32: fix bogus carrier errors with 79c973
The 79C973 version of the pcnet32 chipset would report all transmit
operations as being sent with a carrier error. The root cause was
writing reserved bits in bcr33. It caused the 973 to report xmit
as errors, and caused 975 and 976 to hard hang when reading bcr34.
My thanks to Bruce Penrod for his help in finding the cause of this
bug.
Don Fry [Thu, 27 May 2004 09:04:02 +0000 (05:04 -0400)]
[PATCH] pcnet32: remove timer and complexity.
This removes the timer I recently added, and the 'ltint' interrupt
mitigation from the 79C971 and 79C972. It did not improve performance,
added complexity, and was a bad idea in hind sight.
Don Fry [Thu, 27 May 2004 09:03:48 +0000 (05:03 -0400)]
[PATCH] pcnet32: fix boundary comparison bug.
This patch fixes a boundary condition. It is possible to get an
interrupt and have the transmit queue completely full. Without this
the driver will leak skb's and pci maps (if the arch supports them).
Paul Mundt [Thu, 27 May 2004 08:53:44 +0000 (04:53 -0400)]
[PATCH] Fix 8139too ring size for dreamcast/embedded
Presently 2.6.6 backs out the CONFIG_8139_RXBUF_IDX in favor of using a
hardcoded 8139_RXBUF_IDX (again). This seems to have been done due to
some issues occuring with 8139_RXBUF_IDX =3D=3D 3, however (as the Kconfig
pointed out), we still need 8139_RXBUF_IDX =3D=3D 1 in the CONFIG_SH_DREAMC=
AST
case.
The patch which made this change can be seen at:
{MIME-mangled URL}
Before that, CONFIG_8139_RXBUF_IDX was set to 1 both in the
CONFIG_SH_DREAMCAST and CONFIG_EMBEDDED cases. This patch adds that
back into the current 8139too.
Andrew Morton [Thu, 27 May 2004 00:36:46 +0000 (17:36 -0700)]
[PATCH] nfsd: deleting symlinks over nfs causes oops on unmount
From: "J. Bruce Fields" <bfields@fieldses.org>
From: Neil Brown <neilb@cse.unsw.edu.au>
This fixes an oops on unmount (failure of the assertation at
fs/ext3/super.c:421). Probably reproduceable just by creating and deleting a
single symlink over nfs and then unmounting the exported filesystem.
Recent change to fh_compose means dentry reference is *not* consumed, and so
usually has to be explicitly dput afterwards. One usage was missed in that
patch, so this dput is needed.
Andrew Morton [Thu, 27 May 2004 00:36:14 +0000 (17:36 -0700)]
[PATCH] CPU Hotplug: restore Idle task's priority during CPU_DEAD notification
From: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Fix a CPU Hotplug problem wherein idle task's "->prio" value is not
restored to MAX_PRIO during CPU_DEAD handling. Without this patch, once a
CPU is offlined and then later onlined, it becomes "more or less" useless
(does not run any task other than its idle task!)
Ingo said:
The __setscheduler() call is (technically) incorrect because in the
SCHED_NORMAL case the prio should be zero. So it's a bit cleaner to set up
the static priority to MAX_PRIO and then revert the policy to SCHED_NORMAL
via __setscheduler().
Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org>
Andrew Morton [Thu, 27 May 2004 00:35:42 +0000 (17:35 -0700)]
[PATCH] Fix the setting of file->f_ra on block-special files
We need to set file->f_ra _after_ calling blkdev_open(), when inode->i_mapping
points at the right thing. And we need to get it from
inode->i_mapping->host->i_mapping too, which represents the underlying device.
Also, don't test for null file->f_mapping in the O_DIRECT checks.
Andrew Morton [Thu, 27 May 2004 00:35:31 +0000 (17:35 -0700)]
[PATCH] Set d_bucket correctly for anonymous dentries
From: Neil Brown <neilb@cse.unsw.edu.au>
In researching the oopses reported in bug #2761, Neil came up with:
I have found one problem, but it isn't particularly new and I cannot
see how it would be related.
When d_alloc_anon creates an anonymous dentry, it is put on a special hash
chain for anonymous dentries (sb->s_anon), but d_bucket is set to
d_hash(parent, name_hash)
If, when it is eventually moved to a proper name, that hash value is the same
as the final hash value, it will not be moved to the right bucket, and so it
not be accessible by name. This patch should fix it.
anonymous dentries have their own private hash "bucket" (sb->s_anon) and so
d_bucket should be set to a unique (impossible) address, else d_move will
get confused.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org>
Andrew Morton [Thu, 27 May 2004 00:35:21 +0000 (17:35 -0700)]
[PATCH] posix locks oops fix
From: Andreas Gruenbacher <agruen@suse.de>
There is a race between unshare_files() and the following steal_locks().
As a consequence, steal_locks() may steal some additional FL_POSIX locks
that don't belong to the current thread. This triggers a BUG in
locks_remove_flock().
In detail, the current thread shares its files struct with other threads.
This causes unshare_files() to associate the current thread with a copy of
its files_struct. The copy shares all file objects with the original files
struct. In the time between unshare_files() and steal_locks(), another
thread creates a new file and a FL_POSIX lock on it. The current thread
gets into steal_locks() and takes over all FL_POSIX locks that refer to the
previous files_struct, including the new lock. We do
put_files_struct(original files_struct). This causes the file handle to
the new file to be closed. We get into locks_remove_posix() and miss the
lock, because its fl_owner field now refers to the new files_struct.
Finally we get into locks_remove_flock(), and stumble upon the lock.
While looking into this bug report I gathered the following data with a
SUSE kernel (oops and LKCD dump from Chris):
Here's a proposed fix. As a side effect, steal_locks no longer walks the
global list of locks, but only the locks of all open inodes.
What are the reasons (other than historic ones) for not getting rid of
fl_owner and using fl_pid instead, by the way? I think that would clean up
the whole mess with file locks a bit.
Andrew Morton [Thu, 27 May 2004 00:34:58 +0000 (17:34 -0700)]
[PATCH] ppc64 kernel hackers can't spell
From: Anton Blanchard <anton@samba.org>
From: Dave Hansen
This patch is obviously of the utmost importance. It probably doesn't matter
as much for kernel error messages, but one of these mistakes is in a
user-readable /proc file.
Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org>
Arjan van de Ven [Wed, 26 May 2004 08:37:25 +0000 (01:37 -0700)]
[PATCH] PCI: restore pci config space on resume
The patch below enhances the PCI layer with 2 things
1) enable and busmaster state are stored in the pci device struct
2) pci config space is stored to the pci device struct
with that, it is possible to make a generic pci resume method that restores
config space and reenables the device, including busmaster when appropriate.
One can rightfully argue that the driver resume method should do this, and
yes that is right. So the patch only does it for devices that don't have a
resume method. Like the main PCI bridge on my testbox of which the bios so
nicely forgets to restore the bus master bit during resume.. With this patch
my testbox resumes just fine while it, well, wasn't all too happy as you can
imagine without a busmaster pci bridge.