16 Jan, 2009

1 commit


08 Jan, 2009

1 commit

  • Device drivers that use pci_request_regions() (and similar APIs) have a
    reasonable expectation that they are the only ones accessing their device.
    As part of the e1000e hunt, we were afraid that some userland (X or some
    bootsplash stuff) was mapping the MMIO region that the driver thought it
    had exclusively via /dev/mem or via various sysfs resource mappings.

    This patch adds the option for device drivers to cause their reserved
    regions to the "banned from /dev/mem use" list, so now both kernel memory
    and device-exclusive MMIO regions are banned.
    NOTE: This is only active when CONFIG_STRICT_DEVMEM is set.

    In addition to the config option, a kernel parameter iomem=relaxed is
    provided for the cases where developers want to diagnose, in the field,
    drivers issues from userspace.

    Reviewed-by: Matthew Wilcox
    Signed-off-by: Arjan van de Ven
    Signed-off-by: Jesse Barnes

    Arjan van de Ven
     

17 Dec, 2008

1 commit

  • Impact: reduce false positives in iomem_map_sanity_check()

    Some drivers (vesafb) only map/reserve a portion of a resource.
    If then some other driver comes in and maps the whole resource,
    the current code WARN_ON's. This is not the intent of the checks
    in iomem_map_sanity_check(); rather these checks want to
    warn when crossing *hardware* resources only.

    This patch skips BUSY resources as suggested by Linus.

    Note: having two drivers talk to the same hardware at the same
    time is obviously not optimal behavior, but that's a separate story.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Ingo Molnar

    Arjan van de Ven
     

02 Nov, 2008

1 commit


29 Oct, 2008

1 commit

  • Impact: avoid false-positive WARN_ON()

    Andi Kleen reported:
    > When running x86info on a 2.6.27-git8 system I get
    >
    > resource map sanity check conflict: 0x9e000 0x9efff 0x10000 0x9e7ff System RAM
    > ------------[ cut here ]------------
    > WARNING: at /home/lsrc/linux/arch/x86/mm/ioremap.c:226 __ioremap_caller+0xf2/0x2d6()
    > ...

    Some of the pages below the 1MB ISA addresses will be shared typically by both
    BIOS and system usable RAM. For example:
    BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
    BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)

    x86info reads the low physical address using /dev/mem, which internally
    uses ioremap() for accessing non RAM pages. ioremap() of such low
    pages conflicts with multiple resource entities leading to the
    above warning.

    Change the iomem_map_sanity_check() to allow mapping a page spanning multiple
    resource entities (minimum granularity that one can map is a page anyhow).

    Signed-off-by: Suresh Siddha
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     

24 Oct, 2008

1 commit


17 Oct, 2008

2 commits

  • * 'core-v28-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    do_generic_file_read: s/EINTR/EIO/ if lock_page_killable() fails
    softirq, warning fix: correct a format to avoid a warning
    softirqs, debug: preemption check
    x86, pci-hotplug, calgary / rio: fix EBDA ioremap()
    IO resources, x86: ioremap sanity check to catch mapping requests exceeding, fix
    IO resources, x86: ioremap sanity check to catch mapping requests exceeding the BAR sizes
    softlockup: Documentation/sysctl/kernel.txt: fix softlockup_thresh description
    dmi scan: warn about too early calls to dmi_check_system()
    generic: redefine resource_size_t as phys_addr_t
    generic: make PFN_PHYS explicitly return phys_addr_t
    generic: add phys_addr_t for holding physical addresses
    softirq: allocate less vectors
    IO resources: fix/remove printk
    printk: robustify printk, update comment
    printk: robustify printk, fix #2
    printk: robustify printk, fix
    printk: robustify printk

    Fixed up conflicts in:
    arch/powerpc/include/asm/types.h
    arch/powerpc/platforms/Kconfig.cputype
    manually.

    Linus Torvalds
     
  • No functional change. Just return NULL for kzalloc failure immediately,
    rather than wrapping the whole function body in the body of an "if".

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     

