1. 03 Jul, 2006 1 commit
    • Sam Ravnborg's avatar
      kbuild: introduce utsrelease.h · 63104eec
      Sam Ravnborg authored
      include/linux/version.h contained both actual KERNEL version
      and UTS_RELEASE that contains a subset from git SHA1 for when
      kernel was compiled as part of a git repository.
      This had the unfortunate side-effect that all files including version.h
      would be recompiled when some git changes was made due to changes SHA1.
      Split it out so we keep independent parts in separate files.
      Also update checkversion.pl script to no longer check for UTS_RELEASE.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
  2. 30 Jun, 2006 1 commit
  3. 26 Jun, 2006 3 commits
  4. 11 Apr, 2006 1 commit
  5. 27 Mar, 2006 1 commit
  6. 26 Mar, 2006 1 commit
  7. 25 Mar, 2006 1 commit
  8. 14 Feb, 2006 1 commit
  9. 10 Jan, 2006 2 commits
    • Linus Torvalds's avatar
      x86: fix "make install" target · d274ba20
      Linus Torvalds authored
      Removing the dependency on the boot image build was good, but it also
      meant that the $< expansion by make needed to be done explicitly.
      Noted by Stephen Hemminger.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Antonino A. Daplas's avatar
      [PATCH] vesafb: Drop blank hook · 2b4f2f4b
      Antonino A. Daplas authored
      From: Bugzilla Bug 5351
      "After resuming from S3 (suspended while in X), the LCD panel stays black .
       However, the laptop is up again, and I can SSH into it from another
      I can get the panel working again, when I first direct video output to the
      CRT output of the laptop, and then back to LCD (done by repeatedly hitting
      Fn+F5 buttons on the Toshiba, which directs output to either LCD, CRT or
      TV) None of this ever happened with older kernels."
      This bug is due to the recently added vesafb_blank() method in vesafb.  It
      works with CRT displays, but has a high incidence of problems in laptop
      users.  Since CRT users don't really get that much benefit from hardware
      blanking, drop support for this.
      Signed-off-by: default avatarAntonino Daplas <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  10. 09 Jan, 2006 1 commit
  11. 08 Jan, 2006 1 commit
  12. 09 Sep, 2005 2 commits
  13. 07 Sep, 2005 1 commit
  14. 28 Jun, 2005 1 commit
  15. 25 Jun, 2005 2 commits
  16. 23 Jun, 2005 1 commit
    • Ian Campbell's avatar
      [PATCH] use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh · 0f8e2d62
      Ian Campbell authored
      The attached patch causes the various arch specific install.sh scripts to
      look for ${CROSS_COMPILE}installkernel rather than just installkernel (in
      both /sbin/ and ~/bin/ where the script already did this).  This allows you
      to have e.g.  arm-linux-installkernel as a handy way to install on your
      cross target.  It also prevents the script picking up on the host
      /sbin/installkernel which causes the script to fall through and do the
      install itself (which is what I actually use myself, with $INSTALL_PATH
      I don't believe it causes back-compatibility problems since calling the
      host installkernel was never likely to work or be what you wanted when
      cross compiling anyway.  If $CROSS_COMPILE isn't set then nothing changes.
      I only use ARM and i386 myself but I figured it couldn't hurt to do the
      whole lot.  I've cc'd those who I hope are the arch maintainers for files
      that I've touched.
      Signed-off-by: default avatarIan Campbell <icampbell@arcom.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  17. 21 Jun, 2005 1 commit
  18. 05 May, 2005 1 commit
  19. 01 May, 2005 2 commits
  20. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!