Please find an incremental patch that applies on top of the previous one
(the one from the first message of the thread) and that adds parenthesis
to the macro as pointed out by Mark.
Jean Delvare [Fri, 9 Jul 2004 07:47:23 +0000 (00:47 -0700)]
[PATCH] I2C: remove Documentation for i2c-pport
> > This also raises a question about Documentation/i2c/i2c-pport.
> > Should we keep a document about a driver which is not in the kernel
> > tree (and hasn't even been ported to 2.6 yet)?
>
> No we should not.
Signed-off-by: Jean Delvare <khali at linux-fr dot org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Andras Bali [Thu, 8 Jul 2004 09:08:19 +0000 (02:08 -0700)]
[PATCH] I2C: Add support for LM77
This patch (against the current stack) adds support for the
LM77 sensor chips made by National Semiconductor. Formerly
this was claimed by the LM75 driver but when I got hold of an
embedded board (built around the National Geode SC1100 CPU),
which was equipped with an LM77, it turned out that the two
chips are not compatible.
It has been developed with help of, reviewed and approved
by Jean Delvare.
Signed-off-by: Andras Bali <drewie@freemail.hu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Jean Delvare [Thu, 8 Jul 2004 09:07:58 +0000 (02:07 -0700)]
[PATCH] I2C: Documentation for i2c-parport
At least, the i2c-parport gets some documentation. I heard several
persons complaining that there was no sample electronics schema for
building their own i2c-over-parallel-port, so I did just that, with the
help of Sylvain Munaut. The documentation also includes the list of
supported adapters, and a short comparison with other drivers using the
parallel port to drive an i2c bus. At the end of the document I included
an updated version of the i2c-velleman doc file (which I then deleted).
Signed-off-by: Jean Delvare <khali at linux-fr dot org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
This patch does the fallowing cleanup for
drivers/i2c/i2c-dev.c::i2c_dev_init():
*) in a error condition, return the error code of register_chrdev()
insted of -EIO;
*) adds missing audit for class_register();
*) in a error condition, only prints "Driver Initialisation Failed",
insted printing the cause. (Note that the error will be printed by
the return of the error code, and the information about what function
caused the problem need to be done by a debug code).
Jean Delvare [Thu, 8 Jul 2004 09:07:05 +0000 (02:07 -0700)]
[PATCH] I2C: Add support for LM86, MAX6657 and MAX6658 to lm90
This adds support for the LM86, MAX6657 and MAX6658 sensor chips to the
lm90 driver. These are less popular than the LM90 and ADM1032 but
several users have reported to use these, so I added support to the lm90
driver. All these chips are fully compatible so that's just a matter of
accepting the new chip ids. I also slightly simplified the detection
code.
Signed-off-by: Jean Delvare <khali at linux-fr dot org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
IBM PPC 4xx i2c controller doesn't support 0-length transactions (e.g. used by
SMBUS_QUICK). This patch implements bit-banging emulation for such requests and
removes temporary kludge added earlier.
Ian Campbell [Tue, 6 Jul 2004 19:21:56 +0000 (20:21 +0100)]
[ARM PATCH] 1954/2: Make pxa platform device names more sensible
Patch from Ian Campbell
Update 1954/1 to use pxa2xx- as the platform device prefix
instead of pxa2xx_. This changes pxamci to pxa2xx-mci, pxa2xx_udc
to pxa2xx-udc and pxafb to pxa2xx-fb. pxa2xx-uart doesn't need changing.
The reference count (d_count) of the struct dentry of a new epoll-fd was
set to TWO. (new_inode() assigned ONE, than ep_getfd() incremented it by
dget()). There was only ONE reference to this dentry, so struct dentry and
struct inode were never freed.
Added a new scrolling mode (SCROLL_PAN_REDRAW) to fbcon that should greatly
benefit unaccelerated drivers such as VESA fbdev. An increase of 3-10 times
in scrolling speed can be expected.
Currently, fbcon has 4 different scrolling methods (1-4). Potentially, we can
have 6. This patch implements SCROLL_PAN_REDRAW (5). SCROLL_WRAP_REDRAW (6)
is still unimplemented.
Scroll Mode Operation YPan YWrap
+++++++++++++++++++++++++++++++++++++++++++++++++++++
1. SCROLL_ACCEL copyarea No No
2. SCROLL_REDRAW imageblit No No
3. SCROLL_PAN copyarea Yes No
4. SCROLL_WRAP copyarea No Yes
5. SCROLL_PAN_REDRAW imageblit Yes No
6. SCROLL_WRAP_REDRAW imageblit No Yes
+++++++++++++++++++++++++++++++++++++++++++++++++++++
Note 1: I've changed the nomenclature to increase clarity:
To demonstrate the effect of each of the scrolling methods on
an unaccelerated PCI/AGP-based driver (vesafb), I used a simple
benchmark (time cat linux/MAINTAINERS - a 50K text file). The
framebuffer is set at:
1024x768-8bpp, 8x16 font, yres_virtual = 2*yres
1. SCROLL_MOVE:
real 5m50.277s
user 0m0.001s
sys 5m50.227s
Almost 6 minutes for a 50K text file. Using soft copyarea on a
PCI-based card is just too slow (because copyarea has to
read from the framebuffer memory).
2. SCROLL_PAN_MOVE
scrollmode: SCROLL_PAN
real 0m8.592s
user 0m0.000s
sys 0m8.586s
Using ypan with copyarea dramatically improves the scrolling. However, the
scrolling action is jerky (fast during the panning stages, slows down during
the copyarea stages).
3. SCROLL_REDRAW (this is the default scrolling mode)
real 0m3.189s
user 0m0.000s
sys 0m3.170s
Simply eliminating the copyarea, even without ypanning, makes it faster than
SCROLL_PAN_MOvE. Plus, the scrolling action is smoother.
So, if we combine YPanning with imageblit (PAN_REDRAW), we get this:
4. SCROLL_PAN_REDRAW
real 0m0.520s
user 0m0.000s
sys 0m0.518s
That's almost 6x faster than SCROLL_REDRAW. Increasing the amount of video
RAM still increases the speed, but not very dramatically. Higher than 16 MB,
the increase is negligible.
Using an accelerated driver, we see almost the same effect but not as
dramatically:
1. SCROLL_MOVE - accel
real 0m3.112s
user 0m0.000s
sys 0m3.112s
2. SCROLL_REDRAW - accel
real 0m2.604s
user 0m0.000s
sys 0m2.603s
Redraw is still faster than move, but not much.
3. SCROLL_PAN_MOVE - accel
real 0m0.203s
user 0m0.000s
sys 0m0.202s
4. SCROLL_PAN_REDRAW - accel
real 0m0.326s
user 0m0.002s
sys 0m0.323s
This is one exception. If panning is enabled, move is actually faster than
redraw. As to why, I don't know.
So based on the above, fbcon will choose the scrolling method based on the
following preference:
Note 2: Exception: accel copyarea > accel imageblit if Pan/Wrap is enabled.
Note 3: soft copyarea will be avoided by fbcon as much as possible unless
there is a specific override, ie., FBINFO_READS_FAST flag is set. If this
flag is set, fbcon will prefer copyarea over imageblit, accel or soft.
As a final note, in order for fbcon to use the best scrolling method, the
low-level drivers must provide the correct hinting by setting the
FBINFO_HWACCEL_* flags.
To vesafb users: boot vesafb like this for fastest scrolling action:
yesterday I finally found why 2.6.x has problems with taking
over vgacon. Problem is that take_over_console does:
if (IS_VISIBLE)
save_screen(i);
...
visual_init(i, 0);
...
so code nicely saves screen contents, and calls visual_init,
which calls fbcon's init, which in turn can issue vc_resize. And this
vc_resize will trigger read from vc->vc_origin. But vc_origin still
points to videomemory, not to the buffer where save_screen() copied
its data.
End quote
So updating vc->vc_origin to point to screenbuf after the previous console
deinitializes allows fbcon to correctly update the screen from the screen
buffer. This change makes the clearing of vram (using fillrect) unnecessary.
2. If FBINFO_MISC_MODESWITCH flag is set in info, do the set_par() in
fbcon_switch() instead of piggy-backing the set_par() on fbcon_resize(). This
preserves the current var, skipping the unnecessary fb_find_mode() step.
Ugly workaround. When switching from KD_GRAPHICS to KD_TEXT, the event is
captured at fbcon_blank() allowing fbcon to reinitialize the hardware.
However, some hardware requires the reinitialization to be done
immediately, others require it to be done later. Others may need it to be
done immediately and later, this is the worst case.
This patch introduces a notifier chain for cpu idle. There are two events
CPU_IDLE and CPU_NOT_IDLE that are called just before the cpu goes to sleep
and right after the cpu woke up again. The notifier is used to simplify the
no-hz-timer-in-idle feature and the virtual cpu timers. In addition the
virtual cpu timer functions have been moved to arch/s390/kernel/vtime.c, which
gives a nice separation between the timer functions related to real time and
the timer functions related to virtual cpu time.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
ctc driver changes:
- Make use of the debug feature to ease debugging.
- ctctty: use dev_alloc_name to allocate a network device name.
- ctctty: avoid deadlock of ctc_tty_close vs ctc_tty_flush_buffer.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Herbert Xu [Tue, 6 Jul 2004 07:05:53 +0000 (00:05 -0700)]
[IPCOMP]: Exclude IPCOMP header from props.header_len
This is another patch on the way towards a unified XFRM tunnel
encapsulation function.
This patch changes the value of props.header_len for IPCOMP to
exclude the IPCOMP header. The reason is that the IPCOMP header
is added only if the packet is compressible. That is, if the
size of the compressed payload plus the size of the IPCOMP header
is less than that of the original payload.
This means that the IPCOMP encapsulation does not impose any
overhead at all as far as the MTU is concerned. The current
code incorrectly reduces the MTU by the size of the IPCOMP
header.
As a side-effect, this means that we don't have to move the
IP header around when IPCOMP is used.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@redhat.com>
[PKT_SCHED]: Update to network emulation QOS scheduler.
This patch updates the network emulation packet scheduler.
* name changed from delay to netem since it does more than just delay
* Catalin's merged code to do packet reordering
* uses a socket queue's directly rather than layering on qdisc(fifo)
because this is used in performance tests.
* adds placeholder in API for future enhancements (rate and duplicate).
Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@redhat.com>
[NETFILTER]: ip6t_LOG and packets with hop-by-hop options.
Packet with IPPROTO_HOPOPTS extended header isn't logged properly by
ip6t_LOG.c. It only prints PROTO=0 and nothing more, because
IPPROTO_HOPOPTS=0 and in this file 0 is used to indicate last header.
This patch fix it by using IPPROTO_NONE to indicate last header.
Signed-off-by: Marcel Sebek <sebek64@post.cz> Signed-off-by: Harald Welte <laforge@netfilter.org> Signed-off-by: David S. Miller <davem@redhat.com>
John Lenz [Mon, 5 Jul 2004 17:44:39 +0000 (18:44 +0100)]
[ARM PATCH] 1938/1: Support for Collie device
Patch from John Lenz
Cleanup and forward port of patch 1850.
Add machine support for the Sharp Zaurus SL5500 PDA.
Does not include support for the collie serial port or
the sa1100fb_lcd_power function.
Ian Campbell [Mon, 5 Jul 2004 17:27:25 +0000 (18:27 +0100)]
[ARM PATCH] 1953/1: Omit id for platform devices where only one can possibly exist.
Patch from Ian Campbell
Now that the BK tree allows platform devices to specify an id of -1
to get rid of the numbered suffix.
Following discussion on the l-a-k mailing list here is patch to do
this for the pxafb, pxa2xx-udc and pxamci generic PXA2xx platform
devices and the platform devices on the Lubbock.
The change as seen here:
http://linux.bkbits.net:8080/linux-2.5/diffs/arch/arm/kernel/head.S@1.19?nav=index.html|ChangeSet@-4d|cset@1.1769.3.12
has this note:
"No need to include asm/mach/arch.h"
But it now requires asm/constants.h otherwise SIZEOF_MACHINE_DESC
is not defined. Why compilation succeeds anyways still mystify me.
David S. Miller [Mon, 5 Jul 2004 13:39:01 +0000 (06:39 -0700)]
[PKT_SCHED]: Do not embed spinlock in tc_stats structure.
This makes it not get sized/copied around to/from
userspace correctly. The real crux of the problem
comes from the rtnetlink attribute copying line which
read:
RTA_PUT(skb, TCA_STATS, (char*)&st->lock - (char*)st, st);
which is not necessarily sizeof(struct tc_stats) due
to alignment issues.
Herbert Xu [Mon, 5 Jul 2004 09:02:18 +0000 (02:02 -0700)]
[AH4]: Harmonization of output function.
This is another step towards the union of the tunnel mode encapsulation
between transforms. As there are significant differences between the
tunnel encapsulation of IPv4 and IPv6, I'll be dealing with IPv4 only
for now.
This particular patch rearranges the code in ah_output to isolate the
tunnel mode encapsulation.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@redhat.com>
Herbert Xu [Mon, 5 Jul 2004 08:42:39 +0000 (01:42 -0700)]
[NETLINK]: Return err in netlink_connect.
This patch makes netlink_connect() return the value of err instead of 0.
It doesn't actually make any difference since the current implementation
of netlink_autobind() never fails. But since we went to all this trouble
to check the return status of autobind, might as well return the correct
value :)
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@redhat.com>
[IPV4]: Calculate default broadcast even when using SIOCSIGNETMASK.
While getting hands-on with netkit (www.netkit.org), a networking
simulation environment based on UML, it struck me that ifconfig wasn't
capable of calculating the proper broadcast address for a subnetted
interface. Some browsing through newsgroups and on the Debian package
site (nettools), showed that this leads to misconfigured interfaces and
a couple of bugreports on ifconfig.
Digging a bit deeper revealed that it actually is an issue with
SIOIFNETMASK. Once you bring up an interface with SIOIFADDR, a classfull
netmask and broadcast address is set (if applicable for the type of
interface), in order to get a properly configured interface. But if you
subnet the network using SIOIFNETMASK no proper broadcast address is
set. So you always have to calculate it yourself, obviously leading to
configuration errors.
This patch takes care of this. First of all it doesn't change
existing functionality, eg. a command like 'ifconfig eth0 192.168.1.1
netmask 255.255.255.240 broadcast 192.168.1.0' still works. But if you
omit the broadcast address, a proper 'all ones' broadcast address for the
subnet is set. 'ifconfig eth0 192.168.1.1 netmask 255.255.255.240' gives
you 'eth0 inet addr:192.168.1.1 Bcast:192.168.1.15 Mask:255.255.255.240'
and this should solve some real life problems.
Signed-off-by: Jaap Keuter <jaap.keuter@xs4all.nl> Signed-off-by: David S. Miller <davem@redhat.com>
Andrew Morton [Mon, 5 Jul 2004 03:27:16 +0000 (20:27 -0700)]
[PATCH] kyrofb warning fix
drivers/video/kyro/fbdev.c: In function `kyrofb_probe':
drivers/video/kyro/fbdev.c:736: warning: passing arg 1 of `memset' makes pointer from integer without a cast
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
As ->vm_private_data is used as a cursor for swapout of VM_NONLINEAR vmas,
the check for NULL ->vm_private_data or VM_RESERVED is too strict, and
should allow VM_NONLINEAR vmas with non-NULL ->vm_private_data.
This fixes an issue on 2.6.7-mm5 where system calls to remap_file_pages()
spuriously failed while under memory pressure.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Anton Blanchard [Mon, 5 Jul 2004 03:26:20 +0000 (20:26 -0700)]
[PATCH] gcc 3.5 fixes
gcc 3.5 is warning about static vs non static function declarations. The
following patch removes function prototypes in .h files where possible and
changes prototypes to be static elsewhere.
Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] force O_LARGEFILE in sys_swapon() and sys_swapoff()
For 32-bit, one quickly discovers that swapon() is not given an fd already
opened with O_LARGEFILE to act upon and the forcing of O_LARGEFILE for
64-bit is irrelevant, as the system call's argument is a path. So this
patch manually forces it for swapon() and swapoff().
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Paul Jackson [Mon, 5 Jul 2004 03:25:57 +0000 (20:25 -0700)]
[PATCH] sparc32 cpumask bitop build fix
With the following changes, I was able to compile the "sparc" (32 bit)
arch, using defconfig and crosstool. There were still plenty of warnings,
but nothing else relating to bitops or cpumasks that I noticed. This is
working with 2.6.7-mm5.
I have no way to boot test this, but these changes seem obvious enough that
I'd recommend including them.
Signed-off-by: Paul Jackson <pj@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It looks like someone removed UPF_RESOURCES in remove-upf_resources.patch
in parallel with someone adding drivers/firmware/pcdp.c that references
UPF_RESOURCES.
In any event, trying to build a defconfig ia64 2.6.7-mm5 (which includes
CONFIG_SERIAL_8250=y in the .config) fails with:
drivers/firmware/pcdp.c: In function `setup_serial_console':
drivers/firmware/pcdp.c:100: error: `UPF_RESOURCES' undeclared (first use in this function)
Signed-off-by: Paul Jackson <pj@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
David Eger [Mon, 5 Jul 2004 03:25:35 +0000 (20:25 -0700)]
[PATCH] err1-7, err1-8: double locking fix for radeonfb
radeonfb: the Stanford lock checker found us double-locking rinfo->reg_lock
via sequences like OUTPLL(foo, INPLL(bar) | baz ), as both OUTPLL and INPLL
grab the register lock. This should fix the problem.
Signed-off-by: David Eger <eger@havoc.gtf.org Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Chris Wright [Mon, 5 Jul 2004 03:25:12 +0000 (20:25 -0700)]
[PATCH] selinux build fix
With gcc-3.5 from CVS:
security/selinux/avc.c:76: error: static declaration of 'avc_cache_stats' follows non-static declaration
security/selinux/include/avc.h:107: error: previous declaration of 'avc_cache_stats' was here
Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Andrew Morton [Mon, 5 Jul 2004 03:24:50 +0000 (20:24 -0700)]
[PATCH] wavefront_fx.c build fix
With gcc from CVS:
sound/isa/wavefront/wavefront_fx.c:697: error: static declaration of 'page_zero' follows non-static declaration
include/sound/yss225.h:4: error: previous declaration of 'page_zero' was here
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Martin J. Bligh [Mon, 5 Jul 2004 03:24:39 +0000 (20:24 -0700)]
[PATCH] fix up physnode_map
At the moment, we initialise physnode_map from the various BIOS tables,
which can create problems, as holes inside an node return 1 for pfn_valid,
and yet pfn_to_nid is not correct for them. I'd hacked around this in my
tree by defaulting the mapping to 0, not -1, but that's not the correct fix
... this is.
I consolidated all the code back into 1 place, and use node_start_pfn[] and
node_end_pfn[] to walk over it instead - that means it matches up perfectly
with lmem_map's as we're using the same data. It also cleans up a lot of
the code.
Tested on both NUMA-Q and x440 ... and it only affects i386 NUMA boxen.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Mika Kukkonen [Mon, 5 Jul 2004 03:24:28 +0000 (20:24 -0700)]
[PATCH] Fix sparse warnings in fs/udf/*
CHECK fs/udf/dir.c
fs/udf/dir.c:240:13: warning: expected lvalue for member dereference
[...]
CHECK fs/udf/namei.c
fs/udf/namei.c:872:6: warning: expected lvalue for member dereference
fs/udf/namei.c:916:6: warning: expected lvalue for member dereference
fs/udf/namei.c:1189:14: warning: expected lvalue for member dereference
fs/udf/namei.c:1234:7: warning: expected lvalue for member dereference
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Olaf Hering [Mon, 5 Jul 2004 03:23:54 +0000 (20:23 -0700)]
[PATCH] ppc32: biarch gcc support
A native powerpc64-linux gcc can not compile a ppc32 kernel properly. This
patch fixes it. It was copied from ppc64. The change to vmlinux.lds.S
fixes this error:
ld: warning: powerpc:common architecture of input file `init/built-in.o' is
incompatible with powerpc:common64 output
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Paul Mackerras [Mon, 5 Jul 2004 03:23:09 +0000 (20:23 -0700)]
[PATCH] ppc64: RTAS error log locking fix
From: Linas Vepstas <linas@austin.ibm.com>
When an RTAS call returns the "hardware error" code, we need to do another
RTAS call to find out what went wrong. Previously we weren't doing that
inside the lock that serializes RTAS calls, and thus another cpu could get
in and do another RTAS call in the meantime. This patch fixes it. This
patch also includes some minor whitespace fixes.
Signed-off-by: Linas Vepstas <linas@linas.org> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Paul Mackerras [Mon, 5 Jul 2004 03:22:58 +0000 (20:22 -0700)]
[PATCH] ppc64: EEH fixes for POWER5 machines (2/2)
From: Linas Vepstas <linas@austin.ibm.com>
This patch fixes the usage of the slot-error-detail log buffer for the
Power5 architecture. The size of the error buffer is variable, and the
correct size to use should have been obtained from firmware. Failure to
use the correct buffer sizes will result in hard-to-debug system lockups
deep in firmware. This patch is based on an earlier patch from Ben
Herrenschmidt, which essentially did the same thing.
This patch also tweaks some of the subroutine documentation.
Signed-off-by: Linas Vepstas <linas@linas.org> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Paul Mackerras [Mon, 5 Jul 2004 03:22:47 +0000 (20:22 -0700)]
[PATCH] ppc64: EEH fixes for POWER5 machines (1/2)
From: Linas Vepstas <linas@austin.ibm.com>
This patch allows ppc64 to boot on Power5 machines. The new Power5 PCI
bridge design requires EEH (enhanced PCI error handling) to be enabled for
all PCI devices, not just some PCI devices. In addition, this patch moves
the check for PCI to ISA bridges out of perf critical code, and into
initialization code. This also avoids race conditions where the device
type might not have been set. Also, some whitespace fixes, and some
error-message-printing beautification.
Signed-off-by: Linas Vepstas <linas@linas.org> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
projects / linux / log