26 Sep, 2008

2 commits

  • fix this build error:

    kernel/resource.c: In function 'iomem_map_sanity_check':
    kernel/resource.c:842: error: implicit declaration of function 'r_next'
    kernel/resource.c:842: warning: assignment makes pointer from integer without a cast

    r_next() was only available if CONFIG_PROCFS was enabled.

    and fix this build warning:

    kernel/resource.c:855: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
    kernel/resource.c:855: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'long unsigned int'
    kernel/resource.c:855: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
    kernel/resource.c:855: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'resource_size_t'

    resource_t can be 32 bits.

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • Go through the iomem resource tree to check if any of the ioremap()
    requests span more than any slot in the iomem resource tree and do
    a WARN_ON() if we hit this check.

    This will raise a red-flag, if some driver is mapping more than what
    is needed. And hopefully identify possible corruptions much earlier.

    Signed-off-by: Suresh Siddha
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     

05 Sep, 2008

2 commits

  • Andrew Morton noticed that the printk in kernel/resource.c was buggy:

    | start and end have type resource_size_t. Such types CANNOT be printed
    | unless cast to a known type.
    |
    | Because there is a %s following an incorrect %lld, the above code will
    | crash the machine.

    ... and it's probably quite unneeded as well, so remove it.

    Reported-by: Andrew Morton
    Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • add reserve_region_with_split() to not lose e820 reserved entries if
    they overlap with existing IO regions:

    with test case by extend 0xe0000000 - 0xeffffff to 0xdd800000 -
    we get:
    e0000000-efffffff : PCI MMCONFIG 0
    e0000000-efffffff : reserved

    and in /proc/iomem we get:
    found conflict for reserved [dd800000, efffffff], try to reserve with split
    __reserve_region_with_split: (PCI Bus #80) [dd000000, ddffffff], res: (reserved) [dd800000, efffffff]
    __reserve_region_with_split: (PCI Bus #00) [de000000, dfffffff], res: (reserved) [de000000, efffffff]
    initcall pci_subsys_init+0x0/0x121 returned 0 after 381 msecs
    in dmesg

    various fixes and improvements suggested by Linus.

    Signed-off-by: Yinghai Lu
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     

03 Sep, 2008

1 commit


30 Aug, 2008

1 commit


31 Jul, 2008

1 commit

  • Avoid one-off errors by introducing a resource_size() function.

    Signed-off-by: Magnus Damm
    Cc: Ben Dooks
    Cc: Jean Delvare
    Cc: Paul Mundt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Magnus Damm
     

29 Apr, 2008

1 commit


21 Apr, 2008

1 commit

  • Done per Linus' request and suggestions. Linus has explained that
    better than I'll be able to explain:

    On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote:
    > Actually, before we go any further, there might be a less intrusive
    > alternative: add just a couple of flags to the resource flags field (we
    > still have something like 8 unused bits on 32-bit), and use those to
    > implement a generic "resource_alignment()" routine.
    >
    > Two flags would do it:
    >
    > - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device
    > resources)
    >
    > - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources
    > during probing)
    >
    > and then the case of both flags zero (or both bits set) would actually be
    > "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we
    > actually allocate the resource (so that we don't use the "start" field as
    > alignment incorrectly when it no longer indicates alignment).
    >
    > That wouldn't be totally generic, but it would have the nice property of
    > automatically at least add sanity checking for that whole "res->start has
    > the odd meaning of 'alignment' during probing" and remove the need for a
    > new field, and it would allow us to have a generic "resource_alignment()"
    > routine that just gets a resource pointer.

    Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages.

    Signed-off-by: Ivan Kokshaysky
    Cc: Linus Torvalds
    Cc: Gary Hade
    Signed-off-by: Greg Kroah-Hartman

    Ivan Kokshaysky
     

08 Feb, 2008

