Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 20 11月, 2014 2 次提交
  3. 02 6月, 2014 4 次提交
  5. 16 3月, 2014 16 次提交
  7. 20 12月, 2013 2 次提交
  9. 10 5月, 2012 3 次提交
  11. 19 2月, 2012 2 次提交
    • S
      [SCSI] hpsa: eliminate 8 external target limitation · aca4a520
      由 Scott Teel 提交于 
      Driver limits SAS external target IDs to range 1-8.
Need to increase limit and clean up overlapping concepts of targets and paths
in the code.

There are several defined constants that control this:
HPSA_MAX_TARGETS_PER_CTLR     16
MAX_MSA2XXX_ENCLOSURES        32
HPSA_MAX_PATHS                8

We can condense this to one constant:
MAX_EXT_TARGETS               32

SAS switches allow for 8 connections, and there is capacity for 4 switches per
enclosure in largest blade enclosure type.
Signed-off-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      aca4a520
    • S
      [SCSI] hpsa: removed unneeded structure member max_sg_entries and fix badly... · d66ae08b
      由 Stephen M. Cameron 提交于 
      [SCSI] hpsa: removed unneeded structure member max_sg_entries and fix badly named constant MAXSGENTRIES

We had both h->max_sg_entries and h->maxsgentries in the per controller
structure which is terribly confusing.  max_sg_entries was really
just a constant, 32, which defines how big the "block fetch table"
is, which is as large as the max number of SG elements embedded
within a command (excluding SG elements in chain blocks).

MAXSGENTRIES was the constant used to denote the max number of SG
elements embedded within a command, also a poor name.

So renamed MAXSGENTREIS to SG_ENTRIES_IN_CMD, and removed
h->max_sg_entries and replaced it with SG_ENTRIES_IN_CMD.

h->maxsgentries is unchanged, and is the maximum number of sg
elements the controller will support in a command, including
those in chain blocks, minus 1 for the chain block pointer..
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      d66ae08b
  13. 30 10月, 2011 1 次提交
  15. 17 5月, 2011 3 次提交
  17. 19 2月, 2011 2 次提交
  19. 25 1月, 2011 1 次提交
  21. 28 7月, 2010 1 次提交
    • S
      [SCSI] hpsa: Fix hard reset code. · 1df8552a
      由 Stephen M. Cameron 提交于 
      Smart Array controllers newer than the P600 do not honor the
PCI power state method of resetting the controllers.  Instead,
in these cases we can get them to reset via the "doorbell" register.

This escaped notice until we began using "performant" mode because
the fact that the controllers did not reset did not normally
impede subsequent operation, and so things generally appeared to
"work".  Once the performant mode code was added, if the controller
does not reset, it remains in performant mode.  The code immediately
after the reset presumes the controller is in "simple" mode
(which previously, it had remained in simple mode the whole time).
If the controller remains in performant mode any code which presumes
it is in simple mode will not work.  So the reset needs to be fixed.

Unfortunately there are some controllers which cannot be reset by
either method. (eg. p800).  We detect these cases by noticing that
the controller seems to remain in performant mode even after a
reset has been attempted.  In those case, we proceed anyway,
as if the reset has happened (and skip the step of waiting for
the controller to become ready -- which is expecting it to be in
"simple" mode.)  To sum up, we try to do a better job of resetting
the controller if "reset_devices" is set, and if it doesn't work,
we print a message and try to continue anyway.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      1df8552a
  23. 02 5月, 2010 1 次提交
  25. 03 3月, 2010 2 次提交