This patch updates the G5 thermal control driver, the main change
is support for the new "PowerMac7,3" type desktops including the
dual 2.5Ghz with liquid cooling.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch, from John Rose, is the counterpart of one recently
forwarded by Greg KH. It has the same description, but isn't the same
patch - this is the arch/ppc64 part of the change.
As an unfortunate side effect of runtime addition/removal of PCI Host Bridges,
the RPA DLPAR driver can no longer depend on the success of ioremap_explicit()
(and therefore remap_page_range()) for the case of DLPAR adding an I/O Slot.
Without addressing this, an attempt to add the first child slot of a newly
added PHB will fail when __ioremap_explicit() determines the mappings for that
range to already exist.
For a little context, __ioremap_explicit() creates mappings for the range of a
newly added slot. Here's why these calls will be expected to fail in some
cases. Keep in mind that at boot-time, the PPC64 kernel calls ioremap() for
the entire range spanned by each PHB. Consider the following scenarios of
DLPAR-adding an I/O slot.
1) Just after boot, one removes an I/O slot. At this point the range
associated with the parent PHB is fragmented, and the child range for the
slot in question is iounmap()'ed. One then re-adds the slot, at which point
remap_page_range()/ioremap_explicit() restores the mappings that were
previously removed.
2) One adds a new PHB, at which point the ppc64-specific addition ioremaps the
entire PHB range. One then performs a DLPAR-add of a child slot of that
PHB. At this point, mappings already exist for the range of the slot to
be added. So remap_page_range()/ioremap_explicit() will fail at this point.
The problem is, there's not a good way to distinguish between cases 1 and 2
from the perspective of the DLPAR driver. Because of that, I believe the
correct solution to be:
- Removal of relevant error prints from iounmap_explicit(), which is only used
for DLPAR.
- Removal of error code checks from the RPA driver
Here's the first of these.
Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Thu, 21 Oct 2004 11:04:56 +0000 (04:04 -0700)]
[PATCH] added typechecking ot sparc64 ioremap()
ioremap() made inlined function on sparc64; that had caught one bogosity in
drivers, actually - cpwatchdog.c passed sizeof(structure that was never
declared) as the second argument to ioremap(). It went unnoticed since
that argument was never used in the body of macro, so it disappeared without
a trace...
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Thu, 21 Oct 2004 11:04:43 +0000 (04:04 -0700)]
[PATCH] sparc64 missing volatile in io.h prototypes
A bunch of places passes volatile pointers to readb() et.al.;
sparc64 has their arguments declared as void __iomem *. Prototypes
changed to match other platforms.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It is not needed any longer:
* PIO code is unified and converted to use scatterlists
* taskfile code doesn't support falling back to PIO
* it is much easier to convert non-taskfile version of
__ide_do_rw_disk() to something sane than taskfile one
Sigh, I broke it by accident 16 months ago and nobody has noticed
(I suspect that it was non-functional even earlier).
Additionally, this driver:
* should be converted to use scatterlists
* has verbose debugging enabled by default
* needs hacks all over IDE code
* is guilty of crimes against ide_hwifs[]
Linus Torvalds [Thu, 21 Oct 2004 08:23:16 +0000 (01:23 -0700)]
remap_pfn_range: make the region special.
VM_IO tells the rest fo the world that the pages may
have side effects on reads/writes etc, and VM_RESERVED
historically told swap-out not to bother with it.
It was pointed out to me that I typo'd and lost a backslash in the
PA-RISC io_remap_page_range() definition. This patch corrects the
one-character typo.
Paul Fulghum [Thu, 21 Oct 2004 04:22:34 +0000 (21:22 -0700)]
[PATCH] ppp: terminate connection on hangup
I reviewed, patched, and tested ppp_async.c to implement
ldisc->hangup(). This correctly terminates the PPP connection on
hangup.
Paul Mackerras already did an excellent job of ensuring safe shutdown
and I/O completion in ldisc->close so the change is trivial: just add
the ldisc->hangup and call the existing close routine.
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Stefan Esser [Thu, 21 Oct 2004 03:58:29 +0000 (20:58 -0700)]
[PATCH] smbfs protocol fixes
From: <Urban.Widmark@enlight.net>
The memset is because it was previously possible to send always the same CIFS
fragment and use this to increase the data counters. When the data counter
"exceeds" the amount of bytes expected this will return the buffer only
partially initialised... With findfirst etc requests this should allow
leaking kernel memory content.
The other thing is that the data is only returned when data_tot and parm_tot
both "exceed" the expected values. Previously it was possible to create a
sequence of CIFS fragments that allowed exceeding the counters. The calling
functions then would believe they received a number of bytes that does not fit
into the allocated buffer.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Andy Whitcroft [Thu, 21 Oct 2004 03:58:17 +0000 (20:58 -0700)]
[PATCH] vm_dirty_ratio initialisation fix
When a system has a very large imbalance of overall memory size to
ZONE_NORMAL (for example when large amounts of numa remap space are in use)
page_writeback_init() may incorrectly set vm_dirty_ratio and
dirty_background_ratio to zero; leading to divide by zero errors elsewhere.
This patch bounds these at 1%.
Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] x86_64: no TIOCSBRK/TIOCCBRK in ia32 emulation
In ia32 emulation, the amd64 kernel refuses the ioctls TIOCSBRK and
TIOCCBRK with EINVAL. I've attached a patch that adds them to the
compatibility list.
Since all architectures have these ioctls ("m68knommu" inherits them from
"m68k", "um" from its host) and use the same code, I think adding them to
compat_ioctl.h is the correct choice (as opposed to adding them to
arch/x86_64/ia32/ia32_ioctl.c).
Signed-off-by: Werner Almesberger <werner@almesberger.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Paul Mackerras [Thu, 21 Oct 2004 03:56:51 +0000 (20:56 -0700)]
[PATCH] ppc64: fix XICS startup function to enable as well
When the generic IRQ patch went in, it changed the behaviour of setup_irq
(compared to the previous ppc64 version) in that we now don't call the
handler's enable function if it has a startup function. The XICS interrupt
controller has a startup function, and so we weren't getting any interrupts
through the XICS because they never got enabled. This patch adds a call to
xics_enable_irq to xics_startup and fixes the problem.
Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Roland Dreier [Thu, 21 Oct 2004 03:56:14 +0000 (20:56 -0700)]
[PATCH] ppc: fix build with O=$(output_dir)
Recent changes to arch/ppc/boot/lib/Makefile cause
CC arch/ppc/boot/lib/../../../../lib/zlib_inflate/infblock.o
Assembler messages:
FATAL: can't create arch/ppc/boot/lib/../../../../lib/zlib_inflate/infblock.o: No such file or directory
when building a ppc kernel using O=$(output_dir) with CONFIG_ZLIB_INFLATE=n,
because the $(output_dir)/lib/zlib_inflate directory doesn't get created.
This patch, which makes arch/ppc/boot/lib/Makefile create the
directory if needed, is one fix for the problem.
Signed-off-by: Roland Dreier <roland@topspin.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Thomas Gleixner [Thu, 21 Oct 2004 01:35:05 +0000 (02:35 +0100)]
MTD: NAND flash driver updates.
- Use new RS library for ECC
- Add support for new NAND flash chips
- New board support:
- iPAQ H1910
- Renesas AG-AND devel board
- Simtec S3C210
- Support for shared controllers on multiple chips.
Signed-Off-By: Thomas Gleixner <tglx@linutronix.de> Signed-Off-By: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Thu, 21 Oct 2004 01:13:45 +0000 (02:13 +0100)]
MTD: NOR flash chip driver updates
Mostly from Eric Biederman for supporting BIOS flash.
- Move support firmware hub style lock and unlock into fhw_lock.h (from cfi_cmdset_0002)
- Move cfi_varsize_frob into cfi_util from cfi_cmdset_0001.c and cfi_cmdset_0002.c
- reduce gen_probe probe failuers to a debug level message
- Modify cfi_fixup to take a struct mtd_info instead of a struct map_info
So that the fixup routines can modify the mtd functions.
- Modify cfi_cmdset_0001() to allocate and initialize the mtd structure
before calling cfi_fixup.
- Modify cfi_cmdset_0002() to allocate and initialize the mtd structure
before calling cfi_fixup.
- Refactor the hard coded fixups in cfi_cmdset_0001 and cfi_cmdset_0002
so the improved cfi_fixup infrastructure.
- Rewrote amd76xrom and ichxrom.
They now report their starting physical address in their name.
They now both handle multiple bankwidth configurations
They both can create multipe mtd devices.
They both now assume the rom windows are properly opened by the BIOS
or whatever runs previous to them.
Their code is now synchromized so it is almost identical,
and could be a starting point for a x86_rom_probe.
Signed-Off-By: David Woodhouse <dwmw2@infradead.org>
Thomas Gleixner [Thu, 21 Oct 2004 00:53:32 +0000 (01:53 +0100)]
MTD char device access -- return data when ECC errors happen.
This is sane, as the driver returns the real data and the return
value is for information of NAND aware filesystems. Userspace
access to raw NAND is usually restricted to debugging tools which
are aware of the NAND specific problems.
Signed-Off-By: Thomas Gleixner <tglx@linutronix.de> Signed-Off-By: David Woodhouse <dwmw2@infradead.org>
Thomas Gleixner [Wed, 20 Oct 2004 23:55:08 +0000 (00:55 +0100)]
Shared Reed-Solomon ECC library
The attached patch contains a shared Reed-Solomon Library analogous to
the shared zlib.
(N)AND FLASH is gaining popularity and there are a lot of ASIC/SoC/FPGA
controllers around which implement hardware support for Reed-Solomon
error correction. As usual they use different implementations
(polynomials etc.). So it's obvious to use a shared library for the
common tasks of error correction.
A short scan through the kernel revealed that at least the ftape driver
uses Reed-Solomon error correction. It could be easily converted to use
the shared library code.
The encoder/decoder code is lifted from the GPL'd userspace RS-library
written by Phil Karn. I modified/wrapped it to provide the different
functions which we need in the MTD/NAND code.
The library is tested in extenso under various MTD/NAND configurations.
The lib should be usable for other purposes right out of the box.
Adjustment for currently not implemented functionality is an easy task.
I'm willing to take the maintainership of the library.
Signed-Off-By: Thomas Gleixner <tglx@linutronix.de> Signed-Off-By: David Woodhouse <dwmw2@infradead.org>
"No objections at all. Just keep the authorship notices." -- Phil Karn
Jesse Barnes [Wed, 20 Oct 2004 22:53:23 +0000 (22:53 +0000)]
[IA64-SGI] more sparse I/O accessor fixes
I forgot to add 'const volatile' to the I/O read/write functions in the last
patch, and also forgot to update the _relaxed variants. This patch fixes
that by adding 'const volatile' to the sn2 specific read/write routines as
well as the ia64 machine vector wrappers.
Signed-off-by: Jesse Barnes <jbarnes@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
Jesse Barnes [Wed, 20 Oct 2004 20:40:02 +0000 (20:40 +0000)]
[IA64-SGI] sparse cleanups & misc fixes for sn2
This is a big patch mostly because I trimmed shub_mmr.h down from 17M to 11k
or so. It fixes a number of things sparse discovered and removes some dead
code, fixes up some prototypes, etc. Of note:
o sn_proc_fs.c was directly dereferencing user pointers, fixed
o sn_hwperf.c was missing an include and was using asm-ia64 directly
o the I/O routines were all missing proper sparse annotations
o dead code in prominfo_proc.c has been removed
o fix generic build by putting numionodes into asm/sn/io.h
With this patch applied, the check build is pretty clean. The sn_console bit
depends on some of the other changes, so it's included here.
Signed-off-by: Jesse Barnes <jbarnes@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
John Hawkes [Wed, 20 Oct 2004 18:23:39 +0000 (18:23 +0000)]
[IA64] top level scheduler domain for ia64
Some have noticed that the overlapping sched domains code doesn't quite work
as intended (it results in disjoint domains on some machines), and that a top
level, machine spanning domain is needed. This patch from John Hawkes adds
it to the ia64 code. This allows processes to run on all CPUs in large
systems, though balancing is limited. It should go to Linus soon now
otherwise large systems will only have ~16p (depending on topology) usable by
the scheduler. I sanity checked it on a small system after rediffing John's
original, and he's done some testing on very large systems.
Nick, can you buy off on the sched.c change? Alternatively, do you want to
send that fix separately John? Nick did indeed ACK this change, but it isn't
dependent on this ia64 specific part ... so it's going to be submitted
separately.
Signed-off-by: John Hawkes <hawkes@sgi.com> Signed-off-by: Jesse Barnes <jbarnes@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
Use PIO code from ide-taskfile.c in ide-disk.c so:
* drive status is checked after PIO read
* request is failed if invalid data phase
is detected during PIO write
Russell King [Wed, 20 Oct 2004 21:34:23 +0000 (22:34 +0100)]
[ARM] Add seqlocking to timers.
Sometimes, it's useful to have locking. Especially when we're
talking about time keeping.
It would appear that shemminger's patch of 5th February 2003
completely missed updating _ANY_ ARM timer implementations and,
because linux-arch didn't exist at the time, there appears to
have been no notification to any architecture developer that
maybe, just maybe, some work was required.
One wonders how many other changes are in the kernel which
architecture maintainers have missed.
projects / linux / log