Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 09 5月, 2007 9 次提交
  3. 08 5月, 2007 2 次提交
  5. 03 5月, 2007 3 次提交
    • M
      MSI: arch must connect the irq and the msi_desc · 7fe3730d
      由 Michael Ellerman 提交于 
      set_irq_msi() currently connects an irq_desc to an msi_desc. The archs call
it at some point in their setup routine, and then the generic code sets up the
reverse mapping from the msi_desc back to the irq.

set_irq_msi() should do both connections, making it the one and only call
required to connect an irq with it's MSI desc and vice versa.

The arch code MUST call set_irq_msi(), and it must do so only once it's sure
it's not going to fail the irq allocation.

Given that there's no need for the arch to return the irq anymore, the return
value from the arch setup routine just becomes 0 for success and anything else
for failure.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7fe3730d
    • D
      msi: introduce ARCH_SUPPORTS_MSI Kconfig option (rev2) · f282b970
      由 Dan Williams 提交于 
      Allows architectures to advertise that they support MSI rather than listing
each architecture as a PCI_MSI dependency.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f282b970
    • J
      PCI: Cleanup the includes of <linux/pci.h> · 6473d160
      由 Jean Delvare 提交于 
      I noticed that many source files include <linux/pci.h> while they do
not appear to need it. Here is an attempt to clean it all up.

In order to find all possibly affected files, I searched for all
files including <linux/pci.h> but without any other occurence of "pci"
or "PCI". I removed the include statement from all of these, then I
compiled an allmodconfig kernel on both i386 and x86_64 and fixed the
false positives manually.

My tests covered 66% of the affected files, so there could be false
positives remaining. Untested files are:

arch/alpha/kernel/err_common.c
arch/alpha/kernel/err_ev6.c
arch/alpha/kernel/err_ev7.c
arch/ia64/sn/kernel/huberror.c
arch/ia64/sn/kernel/xpnet.c
arch/m68knommu/kernel/dma.c
arch/mips/lib/iomap.c
arch/powerpc/platforms/pseries/ras.c
arch/ppc/8260_io/enet.c
arch/ppc/8260_io/fcc_enet.c
arch/ppc/8xx_io/enet.c
arch/ppc/syslib/ppc4xx_sgdma.c
arch/sh64/mach-cayman/iomap.c
arch/xtensa/kernel/xtensa_ksyms.c
arch/xtensa/platform-iss/setup.c
drivers/i2c/busses/i2c-at91.c
drivers/i2c/busses/i2c-mpc.c
drivers/media/video/saa711x.c
drivers/misc/hdpuftrs/hdpu_cpustate.c
drivers/misc/hdpuftrs/hdpu_nexus.c
drivers/net/au1000_eth.c
drivers/net/fec_8xx/fec_main.c
drivers/net/fec_8xx/fec_mii.c
drivers/net/fs_enet/fs_enet-main.c
drivers/net/fs_enet/mac-fcc.c
drivers/net/fs_enet/mac-fec.c
drivers/net/fs_enet/mac-scc.c
drivers/net/fs_enet/mii-bitbang.c
drivers/net/fs_enet/mii-fec.c
drivers/net/ibm_emac/ibm_emac_core.c
drivers/net/lasi_82596.c
drivers/parisc/hppb.c
drivers/sbus/sbus.c
drivers/video/g364fb.c
drivers/video/platinumfb.c
drivers/video/stifb.c
drivers/video/valkyriefb.c
include/asm-arm/arch-ixp4xx/dma.h
sound/oss/au1550_ac97.c

I would welcome test reports for these files. I am fine with removing
the untested files from the patch if the general opinion is that these
changes aren't safe. The tested part would still be nice to have.

Note that this patch depends on another header fixup patch I submitted
to LKML yesterday:
  [PATCH] scatterlist.h needs types.h
  http://lkml.org/lkml/2007/3/01/141Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6473d160
  7. 28 4月, 2007 1 次提交
  9. 26 4月, 2007 5 次提交
  11. 07 4月, 2007 4 次提交
  13. 31 3月, 2007 4 次提交
    • B
      [IA64] fail mmaps that span areas with incompatible attributes · 6d40fc51
      由 Bjorn Helgaas 提交于 
      Example memory map (from HP sx1000 with VGA enabled):
    0x00000 - 0x9FFFF supports only WB (cacheable) access
    0xA0000 - 0xBFFFF supports only UC (uncacheable) access
    0xC0000 - 0xFFFFF supports only WB (cacheable) access

Some versions of X map the entire 0x00000-0xFFFFF area at once.  With the
example above, this mmap must fail because there's no memory attribute that's
safe for the entire area.

Prior to this patch, we performed the mmap with a UC mapping.  When X
accessed the WB memory at 0xC0000, it caused an MCA.  The crash can happen
when mapping 0xC0000 from either /dev/mem or a /sys/.../legacy_mem file.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      6d40fc51
    • B
      [IA64] allow WB /sys/.../legacy_mem mmaps · 2cb22e23
      由 Bjorn Helgaas 提交于 
      Allow cacheable mmaps of legacy_mem if WB access is supported for the region.
The "legacy_mem" file often contains a shadow option ROM, and some versions of
X depend on this.

Tim Yamin <plasm@roo.me.uk> reported that this change fixes X on a Dell
PowerEdge 3250.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      2cb22e23
    • B
      [IA64] make ioremap avoid unsupported attributes · 9b50ffb0
      由 Bjorn Helgaas 提交于 
      Example memory map (from HP sx1000 with VGA enabled):
    0x00000 - 0x9FFFF supports only WB (cacheable) access
    0xA0000 - 0xBFFFF supports only UC (uncacheable) access
    0xC0000 - 0xFFFFF supports only WB (cacheable) access

