1. 30 1月, 2008 3 次提交
  2. 04 12月, 2007 1 次提交
  3. 14 10月, 2007 1 次提交
    • D
      Delete filenames in comments. · 835c34a1
      Dave Jones 提交于
      Since the x86 merge, lots of files that referenced their own filenames
      are no longer correct.  Rather than keep them up to date, just delete
      them, as they add no real value.
      
      Additionally:
      - fix up comment formatting in scx200_32.c
      - Remove a credit from myself in setup_64.c from a time when we had no SCM
      - remove longwinded history from tsc_32.c which can be figured out from
        git.
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      835c34a1
  4. 11 10月, 2007 2 次提交
  5. 10 10月, 2007 1 次提交
    • J
      drivers/firmware: const-ify DMI API and internals · 1855256c
      Jeff Garzik 提交于
      Three main sets of changes:
      
      1) dmi_get_system_info() return value should have been marked const,
         since callers should not be changing that data.
      
      2) const-ify DMI internals, since DMI firmware tables should,
         whenever possible, be marked const to ensure we never ever write to
         that data area.
      
      3) const-ify DMI API, to enable marking tables const where possible
         in low-level drivers.
      
      And if we're really lucky, this might enable some additional
      optimizations on the part of the compiler.
      
      The bulk of the changes are #2 and #3, which are interrelated.  #1 could
      have been a separate patch, but it was so small compared to the others,
      it was easier to roll it into this changeset.
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      1855256c
  6. 22 7月, 2007 1 次提交
  7. 01 6月, 2007 1 次提交
  8. 03 5月, 2007 3 次提交
  9. 08 12月, 2006 1 次提交
  10. 26 9月, 2006 1 次提交
  11. 01 7月, 2006 1 次提交
  12. 12 1月, 2006 1 次提交
    • E
      [PATCH] i386/x86-64: Don't IPI to offline cpus on shutdown · 6e3fbee5
      Eric W. Biederman 提交于
      So why are we calling smp_send_stop from machine_halt?
      
      We don't.
      
      Looking more closely at the bug report the problem here
      is that halt -p is called which triggers not a halt but
      an attempt to power off.
      
      machine_power_off calls machine_shutdown which calls smp_send_stop.
      
      If pm_power_off is set we should never make it out machine_power_off
      to the call of do_exit.  So pm_power_off must not be set in this case.
      When pm_power_off is not set we expect machine_power_off to devolve
      into machine_halt.
      
      So how do we fix this?
      
      Playing too much with smp_send_stop is dangerous because it
      must also be safe to be called from panic.
      
      It looks like the obviously correct fix is to only call
      machine_shutdown when pm_power_off is defined.  Doing
      that will make Andi's assumption about not scheduling
      true and generally simplify what must be supported.
      
      This turns machine_power_off into a noop like machine_halt
      when pm_power_off is not defined.
      
      If the expected behavior is that sys_reboot(LINUX_REBOOT_CMD_POWER_OFF)
      becomes sys_reboot(LINUX_REBOOT_CMD_HALT) if pm_power_off is NULL
      this is not quite a comprehensive fix as we pass a different parameter
      to the reboot notifier and we set system_state to a different value
      before calling device_shutdown().
      
      Unfortunately any fix more comprehensive I can think of is not
      obviously correct.  The core problem is that there is no architecture
      independent way to detect if machine_power will become a noop, without
      calling it.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6e3fbee5
  13. 07 1月, 2006 1 次提交
  14. 30 11月, 2005 1 次提交
  15. 13 9月, 2005 1 次提交
  16. 05 9月, 2005 1 次提交
  17. 27 7月, 2005 4 次提交
  18. 26 6月, 2005 1 次提交
  19. 24 6月, 2005 1 次提交
  20. 01 5月, 2005 1 次提交
  21. 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