1. 13 10月, 2008 4 次提交
    • M
      [SCSI] qla4xxx: return SCSI_MLQUEUE_TARGET_BUSY when driver has detected session error · c5e98e91
      Mike Christie 提交于
      When qla4xxx begins recovery and the iscsi class is firing up to handle
      it, we need to retrn SCSI_MLQUEUE_TARGET_BUSY from the driver instead
      of host busy, because the session recovery only affects the one target.
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Acked-by: NDavid C Somayajulu <david.somayajulu@qlogic.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      c5e98e91
    • M
      [SCSI] Add helper code so transport classes/driver can control queueing (v3) · f0c0a376
      Mike Christie 提交于
      SCSI-ml manages the queueing limits for the device and host, but
      does not do so at the target level. However something something similar
      can come in userful when a driver is transitioning a transport object to
      the the blocked state, becuase at that time we do not want to queue
      io and we do not want the queuecommand to be called again.
      
      The patch adds code similar to the exisiting SCSI_ML_*BUSY handlers.
      You can now return SCSI_MLQUEUE_TARGET_BUSY when we hit
      a transport level queueing issue like the hw cannot allocate some
      resource at the iscsi session/connection level, or the target has temporarily
      closed or shrunk the queueing window, or if we are transitioning
      to the blocked state.
      
      bnx2i, when they rework their firmware according to netdev
      developers requests, will also need to be able to limit queueing at this
      level. bnx2i will hook into libiscsi, but will allocate a scsi host per
      netdevice/hba, so unlike pure software iscsi/iser which is allocating
      a host per session, it cannot set the scsi_host->can_queue and return
      SCSI_MLQUEUE_HOST_BUSY to reflect queueing limits on the transport.
      
      The iscsi class/driver can also set a scsi_target->can_queue value which
      reflects the max commands the driver/class can support. For iscsi this
      reflects the number of commands we can support for each session due to
      session/connection hw limits, driver limits, and to also reflect the
      session/targets's queueing window.
      
      Changes:
      v1 - initial patch.
      v2 - Fix scsi_run_queue handling of multiple blocked targets.
      Previously we would break from the main loop if a device was added back on
      the starved list. We now run over the list and check if any target is
      blocked.
      v3 - Rediff for scsi-misc.
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      f0c0a376
    • L
      Fix Kconfig dependency for WM97xx battery driver · 5e4c5f4c
      Linus Torvalds 提交于
      It needs the WM97xx touchscreen driver to be compiled in, not as a
      module.  And it cannot itself be a module, due to some unfortunate
      interactions with platform data.
      Reported-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5e4c5f4c
    • L
      Fix RTC wakealarm sysfs interface breakage. · 1efd325f
      Linus Torvalds 提交于
      Commit ed458df4 ("PnP: move
      pnpacpi/pnpbios_init to after PCI init") moved the PnP RTC discovery
      later, and now the ACPI RTC glue code doesn't find it any more, breaking
      the RTC wakealarm sysfs interfaces, as reported by Rafael.
      
      This really is fairly messy, and we have several annoying ordering
      constraints here - the PnP code that sets up the RTC resources wants to
      run after the PCI resources have to be registered, which in turn needs
      to run after ACPI has at least enumerated the root PCI buses etc.  Our
      initcall ordering is not fine-grained enough to make this all painless.
      
      So this moves the ACPI RTC glue ("acpi_rtc_init()") down to a regular
      module call, which fixes the problem Rafael has.  The reason this isn't
      wonderful is that we really should do acpi_rtc_init before we do the
      rtc_cmos init, and now those two are in the same module_init() section.
      
      Which happens to work, but only because drivers/rtc is linked after
      drivers/acpi.  In other words, we still have a very subtle ordering
      issue here. Grr.
      Reported-and-tested-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NDavid Brownell <david-b@pacbell.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1efd325f
  2. 12 10月, 2008 19 次提交
  3. 11 10月, 2008 17 次提交