pci_read_rom() indirectly uses ioremap(0xC0000) to read the shadow VGA option
ROM.  ioremap() used to default to a 16MB or 64MB UC kernel identity mapping,
which would cause an MCA when reading 0xC0000 since only WB is supported there.

X uses reads the option ROM to initialize devices.  A smaller test case is:
  # echo 1 > /sys/bus/pci/devices/0000:aa:03.0/rom
  # cp /sys/bus/pci/devices/0000:aa:03.0/rom x

To avoid this, we can use the same ioremap_page_range() strategy that most
architectures use for all ioremaps.  These page table mappings come out of the
vmalloc area.  On ia64, these are in region 5 (0xA... addresses) and typically
use 16KB or 64KB mappings instead of 16MB or 64MB mappings.  The smaller
mappings give more flexibility to use the correct attributes.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      9b50ffb0
    • B
      [IA64] rename ioremap variables to match i386 · c4add2e5
      由 Bjorn Helgaas 提交于 
      No functional change, just use the same names as i386.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      c4add2e5
  15. 30 3月, 2007 4 次提交
  17. 29 3月, 2007 1 次提交
  19. 21 3月, 2007 5 次提交
    • B
      [IA64] Fix wrong /proc/iomem on SGI Altix · 58a69c36
      由 Bernhard Walle 提交于 
      In sn_io_slot_fixup(), the parent is re-set from the bus to
io(port|mem)_resource because the address is changed in a way that it's not
child of the bus any more.

However, only the root is set but not the parent/child/sibling relationship in
the resource tree which causes 'cat /proc/iomem' to stop after this memory
area. Depding on the poition in the tree the iomem may be nearly completely
empty.
Signed-off-by: NBernhard Walle <bwalle@suse.de>
Acked-by: NJohn Keller <jpk@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      58a69c36
    • J
      [IA64] Altix: ioremap vga_console_iobase · 0bdfc190
      由 John Keller 提交于 
      When booting an SN system without specifing a console
(i.e., no "console=" on boot line), the system will hang during
boot at the point where /sbin/init is run.

The problem is that vga_console_iobase is not converted to a
virtual address before storing in io_space[0].mmio_base.
The conversion was happening in sn_scan_pcdp(), but not in
setup_vga_console().
Signed-off-by: NJohn Keller <jpk@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      0bdfc190
    • J
      [IA64] Fix typo/thinko in crash.c · 60b548df
      由 Jay Lan 提交于 
      Clearly should be checking for "val == DIE_INIT_SLAVE_ENTER".
Signed-off-by: NJay Lan <jlan@sgi.com>
Acked-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      60b548df
    • J
      [IA64] Fix get_model_name() for mixed cpu type systems · c5e83e3f
      由 Jack Steiner 提交于 
      If a system consists of mixed processor types, kmalloc()
can be called before the per-cpu data page is initialized.
If the slab contains sufficient memory, then kmalloc() works
ok. However, if the slabs are empty, slab calls the memory
allocator. This requires per-cpu data (NODE_DATA()) & the
cpu dies.

Also noted by Russ Anderson who had a very similar patch.
Signed-off-by: NJack Steiner <steiner@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      c5e83e3f
    • Z
      [IA64] min_low_pfn and max_low_pfn calculation fix · a3f5c338
      由 Zou Nan hai 提交于 
      We have seen bad_pte_print when testing crashdump on an SN machine in
recent 2.6.20 kernel.  There are tons of bad pte print (pfn < max_low_pfn)
reports when the crash kernel boots up, all those reported bad pages
are inside initmem range; That is because if the crash kernel code and
data happens to be at the beginning of the 1st node. build_node_maps in
discontig.c will bypass reserved regions with filter_rsvd_memory. Since
min_low_pfn is calculated in build_node_map, so in this case, min_low_pfn
will be greater than kernel code and data.

Because pages inside initmem are freed and reused later, we saw
pfn_valid check fail on those pages.

I think this theoretically happen on a normal kernel. When I check
min_low_pfn and max_low_pfn calculation in contig.c and discontig.c.
I found more issues than this.

1. min_low_pfn and max_low_pfn calculation is inconsistent between
contig.c and discontig.c,
min_low_pfn is calculated as the first page number of boot memmap in
contig.c (Why? Though this may work at the most of the time, I don't
think it is the right logic). It is calculated as the lowest physical
memory page number bypass reserved regions in discontig.c.
max_low_pfn is calculated include reserved regions in contig.c. It is
calculated exclude reserved regions in discontig.c.

2. If kernel code and data region is happen to be at the begin or the
end of physical memory, when min_low_pfn and max_low_pfn calculation is
bypassed kernel code and data, pages in initmem will report bad.

3. initrd is also in reserved regions, if it is at the begin or at the
end of physical memory, kernel will refuse to reuse the memory. Because
the virt_addr_valid check in free_initrd_mem.

So it is better to fix and clean up those issues.
Calculate min_low_pfn and max_low_pfn in a consistent way.
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
Acked-by: NJay Lan <jlan@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      a3f5c338
  21. 20 3月, 2007 1 次提交
    • L
      ACPI: IA64: fix allnoconfig build · 8140a90e
      由 Len Brown 提交于 
      The evils of Kconfig's select bite us once again...
ia64/Kconfig selects ACPI, which depends on PM.
But select ignores dependencies, allnoconfig
chooses CONFIG_PM=n, and thus the menu of sub-options
under ACPI vanish, which breaks the build.

Manually select PM along with ACPI for now.
Some day, we should delete them both, or fix select.

Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
      8140a90e
  23. 19 3月, 2007 1 次提交