21 Dec, 2011

3 commits


20 Dec, 2011

1 commit


17 Dec, 2011

2 commits

  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
    sparc32: Be less strict in matching %lo part of relocation.
    sbus: convert drivers/sbus/char/* to use module_platform_driver()
    bbc_i2c: Remove unneeded err variable
    sparc: Use kmemdup rather than duplicating its implementation

    Linus Torvalds
     
  • * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
    ARM: OMAP: rx51: fix USB
    ARM: OMAP: mcbsp: Fix possible memory corruption
    arm/imx: fix power button on imx51 babbage board
    ARM: imx: fix cpufreq build errors
    ARM: mx5: add __initconst for fec pdata
    MXC PWM: should active during DOZE/WAIT/DBG mode
    ARM: EXYNOS: Fix build error without CONFIG_LOCAL_TIMERS
    ARM: EXYNOS: Fix for stall in case of cpu hotplug or sleep
    ARM: S5PV210: Set 1000ns as PWM backlight period on SMDKV210
    ARM: SAMSUNG: remove duplicated header include

    Linus Torvalds
     

16 Dec, 2011

5 commits

  • …kgene/linux-samsung into fixes

    Olof Johansson
     
  • Olof Johansson
     
  • The bisection implemented in unwind_find_origin() stopped to early. If
    there is only a single entry left to check the original code just took
    the end point as origin which might be wrong.

    This was introduced in commit de66a979012d ("ARM: 7187/1: fix unwinding
    for XIP kernels").

    Reported-and-tested-by: Nick Bowler
    Signed-off-by: Uwe Kleine-König
    Signed-off-by: Linus Torvalds

    Uwe Kleine-König
     
  • …kernel/git/konrad/xen

    * 'stable/for-linus-fixes-3.2' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
    xen/swiotlb: Use page alignment for early buffer allocation.
    xen: only limit memory map to maximum reservation for domain 0.

    Linus Torvalds
     
  • d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
    clamped the total amount of RAM to the current maximum reservation. This is
    correct for dom0 but is not correct for guest domains. In order to boot a guest
    "pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
    future memory expansion the guest must derive max_pfn from the e820 provided by
    the toolstack and not the current maximum reservation (which can reflect only
    the current maximum, not the guest lifetime max). The existing algorithm
    already behaves this correctly if we do not artificially limit the maximum
    number of pages for the guest case.

    For a guest booted with maxmem=512, memory=128 this results in:
    [ 0.000000] BIOS-provided physical RAM map:
    [ 0.000000] Xen: 0000000000000000 - 00000000000a0000 (usable)
    [ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved)
    -[ 0.000000] Xen: 0000000000100000 - 0000000008100000 (usable)
    -[ 0.000000] Xen: 0000000008100000 - 0000000020800000 (unusable)
    +[ 0.000000] Xen: 0000000000100000 - 0000000020800000 (usable)
    ...
    [ 0.000000] NX (Execute Disable) protection: active
    [ 0.000000] DMI not present or invalid.
    [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
    [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
    -[ 0.000000] last_pfn = 0x8100 max_arch_pfn = 0x1000000
    +[ 0.000000] last_pfn = 0x20800 max_arch_pfn = 0x1000000
    [ 0.000000] initial memory mapped : 0 - 027ff000
    [ 0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
    -[ 0.000000] init_memory_mapping: 0000000000000000-0000000008100000
    -[ 0.000000] 0000000000 - 0008100000 page 4k
    -[ 0.000000] kernel direct mapping tables up to 8100000 @ 27bb000-27ff000
    +[ 0.000000] init_memory_mapping: 0000000000000000-0000000020800000
    +[ 0.000000] 0000000000 - 0020800000 page 4k
    +[ 0.000000] kernel direct mapping tables up to 20800000 @ 26f8000-27ff000
    [ 0.000000] xen: setting RW the range 27e8000 - 27ff000
    [ 0.000000] 0MB HIGHMEM available.
    -[ 0.000000] 129MB LOWMEM available.
    -[ 0.000000] mapped low ram: 0 - 08100000
    -[ 0.000000] low ram: 0 - 08100000
    +[ 0.000000] 520MB LOWMEM available.
    +[ 0.000000] mapped low ram: 0 - 20800000
    +[ 0.000000] low ram: 0 - 20800000

    With this change "xl mem-set 512M" will successfully increase the
    guest RAM (by reducing the balloon).

    There is no change for dom0.

    Reported-and-Tested-by: George Shuklin
    Signed-off-by: Ian Campbell
    Cc: stable@kernel.org
    Reviewed-by: David Vrabel
    Signed-off-by: Konrad Rzeszutek Wilk

    Ian Campbell
     

15 Dec, 2011

1 commit


14 Dec, 2011

4 commits


13 Dec, 2011

2 commits

  • Commits 09d28d ("ARM: OMAP: mcbsp: Start generalize omap2_mcbsp_set_clks_src")
    and 7bc0c4 ("ARM: OMAP: mcbsp: Start generalize signal muxing functions")
    incorrectly set two struct omap_mcbsp_platform_data fields after
    omap_device_build_ss and kfree calls.

    Fix this by moving these pdata assignments before those calls.

    Signed-off-by: Jarkko Nikula
    Reported-by: NeilBrown
    Signed-off-by: Tony Lindgren

    Jarkko Nikula
     
  • This hangs my MacBook Air at boot time; I get no console
    messages at all. I reverted this on top of -rc5 and my machine
    boots again.

    This reverts commit e8c7106280a305e1ff2a3a8a4dfce141469fb039.

    Signed-off-by: Matt Fleming
    Signed-off-by: Keith Packard
    Acked-by: H. Peter Anvin
    Cc: Matthew Garrett
    Cc: Zhang Rui
    Cc: Huang Ying
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Link: http://lkml.kernel.org/r/1321621751-3650-1-git-send-email-matt@console
    Signed-off-by: Ingo Molnar

    Keith Packard
     

12 Dec, 2011

1 commit


10 Dec, 2011

4 commits

  • efi_call_phys_prelog() sets up a 1:1 mapping of the physical address
    range in swapper_pg_dir. Instead of replacing then restoring entries
    in swapper_pg_dir we should be using initial_page_table which already
    contains the 1:1 mapping.

    It's safe to blindly switch back to swapper_pg_dir in the epilog
    because the physical EFI routines are only called before
    efi_enter_virtual_mode(), e.g. before any user processes have been
    forked. Therefore, we don't need to track which pgd was in %cr3 when
    we entered the prelog.

    The previous code actually contained a bug because it assumed that the
    kernel was loaded at a physical address within the first 8MB of ram,
    usually at 0x100000. However, this isn't the case with a
    CONFIG_RELOCATABLE=y kernel which could have been loaded anywhere in
    the physical address space.

    Also delete the ancient (and bogus) comments about the page table
    being restored after the lock is released. There is no locking.

    Cc: Matthew Garrett
    Cc: Darrent Hart
    Signed-off-by: Matt Fleming
    Link: http://lkml.kernel.org/r/1323346250.3894.74.camel@mfleming-mobl1.ger.corp.intel.com
    Signed-off-by: H. Peter Anvin

    Matt Fleming
     
  • * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
    x86, efi: Calling __pa() with an ioremap()ed address is invalid
    x86, hpet: Immediately disable HPET timer 1 if rtc irq is masked
    x86/intel_mid: Kconfig select fix
    x86/intel_mid: Fix the Kconfig for MID selection

    Linus Torvalds
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
    arch/tile: use new generic {enable,disable}_percpu_irq() routines
    drivers/net/ethernet/tile: use skb_frag_page() API
    asm-generic/unistd.h: support new process_vm_{readv,write} syscalls
    arch/tile: fix double-free bug in homecache_free_pages()
    arch/tile: add a few #includes and an EXPORT to catch up with kernel changes.

    Linus Torvalds
     
  • * 'iommu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
    MAINTAINERS: Update amd-iommu F: patterns
    iommu/amd: Fix typo in kernel-parameters.txt
    iommu/msm: Fix compile error in mach-msm/devices-iommu.c
    Fix comparison using wrong pointer variable in dma debug code

    Linus Torvalds
     

09 Dec, 2011

8 commits

  • With the 3.2-rc kernel, IOMMU 2M pages in KVM works. But when I tried
    to use IOMMU 1GB pages in KVM, I encountered an oops and the 1GB page
    failed to be used.

    The root cause is that 1GB page allocation calls gup_huge_pud() while 2M
    page calls gup_huge_pmd. If compound pages are used and the page is a
    tail page, gup_huge_pmd() increases _mapcount to record tail page are
    mapped while gup_huge_pud does not do that.

    So when the mapped page is relesed, it will result in kernel oops
    because the page is not marked mapped.

    This patch add tail process for compound page in 1GB huge page which
    keeps the same process as 2M page.

    Reproduce like:
    1. Add grub boot option: hugepagesz=1G hugepages=8
    2. mount -t hugetlbfs -o pagesize=1G hugetlbfs /dev/hugepages
    3. qemu-kvm -m 2048 -hda os-kvm.img -cpu kvm64 -smp 4 -mem-path /dev/hugepages
    -net none -device pci-assign,host=07:00.1

    kernel BUG at mm/swap.c:114!
    invalid opcode: 0000 [#1] SMP
    Call Trace:
    put_page+0x15/0x37
    kvm_release_pfn_clean+0x31/0x36
    kvm_iommu_put_pages+0x94/0xb1
    kvm_iommu_unmap_memslots+0x80/0xb6
    kvm_assign_device+0xba/0x117
    kvm_vm_ioctl_assigned_device+0x301/0xa47
    kvm_vm_ioctl+0x36c/0x3a2
    do_vfs_ioctl+0x49e/0x4e4
    sys_ioctl+0x5a/0x7c
    system_call_fastpath+0x16/0x1b
    RIP put_compound_page+0xd4/0x168

    Signed-off-by: Youquan Song
    Reviewed-by: Andrea Arcangeli
    Cc: Andi Kleen
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Youquan Song
     
  • Since commit 6571534 (plat-mxc: iomux-v3.h: implicitly enable
    pull-up/down when that's desired) was in, the power button on imx51
    babbage board stopped working because it's pulled up by mistake.
    The patch removes the pull-up setting from the pad configuration for
    that gpio to make the power button back to work.

    Signed-off-by: Shawn Guo
    Signed-off-by: Sascha Hauer

    Shawn Guo
     
  • CC arch/arm/plat-mxc/cpufreq.o
    arch/arm/plat-mxc/cpufreq.c:203: error: expected declaration specifiers or '...' before string constant
    arch/arm/plat-mxc/cpufreq.c:203: warning: data definition has no type or storage class
    arch/arm/plat-mxc/cpufreq.c:203: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
    arch/arm/plat-mxc/cpufreq.c:203: warning: function declaration isn't a prototype
    arch/arm/plat-mxc/cpufreq.c:204: error: expected declaration specifiers or '...' before string constant
    arch/arm/plat-mxc/cpufreq.c:204: warning: data definition has no type or storage class
    arch/arm/plat-mxc/cpufreq.c:204: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
    arch/arm/plat-mxc/cpufreq.c:204: warning: function declaration isn't a prototype
    arch/arm/plat-mxc/cpufreq.c:205: error: expected declaration specifiers or '...' before string constant
    arch/arm/plat-mxc/cpufreq.c:205: warning: data definition has no type or storage class
    arch/arm/plat-mxc/cpufreq.c:205: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
    arch/arm/plat-mxc/cpufreq.c:205: warning: function declaration isn't a prototype
    make[1]: *** [arch/arm/plat-mxc/cpufreq.o] Error 1
    make: *** [arch/arm/plat-mxc] Error 2

    Signed-off-by: Richard Zhao
    Signed-off-by: Richard Zhao
    Signed-off-by: Sascha Hauer

    Richard Zhao
     
  • Signed-off-by: Dong Aisheng
    Acked-by: Uwe Kleine-König
    Signed-off-by: Sascha Hauer

    Dong Aisheng
     
  • Signed-off-by: Jason Chen
    Signed-off-by: Sascha Hauer
    Cc: stable@kernel.org

    Jason Chen
     
  • If we encounter an efi_memory_desc_t without EFI_MEMORY_WB set
    in ->attribute we currently call set_memory_uc(), which in turn
    calls __pa() on a potentially ioremap'd address.

    On CONFIG_X86_32 this is invalid, resulting in the following
    oops on some machines:

    BUG: unable to handle kernel paging request at f7f22280
    IP: [] reserve_ram_pages_type+0x89/0x210
    [...]

    Call Trace:
    [] ? page_is_ram+0x1a/0x40
    [] reserve_memtype+0xdf/0x2f0
    [] set_memory_uc+0x49/0xa0
    [] efi_enter_virtual_mode+0x1c2/0x3aa
    [] start_kernel+0x291/0x2f2
    [] ? loglevel+0x1b/0x1b
    [] i386_start_kernel+0xbf/0xc8

    A better approach to this problem is to map the memory region
    with the correct attributes from the start, instead of modifying
    it after the fact. The uncached case can be handled by
    ioremap_nocache() and the cached by ioremap_cache().

    Despite first impressions, it's not possible to use
    ioremap_cache() to map all cached memory regions on
    CONFIG_X86_64 because EFI_RUNTIME_SERVICES_DATA regions really
    don't like being mapped into the vmalloc space, as detailed in
    the following bug report,

    https://bugzilla.redhat.com/show_bug.cgi?id=748516

    Therefore, we need to ensure that any EFI_RUNTIME_SERVICES_DATA
    regions are covered by the direct kernel mapping table on
    CONFIG_X86_64. To accomplish this we now map E820_RESERVED_EFI
    regions via the direct kernel mapping with the initial call to
    init_memory_mapping() in setup_arch(), whereas previously these
    regions wouldn't be mapped if they were after the last E820_RAM
    region until efi_ioremap() was called. Doing it this way allows
    us to delete efi_ioremap() completely.

    Signed-off-by: Matt Fleming
    Cc: H. Peter Anvin
    Cc: Matthew Garrett
    Cc: Zhang Rui
    Cc: Huang Ying
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Link: http://lkml.kernel.org/r/1321621751-3650-1-git-send-email-matt@console-pimps.org
    Signed-off-by: Ingo Molnar

    Matt Fleming
     
  • * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (28 commits)
    ARM: sa1100: fix build error
    ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram
    ARM: davinci: dm365 evm: align nand partition table to u-boot
    ARM: davinci: da850 evm: change audio edma event queue to EVENTQ_0
    ARM: davinci: dm646x evm: wrong register used in setup_vpif_input_channel_mode
    ARM: davinci: dm646x does not have a DSP domain
    ARM: davinci: psc: fix incorrect offsets
    ARM: davinci: psc: fix incorrect mask
    ARM: mx28: LRADC macro rename
    arm: mx23: recognise stmp378x as mx23
    ARM: mxs: fix machines' initializers order
    ARM: mxs/tx28: add __initconst for fec pdata
    ARM: S3C64XX: Staticise s3c6400_sysclass
    ARM: S3C64XX: Add linux/export.h to dev-spi.c
    ARM: S3C64XX: Remove extern from definition of framebuffer setup call
    MAINTAINERS: Extend Samsung patterns to cover SPI and ASoC drivers
    MAINTAINERS: Add linux-samsung-soc mailing list for Samsung
    MAINTAINERS: Consolidate Samsung MAINTAINERS
    ARM: CSR: PM: fix build error due to undeclared 'THIS_MODULE'
    ARM: CSR: fix build error due to new mdesc->dma_zone_size
    ...

    Linus Torvalds
     
  • When HPET is operating in RTC mode, the TN_ENABLE bit on timer1
    controls whether the HPET or the RTC delivers interrupts to irq8. When
    the system goes into suspend, the RTC driver sends a signal to the
    HPET driver so that the HPET releases control of irq8, allowing the
    RTC to wake the system from suspend. The switchover is accomplished by
    a write to the HPET configuration registers which currently only
    occurs while servicing the HPET interrupt.

    On some systems, I have seen the system suspend before an HPET
    interrupt occurs, preventing the write to the HPET configuration
    register and leaving the HPET in control of the irq8. As the HPET is
    not active during suspend, it does not generate a wake signal and RTC
    alarms do not work.

    This patch forces the HPET driver to immediately transfer control of
    the irq8 channel to the RTC instead of waiting until the next
    interrupt event.

    Signed-off-by: Mark Langsdorf
    Link: http://lkml.kernel.org/r/20111118153306.GB16319@alberich.amd.com
    Tested-by: Andreas Herrmann
    Signed-off-by: Andreas Herrmann
    Signed-off-by: Thomas Gleixner
    Cc: stable@vger.kernel.org

    Mark Langsdorf
     

08 Dec, 2011

8 commits


07 Dec, 2011

1 commit

  • With this patch the OProfile Basic Mode Sampling support for System z
    is enhanced with a counter file system. That way hardware sampling
    can be configured using the user space tools with only little
    modifications.

    With the patch by default new cpu_types (s390/z10, s390/z196) are
    returned in order to indicate that we are running a CPU which provides
    the hardware sampling facility. Existing user space tools will
    complain about an unknown cpu type. In order to be compatible with
    existing user space tools the `cpu_type' module parameter has been
    added. Setting the parameter to `timer' will force the module to
    return `timer' as cpu_type. The module will still try to use hardware
    sampling if available and the hwsampling virtual filesystem will be
    also be available for configuration. So this has a different effect
    than using the generic oprofile module parameter `timer=1'.

    If the basic mode sampling is enabled on the machine and the
    cpu_type=timer parameter is not used the kernel module will provide
    the following virtual filesystem:

    /dev/oprofile/0/enabled
    /dev/oprofile/0/event
    /dev/oprofile/0/count
    /dev/oprofile/0/unit_mask
    /dev/oprofile/0/kernel
    /dev/oprofile/0/user

    In the counter file system only the values of 'enabled', 'count',
    'kernel', and 'user' are evaluated by the kernel module. Everything
    else must contain fixed values.

    The 'event' value only supports a single event - HWSAMPLING with value
    0.

    The 'count' value specifies the hardware sampling rate as it is passed
    to the CPU measurement facility.

    The 'kernel' and 'user' flags can now be used to filter for samples
    when using hardware sampling.

    Additionally also the following file will be created:
    /dev/oprofile/timer/enabled

    This will always be the inverted value of /dev/oprofile/0/enabled. 0
    is not accepted without hardware sampling.

    Signed-off-by: Andreas Krebbel
    Signed-off-by: Robert Richter

    Andreas Krebbel