Dely Sy [Wed, 6 Oct 2004 05:55:35 +0000 (22:55 -0700)]
[PATCH] PCI Hotplug: Bug fixes for shpchp driver
Can you please apply the following patch that has bug fixes for shpchp
driver? One bug was writing 1's to RsvdZ in Slot Status register
causing hot-plugging of PCI-X cards not working in some slots. The
other fix is for getting the correct bus number.
Signed-off-by: Dely Sy <dely.l.sy@intel.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Dely Sy [Wed, 6 Oct 2004 05:51:12 +0000 (22:51 -0700)]
[PATCH] PCI Hotplug: change bus speed patch
Greg,
Here is a patch (against 2.6.8-rc2) that fixes the following things:
1) adds code to lower bus speed if the adapter card added run at a
lower speed that the current bus speed; 2) checks for any devices on
the same bus - not just those that sit on slots controlled by the same
shpc; 3) cleans up the code in the check bus speed area in board_added()
by creating two functions to handle common code.
Signed-off-by: Dely Sy <dely.l.sy@intel.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Kenji Kaneshige [Wed, 6 Oct 2004 05:50:32 +0000 (22:50 -0700)]
[PATCH] PCI: warn of missing pci_disable_device()
As mentioned in Documentaion/pci.txt, pci device driver should call
pci_disable_device() when it decides to stop using the device. But
there are some drivers that don't use pci_disable_device() so far.
This patch adds warning messages that are displayed if the device is
removed without properly calling pci_disable_device().
'WARN_ON(1)' is commented out for now because I guess many people
(including some distros) enables 'CONFIG_DEBUG_KERNEL'. People might
be surprised if many stack dumps are displayed on their console.
John Rose [Wed, 6 Oct 2004 05:38:06 +0000 (22:38 -0700)]
[PATCH] PCI Hotplug: add host bridges to RPA hotplug subsystem
The following patch implements the registration of PCI Host Bridges as hotplug
slots. Only host bridges that are dynamically removable will be registered.
The hotplug slots directory goes from looking like this:
# ls /sys/bus/pci/slots
. 0000:00:02.2 0001:00:02.4 0002:00:02.2 30000000
.. 0000:00:02.4 0001:00:02.6 0002:00:02.4 control
0000:00:02.0 0001:00:02.2 0002:00:02.0 0002:00:02.6
to this:
# ls /sys/bus/pci/slots
. 0000:00:02.0 0001:00:00.0 0001:00:02.6 0002:00:02.2 30000000
.. 0000:00:02.2 0001:00:02.2 0002:00:00.0 0002:00:02.4 control
0000:00:00.0 0000:00:02.4 0001:00:02.4 0002:00:02.0 0002:00:02.6
This work is precursory to the DLPAR module changes that implement
addition/removal of these bridges. Please apply if there are no objections.
Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Andrew Morton [Wed, 6 Oct 2004 05:25:07 +0000 (22:25 -0700)]
[PATCH] add-pci_fixup_enable-pass.patch
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Nick Piggin's USB driver stopped working when I removed the unconditional
PCI ACPI IRQ routing stuff. He has verified that the attached patch fixes
it. I sort of hate to add another pass of PCI fixups, so I'm open to
alternate solutions if anybody suggests one.
Add a "pci_fixup_enable" pass of PCI fixups. These are run at the end of
pci_enable_device() to fix up things like IRQs that are not set up until
then. Some VIA boards require a fixup after the IRQ is set up. Found by
Nick Piggin, initial patch by Bjorn Helgaas, reworked to fit into current
-mm by Nick.
Signed-off-by: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Li Shaohua [Wed, 6 Oct 2004 04:50:52 +0000 (21:50 -0700)]
[PATCH] PCI: Reorder some initialization code to allow resources to be proper allocated.
On Tuesday, August 31, 2004, Linus Torvalds wrote:
> That list per se obviously looks ok by me, although I'd worry that some
> other fs_initcall depends on the ACPI stuff having been run (ie while the
> abover ordering is great, I worry that some _other_ part doesn't fit in
> the above ordering). Doing a quick check finds "chr_dev_init()", for
> example, which will do fbmem_init(), which might depend on the ACPI/PnP
> stuff having run already.
>
> So it _might_ be safer to make this ordering more explicit, rather than
Yes, I agree. The problem is there isn't a straightforward method for
it. It possibly is hard to get it.
> depending on the different phases of the initcalls. But I'd happily be
> proven wrogn with some simple argument for why this is guaranteed to be
> ok.. For example, maybe ACPI and PnP is linked before chr/mem.c, in which
> case it should all be ok.
Original PCI assign resources code is the last 'subsys_initcall'
according to the makefile, so move some code of it to 'fs_initcall'
(just below 'subsystem_initcall') should be ok. As you said, ACPI and
PnP is linked before chr/mem.c. The method requires all other
'fs_initcall' don't touch PCI resources, since
'pcibios_assign_resources' is a 'fs_initcall' and maybe don't run, but
it looks ok currently. Again, I will be appreciated if we can find a
solution to make the ordering explicit.
David Brownell [Wed, 6 Oct 2004 04:50:24 +0000 (21:50 -0700)]
[PATCH] PCI: update Documentation/power/pci.txt
That document was wrong on some things, misleading on others; this
fixes some of the issues I noticed.
However it probably needs to say that drivers for devices that implement
the PCI PM spec "should" always use pci_set_power_state() to reduce the
power usage. If I get ambitions I might submit a patch to the PCI core
to print a nag message for drivers that don't do that.
Updates the PCI PM docs, better matching the specs and code.
- List both D3 states (D3hot, D3cold) up front.
- Clarify that suspend() methods should disable I/0 (including DMA)
and IRQs; it's not optional.
- More accurately describe resume(); there are common cases where
device re-initialization isn't appropriate. The previous text said
re-init was always required; that's false.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Hirokazu Takata [Wed, 6 Oct 2004 01:15:24 +0000 (18:15 -0700)]
[PATCH] m32r: update ioremap routine
Here is a patch to update ioremap*.c for m32r, taken from "Add __iomem
modifier to the return value type of __ioremap() for much stricter
type-checking."
* arch/m32r/mm/ioremap.c: ditto.
- Add __iomem modifier to the return value type of __ioremap()
for much stricter type-checking.
* arch/m32r/mm/ioremap-nommu.c: ditto.
* include/asm-m32r/io.h:
- Modified for much stricter type-checking.
- Change __inline__ to inline.
[PATCH] Disable SW irqbalance/irqaffinity for E7520/E7320/E7525 - change TARGET_CPUS on x86_64
Set TARGET_CPUS on x86_64 to cpu_online_map. This brings the code inline
with x86 mach-default. Fix MSI_TARGET_CPU code which will break with this
target_cpus change.
Andi Kleen [Wed, 6 Oct 2004 01:14:35 +0000 (18:14 -0700)]
[PATCH] x86_64: make in_gate_vma() safer
x86-64 in_gate_vma would take a read lock on the VMA when the passed
address was inside the 32bit vsyscall page.
This would be called by get_user_pages, which already holds the mmap_sem.
Unfortunately some callers of get_user_pages hold the mmap_sem for writing,
which could in theory cause a deadlock.
I think it can currently not happen because the only users who hold it for
write before calling gup() are coredump and AIO in the ring setup, and both
should not ever access the vsyscall page.
But not taking the semaphore is safer and avoid this here.
Andi Kleen [Wed, 6 Oct 2004 01:13:54 +0000 (18:13 -0700)]
[PATCH] x86_64: remove CONFIG_FRAME_POINTER
CONFIG_FRAME_POINTER has never worked on x86-64 because it never passed
-fno-omit-frame-pointer to the compiler, and that is the only way to get a
frame pointer on x86-64.
It also causes complications with profiling. Drop it.
Andi Kleen [Wed, 6 Oct 2004 01:13:42 +0000 (18:13 -0700)]
[PATCH] x86_64: fix profile_pc
This fixes profile_pc to work properly on x86-64 and not crash.
It does now a simple backtrace to the caller of the spin lock without
requiring a frame pointer for this.
Frame pointer support has been dropped because it never worked.
There is still a small race window, but the only way to avoid it would be
to rewrite kernel/spinlock.c in assembler again. The race will account a
profile tick the the parent of the spinlock caller.
David Gibson [Wed, 6 Oct 2004 01:12:54 +0000 (18:12 -0700)]
[PATCH] ppc64: squash EEH warnings
A slightly non-ideal version of the recent patch which fixed EEH being a
no-op went in. The srcsave variable in eeh_memcpy_to_io() is now never
referenced on non-pSeries machines, and so spews hundreds of warnings. The
variable doesn't actually accomplish anything, so this patch gets rid of
it.
Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Gerhard Jaeger [Wed, 6 Oct 2004 01:11:53 +0000 (18:11 -0700)]
[PATCH] ppc32: fix PFC1_EPS and PFC1_EPS_SHIFT for IBM440GX
While writing some BSP code for a 440GX custom board, I noticed, that the
DCRN_SDR_PFC1_EPS and DCRN_SDR_PFC1_EPS_SHIFT definitions are wrong and
therefore the functions ibm440gx_get_eth_grp() and ibm440gx_set_eth_grp()
won't work correctly.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org> Signed-off-by: Gerhard Jaeger <gjaeger@sysgo.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Wed, 6 Oct 2004 00:56:41 +0000 (17:56 -0700)]
[PATCH] trivial usb endianness annotations
trivial endianness annotations in drivers/usb (apply after ohci and isd200
fixes).
Note: drivers/usb is nearly endian-clean at that point; there are several
very dubious places in there (in particular, rtl8150, pegasus and usbnet
are almost certainly broken in mii-related code on big-endian hosts); I'm
leaving them alone for now.
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Wed, 6 Oct 2004 00:56:15 +0000 (17:56 -0700)]
[PATCH] ohci bugfix for big-endian 64bit boxen
->dma can be a 64bit variable on 64bit boxen; its value will fit into 32 bits
just fine (due to dma mask). However, cpu_to_le32p(&...) will break if we
are on a 64bit big-endian; we'll end up up passing it the address of upper
32 bits and get 0 instead of correct value. Fix is trivial...
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Wed, 6 Oct 2004 00:56:03 +0000 (17:56 -0700)]
[PATCH] hfsplus endianness bugfix
hfs_bnode_read_u8() always returns 0 on little-endian (cut'n'paste bug -
function is almost exact copy of its u16 counterpart, but be16_to_cpu()
should've been removed here).
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Wed, 6 Oct 2004 00:54:02 +0000 (17:54 -0700)]
[PATCH] ncpfs (7/7): misc fixes and cleanups
* remaining endiannes cleanups
* don't mess with setting finfo.i.dataStreamSize when creating the root
directory inode; that field is ignored when populating in-core directory
inodes.
* missing cpu_to_le16() in ncp_search_for_fileset() (for big-endian clients
server sees 0xff7f instead of intended 0x7fff).
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Wed, 6 Oct 2004 00:53:38 +0000 (17:53 -0700)]
[PATCH] ncpfs (5/7): le16 handling in marshalling
New helper: ncp_reply_le16() (decode 16bit little-endian).
ConvertToNWfromDWORD() cleaned up and fixed (it used to have one too many
le16_to_cpu() in arithmetics, on top of ugly tricks with memcpy() et.al.).
ncp_reply_word() has no callers left; removed.
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alexander Viro [Wed, 6 Oct 2004 00:52:50 +0000 (17:52 -0700)]
[PATCH] ncpfs (1/7): constants sanitized
That's the beginning of ncpfs endianness cleanup.
* converted fixed-endian constants to little-endian (i.e. replaced
htons(0xCDAB) with cpu_to_le16(0xABCD), etc.). These guys _are_ little-endian
and make much more sense that way, even aside of annotation issues.
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Herbert Xu [Tue, 5 Oct 2004 15:01:33 +0000 (08:01 -0700)]
[TCP]: Fix bug that hid sockets in tcp_diag
This patch squashes a bug in tcp_diag which was created when the
sk_* loops replaced the original for loops. It's a pity that these
sk_*/hlist_*/list_* loops don't take an arbitrary expression as an
argument for continue.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
We broke ECN encapsulation in tunnels recently.
Without this patch, even though encapusulated (inner) packet is
'not-ECN', encapusulating (outer) packet is sent with 'ECT(0)' set.
This is wrong and should be 'not-ECN.'
This patch fixes up.
From RFC3168:
The full-functionality option for ECN encapsulation is to copy the
ECN codepoint of the inside header to the outside header on
encapsulation if the inside header is not-ECT or ECT, and to set the
ECN codepoint of the outside header to ECT(0) if the ECN codepoint of
the inside header is CE.
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Herbert Xu [Tue, 5 Oct 2004 14:58:06 +0000 (07:58 -0700)]
[TCP]: Show all SYN_RECV sockets in /proc/net/tcp
I was fixing the tcp_diag so that it shows SYN_RECV sockets properly.
I found that /proc/net/tcp didn't do it correctly either. So here is
a small patch to fix /proc/net/tcp.
The logic in there stinks though so I'd love to see a rewrite.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / linux / log