1. 18 5月, 2012 3 次提交
    • D
      isci: refactor initialization for S3/S4 · abec912d
      Dan Williams 提交于
      Based on an original implementation by Ed Nadolski and Artur Wojcik
      
      In preparation for S3/S4 support refactor initialization so that
      driver-load and resume-from-suspend can share the common init path of
      isci_host_init().  Organize the initialization into objects that are
      self-contained to the driver (initialized by isci_host_init) versus
      those that have some upward registration (initialized at allocation time
      asd_sas_phy, asd_sas_port, dma allocations).  The largest change is
      moving the the validation of the oem and module parameters from
      isci_host_init() to isci_host_alloc().
      
      The S3/S4 approach being taken is that libsas will be tasked with
      remembering the state of the domain and the lldd is free to be
      forgetful.  In the case of isci we'll just re-init using a subset of the
      normal driver load path.
      
      [clean up some unused / mis-indented function definitions in host.h]
      Signed-off-by: NEd Nadolski <edmund.nadolski@intel.com>
      Signed-off-by: NArtur Wojcik <artur.wojcik@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      abec912d
    • D
      isci: kill sci_phy_protocol and sci_request_protocol · c79dd80d
      Dan Williams 提交于
      Holdovers from the initial driver cleanup, replace with enum sas_protocol.
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      c79dd80d
    • D
      isci: kill ->is_direct_attached · 11cc5183
      Dan Williams 提交于
      domain_device ->parent conveys the same information.
      
      Occurrences of ->is_direct_attached appear next to incomplete open-coded
      versions of dev_is_sata(), clean those up as well.
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      11cc5183
  2. 20 3月, 2012 1 次提交
  3. 01 3月, 2012 2 次提交
  4. 20 2月, 2012 1 次提交
  5. 19 2月, 2012 1 次提交
  6. 31 10月, 2011 2 次提交
    • J
      [SCSI] isci: Remove redundant isci_request.ttype field. · 3b34c169
      Jeff Skirvin 提交于
      Use the existing IREQ_TMF flag as a request type indicator.
      Signed-off-by: NJeff Skirvin <jeffrey.d.skirvin@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      3b34c169
    • J
      [SCSI] isci: Lookup device references through requests in completions. · 0e2e2799
      Jeff Skirvin 提交于
      The LLDD needs to obtain a reference to the device through the request
      itself and not through the domain_device, because the
      domain_device.lldd_dev is set to NULL early in the lldd_dev_gone call.
      This relies on the fact that the isci_remote_device object is keeping a
      seperate reference count of outstanding requests.  TODO: unify the
      request count tracking with the isci_remote_device kref.
      
      The failure signature of this condition looks like the following
      log, where the important bits are the call to lldd_dev_gone followed
      by a crash in isci_terminate_request_core:
      
      [  229.151541] isci 0000:0b:00.0: isci_remote_device_gone: domain_device = ffff8801492d4800, isci_device = ffff880143c657d0, isci_port = ffff880143c63658
      [  229.166007] isci 0000:0b:00.0: isci_remote_device_stop: isci_device = ffff880143c657d0
      [  229.175317] isci 0000:0b:00.0: isci_terminate_pending_requests: idev=ffff880143c657d0 request=ffff88014741f000; task=ffff8801470f46c0 old_state=2
      [  229.189702] isci 0000:0b:00.0: isci_terminate_request_core: device = ffff880143c657d0; request = ffff88014741f000
      [  229.201339] isci 0000:0b:00.0: isci_terminate_request_core: before completion wait (ffff88014741f000/ffff880149715ad0)
      [  229.213414] isci 0000:0b:00.0: sci_controller_process_completions: completion queue entry:0x8000a0e9
      [  229.214401] BUG: unable to handle kernel NULL pointer dereference at 0000000000000228
      [  229.214401] IP:jdskirvi-testlbo [<ffffffffa00a58be>] sci_request_completed_state_enter+0x50/0xafb [isci]
      [  229.214401] PGD 13d19e067 PUD 13d104067 PMD 0
      [  229.214401] Oops: 0000 [#1] SMP
      [  229.214401] CPU 0 x kernel: [  226
      [  229.214401] Modules linked in: ipv6 dm_multipath uinput nouveau snd_hda_codec_realtek snd_hda_intel ttm drm_kms_helper drm snd_hda_codec snd_hwdep snd_pcm snd_timer i2c_algo_bit isci snd libsas ioatdma mxm_wmi iTCO_wdt soundcore snd_page_alloc scsi_transport_sas iTCO_vendor_support wmi dca video i2c_i801 i2c_core [last unloaded: speedstep_lib]
      [  229.214401]
      [  229.214401] Pid: 5, comm: kworker/u:0 Not tainted 3.0.0-isci-11.7.29+ #30.353196] Buffer  Intel Corporation Stoakley/Pearlcity Workstation
      [  229.214401] RIP: 0010:[<ffffffffa00a58be>] I/O error on dev [<ffffffffa00a58be>] sci_request_completed_state_enter+0x50/0xafb [isci]
      [  229.214401] RSP: 0018:ffff88014fc03d20  EFLAGS: 00010046
      [  229.214401] RAX: 0000000000000000 RBX: ffff88014741f000 RCX: 0000000000000000
      [  229.214401] RDX: ffffffffa00b2c90 RSI: 0000000000000017 RDI: ffff88014741f0a0
      [  229.214401] RBP: ffff88014fc03d90 R08: 0000000000000018 R09: 0000000000000000
      [  229.214401] R10: 0000000000000000 R11: ffffffff81a17d98 R12: 000000000000001d
      [  229.214401] R13: ffff8801470f46c0 R14: 0000000000000000 R15: 0000000000008000
      [  229.214401] FS:  0000000000000000(0000) GS:ffff88014fc00000(0000) knlGS:0000000000000000
      [  229.214401] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  229.214401] CR2: 0000000000000228 CR3: 000000013ceaa000 CR4: 00000000000406f0
      [  229.214401] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  229.214401] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  229.214401] Process kworker/u:0 (pid: 5, threadinfo ffff880149714000, task ffff880149718000)
      [  229.214401] Call Trace:
      [  229.214401]  <IRQ>
      [  229.214401]  [<ffffffffa00aa6ce>] sci_change_state+0x4a/0x4f [isci]
      [  229.214401]  [<ffffffffa00a4ca6>] sci_io_request_tc_completion+0x79c/0x7a0 [isci]
      [  229.214401]  [<ffffffffa00acf35>] sci_controller_process_completions+0x14f/0x396 [isci]
      [  229.214401]  [<ffffffffa00abbda>] ? spin_lock_irq+0xe/0x10 [isci]
      [  229.214401]  [<ffffffffa00ad2cf>] isci_host_completion_routine+0x71/0x2be [isci]
      [  229.214401]  [<ffffffff8107c6b3>] ? mark_held_locks+0x52/0x70
      [  229.214401]  [<ffffffff810538e8>] tasklet_action+0x90/0xf1
      [  229.214401]  [<ffffffff81054050>] __do_softirq+0xe5/0x1bf
      [  229.214401]  [<ffffffff8106d9d1>] ? hrtimer_interrupt+0x129/0x1bb
      [  229.214401]  [<ffffffff814ff69c>] call_softirq+0x1c/0x30
      [  229.214401]  [<ffffffff8100bb67>] do_softirq+0x4b/0xa3
      [  229.214401]  [<ffffffff81053d84>] irq_exit+0x53/0xb4
      [  229.214401]  [<ffffffff814fffe7>] smp_apic_timer_interrupt+0x83/0x91
      [  229.214401]  [<ffffffff814fee53>] apic_timer_interrupt+0x13/0x20
      [  229.214401]  <EOI>
      [  229.214401]  [<ffffffff814f7ad4>] ? retint_restore_args+0x13/0x13
      [  229.214401]  [<ffffffff8107af29>] ? trace_hardirqs_off+0xd/0xf
      [  229.214401]  [<ffffffff8104ea71>] ? vprintk+0x40b/0x452
      [  229.214401]  [<ffffffff814f4b5a>] printk+0x41/0x47
      [  229.214401]  [<ffffffff81314484>] __dev_printk+0x78/0x7a
      [  229.214401]  [<ffffffff8131471e>] dev_printk+0x45/0x47
      [  229.214401]  [<ffffffffa00ae2a3>] isci_terminate_request_core+0x15d/0x317 [isci]
      [  229.214401]  [<ffffffffa00af1ad>] isci_terminate_pending_requests+0x1a4/0x204 [isci]
      [  229.214401]  [<ffffffffa00229f6>] ? sas_phye_oob_error+0xc3/0xc3 [libsas]
      [  229.214401]  [<ffffffffa00a7d9e>] isci_remote_device_nuke_requests+0xa6/0xff [isci]
      [  229.214401]  [<ffffffffa00a811a>] isci_remote_device_stop+0x7c/0x166 [isci]
      [  229.214401]  [<ffffffffa00229f6>] ? sas_phye_oob_error+0xc3/0xc3 [libsas]
      [  229.214401]  [<ffffffffa00a827a>] isci_remote_device_gone+0x76/0x7e [isci]
      [  229.214401]  [<ffffffffa002363e>] sas_notify_lldd_dev_gone+0x34/0x36 [libsas]
      [  229.214401]  [<ffffffffa0023945>] sas_unregister_dev+0x57/0x9c [libsas]
      [  229.214401]  [<ffffffffa00239c0>] sas_unregister_domain_devices+0x36/0x65 [libsas]
      [  229.214401]  [<ffffffffa0022cb8>] sas_deform_port+0x72/0x1ac [libsas]
      [  229.214401]  [<ffffffffa00229f6>] ? sas_phye_oob_error+0xc3/0xc3 [libsas]
      [  229.214401]  [<ffffffffa0022a34>] sas_phye_loss_of_signal+0x3e/0x42 [libsas]
      Signed-off-by: NJeff Skirvin <jeffrey.d.skirvin@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      0e2e2799
  7. 03 10月, 2011 3 次提交
    • J
      [SCSI] isci: fix decode of DONE_CRC_ERR TC completion status · 7582ba8b
      Jeff Skirvin 提交于
      DONE_CRC_ERR is not a RNC suspension condition, so do not change the
      state to expect the incoming suspension notification.
      Signed-off-by: NJeff Skirvin <jeffrey.d.skirvin@intel.com>
      [djbw: dropped DONE_CMD_LL_R_ERR change]
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      7582ba8b
    • D
      [SCSI] isci: atapi support · b50102d3
      Dan Williams 提交于
      Based on original implementation from Jiangbi Liu and Maciej Trela.
      
      ATAPI transfers happen in two-to-three stages.  The two stage atapi
      commands are those that include a dma data transfer.  The data transfer
      portion of these operations is handled by the hardware packet-dma
      acceleration.  The three-stage commands do not have a data transfer and
      are handled without hardware assistance in raw frame mode.
      
      stage1: transmit host-to-device fis to notify the device of an incoming
      atapi cdb.  Upon reception of the pio-setup-fis repost the task_context
      to perform the dma transfer of the cdb+data (go to stage3), or repost
      the task_context to transmit the cdb as a raw frame (go to stage 2).
      
      stage2: wait for hardware notification of the cdb transmission and then
      go to stage 3.
      
      stage3: wait for the arrival of the terminating device-to-host fis and
      terminate the command.
      
      To keep the implementation simple we only support ATAPI packet-dma
      protocol (for commands with data) to avoid needing to handle the data
      transfer manually (like we do for SATA-PIO).  This may affect
      compatibility for a small number of devices (see
      ATA_HORKAGE_ATAPI_MOD16_DMA).
      
      If the data-transfer underruns, or encounters an error the
      device-to-host fis is expected to arrive in the unsolicited frame queue
      to pass to libata for disposition.  However, in the DONE_UNEXP_FIS (data
      underrun) case it appears we need to craft a response.  In the
      DONE_REG_ERR case we do receive the UF and propagate it to libsas.
      Signed-off-by: NMaciej Trela <maciej.trela@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      b50102d3
    • D
      [SCSI] isci: fix support for large smp requests · 54b5e3a4
      Dan Williams 提交于
      Kill the local smp response buffer.
      
      Besides being unnecessary, it is too small (currently truncates
      responses to 60 bytes).  The mid-layer will have already allocated a
      sufficiently sized buffer, just kmap and copy into it directly.
      
      Cc: <stable@kernel.org>
      Reported-by: NDerick Marks <derick.w.marks@intel.com>
      Tested-by: NDerick Marks <derick.w.marks@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      54b5e3a4
  8. 24 8月, 2011 2 次提交
  9. 03 7月, 2011 25 次提交