Eric Lee / smarc-fsl-linux-kernel

16 Dec, 2011

2 commits

14 Dec, 2011

2 commits

13 Dec, 2011

1 commit

  • 0c8551e5f   ARM: OMAP: mcbsp: Fix possible memory corruption ... Browse Code »

    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
     

10 Dec, 2011

3 commits

09 Dec, 2011

8 commits

  • b6999b191   thp: add compound tail page _mapcount when mapped ... Browse Code »
    87

    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
     
  • 847a2ee73   arm/imx: fix power button on imx51 babbage board ... Browse Code »

    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
     
  • 300a47b43   ARM: imx: fix cpufreq build errors ... Browse Code »

    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
     
  • 16b3647d3   ARM: mx5: add __initconst for fec pdata ... Browse Code »

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

    Dong Aisheng
     
  • c0d96aed8   MXC PWM: should active during DOZE/WAIT/DBG mode ... Browse Code »
    1

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

    Jason Chen
     
  • e8c710628   x86, efi: Calling __pa() with an ioremap()ed address is invalid ... Browse Code »

    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
     
  • 8bd1c8815   Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc ... Browse Code »

    * '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
     
  • 2ded6e6a9   x86, hpet: Immediately disable HPET timer 1 if rtc irq is masked ... Browse Code »
    1

    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

2 commits

06 Dec, 2011

14 commits