1. 24 6月, 2012 2 次提交
  2. 22 6月, 2012 6 次提交
    • R
      ARM: OMAP4: hwmod data: Force HDMI in no-idle while enabled · dc57aef5
      Ricardo Neri 提交于
      As per the OMAP4 documentation, audio over HDMI must be transmitted in
      no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmod uses
      no-idle/force-idle settings instead of smart-idle mode.
      
      This is required as the DSS interface clock is used as functional clock
      for the HDMI wrapper audio FIFO. If no-idle mode is not used, audio could
      be choppy, have bad quality or not be audible at all.
      Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
      [b-cousson@ti.com: Update the subject and align the .flags
      location with the script template]
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      dc57aef5
    • P
      ARM: OMAP2+: mux: fix sparse warning · 65e25976
      Paul Walmsley 提交于
      Commit bbd707ac ("ARM: omap2: use
      machine specific hook for late init") resulted in the addition of this
      sparse warning:
      
      arch/arm/mach-omap2/mux.c:791:12: warning: symbol 'omap_mux_late_init' was not declared. Should it be static?
      
      Fix by including the header file containing the prototype.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Tony Lindgren <tony@atomide.com>
      65e25976
    • P
      ARM: OMAP2+: CM: increase the module disable timeout · b8f15b7e
      Paul Walmsley 提交于
      Increase the timeout for disabling an IP block to five milliseconds.
      This is to handle the usb_host_fs idle latency, which takes almost
      four milliseconds after a host controller reset.
      
      This is the second of two patches needed to resolve the following
      boot warning:
      
      omap_hwmod: usb_host_fs: _wait_target_disable failed
      
      Thanks to Sergei Shtylyov <sshtylyov@mvista.com> for finding
      an unrelated hunk in a previous version of this patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Sergei Shtylyov <sshtylyov@mvista.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      b8f15b7e
    • P
      ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks · 9a47d32d
      Paul Walmsley 提交于
      Until the OMAP4 code is converted to disable the use of the clock
      framework-based clockdomain enable/disable sequence, any clock used as
      a hwmod main_clk must have a clockdomain associated with it.  This
      patch populates some clock structure clockdomain names to resolve the
      following warnings during kernel init:
      
      omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
      omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
      omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
      omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      9a47d32d
    • P
      ARM: OMAP4: hwmod data: fix 32k sync timer idle modes · 252a4c54
      Paul Walmsley 提交于
      The 32k sync timer IP block target idle modes in the hwmod data are
      incorrect.  The IP block does not support any smart-idle modes.
      Update the data to reflect the correct modes.
      
      This problem was initially identified and a diff fragment posted to
      the lists by Benoît Cousson <b-cousson@ti.com>.  A patch description
      bug in the first version was also identified by Benoît.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      252a4c54
    • D
      ARM: OMAP4+: hwmod: fix issue causing IPs not going back to Smart-Standby · 561038f0
      Djamil Elaidi 提交于
      If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature the
      IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup.
      Signed-off-by: NDjamil Elaidi <d-elaidi@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      561038f0
  3. 20 6月, 2012 4 次提交
    • R
      ARM: OMAP: Fix Beagleboard DVI reset gpio · aef2b896
      Russ Dill 提交于
      Commit e813a55e ("OMAP: board-files:
      remove custom PD GPIO handling for DVI output") moved TFP410 chip's
      powerdown-gpio handling from the board files to the tfp410 driver. One
      gpio_request_one(powerdown-gpio, ...) was mistakenly left unremoved in
      the Beagle board file. This causes the tfp410 driver to fail to request
      the gpio on Beagle, causing the driver to fail and thus the DVI output
      doesn't work.
      
      This patch removes several boot errors from board-omap3beagle.c:
      
       - gpio_request: gpio--22 (DVI reset) status -22
       - Unable to get DVI reset GPIO
      
      There is a combination of leftover code and revision confusion.
      Additionally, xM support is currently a hack.
      
      For original Beagleboard this removes the double initialization of GPIO
      170, properly configures it as an output, and wraps the initialization
      in an if block so that xM does not attempt to request it.
      
      For Beagleboard xM it removes reference to GPIO 129 which was part
      of rev A1 and A2 designs, but never functioned. It then properly assigns
      beagle_dvi_device.reset_gpio in beagle_twl_gpio_setup and removes the
      hack of initializing it high. Additionally, it uses
      gpio_set_value_cansleep since this GPIO is connected through i2c.
      
      Unfortunately, there is no way to tell the difference between xM A2 and
      A3. However, GPIO 129 does not function on rev A1 and A2, and the TWL
      GPIO used on A3 and beyond is not used on rev A1 and A2, there are no
      problems created by this fix.
      
      Tested on Beagleboard-xM Rev C1 and Beagleboard Rev B4.
      Signed-off-by: NRuss Dill <Russ.Dill@ti.com>
      Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      aef2b896
    • J
      arm/dts: OMAP2: Fix interrupt controller binding · 95dca12d
      Jon Hunter 提交于
      When booting with device-tree on an OMAP2420H4, the kernel is hanging when
      initialising the interrupts and following kernel dumps is seen ...
      
      [    0.000000] ------------[ cut here ]------------
      [    0.000000] WARNING: at arch/arm/mach-omap2/irq.c:271 omap_intc_of_init+0x50/0xb4()
      [    0.000000] unable to get intc registers
      [    0.000000] Modules linked in:
      [    0.000000] [<c001befc>] (unwind_backtrace+0x0/0xf4) from [<c0040c34>] (warn_slowpath_common+0x4c/0x64)
      [    0.000000] [<c0040c34>] (warn_slowpath_common+0x4c/0x64) from [<c0040ce0>] (warn_slowpath_fmt+0x30/0x40)
      [    0.000000] [<c0040ce0>] (warn_slowpath_fmt+0x30/0x40) from [<c066b8a4>] (omap_intc_of_init+0x50/0xb4)
      [    0.000000] [<c066b8a4>] (omap_intc_of_init+0x50/0xb4) from [<c0688b70>] (of_irq_init+0x144/0x288)
      [    0.000000] [<c0688b70>] (of_irq_init+0x144/0x288) from [<c0663294>] (init_IRQ+0x14/0x1c)
      [    0.000000] [<c0663294>] (init_IRQ+0x14/0x1c) from [<c06607fc>] (start_kernel+0x198/0x304)
      [    0.000000] [<c06607fc>] (start_kernel+0x198/0x304) from [<80008044>] (0x80008044)
      [    0.000000] ---[ end trace 1b75b31a2719ed1c ]---
      [    0.000000] of_irq_init: children remain, but no parents
      
      The OMAP2 interrupt controller binding is missing the number of interrupts and
      interrupt controller register address. Adding these fixes the problem.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      95dca12d
    • T
      ARM: OMAP2: Fix tusb6010 GPIO interrupt for n8x0 · 3d09b33f
      Tony Lindgren 提交于
      Here's one more gpio_to_irq conversion that we missed
      earlier. Tested with n800 in gadget mode using USB_ETH.
      
      Cc: Felipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      3d09b33f
    • T
      ARM: OMAP2+: Fix MUSB ifdefs for platform init code · 310018d5
      Tony Lindgren 提交于
      Commit 62285963 (usb: musb: drop a gigantic amount of ifdeferry)
      got rid of a bunch of ifdefs in the MUSB code. Looks like the
      platform init code is still using these dropped defines though,
      which in many cases results the board defaulting always to host
      mode.
      
      Currently the situation is that USB_MUSB_HDRC is the main
      Kconfig option with additional USB_GADGET_MUSB_HDRC so only
      these two should be used to select between host and OTG mode.
      
      Fix the situation for omaps. The following users should fix the
      platform init code in a similar way:
      
      Dropped Kconfig option          Current users
      
      USB_MUSB_OTG                    blackfin, davinci, not in Kconfigs
      USB_MUSB_PERIPHERAL             davinci, not in Kconfigs
      USB_MUSB_HOST                   davinci, not in Kconfigs
      USB_MUSB_HDRC_HCD               blackfin, not in Kconfigs
      USB_MUSB_OTG                    blackfin, not in Kconfigs
      
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Sekhar Nori <nsekhar@ti.com>
      Cc: linux-usb@vger.kernel.org
      Cc: Felipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      310018d5
  4. 19 6月, 2012 1 次提交
  5. 18 6月, 2012 2 次提交
  6. 17 6月, 2012 3 次提交
    • A
      ARM: Kirkwood: Fix clk problems modular ethernet driver · 128789a8
      Andrew Lunn 提交于
      When the ethernet driver was built as a module, it would lock the
      machine when loaded. At boot the ethernet clks are unused, so get
      turned off.  Later, when the module is loaded, the probe function
      would access the hardware before the clock was restarted, and the
      machine would lock. It has also been determined that when the clk is
      turned off, the interface forgets its MAC address, which for most
      systems, is set by the boot loader.
      
      When the machine setup file creates a platform device for the
      interface, prepare and enable the clock for the interface. This will
      ensure it is not turned off. However, if the setup file only
      instantiates one platform device, the other will have its clk
      disabled, thus maybe saving a little power.
      Report-by: NSimon Baatz <gmbnomis@gmail.com>
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Tested-by: NSimon Baatz <gmbnomis@gmail.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      128789a8
    • A
      arm: versatile: fix and enable PCI I/O space · 9b0f7e39
      Arnd Bergmann 提交于
      With commit 4d5fc58d (ARM: remove bunch of now unused
      mach/io.h files), the I/O space setup was completely broken on
      versatile. This patch fixes that and prepares for further
      I/O space clean-up.
      
      I/O space handling on the versatile platform is currently
      broken in multiple ways. Most importantly, the ports do
      not get mapped into the virtual address space at all.
      
      Also, there is some amount of confusion between PCI I/O
      space and other statically mapped MMIO registers in the
      platform code:
      
      * The __io_address() macro that is used to access the
        platform register maps to the same __io macro that gets
        used for I/O space.
      
      * The IO_SPACE_LIMIT is set to a value that is much larger
        than the total available space.
      
      * The I/O resource of the PCI bus is set to the physical
        address of the mapping, which is way outside of the
        actual I/O space limit as well as the address range that
        gets decoded by traditional PCI cards.
      
      * No attempt is made to stay outside of the ISA port range
        that some device drivers try access.
      
      * No resource gets requested as a child of ioport_resource,
        but an IORESOURCE_IO type mapping gets requested
        as a child of iomem_resource.
      
      This patch attempts to correct all of the above. This makes
      it possible to use virtio-pci based virtual devices as well
      as actual PCI cards including those with legacy ISA port
      ranges like VGA.
      
      Some of the issues seem to be duplicated on other platforms.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      [rob: update to 3.5-rc2 and io.h cleanup related changes]
      Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      Tested-by: NRobert Schwebel <r.schwebel@pengutronix.de>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      9b0f7e39
    • C
      tile: fix bug in get_user() for 4-byte values · 6699c8cd
      Chris Metcalf 提交于
      The definition of 32-bit values in the 64-bit tilegx architecture is that
      they should be sign-extended regardless of whether they are considered
      signed or unsigned by the compiler.  Accordingly, we need to use an
      "ld4s" rather than "ld4u" to load and sign-extend for get_user().
      
      This fixes glibc bug 14238 (see http://sourceware.org/bugzilla),
      introduced during the 3.5 merge window.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      6699c8cd
  7. 15 6月, 2012 2 次提交
    • P
      Make hard_irq_disable() actually hard-disable interrupts · f948501b
      Paul Mackerras 提交于
      At present, hard_irq_disable() does nothing on powerpc because of
      this code in include/linux/interrupt.h:
      
          #ifndef hard_irq_disable
          #define hard_irq_disable()      do { } while(0)
          #endif
      
      So we need to make our hard_irq_disable be a macro.  It was previously
      a macro until commit 7230c564 ("powerpc: Rework lazy-interrupt
      handling") changed it to a static inline function.
      
      Cc: stable@vger.kernel.org
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      --
       arch/powerpc/include/asm/hw_irq.h |    3 +++
       1 file changed, 3 insertions(+)
      f948501b
    • S
      xen: mark local pages as FOREIGN in the m2p_override · b9e0d95c
      Stefano Stabellini 提交于
      When the frontend and the backend reside on the same domain, even if we
      add pages to the m2p_override, these pages will never be returned by
      mfn_to_pfn because the check "get_phys_to_machine(pfn) != mfn" will
      always fail, so the pfn of the frontend will be returned instead
      (resulting in a deadlock because the frontend pages are already locked).
      
      INFO: task qemu-system-i38:1085 blocked for more than 120 seconds.
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      qemu-system-i38 D ffff8800cfc137c0     0  1085      1 0x00000000
       ffff8800c47ed898 0000000000000282 ffff8800be4596b0 00000000000137c0
       ffff8800c47edfd8 ffff8800c47ec010 00000000000137c0 00000000000137c0
       ffff8800c47edfd8 00000000000137c0 ffffffff82213020 ffff8800be4596b0
      Call Trace:
       [<ffffffff81101ee0>] ? __lock_page+0x70/0x70
       [<ffffffff81a0fdd9>] schedule+0x29/0x70
       [<ffffffff81a0fe80>] io_schedule+0x60/0x80
       [<ffffffff81101eee>] sleep_on_page+0xe/0x20
       [<ffffffff81a0e1ca>] __wait_on_bit_lock+0x5a/0xc0
       [<ffffffff81101ed7>] __lock_page+0x67/0x70
       [<ffffffff8106f750>] ? autoremove_wake_function+0x40/0x40
       [<ffffffff811867e6>] ? bio_add_page+0x36/0x40
       [<ffffffff8110b692>] set_page_dirty_lock+0x52/0x60
       [<ffffffff81186021>] bio_set_pages_dirty+0x51/0x70
       [<ffffffff8118c6b4>] do_blockdev_direct_IO+0xb24/0xeb0
       [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
       [<ffffffff8118ca95>] __blockdev_direct_IO+0x55/0x60
       [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
       [<ffffffff811e91c8>] ext3_direct_IO+0xf8/0x390
       [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
       [<ffffffff81004b60>] ? xen_mc_flush+0xb0/0x1b0
       [<ffffffff81104027>] generic_file_aio_read+0x737/0x780
       [<ffffffff813bedeb>] ? gnttab_map_refs+0x15b/0x1e0
       [<ffffffff811038f0>] ? find_get_pages+0x150/0x150
       [<ffffffff8119736c>] aio_rw_vect_retry+0x7c/0x1d0
       [<ffffffff811972f0>] ? lookup_ioctx+0x90/0x90
       [<ffffffff81198856>] aio_run_iocb+0x66/0x1a0
       [<ffffffff811998b8>] do_io_submit+0x708/0xb90
       [<ffffffff81199d50>] sys_io_submit+0x10/0x20
       [<ffffffff81a18d69>] system_call_fastpath+0x16/0x1b
      
      The explanation is in the comment within the code:
      
      We need to do this because the pages shared by the frontend
      (xen-blkfront) can be already locked (lock_page, called by
      do_read_cache_page); when the userspace backend tries to use them
      with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
      do_blockdev_direct_IO is going to try to lock the same pages
      again resulting in a deadlock.
      
      A simplified call graph looks like this:
      
      pygrub                          QEMU
      -----------------------------------------------
      do_read_cache_page              io_submit
        |                              |
      lock_page                       ext3_direct_IO
                                       |
                                      bio_add_page
                                       |
                                      lock_page
      
      Internally the xen-blkback uses m2p_add_override to swizzle (temporarily)
      a 'struct page' to have a different MFN (so that it can point to another
      guest). It also can easily find out whether another pfn corresponding
      to the mfn exists in the m2p, and can set the FOREIGN bit
      in the p2m, making sure that mfn_to_pfn returns the pfn of the backend.
      
      This allows the backend to perform direct_IO on these pages, but as a
      side effect prevents the frontend from using get_user_pages_fast on
      them while they are being shared with the backend.
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      b9e0d95c
  8. 14 6月, 2012 1 次提交
  9. 13 6月, 2012 9 次提交
    • S
      perf/x86: Fix broken LBR fixup code · 25f42985
      Stephane Eranian 提交于
      I noticed that the LBR fixups were not working anymore
      on programs where they used to. I tracked this down to
      a recent change to copy_from_user_nmi():
      
       db0dc75d ("perf/x86: Check user address explicitly in copy_from_user_nmi()")
      
      This commit added a call to __range_not_ok() to the
      copy_from_user_nmi() routine. The problem is that the logic
      of the test must be reversed. __range_not_ok() returns 0 if the
      range is VALID. We want to return early from copy_from_user_nmi()
      if the range is NOT valid.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NArun Sharma <asharma@fb.com>
      Link: http://lkml.kernel.org/r/20120611134426.GA7542@quadSigned-off-by: NIngo Molnar <mingo@kernel.org>
      25f42985
    • B
      x86/smp: Fix topology checks on AMD MCM CPUs · 161270fc
      Borislav Petkov 提交于
      The warning below triggers on AMD MCM packages because physical package
      IDs on the cores of a _physical_ socket are the same. I.e., this field
      says which CPUs belong to the same physical package.
      
      However, the same two CPUs belong to two different internal, i.e.
      "logical" nodes in the same physical socket which is reflected in the
      CPU-to-node map on x86 with NUMA.
      
      Which makes this check wrong on the above topologies so circumvent it.
      
      [    0.444413] Booting Node   0, Processors  #1 #2 #3 #4 #5 Ok.
      [    0.461388] ------------[ cut here ]------------
      [    0.465997] WARNING: at arch/x86/kernel/smpboot.c:310 topology_sane.clone.1+0x6e/0x81()
      [    0.473960] Hardware name: Dinar
      [    0.477170] sched: CPU #6's mc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
      [    0.486860] Booting Node   1, Processors  #6
      [    0.491104] Modules linked in:
      [    0.494141] Pid: 0, comm: swapper/6 Not tainted 3.4.0+ #1
      [    0.499510] Call Trace:
      [    0.501946]  [<ffffffff8144bf92>] ? topology_sane.clone.1+0x6e/0x81
      [    0.508185]  [<ffffffff8102f1fc>] warn_slowpath_common+0x85/0x9d
      [    0.514163]  [<ffffffff8102f2b7>] warn_slowpath_fmt+0x46/0x48
      [    0.519881]  [<ffffffff8144bf92>] topology_sane.clone.1+0x6e/0x81
      [    0.525943]  [<ffffffff8144c234>] set_cpu_sibling_map+0x251/0x371
      [    0.532004]  [<ffffffff8144c4ee>] start_secondary+0x19a/0x218
      [    0.537729] ---[ end trace 4eaa2a86a8e2da22 ]---
      [    0.628197]  #7 #8 #9 #10 #11 Ok.
      [    0.807108] Booting Node   3, Processors  #12 #13 #14 #15 #16 #17 Ok.
      [    0.897587] Booting Node   2, Processors  #18 #19 #20 #21 #22 #23 Ok.
      [    0.917443] Brought up 24 CPUs
      
      We ran a topology sanity check test we have here on it and
      it all looks ok... hopefully :).
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20120529135442.GE29157@aftab.osrc.amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      161270fc
    • M
      ARM: dma-mapping: fix debug messages in dmabounce code · fdb11173
      Marek Szyprowski 提交于
      This patch fixes the usage of uninitialized variables in dmabounce code
      intoduced by commit a227fb92 ('ARM: dma-mapping: remove offset parameter
      to prepare for generic dma_ops'):
      arch/arm/common/dmabounce.c: In function ‘dmabounce_sync_for_device’:
      arch/arm/common/dmabounce.c:409: warning: ‘off’ may be used uninitialized in this function
      arch/arm/common/dmabounce.c:407: note: ‘off’ was declared here
      arch/arm/common/dmabounce.c: In function ‘dmabounce_sync_for_cpu’:
      arch/arm/common/dmabounce.c:369: warning: ‘off’ may be used uninitialized in this function
      arch/arm/common/dmabounce.c:367: note: ‘off’ was declared here
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      fdb11173
    • P
      sh: Kill off additional asm-generic wrappers. · 1318002a
      Paul Mundt 提交于
      A few wrappers were overlooked in the initial conversion, take care of
      them now.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      1318002a
    • G
      sh: Setup CROSS_COMPILE at the top · d14a5fdc
      Geert Uytterhoeven 提交于
      CROSS_COMPILE must be setup before using e.g. cc-option (and a few other
      as-*, cc-*, ld-* macros), else they will check against the wrong compiler
      when cross-compiling, and may invoke the cross compiler with wrong or
      suboptimal compiler options.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: linux-sh@vger.kernel.org
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      d14a5fdc
    • P
      sh: Fix up link time defsym warnings. · 8e780be9
      Paul Mundt 提交于
      sh-linux-gnu-ld:--defsym 'jiffies=jiffies_64': ignoring invalid character `'' in expression
      
      For some reason ld has recently started complaining about the quotes, so just
      get rid of them, we don't need them for anything anyways.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      8e780be9
    • P
      sh: use the new generic strnlen_user() function · cba8df4b
      Paul Mundt 提交于
      This discards both the _32 and _64 versions in favour of the consolidated
      generic one.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      cba8df4b
    • P
      sh: switch to generic strncpy_from_user(). · 0e100e11
      Paul Mundt 提交于
      This kills off the special sh32/64 versions and adopts the generic
      version. It should be possible to optimize this for SH-4A unaligned
      loads, but this is a corner case that can be supported incrementally.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      0e100e11
    • P
      sh: Kill off last dead UBC header · 74ca4313
      Paul Bolle 提交于
      Commit 7025bec9 ("sh: Kill off dead UBC
      headers.") skipped arch/sh/include/cpu-sh2a/cpu/ubc.h. Since nothing is
      using that header either, kill it off too.
      Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      74ca4313
  10. 12 6月, 2012 7 次提交
    • M
      x86: kvmclock: remove check_and_clear_guest_paused warning · e32025a5
      Marcelo Tosatti 提交于
      CPU offline path calls the hrtimer interrupt handler with interrupts
      disabled, without touching preempt_count, triggering this warning.
      
      Remove the warning since it is supposed to be used from hrtimer
      interrupt context only.
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      e32025a5
    • G
      m68k: make syscall_trace_enter/leave exist for non-MMU classic m68k types · 70c778f7
      Greg Ungerer 提交于
      The assembler entry code calls directly to the syscall_trace_enter() and
      syscall_trace_leave() functions. But currently they are conditionaly
      compiled out for the non-MMU classic m68k CPU types (so 68328 for example),
      resulting in a link error:
      
            LD      vmlinux
          arch/m68k/platform/68328/built-in.o: In function `do_trace':
          (.text+0x1c): undefined reference to `syscall_trace_enter'
          arch/m68k/platform/68328/built-in.o: In function `do_trace':
          (.text+0x4c): undefined reference to `syscall_trace_leave'
      
      Change the conditional check that includes these functions to be true for
      the !defined(CONFIG_MMU) case as well.
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      70c778f7
    • G
      m68knommu: fix 68360 local setting of timer interrupt handler · 1b461d76
      Greg Ungerer 提交于
      Compiling for 68360 based targets fails with:
      
          arch/m68k/platform/68360/config.c: In function ‘hw_tick’:
          arch/m68k/platform/68360/config.c:55:2: error: implicit declaration of function ‘arch_timer_interrupt’
          arch/m68k/platform/68360/config.c: At top level:
          arch/m68k/platform/68360/config.c:64:6: error: conflicting types for ‘hw_timer_init’
          arch/m68k/include/asm/machdep.h:36:13: note: previous declaration of ‘hw_timer_init’ was here
      
      Changes made to hw_timer_init() didn't get updated in the 68328 timer code.
      So process and call the "handler" arg that is now passed into that
      hw_timer_init() function.
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      1b461d76
    • G
      m68knommu: fix 68328 local setting of timer interrupt handler · dc5588ae
      Greg Ungerer 提交于
      Compiling for 68328 based targets fails with:
      
          arch/m68k/platform/68328/timers.c: In function ‘hw_tick’:
          arch/m68k/platform/68328/timers.c:65:2: error: implicit declaration of function ‘arch_timer_interrupt’
          arch/m68k/platform/68328/timers.c: At top level:
          arch/m68k/platform/68328/timers.c:102:6: error: conflicting types for ‘hw_timer_init’
          arch/m68k/include/asm/machdep.h:36:13: note: previous declaration of ‘hw_timer_init’ was here
      
      Changes made to hw_timer_init() didn't get updated in the 68328 timer code.
      So process and call the "handler" arg that is now passed into that
      hw_timer_init() function.
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      dc5588ae
    • G
      m68k: fix inclusion of arch_gettimeoffset for non-MMU 68k classic CPU types · b13b3f51
      Greg Ungerer 提交于
      When building for non-MMU based classic 68k CPU types (like the 68328 for
      example) you get a compilation error:
      
        CC      arch/m68k/kernel/time.o
      arch/m68k/kernel/time.c:91:5: error: redefinition of ‘arch_gettimeoffset’
      include/linux/time.h:145:19: note: previous definition of ‘arch_gettimeoffset’ was here
      
      The arch_gettimeoffset() code is included when building for these CPU types,
      but it shouldn't be. Those machine types do not have
      CONFIG_ARCH_USES_GETTIMEOFFSET set.
      
      The fix is simply to conditionally include the arch_gettimeoffset() code on
      that same config setting that specifies its use or not.
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      b13b3f51
    • S
      m68knommu: m528x qspi definition fix · f75b0d07
      Steven King 提交于
      The consolidation of the qspi code missed a definition for 528x.
      Signed-off-by: NSteven King <sfking@fdwdc.com>
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      f75b0d07
    • P
      sparc: remove two unused headers · 8a51178e
      Paul Bolle 提交于
      Nothing includes these two headers. None of the macros they define are
      used anywhere in the tree. This was also the case in v2.6.12-rc2 and,
      presumably, every release in between. These two headers can safely be
      removed.
      Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a51178e
  11. 11 6月, 2012 3 次提交
新手
引导
客服 返回
顶部