1. 29 1月, 2014 1 次提交
  2. 29 3月, 2012 1 次提交
  3. 07 10月, 2010 1 次提交
    • D
      Fix IRQ flag handling naming · df9ee292
      David Howells 提交于
      Fix the IRQ flag handling naming.  In linux/irqflags.h under one configuration,
      it maps:
      
      	local_irq_enable() -> raw_local_irq_enable()
      	local_irq_disable() -> raw_local_irq_disable()
      	local_irq_save() -> raw_local_irq_save()
      	...
      
      and under the other configuration, it maps:
      
      	raw_local_irq_enable() -> local_irq_enable()
      	raw_local_irq_disable() -> local_irq_disable()
      	raw_local_irq_save() -> local_irq_save()
      	...
      
      This is quite confusing.  There should be one set of names expected of the
      arch, and this should be wrapped to give another set of names that are expected
      by users of this facility.
      
      Change this to have the arch provide:
      
      	flags = arch_local_save_flags()
      	flags = arch_local_irq_save()
      	arch_local_irq_restore(flags)
      	arch_local_irq_disable()
      	arch_local_irq_enable()
      	arch_irqs_disabled_flags(flags)
      	arch_irqs_disabled()
      	arch_safe_halt()
      
      Then linux/irqflags.h wraps these to provide:
      
      	raw_local_save_flags(flags)
      	raw_local_irq_save(flags)
      	raw_local_irq_restore(flags)
      	raw_local_irq_disable()
      	raw_local_irq_enable()
      	raw_irqs_disabled_flags(flags)
      	raw_irqs_disabled()
      	raw_safe_halt()
      
      with type checking on the flags 'arguments', and then wraps those to provide:
      
      	local_save_flags(flags)
      	local_irq_save(flags)
      	local_irq_restore(flags)
      	local_irq_disable()
      	local_irq_enable()
      	irqs_disabled_flags(flags)
      	irqs_disabled()
      	safe_halt()
      
      with tracing included if enabled.
      
      The arch functions can now all be inline functions rather than some of them
      having to be macros.
      
      Signed-off-by: David Howells <dhowells@redhat.com> [X86, FRV, MN10300]
      Signed-off-by: Chris Metcalf <cmetcalf@tilera.com> [Tile]
      Signed-off-by: Michal Simek <monstr@monstr.eu> [Microblaze]
      Tested-by: Catalin Marinas <catalin.marinas@arm.com> [ARM]
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> [AVR]
      Acked-by: Tony Luck <tony.luck@intel.com> [IA-64]
      Acked-by: Hirokazu Takata <takata@linux-m32r.org> [M32R]
      Acked-by: Greg Ungerer <gerg@uclinux.org> [M68K/M68KNOMMU]
      Acked-by: Ralf Baechle <ralf@linux-mips.org> [MIPS]
      Acked-by: Kyle McMartin <kyle@mcmartin.ca> [PA-RISC]
      Acked-by: Paul Mackerras <paulus@samba.org> [PowerPC]
      Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com> [S390]
      Acked-by: Chen Liqin <liqin.chen@sunplusct.com> [Score]
      Acked-by: Matt Fleming <matt@console-pimps.org> [SH]
      Acked-by: David S. Miller <davem@davemloft.net> [Sparc]
      Acked-by: Chris Zankel <chris@zankel.net> [Xtensa]
      Reviewed-by: Richard Henderson <rth@twiddle.net> [Alpha]
      Reviewed-by: Yoshinori Sato <ysato@users.sourceforge.jp> [H8300]
      Cc: starvik@axis.com [CRIS]
      Cc: jesper.nilsson@axis.com [CRIS]
      Cc: linux-cris-kernel@axis.com
      df9ee292
  4. 24 8月, 2010 1 次提交
    • D
      sparc64: Get rid of indirect p1275 PROM call buffer. · 25edd694
      David S. Miller 提交于
      This is based upon a report by Meelis Roos showing that it's possible
      that we'll try to fetch a property that is 32K in size with some
      devices.  With the current fixed 3K buffer we use for moving data in
      and out of the firmware during PROM calls, that simply won't work.
      
      In fact, it will scramble random kernel data during bootup.
      
      The reasoning behind the temporary buffer is entirely historical.  It
      used to be the case that we had problems referencing dynamic kernel
      memory (including the stack) early in the boot process before we
      explicitly told the firwmare to switch us over to the kernel trap
      table.
      
      So what we did was always give the firmware buffers that were locked
      into the main kernel image.
      
      But we no longer have problems like that, so get rid of all of this
      indirect bounce buffering.
      
      Besides fixing Meelis's bug, this also makes the kernel data about 3K
      smaller.
      
      It was also discovered during these conversions that the
      implementation of prom_retain() was completely wrong, so that was
      fixed here as well.  Currently that interface is not in use.
      Reported-by: NMeelis Roos <mroos@linux.ee>
      Tested-by: NMeelis Roos <mroos@linux.ee>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      25edd694
  5. 04 3月, 2010 1 次提交
  6. 05 12月, 2008 1 次提交
    • S
      sparc,sparc64: unify prom/ · 5de18cde
      Sam Ravnborg 提交于
      - all files with identical names copied and renamed to *_64.c
      - the remaning files copied as is
      - added sparc64 specific files to sparc/prom/Makefile
      - teach sparc64 Makefile to look into sparc/prom/
      - delete unused Makefile from sparc64/prom/
      
      linking order was not kept for sparc64 with this change.
      It was not possible to keep linking order for both sparc and sparc64
      and as sparc64 see more testing than sparc it was natural to
      break linking order on sparc64. Should it have any effect it
      would be detected sooner this way.
      
      printf_32.c and printf_64.c are obvious candidates to be merged
      but they are not 100% equal so that was left for later
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5de18cde
  7. 20 5月, 2008 1 次提交
  8. 16 7月, 2007 1 次提交
    • D
      [SPARC64]: Initial LDOM cpu hotplug support. · 4f0234f4
      David S. Miller 提交于
      Only adding cpus is supports at the moment, removal
      will come next.
      
      When new cpus are configured, the machine description is
      updated.  When we get the configure request we pass in a
      cpu mask of to-be-added cpus to the mdesc CPU node parser
      so it only fetches information for those cpus.  That code
      also proceeds to update the SMT/multi-core scheduling bitmaps.
      
      cpu_up() does all the work and we return the status back
      over the DS channel.
      
      CPUs via dr-cpu need to be booted straight out of the
      hypervisor, and this requires:
      
      1) A new trampoline mechanism.  CPUs are booted straight
         out of the hypervisor with MMU disabled and running in
         physical addresses with no mappings installed in the TLB.
      
         The new hvtramp.S code sets up the critical cpu state,
         installs the locked TLB mappings for the kernel, and
         turns the MMU on.  It then proceeds to follow the logic
         of the existing trampoline.S SMP cpu bringup code.
      
      2) All calls into OBP have to be disallowed when domaining
         is enabled.  Since cpus boot straight into the kernel from
         the hypervisor, OBP has no state about that cpu and therefore
         cannot handle being invoked on that cpu.
      
         Luckily it's only a handful of interfaces which can be called
         after the OBP device tree is obtained.  For example, rebooting,
         halting, powering-off, and setting options node variables.
      
      CPU removal support will require some infrastructure changes
      here.  Namely we'll have to process the requests via a true
      kernel thread instead of in a workqueue.  workqueues run on
      a per-cpu thread, but when unconfiguring we might need to
      force the thread to execute on another cpu if the current cpu
      is the one being removed.  Removal of a cpu also causes the kernel
      to destroy that cpu's workqueue running thread.
      
      Another issue on removal is that we may have interrupts still
      pointing to the cpu-to-be-removed.  So new code will be needed
      to walk the active INO list and retarget those cpus as-needed.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f0234f4
  9. 20 3月, 2006 1 次提交
  10. 23 9月, 2005 1 次提交
    • D
      [SPARC64]: Rewrite bootup sequence. · bff06d55
      David S. Miller 提交于
      Instead of all of this cpu-specific code to remap the kernel
      to the correct location, use portable firmware calls to do
      this instead.
      
      What we do now is the following in position independant
      assembler:
      
      	chosen_node = prom_finddevice("/chosen");
      	prom_mmu_ihandle_cache = prom_getint(chosen_node, "mmu");
      	vaddr = 4MB_ALIGN(current_text_addr());
      	prom_translate(vaddr, &paddr_high, &paddr_low, &mode);
      	prom_boot_mapping_mode = mode;
      	prom_boot_mapping_phys_high = paddr_high;
      	prom_boot_mapping_phys_low = paddr_low;
      	prom_map(-1, 8 * 1024 * 1024, KERNBASE, paddr_low);
      
      and that replaces the massive amount of by-hand TLB probing and
      programming we used to do here.
      
      The new code should also handle properly the case where the kernel
      is mapped at the correct address already (think: future kexec
      support).
      
      Consequently, the bulk of remap_kernel() dies as does the entirety
      of arch/sparc64/prom/map.S
      
      We try to share some strings in the PROM library with the ones used
      at bootup, and while we're here mark input strings to oplib.h routines
      with "const" when appropriate.
      
      There are many more simplifications now possible.  For one thing, we
      can consolidate the two copies we now have of a lot of cpu setup code
      sitting in head.S and trampoline.S.
      
      This is a significant step towards CONFIG_DEBUG_PAGEALLOC support.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bff06d55
  11. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4