1 commit

  • walk_memory_resource() verifies if there are holes in a given memory
    range, by checking against /proc/iomem. On x86/ia64 system memory is
    represented in /proc/iomem. On powerpc, we don't show system memory as
    IO resource in /proc/iomem - instead it's maintained in
    /proc/device-tree.

    This provides a way for an architecture to provide its own
    walk_memory_resource() function. On powerpc, the memory region is
    small (16MB), contiguous and non-overlapping. So extra checking
    against the device-tree is not needed.

    Signed-off-by: Badari Pulavarty
    Acked-by: KAMEZAWA Hiroyuki
    Cc: Dave Hansen
    Cc: Benjamin Herrenschmidt
    Cc: Kumar Gala
    Signed-off-by: Andrew Morton
    Signed-off-by: Paul Mackerras

    Badari Pulavarty
     

15 Nov, 2007

1 commit

  • i386 and x86-64 registers System RAM as IORESOURCE_MEM | IORESOURCE_BUSY.

    But ia64 registers it as IORESOURCE_MEM only.
    In addition, memory hotplug code registers new memory as IORESOURCE_MEM too.

    This difference causes a failure of memory unplug of x86-64. This patch
    fixes it.

    This patch adds IORESOURCE_BUSY to avoid potential overlap mapping by PCI
    device.

    Signed-off-by: Yasunori Goto
    Signed-off-by: Badari Pulavarty
    Cc: Luck, Tony"
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Yasunori Goto
     

17 Oct, 2007

1 commit

  • A clean up patch for "scanning memory resource [start, end)" operation.

    Now, find_next_system_ram() function is used in memory hotplug, but this
    interface is not easy to use and codes are complicated.

    This patch adds walk_memory_resouce(start,len,arg,func) function.
    The function 'func' is called per valid memory resouce range in [start,pfn).

    [pbadari@us.ibm.com: Error handling in walk_memory_resource()]
    Signed-off-by: KAMEZAWA Hiroyuki
    Signed-off-by: Badari Pulavarty
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KAMEZAWA Hiroyuki
     

29 Apr, 2007

1 commit

  • Both old-IDE and libata should be able handle all controllers and
    devices found using normal resource reservation methods.

    This eliminates the awful, low-performing split-driver configuration
    where old-IDE drove the PATA portion of a PCI device, in PIO-only mode,
    and libata drove the SATA portion of the /same/ PCI device, in DMA mode.
    Typically vendors would ship SATA hard drive / PATA optical
    configuration, which would lend itself to slow (PIO-only) CD-ROM
    performance.

    For Intel users running in combined mode, it is now wholly dependent on
    your driver choice (potentially link order, if you compile both drivers
    in) whether old-IDE or libata will drive your hardware.

    In either case, you will get full performance from both SATA and PATA
    ports now, without having to pass a kernel command line parameter.

    Signed-off-by: Jeff Garzik

    Jeff Garzik
     

15 Feb, 2007

1 commit

  • After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

10 Feb, 2007

1 commit

  • Implement device resource management, in short, devres. A device
    driver can allocate arbirary size of devres data which is associated
    with a release function. On driver detach, release function is
    invoked on the devres data, then, devres data is freed.

    devreses are typed by associated release functions. Some devreses are
    better represented by single instance of the type while others need
    multiple instances sharing the same release function. Both usages are
    supported.

    devreses can be grouped using devres group such that a device driver
    can easily release acquired resources halfway through initialization
    or selectively release resources (e.g. resources for port 1 out of 4
    ports).

    This patch adds devres core including documentation and the following
    managed interfaces.

    * alloc/free : devm_kzalloc(), devm_kzfree()
    * IO region : devm_request_region(), devm_release_region()
    * IRQ : devm_request_irq(), devm_free_irq()
    * DMA : dmam_alloc_coherent(), dmam_free_coherent(),
    dmam_declare_coherent_memory(), dmam_pool_create(),
    dmam_pool_destroy()
    * PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
    * iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
    devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
    pcim_iomap(), pcim_iounmap()

    Signed-off-by: Tejun Heo
    Signed-off-by: Jeff Garzik

    Tejun Heo
     

