1. 14 Jul, 2008 10 commits
  2. 10 Jun, 2008 9 commits
  3. 06 Jun, 2008 1 commit
  4. 30 May, 2008 6 commits
  5. 29 May, 2008 1 commit
    • Rusty Russell's avatar
      virtio: set device index in common code. · b769f579
      Rusty Russell authored
      Anthony Liguori points out that three different transports use the virtio code,
      but each one keeps its own counter to set the virtio_device's index field.  In
      theory (though not in current practice) this means that names could be
      duplicated, and that risk grows as more transports are created.
      So we move the selection of the unique virtio_device.index into the common code
      in virtio.c, which has the side-benefit of removing duplicate code.
      The only complexity is that lguest and S/390 use the index to uniquely identify
      the device in case of catastrophic failure before register_virtio_device() is
      called: now we use the offset within the descriptor page as a unique identifier
      for the printks.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chris Lalancette <clalance@redhat.com>
      Cc: Anthony Liguori <anthony@codemonkey.ws>
  6. 20 May, 2008 1 commit
    • Greg Kroah-Hartman's avatar
      s390: fix race in device_create · c5fb920a
      Greg Kroah-Hartman authored
      There is a race from when a device is created with device_create() and
      then the drvdata is set with a call to dev_set_drvdata() in which a
      sysfs file could be open, yet the drvdata will be NULL, causing all
      sorts of bad things to happen.
      This patch fixes the problem by using the new function,
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  7. 18 May, 2008 1 commit
  8. 15 May, 2008 6 commits
  9. 07 May, 2008 4 commits
  10. 02 May, 2008 1 commit
    • Boaz Harrosh's avatar
      [SCSI] Let scsi_cmnd->cmnd use request->cmd buffer · 64a87b24
      Boaz Harrosh authored
       - struct scsi_cmnd had a 16 bytes command buffer of its own.
         This is an unnecessary duplication and copy of request's
         cmd. It is probably left overs from the time that scsi_cmnd
         could function without a request attached. So clean that up.
       - Once above is done, few places, apart from scsi-ml, needed
         adjustments due to changing the data type of scsi_cmnd->cmnd.
       - Lots of drivers still use MAX_COMMAND_SIZE. So I have left
         that #define but equate it to BLK_MAX_CDB. The way I see it
         and is reflected in the patch below is.
         MAX_COMMAND_SIZE - means: The longest fixed-length (*) SCSI CDB
                            as per the SCSI standard and is not related
                            to the implementation.
         BLK_MAX_CDB.     - The allocated space at the request level
       - I have audit all ISA drivers and made sure none use ->cmnd in a DMA
         Operation. Same audit was done by Andi Kleen.
      (*)fixed-length here means commands that their size can be determined
         by their opcode and the CDB does not carry a length specifier, (unlike
         the VARIABLE_LENGTH_CMD(0x7f) command). This is actually not exactly
         true and the SCSI standard also defines extended commands and
         vendor specific commands that can be bigger than 16 bytes. The kernel
         will support these using the same infrastructure used for VARLEN CDB's.
         So in effect MAX_COMMAND_SIZE means the maximum size command
         scsi-ml supports without specifying a cmd_len by ULD's
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>