1. 10 7月, 2007 3 次提交
    • S
      ide: make void and rename ide_dma_timeout() method · c283f5db
      Sergei Shtylyov 提交于
      Since ide_dma_timeout() method's result is discarded, make it return 'void'.
      While at it, drop 'ide_' from the method's name, drop the '__' prefix from
      the default method's name, and do some cleanups in this method driver-wise:
      
      - in ide-dma.c, au1xxx-ide.c, and pdc202xx_old.c, define/use 'hwif' variable;
      
      - in au1xxx-ide.c, get rid of commented out printk();
      
      - in sl82c105.c, get rid of unnecessary variables.
      Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      c283f5db
    • S
      ide: make void and rename ide_dma_lostirq() method · 841d2a9b
      Sergei Shtylyov 提交于
      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: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      841d2a9b
    • B
      serverworks: always tune CSB6 · b740d884
      Bartlomiej Zolnierkiewicz 提交于
      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: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      b740d884
  2. 08 7月, 2007 2 次提交
  3. 07 7月, 2007 2 次提交
    • Y
      potential compiler error, irqfunc caller sites update · 0da2f0f1
      Yoann Padioleau 提交于
      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: NYoann 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0da2f0f1
    • B
      PNP SMCf010 quirk: work around Toshiba Portege 4000 ACPI issues · 41a53114
      Bjorn Helgaas 提交于
      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: NBjorn 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      41a53114
  4. 05 7月, 2007 1 次提交
    • L
      Remove the blink driver · 2bcb1b7d
      Linus Torvalds 提交于
      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: NLinus Torvalds <torvalds@linux-foundation.org>
      2bcb1b7d
  5. 04 7月, 2007 12 次提交
  6. 03 7月, 2007 10 次提交
  7. 02 7月, 2007 10 次提交