1. 28 Apr, 2007 1 commit
    • Jeff Garzik's avatar
      libata/IDE: remove combined mode quirk · 8cdfb29c
      Jeff Garzik authored
      Both old-IDE and libata should be able handle all controllers and
      devices found using normal resource reservation methods.
      
      This eliminates the awful, low-performing split-driver configuration
      where old-IDE drove the PATA portion of a PCI device, in PIO-only mode,
      and libata drove the SATA portion of the /same/ PCI device, in DMA mode.
      Typically vendors would ship SATA hard drive / PATA optical
      configuration, which would lend itself to slow (PIO-only) CD-ROM
      performance.
      
      For Intel users running in combined mode, it is now wholly dependent on
      your driver choice (potentially link order, if you compile both drivers
      in) whether old-IDE or libata will drive your hardware.
      
      In either case, you will get full performance from both SATA and PATA
      ports now, without having to pass a kernel command line parameter.
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      8cdfb29c
  2. 30 Mar, 2006 2 commits
  3. 23 Jan, 2006 1 commit
  4. 18 Jan, 2006 1 commit
  5. 22 Oct, 2005 1 commit
  6. 29 Jun, 2005 1 commit
    • Russell King's avatar
      [PATCH] Serial: Split 8250 port table (part 2) · 026d02a2
      Russell King authored
      Remove legacy ISA serial ports for Accent, Boca, Fourport, Hub6 and MCA
      from the architecture specific serial.h include.
      
      The only ports which remain in asm-*/serial.h are the platform specific
      entries.  These should really be converted by platform maintainers to
      use a platform device, such as can be found in
      arch/arm/mach-footbridge/isa.c
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      026d02a2
  7. 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!
      1da177e4