08 Dec, 2006

1 commit


03 Oct, 2006

1 commit


27 Sep, 2006

1 commit

  • If you have two resources which aree exactly the same size,
    insert_resource() currently inserts the new one below the existing one.
    This is wrong because there's no way to insert a resource of the same size
    above an existing one.

    I took this opportunity to rewrite the initial loop to be a for-loop
    instead of a goto-loop and fix the documentation.

    Signed-off-by: Matthew Wilcox
    Cc: Ivan Kokshaysky
    Cc: Dominik Brodowski
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Matthew Wilcox
     

06 Aug, 2006

2 commits

  • find_next_system_ram() is used to find available memory resource at onlining
    newly added memory. This patch fixes following problem.

    find_next_system_ram() cannot catch this case.

    Resource: (start)-------------(end)
    Section : (start)-------------(end)

    Signed-off-by: KAMEZAWA Hiroyuki
    Cc: Keith Mannthey
    Cc: Yasunori Goto
    Cc: Dave Hansen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KAMEZAWA Hiroyuki
     
  • find_next_system_ram() returns valid memory range which meets requested area,
    only used by memory-hot-add.

    This function always rewrite requested resource even if returned area is not
    fully fit in requested one. And sometimes the returnd resource is larger than
    requested area. This annoyes the caller. This patch changes the returned
    value to fit in requested area.

    Signed-off-by: KAMEZAWA Hiroyuki
    Cc: Keith Mannthey
    Cc: Yasunori Goto
    Cc: Dave Hansen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KAMEZAWA Hiroyuki
     

13 Jul, 2006

1 commit


01 Jul, 2006

1 commit


30 Jun, 2006

1 commit

  • * master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6:
    [PATCH] i386: export memory more than 4G through /proc/iomem
    [PATCH] 64bit Resource: finally enable 64bit resource sizes
    [PATCH] 64bit Resource: convert a few remaining drivers to use resource_size_t where needed
    [PATCH] 64bit resource: change pnp core to use resource_size_t
    [PATCH] 64bit resource: change pci core and arch code to use resource_size_t
    [PATCH] 64bit resource: change resource core to use resource_size_t
    [PATCH] 64bit resource: introduce resource_size_t for the start and end of struct resource
    [PATCH] 64bit resource: fix up printks for resources in misc drivers
    [PATCH] 64bit resource: fix up printks for resources in arch and core code
    [PATCH] 64bit resource: fix up printks for resources in pcmcia drivers
    [PATCH] 64bit resource: fix up printks for resources in video drivers
    [PATCH] 64bit resource: fix up printks for resources in ide drivers
    [PATCH] 64bit resource: fix up printks for resources in mtd drivers
    [PATCH] 64bit resource: fix up printks for resources in pci core and hotplug drivers
    [PATCH] 64bit resource: fix up printks for resources in networks drivers
    [PATCH] 64bit resource: fix up printks for resources in sound drivers
    [PATCH] 64bit resource: C99 changes for struct resource declarations

    Fixed up trivial conflict in drivers/ide/pci/cmd64x.c (the printk that
    was changed by the 64-bit resources had been deleted in the meantime ;)

    Linus Torvalds
     

28 Jun, 2006

4 commits


11 Jan, 2006

1 commit


08 Sep, 2005

1 commit


26 Jun, 2005

1 commit


17 Apr, 2005

2 commits

  • IXP2000 (ARM-based) platforms use a separate 'struct resource' for PCI MEM
    space. Resource allocation for PCI BARs always fails because the 'root'
    resource (the IXP2000 PCI MEM resource) always has the entire address space
    (00000000-ffffffff) free, and find_resource() calculates the size of that
    range as ffffffff-00000000+1=0, so all allocations fail because it thinks
    there is no space.

    (akpm: pls. double-check)

    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Lennert Buytenhek
     
  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds