1. 09 Jul, 2007 2 commits
    • Sergei Shtylyov's avatar
      ide: make void and rename ide_dma_lostirq() method · 841d2a9b
      Sergei Shtylyov authored
      Since ide_dma_lostirq() method's result is discarded, make it return 'void'.
      While at it, rename the method to dma_lost_irq(), drop the '__' prefix from the
      default method's name, and do some cleanups in this method driver-wise:
      - in aec62xx.c, rename the method in accordance with other drivers, and get rid
        of unnecessary variables there;
      - in pdc202xx_old.c, define/use 'hwif' variable;
      - in sgiioc4.c, rearrange the code to call the resetproc() method directly.
      Signed-off-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
    • Bartlomiej Zolnierkiewicz's avatar
      serverworks: always tune CSB6 · b740d884
      Bartlomiej Zolnierkiewicz authored
      Switch the driver to always program DMA/PIO timings and set device transfer
      mode instead of trusting BIOS on CSB6 controllers (libata pata_serverworks.c
      driver is also doing things this way and there were no problems reported so
      far).  While doing conversion I noticed that the old code had many issues:
      * the code was assuming that hwif->dma_status is always valid
        (which obviously isn't true if hwif->dma_base == NULL)
      * value of "(ultra_timing >> (4*unit)) & ~(0xF0)" expression wasn't checked
        to fit into udma_modes[5]
      * code validating DMA timings didn't validate corresponding PIO timings
      * extra CSB5 PIO register wasn't validated et all
      * hwif->ide_dma_off_quietly() is always called before ide_set_dma() (which in
        turn calls hwif->speedproc() method - svwks_tune_chipset() in this case)
        so the code depending on DMA capable bit of DMA status to be set was never
        executed (=> the code was never validating DMA timings despite actually
        enabling DMA if the PIO timings were OK!)
      * on resume driver dependend entirely on BIOS to restore timings and set
        transfer mode on the device
      While at it:
      There is no need to read PIO/MWDMA timings now so don't do it.
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      Acked-by: default avatarAlan Cox <alan@lxorguk.ukuu.org.uk>
  2. 08 Jul, 2007 2 commits
  3. 06 Jul, 2007 2 commits
    • Yoann Padioleau's avatar
      potential compiler error, irqfunc caller sites update · 0da2f0f1
      Yoann Padioleau authored
      In 7d12e780 David Howells performed
      this evolution:
       "IRQ: Maintain regs pointer globally rather than passing to IRQ handlers"
      He correctly updated many of the function definitions that were using this
      extra regs pointer parameter but forgot to update some caller sites of
      those functions.  The reason the modifications was not properly done on all
      drivers is that some drivers were rarely compiled because they are for
      AMIGA, or that some code sites were inside #ifdefs where the option is not
      set or inside #if 0.
      Here is the semantic patch that found the occurences
      and fixed the problem.
      @ rule1 @
      identifier fn;
      identifier irq, dev_id;
      typedef irqreturn_t;
      static irqreturn_t fn(int irq, void *dev_id)
      identifier rule1.fn;
      expression E1, E2, E3;
       fn(E1, E2
      -   ,E3
      Signed-off-by: default avatarYoann Padioleau <padator@wanadoo.fr>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Bjorn Helgaas's avatar
      PNP SMCf010 quirk: work around Toshiba Portege 4000 ACPI issues · 41a53114
      Bjorn Helgaas authored
      When we enable the SMCf010 IR device, the Toshiba Portege 4000 BIOS claims
      the device is working, but it really isn't configured correctly.  The BIOS
      *will* configure it, but only if we call _SRS after (1) reversing the order
      of the SIR and FIR I/O port regions and (2) changing the IRQ from
      active-high to active-low.
      This patch addresses the 2.6.22 regression:
          "no irda0 interface (2.6.21 was OK), smsc does not find chip"
      I tested this on a Portege 4000.  The smsc-ircc2 driver correctly detects
      the device, and "irattach irda0 -s && irdadump" shows transmitted and
      received packets.
      Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: Andrey Borzenkov <arvidjaar@mail.ru>
      Cc: Samuel Ortiz <samuel@sortiz.org>
      Cc: "Linus Walleij (LD/EAB)" <linus.walleij@ericsson.com>
      Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
      Cc: Adam Belay <ambx1@neo.rr.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  4. 04 Jul, 2007 1 commit
    • Linus Torvalds's avatar
      Remove the blink driver · 2bcb1b7d
      Linus Torvalds authored
      Yeah, we could have just disabled it, but there's work on a new one that
      isn't as fundamentally broken, so there really doesn't seem to be any
      point in keeping it around.
      The recent timer cleanup broke the only valid use, and when I say
      "valid", I obviously mean "totally broken".  So it's not like it works,
      or really even can work in the current format that uses the unsafe
      "panic" LED blinking routines..
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  5. 03 Jul, 2007 18 commits
  6. 02 Jul, 2007 15 commits