Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 30 10月, 2009 1 次提交
  3. 10 6月, 2009 4 次提交
    • K
      [SCSI] mpt fusion: Code Cleanup patch · 2f187862
      由 Kashyap, Desai 提交于 
      Resending patch considering Grants G's code review.

Main goal to submit this patch is code cleaup.
1. Better driver debug prints and code indentation.
2. fault_reset_work_lock is not used anywhere. driver is using taskmgmt_lock
instead of fault_reset_work_lock.
3. setting pci_set_drvdata properly.
4. Ingore config request when IOC is in reset state.( ioc_reset_in_progress
is set).
5. Init/clear managment frame proprely.(INITIALIZE_MGMT_STATUS and
CLEAR_MGMT_STATUS)
Signed-off-by: NKashyap Desai <kadesai@lsi.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      2f187862
    • K
      [SCSI] mpt fusion: rewrite of ioctl_cmds internal generated function · ea2a788d
      由 Kashyap, Desai 提交于 
      1) rewrite of ioctl_cmds internal generated function that issue commands to
firmware, porting them to be single threaded using the generic MPT_MGMT
struct. All wait Queues are replace by completion Queue.
2) added seperate callback handler for ioctl task managment
(mptctl_taskmgmt_reply), to handle command that timeout
3) rewrite mptctl_bus_reset
Signed-off-by: NKashyap Desai <kadesai@lsi.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      ea2a788d
    • K
      [SCSI] mpt fusion: config path optimized, completion queue is used · f0f09d3b
      由 Kashyap, Desai 提交于 
      1) 	Previously we had mutliple #defines to use same values.
	Now those #defines are optimized.
	MPT_IOCTL_STATUS_* is removed and  MPT_MGMT_STATUS_* are new
	#defines.
2.)	config path is optimized.
	Instead of wait Queue and timer, using completion Q.
3.)	mpt_timer_expired is not used.

[jejb: elide patch to eliminate mpt_timer_expired]
Signed-off-by: NKashyap Desai <kadesai@lsi.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      f0f09d3b
    • K
      [SCSI] mpt fusion: Fixing 1078 data corruption issue for 36GB memory region · 14d0f0b0
      由 Kashyap, Desai 提交于 
      The reason for this change is there is a data corruption when four different
physical memory regions in the 36GB to 37GB region are
accessed. This is only affecting 1078.

The solution is we need to use different addressing when filling in
the scatter gather table for the effected memory regions.  So instead
of snooping on all four different memory holes, we treat any physical
addresses in the 36GB address with the same algorithm.

The fix is explained below
1) Ensure that the message frames are NOT located in the trouble
region. There is no remapping available for message frames, they must
be allocated outside the problem region.
2) Ensure that Sense buffers are NOT in the trouble region. There is
no remapping available.
3) Walk through the SGE entries and if any are inside the trouble region
   then they need to be remapped as discussed below.
	1) Set the Local Address bit in the SGE Flags field.
  	MPI_SGE_FLAGS_LOCAL_ADDRESS
  	2) Ensure we are using 64-bit SGEs
  	3) Set MSb (Bit 63) of the 64-bit address, this will indicate buffer
	location is Host Memory.
Signed-off-by: NKashyap Desai <kadesai@lsi.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      14d0f0b0
  5. 03 1月, 2009 1 次提交
  7. 02 11月, 2008 1 次提交
    • A
      saner FASYNC handling on file close · 233e70f4
      由 Al Viro 提交于 
      As it is, all instances of ->release() for files that have ->fasync()
need to remember to evict file from fasync lists; forgetting that
creates a hole and we actually have a bunch that *does* forget.

So let's keep our lives simple - let __fput() check FASYNC in
file->f_flags and call ->fasync() there if it's been set.  And lose that
crap in ->release() instances - leaving it there is still valid, but we
don't have to bother anymore.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      233e70f4
  9. 27 7月, 2008 1 次提交
  11. 03 7月, 2008 1 次提交
  13. 05 6月, 2008 1 次提交
  15. 03 2月, 2008 1 次提交
  17. 13 10月, 2007 8 次提交
  19. 28 7月, 2007 1 次提交
  21. 18 6月, 2007 1 次提交
  23. 13 2月, 2007 1 次提交
  25. 03 2月, 2007 3 次提交
  27. 06 1月, 2007 1 次提交
  29. 13 7月, 2006 1 次提交
  31. 15 3月, 2006 2 次提交
  33. 05 2月, 2006 8 次提交
  35. 15 1月, 2006 1 次提交
  37. 11 1月, 2006 1 次提交
  39. 14 12月, 2005 1 次提交