1. 13 4月, 2012 3 次提交
    • P
      ARM: OMAP1: OCPI: move to mach-omap1/ · 6f3c1af2
      Paul Walmsley 提交于
      Move the OMAP1 OCPI "bus" code to arch/arm/mach-omap1, since it is
      only used on OMAP1 devices.  In the long term, it probably makes sense
      to move the OCPI bus code to somewhere under drivers/.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      6f3c1af2
    • P
      ARM: OMAP: add includes for missing prototypes · e2ed89fc
      Paul Walmsley 提交于
      Several C files in arch/arm/mach-omap* and arch/arm/plat-omap declare
      functions that are used by other files, but don't include the header
      file where the prototype is declared.  This results in the following
      warnings from sparse:
      
          arch/arm/mach-omap2/irq.c:114:5: warning: symbol 'omap_irq_pending' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:186:13: warning: symbol 'omap2_init_irq' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:191:13: warning: symbol 'omap3_init_irq' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:196:13: warning: symbol 'ti81xx_init_irq' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:233:39: warning: symbol 'omap2_intc_handle_irq' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:242:6: warning: symbol 'omap_intc_save_context' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:265:6: warning: symbol 'omap_intc_restore_context' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:291:6: warning: symbol 'omap3_intc_suspend' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:297:6: warning: symbol 'omap3_intc_prepare_idle' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:306:6: warning: symbol 'omap3_intc_resume_idle' was not declared. Should it be static?
          arch/arm/mach-omap2/irq.c:312:39: warning: symbol 'omap3_intc_handle_irq' was not declared. Should it be static?
          arch/arm/mach-omap2/omap-secure.c:59:12: warning: symbol 'omap_secure_ram_reserve_memblock' was not declared. Should it be static?
          arch/arm/mach-omap2/board-zoom-display.c:133:13: warning: symbol 'zoom_display_init' was not declared. Should it be static?
          arch/arm/plat-omap/common.c:73:13: warning: symbol 'omap_init_consistent_dma_size' was not declared. Should it be static?
          arch/arm/mach-omap1/irq.c:61:5: warning: symbol 'omap_irq_flags' was not declared. Should it be static?
          arch/arm/mach-omap1/irq.c:179:13: warning: symbol 'omap1_init_irq' was not declared. Should it be static?
          arch/arm/mach-omap1/reset.c:11:6: warning: symbol 'omap1_restart' was not declared. Should it be static?
      
      Fix by including the appropriate header files.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Senthilvadivu Guruswamy <svadivu@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      
      e2ed89fc
    • P
      ARM: OMAP2+: declare file-local functions as static · 8c3d4534
      Paul Walmsley 提交于
      Several function declarations used only in the files in which they're
      declared should include the static keyword, but don't:
      
          arch/arm/mach-omap2/serial.c:248:6: warning: symbol 'cmdline_find_option' was not declared. Should it be static?
          arch/arm/mach-omap2/omap-wakeupgen.c:259:6: warning: symbol 'irq_sar_clear' was not declared. Should it be static?
          arch/arm/mach-omap2/board-rx51-peripherals.c:878:27: warning: symbol 'rx51_vibra_data' was not declared. Should it be static?
          arch/arm/mach-omap2/board-rx51-peripherals.c:882:27: warning: symbol 'rx51_audio_data' was not declared. Should it be static?
          arch/arm/mach-omap2/board-omap4panda.c:201:29: warning: symbol 'omap_panda_wlan_data' was not declared. Should it be static?
          arch/arm/mach-omap2/board-omap4panda.c:393:24: warning: symbol 'omap4_panda_dvi_device' was not declared. Should it be static?
          arch/arm/mach-omap2/board-omap4panda.c:403:12: warning: symbol 'omap4_panda_dvi_init' was not declared. Should it be static?
          arch/arm/mach-omap2/board-omap4panda.c:464:6: warning: symbol 'omap4_panda_display_init' was not declared. Should it be static?
          arch/arm/mach-omap2/hsmmc.c:434:6: warning: symbol 'omap_init_hsmmc' was not declared. Should it be static?
          arch/arm/mach-omap2/hwspinlock.c:31:12: warning: symbol 'hwspinlocks_init' was not declared. Should it be static?
          arch/arm/mach-omap1/timer.c:58:12: warning: symbol 'omap1_dm_timer_init' was not declared. Should it be static?
          arch/arm/mach-omap1/fpga.c:90:6: warning: symbol 'innovator_fpga_IRQ_demux' was not declared. Should it be static?
      
      Mark all of these as static.
      
      Thanks to Arnd Bergmann <arnd@arndb.de> for pointing out a typo in the
      original patch description.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Govindraj R <govindraj.raja@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: David Anders <x0132446@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      8c3d4534
  2. 07 4月, 2012 3 次提交
    • L
      Make the "word-at-a-time" helper functions more commonly usable · f68e556e
      Linus Torvalds 提交于
      I have a new optimized x86 "strncpy_from_user()" that will use these
      same helper functions for all the same reasons the name lookup code uses
      them.  This is preparation for that.
      
      This moves them into an architecture-specific header file.  It's
      architecture-specific for two reasons:
      
       - some of the functions are likely to want architecture-specific
         implementations.  Even if the current code happens to be "generic" in
         the sense that it should work on any little-endian machine, it's
         likely that the "multiply by a big constant and shift" implementation
         is less than optimal for an architecture that has a guaranteed fast
         bit count instruction, for example.
      
       - I expect that if architectures like sparc want to start playing
         around with this, we'll need to abstract out a few more details (in
         particular the actual unaligned accesses).  So we're likely to have
         more architecture-specific stuff if non-x86 architectures start using
         this.
      
         (and if it turns out that non-x86 architectures don't start using
         this, then having it in an architecture-specific header is still the
         right thing to do, of course)
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f68e556e
    • S
      xen/smp: Remove unnecessary call to smp_processor_id() · e8c9e788
      Srivatsa S. Bhat 提交于
      There is an extra and unnecessary call to smp_processor_id()
      in cpu_bringup(). Remove it.
      Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      e8c9e788
    • K
      xen/x86: Workaround 'x86/ioapic: Add register level checks to detect bogus io-apic entries' · 2531d64b
      Konrad Rzeszutek Wilk 提交于
      The above mentioned patch checks the IOAPIC and if it contains
      -1, then it unmaps said IOAPIC. But under Xen we get this:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
      IP: [<ffffffff8134e51f>] xen_irq_init+0x1f/0xb0
      PGD 0
      Oops: 0002 [#1] SMP
      CPU 0
      Modules linked in:
      
      Pid: 1, comm: swapper/0 Not tainted 3.2.10-3.fc16.x86_64 #1 Dell Inc. Inspiron
      1525                  /0U990C
      RIP: e030:[<ffffffff8134e51f>]  [<ffffffff8134e51f>] xen_irq_init+0x1f/0xb0
      RSP: e02b: ffff8800d42cbb70  EFLAGS: 00010202
      RAX: 0000000000000000 RBX: 00000000ffffffef RCX: 0000000000000001
      RDX: 0000000000000040 RSI: 00000000ffffffef RDI: 0000000000000001
      RBP: ffff8800d42cbb80 R08: ffff8800d6400000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: 00000000ffffffef
      R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000010
      FS:  0000000000000000(0000) GS:ffff8800df5fe000(0000) knlGS:0000000000000000
      CS:  e033 DS: 0000 ES: 0000 CR0:000000008005003b
      CR2: 0000000000000040 CR3: 0000000001a05000 CR4: 0000000000002660
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process swapper/0 (pid: 1, threadinfo ffff8800d42ca000, task ffff8800d42d0000)
      Stack:
       00000000ffffffef 0000000000000010 ffff8800d42cbbe0 ffffffff8134f157
       ffffffff8100a9b2 ffffffff8182ffd1 00000000000000a0 00000000829e7384
       0000000000000002 0000000000000010 00000000ffffffff 0000000000000000
      Call Trace:
       [<ffffffff8134f157>] xen_bind_pirq_gsi_to_irq+0x87/0x230
       [<ffffffff8100a9b2>] ? check_events+0x12+0x20
       [<ffffffff814bab42>] xen_register_pirq+0x82/0xe0
       [<ffffffff814bac1a>] xen_register_gsi.part.2+0x4a/0xd0
       [<ffffffff814bacc0>] acpi_register_gsi_xen+0x20/0x30
       [<ffffffff8103036f>] acpi_register_gsi+0xf/0x20
       [<ffffffff8131abdb>] acpi_pci_irq_enable+0x12e/0x202
       [<ffffffff814bc849>] pcibios_enable_device+0x39/0x40
       [<ffffffff812dc7ab>] do_pci_enable_device+0x4b/0x70
       [<ffffffff812dc878>] __pci_enable_device_flags+0xa8/0xf0
       [<ffffffff812dc8d3>] pci_enable_device+0x13/0x20
      
      The reason we are dying is b/c the call acpi_get_override_irq() is used,
      which returns the polarity and trigger for the IRQs. That function calls
      mp_find_ioapics to get the 'struct ioapic' structure - which along with the
      mp_irq[x] is used to figure out the default values and the polarity/trigger
      overrides. Since the mp_find_ioapics now returns -1 [b/c the IOAPIC is filled
      with 0xffffffff], the acpi_get_override_irq() stops trying to lookup in the
      mp_irq[x] the proper INT_SRV_OVR and we can't install the SCI interrupt.
      
      The proper fix for this is going in v3.5 and adds an x86_io_apic_ops
      struct so that platforms can override it. But for v3.4 lets carry this
      work-around. This patch does that by providing a slightly different variant
      of the fake IOAPIC entries.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      2531d64b
  3. 06 4月, 2012 10 次提交
  4. 05 4月, 2012 18 次提交
  5. 04 4月, 2012 6 次提交