1. 20 8月, 2015 1 次提交
  2. 18 8月, 2015 2 次提交
    • M
      ARM: 8418/1: add boot image dependencies to not generate invalid images · 3939f334
      Masahiro Yamada 提交于
      U-Boot is often used to boot the kernel on ARM boards, but uImage
      is not built by "make all", so we are often inclined to do
      "make all uImage" to generate DTBs, modules and uImage in a single
      command, but we should notice a pitfall behind it.  In fact,
      "make all uImage" could generate an invalid uImage if it is run with
      the parallel option (-j).
      
      You can reproduce this problem with the following procedure:
      
      [1] First, build "all" and "uImage" separately.
          You will get a valid uImage
      
        $ git clean -f -x -d
        $ export CROSS_COMPILE=<your-tools-prefix>
        $ make -s -j8 ARCH=arm multi_v7_defconfig
        $ make -s -j8 ARCH=arm all
        $ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage
          CHK     include/config/kernel.release
          CHK     include/generated/uapi/linux/version.h
          CHK     include/generated/utsrelease.h
        make[1]: `include/generated/mach-types.h' is up to date.
          CHK     include/generated/timeconst.h
          CHK     include/generated/bounds.h
          CHK     include/generated/asm-offsets.h
          CALL    scripts/checksyscalls.sh
          CHK     include/generated/compile.h
          Kernel: arch/arm/boot/Image is ready
          Kernel: arch/arm/boot/zImage is ready
          UIMAGE  arch/arm/boot/uImage
        Image Name:   Linux-4.2.0-rc5-00156-gdd2384a7-d
        Created:      Sat Aug  8 23:21:35 2015
        Image Type:   ARM Linux Kernel Image (uncompressed)
        Data Size:    6138648 Bytes = 5994.77 kB = 5.85 MB
        Load Address: 80208000
        Entry Point:  80208000
          Image arch/arm/boot/uImage is ready
        $ ls -l arch/arm/boot/*Image
        -rwxrwxr-x 1 masahiro masahiro 13766656 Aug  8 23:20 arch/arm/boot/Image
        -rw-rw-r-- 1 masahiro masahiro  6138712 Aug  8 23:21 arch/arm/boot/uImage
        -rwxrwxr-x 1 masahiro masahiro  6138648 Aug  8 23:20 arch/arm/boot/zImage
      
      [2] Update some source file(s)
      
        $ touch init/main.c
      
      [3] Then, re-build "all" and "uImage" simultaneously.
          You will get an invalid uImage at random.
      
        $ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 all uImage
          CHK     include/config/kernel.release
          CHK     include/generated/uapi/linux/version.h
          CHK     include/generated/utsrelease.h
        make[1]: `include/generated/mach-types.h' is up to date.
          CHK     include/generated/timeconst.h
          CHK     include/generated/bounds.h
          CHK     include/generated/asm-offsets.h
          CALL    scripts/checksyscalls.sh
          CC      init/main.o
          CHK     include/generated/compile.h
          LD      init/built-in.o
          LINK    vmlinux
          LD      vmlinux.o
          MODPOST vmlinux.o
          GEN     .version
          CHK     include/generated/compile.h
          UPD     include/generated/compile.h
          CC      init/version.o
          LD      init/built-in.o
          KSYM    .tmp_kallsyms1.o
          KSYM    .tmp_kallsyms2.o
          LD      vmlinux
          SORTEX  vmlinux
          SYSMAP  System.map
          OBJCOPY arch/arm/boot/Image
          Building modules, stage 2.
          Kernel: arch/arm/boot/Image is ready
          GZIP    arch/arm/boot/compressed/piggy.gzip
          AS      arch/arm/boot/compressed/piggy.gzip.o
          Kernel: arch/arm/boot/Image is ready
          LD      arch/arm/boot/compressed/vmlinux
          GZIP    arch/arm/boot/compressed/piggy.gzip
          OBJCOPY arch/arm/boot/zImage
          Kernel: arch/arm/boot/zImage is ready
          UIMAGE  arch/arm/boot/uImage
        Image Name:   Linux-4.2.0-rc5-00156-gdd2384a7-d
        Created:      Sat Aug  8 23:23:14 2015
        Image Type:   ARM Linux Kernel Image (uncompressed)
        Data Size:    26472 Bytes = 25.85 kB = 0.03 MB
        Load Address: 80208000
        Entry Point:  80208000
          Image arch/arm/boot/uImage is ready
          MODPOST 192 modules
          AS      arch/arm/boot/compressed/piggy.gzip.o
          LD      arch/arm/boot/compressed/vmlinux
          OBJCOPY arch/arm/boot/zImage
          Kernel: arch/arm/boot/zImage is ready
        $ ls -l arch/arm/boot/*Image
        -rwxrwxr-x 1 masahiro masahiro 13766656 Aug  8 23:23 arch/arm/boot/Image
        -rw-rw-r-- 1 masahiro masahiro    26536 Aug  8 23:23 arch/arm/boot/uImage
        -rwxrwxr-x 1 masahiro masahiro  6138648 Aug  8 23:23 arch/arm/boot/zImage
      
      Please notice the uImage is extremely small when this issue is
      encountered.  Besides, "Kernel: arch/arm/boot/zImage is ready" is
      displayed twice, before and after the uImage log.
      
      The root cause of this is the race condition between zImage and
      uImage.  Actually, uImage depends on zImage, but the dependency
      between the two is only described in arch/arm/boot/Makefile.
      Because arch/arm/boot/Makefile is not included from the top-level
      Makefile, it cannot know the dependency between zImage and uImage.
      
      Consequently, when we run make with the parallel option, Kbuild
      updates vmlinux first, and then two different threads descends into
      the arch/arm/boot/Makefile almost at the same time, one for updating
      zImage and the other for uImage.  While one thread is re-generating
      zImage, the other also tries to update zImage before creating uImage
      on top of that.  zImage is overwritten by the slower thread and then
      uImage is created based on the half-written zImage.
      
      This is the reason why "Kernel: arch/arm/boot/zImage is ready" is
      displayed twice, and a broken uImage is created.
      
      The same problem could happen on bootpImage.
      
      This commit adds dependencies among Image, zImage, uImage, and
      bootpImage to arch/arm/Makefile, which is included from the
      top-level Makefile.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3939f334
    • N
      ARM: 8414/1: __copy_to_user_memcpy: fix mmap semaphore usage · 0f64b247
      Nicolas Pitre 提交于
      The mmap semaphore should not be taken when page faults are disabled.
      Since pagefault_disable() no longer disables preemption, we now need
      to use faulthandler_disabled() in place of in_atomic().
      Signed-off-by: NNicolas Pitre <nico@linaro.org>
      Tested-by: NMark Salter <msalter@redhat.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      0f64b247
  3. 15 8月, 2015 1 次提交
  4. 14 8月, 2015 2 次提交
  5. 11 8月, 2015 1 次提交
    • N
      ARM: 8410/1: VDSO: fix coarse clock monotonicity regression · 09edea4f
      Nathan Lynch 提交于
      Since 906c5557 ("timekeeping: Copy the shadow-timekeeper over the
      real timekeeper last") it has become possible on ARM to:
      
      - Obtain a CLOCK_MONOTONIC_COARSE or CLOCK_REALTIME_COARSE timestamp
        via syscall.
      - Subsequently obtain a timestamp for the same clock ID via VDSO which
        predates the first timestamp (by one jiffy).
      
      This is because ARM's update_vsyscall is deriving the coarse time
      using the __current_kernel_time interface, when it should really be
      using the timekeeper object provided to it by the timekeeping core.
      It happened to work before only because __current_kernel_time would
      access the same timekeeper object which had been passed to
      update_vsyscall.  This is no longer the case.
      
      Cc: stable@vger.kernel.org
      Fixes: 906c5557 ("timekeeping: Copy the shadow-timekeeper over the real timekeeper last")
      Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      09edea4f
  6. 08 8月, 2015 2 次提交
  7. 06 8月, 2015 2 次提交
  8. 05 8月, 2015 5 次提交
  9. 04 8月, 2015 1 次提交
  10. 01 8月, 2015 2 次提交
    • M
      ARM: dts: keystone: fix dt bindings to use post div register for mainpll · c1bfa985
      Murali Karicheri 提交于
      All of the keystone devices have a separate register to hold post
      divider value for main pll clock. Currently the fixed-postdiv
      value used for k2hk/l/e SoCs works by sheer luck as u-boot happens to
      use a value of 2 for this. Now that we have fixed this in the pll
      clock driver change the dt bindings for the same.
      Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com>
      Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      c1bfa985
    • N
      ARM: 8405/1: VDSO: fix regression with toolchains lacking ld.bfd executable · 3473f265
      Nathan Lynch 提交于
      The Sourcery CodeBench Lite 2014.05 toolchain (gcc 4.8.3, binutils
      2.24.51) has a GCC which implements -fuse-ld, and it doesn't include
      the gold linker, but it lacks an ld.bfd executable in its
      installation.  This means that passing -fuse-ld=bfd fails with:
      
            VDSO    arch/arm/vdso/vdso.so.raw
          collect2: fatal error: cannot find 'ld'
      
      Arguably this is a deficiency in the toolchain, but I suspect it's
      commonly used enough that it's worth accommodating: just use
      
      cc-ldoption (to cause a link attempt) instead of cc-option to test
      whether we can use -fuse-ld.  So -fuse-ld=bfd won't be used with this
      toolchain, but the build will rightly succeed, just as it does for
      toolchains which don't implement -fuse-ld (and don't use gold as the
      default linker).
      
      Note: this will change the failure mode for a corner case I was trying
      to handle in d2b30cd4, where the toolchain defaults to the gold
      linker and the BFD linker is not found in PATH, from:
      
            VDSO    arch/arm/vdso/vdso.so.raw
          collect2: fatal error: cannot find 'ld'
      
      i.e. the BFD linker is not found, to:
      
            OBJCOPY arch/arm/vdso/vdso.so
          BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try
          linking with -N
      
      that is, we fail to prevent gold from being used as the linker, and it
      produces an object that objcopy can't digest.
      Reported-by: NBaruch Siach <baruch@tkos.co.il>
      Tested-by: NBaruch Siach <baruch@tkos.co.il>
      Tested-by: NRaphaël Poggi <poggi.raph@gmail.com>
      Fixes: d2b30cd4 ("ARM: 8384/1: VDSO: force use of BFD linker")
      Cc: stable@vger.kernel.org
      Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3473f265
  11. 31 7月, 2015 2 次提交
  12. 30 7月, 2015 1 次提交
  13. 27 7月, 2015 1 次提交
  14. 25 7月, 2015 1 次提交
  15. 24 7月, 2015 6 次提交
  16. 23 7月, 2015 1 次提交
    • R
      ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc · 9a258afa
      Roger Quadros 提交于
      For hwmods without sysc, _init_mpu_rt_base(oh) won't be called and so
      _find_mpu_rt_port(oh) will return NULL thus preventing ready state check
      on those modules after the module is enabled.
      
      This can potentially cause a bus access error if the module is accessed
      before the module is ready.
      
      Fix this by unconditionally calling _init_mpu_rt_base() during hwmod
      _init(). Do ioremap only if we need SYSC access.
      
      Eventhough _wait_target_ready() check doesn't really need MPU RT port but
      just the PRCM registers, we still mandate that the hwmod must have an
      MPU RT port if ready state check needs to be done. Else it would mean that
      the module is not accessible by MPU so there is no point in waiting
      for target to be ready.
      
      e.g. this fixes the below DCAN bus access error on AM437x-gp-evm.
      
      [   16.672978] ------------[ cut here ]------------
      [   16.677885] WARNING: CPU: 0 PID: 1580 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x234/0x35c()
      [   16.687946] 44000000.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_PER_0 (Read): Data Access in User mode during Functional access
      [   16.700654] Modules linked in: xhci_hcd btwilink ti_vpfe dwc3 videobuf2_core ov2659 bluetooth v4l2_common videodev ti_am335x_adc kfifo_buf industrialio c_can_platform videobuf2_dma_contig media snd_soc_tlv320aic3x pixcir_i2c_ts c_can dc
      [   16.731144] CPU: 0 PID: 1580 Comm: rpc.statd Not tainted 3.14.26-02561-gf733aa036398 #180
      [   16.739747] Backtrace:
      [   16.742336] [<c0011108>] (dump_backtrace) from [<c00112a4>] (show_stack+0x18/0x1c)
      [   16.750285]  r6:00000093 r5:00000009 r4:eab5b8a8 r3:00000000
      [   16.756252] [<c001128c>] (show_stack) from [<c05a4418>] (dump_stack+0x20/0x28)
      [   16.763870] [<c05a43f8>] (dump_stack) from [<c0037120>] (warn_slowpath_common+0x6c/0x8c)
      [   16.772408] [<c00370b4>] (warn_slowpath_common) from [<c00371e4>] (warn_slowpath_fmt+0x38/0x40)
      [   16.781550]  r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210
      [   16.788626] [<c00371b0>] (warn_slowpath_fmt) from [<c027fa94>] (l3_interrupt_handler+0x234/0x35c)
      [   16.797968]  r3:ed0cd480 r2:c0730508
      [   16.801747] [<c027f860>] (l3_interrupt_handler) from [<c0063758>] (handle_irq_event_percpu+0x54/0x1bc)
      [   16.811533]  r10:ed005600 r9:c084855b r8:0000002a r7:00000000 r6:00000000 r5:0000002a
      [   16.819780]  r4:ed0e6d80
      [   16.822453] [<c0063704>] (handle_irq_event_percpu) from [<c00638f0>] (handle_irq_event+0x30/0x40)
      [   16.831789]  r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6:00000000 r5:0000002a
      [   16.840052]  r4:ed005600
      [   16.842744] [<c00638c0>] (handle_irq_event) from [<c00661d8>] (handle_fasteoi_irq+0x74/0x128)
      [   16.851702]  r4:ed005600 r3:00000000
      [   16.855479] [<c0066164>] (handle_fasteoi_irq) from [<c0063068>] (generic_handle_irq+0x28/0x38)
      [   16.864523]  r4:0000002a r3:c0066164
      [   16.868294] [<c0063040>] (generic_handle_irq) from [<c000ef60>] (handle_IRQ+0x38/0x8c)
      [   16.876612]  r4:c081c640 r3:00000202
      [   16.880380] [<c000ef28>] (handle_IRQ) from [<c00084f0>] (gic_handle_irq+0x30/0x5c)
      [   16.888328]  r6:eab5ba38 r5:c0804460 r4:fa24010c r3:00000100
      [   16.894303] [<c00084c0>] (gic_handle_irq) from [<c05a8d80>] (__irq_svc+0x40/0x50)
      [   16.902193] Exception stack(0xeab5ba38 to 0xeab5ba80)
      [   16.907499] ba20:                                                       00000000 00000006
      [   16.916108] ba40: fa1d0000 fa1d0008 ed3d3000 eab5bab4 ed3d3460 c0842af4 bf011420 eb2b6960
      [   16.924716] ba60: eb2b6938 eab5ba8c eab5ba90 eab5ba80 bf035220 bf07702c 600f0013 ffffffff
      [   16.933317]  r7:eab5ba6c r6:ffffffff r5:600f0013 r4:bf07702c
      [   16.939317] [<bf077000>] (c_can_plat_read_reg_aligned_to_16bit [c_can_platform]) from [<bf035220>] (c_can_get_berr_counter+0x38/0x64 [c_can])
      [   16.952696] [<bf0351e8>] (c_can_get_berr_counter [c_can]) from [<bf010294>] (can_fill_info+0x124/0x15c [can_dev])
      [   16.963480]  r5:ec8c9740 r4:ed3d3000
      [   16.967253] [<bf010170>] (can_fill_info [can_dev]) from [<c0502fa8>] (rtnl_fill_ifinfo+0x58c/0x8fc)
      [   16.976749]  r6:ec8c9740 r5:ed3d3000 r4:eb2b6780
      [   16.981613] [<c0502a1c>] (rtnl_fill_ifinfo) from [<c0503408>] (rtnl_dump_ifinfo+0xf0/0x1dc)
      [   16.990401]  r10:ec8c9740 r9:00000000 r8:00000000 r7:00000000 r6:ebd4d1b4 r5:ed3d3000
      [   16.998671]  r4:00000000
      [   17.001342] [<c0503318>] (rtnl_dump_ifinfo) from [<c050e6e4>] (netlink_dump+0xa8/0x1e0)
      [   17.009772]  r10:00000000 r9:00000000 r8:c0503318 r7:ebf3e6c0 r6:ebd4d1b4 r5:ec8c9740
      [   17.018050]  r4:ebd4d000
      [   17.020714] [<c050e63c>] (netlink_dump) from [<c050ec10>] (__netlink_dump_start+0x104/0x154)
      [   17.029591]  r6:eab5bd34 r5:ec8c9980 r4:ebd4d000
      [   17.034454] [<c050eb0c>] (__netlink_dump_start) from [<c0505604>] (rtnetlink_rcv_msg+0x110/0x1f4)
      [   17.043778]  r7:00000000 r6:ec8c9980 r5:00000f40 r4:ebf3e6c0
      [   17.049743] [<c05054f4>] (rtnetlink_rcv_msg) from [<c05108e8>] (netlink_rcv_skb+0xb4/0xc8)
      [   17.058449]  r8:eab5bdac r7:ec8c9980 r6:c05054f4 r5:ec8c9980 r4:ebf3e6c0
      [   17.065534] [<c0510834>] (netlink_rcv_skb) from [<c0504134>] (rtnetlink_rcv+0x24/0x2c)
      [   17.073854]  r6:ebd4d000 r5:00000014 r4:ec8c9980 r3:c0504110
      [   17.079846] [<c0504110>] (rtnetlink_rcv) from [<c05102ac>] (netlink_unicast+0x180/0x1ec)
      [   17.088363]  r4:ed0c6800 r3:c0504110
      [   17.092113] [<c051012c>] (netlink_unicast) from [<c0510670>] (netlink_sendmsg+0x2ac/0x380)
      [   17.100813]  r10:00000000 r8:00000008 r7:ec8c9980 r6:ebd4d000 r5:eab5be70 r4:eab5bee4
      [   17.109083] [<c05103c4>] (netlink_sendmsg) from [<c04dfdb4>] (sock_sendmsg+0x90/0xb0)
      [   17.117305]  r10:00000000 r9:eab5a000 r8:becdda3c r7:0000000c r6:ea978400 r5:eab5be70
      [   17.125563]  r4:c05103c4
      [   17.128225] [<c04dfd24>] (sock_sendmsg) from [<c04e1c28>] (SyS_sendto+0xb8/0xdc)
      [   17.136001]  r6:becdda5c r5:00000014 r4:ecd37040
      [   17.140876] [<c04e1b70>] (SyS_sendto) from [<c000e680>] (ret_fast_syscall+0x0/0x30)
      [   17.148923]  r10:00000000 r8:c000e804 r7:00000122 r6:becdda5c r5:0000000c r4:becdda5c
      [   17.157169] ---[ end trace 2b71e15b38f58bad ]---
      
      Fixes: 6423d6df ("ARM: OMAP2+: hwmod: check for module address space during init")
      Signed-off-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: <stable@vger.kernel.org>
      9a258afa
  17. 22 7月, 2015 3 次提交
  18. 21 7月, 2015 2 次提交
  19. 18 7月, 2015 2 次提交
  20. 17 7月, 2015 2 次提交