Commit Graph

4 Commits

Author SHA1 Message Date
James Bottomley 10c1b88987 [SCSI] add ability to deny binding to SPI transport class
This patch is necessary if we begin exposing underlying physical disks
(which can attach to the SPI transport class) of the hardware RAID
cards, since we don't want any SPI parameters binding to the RAID
devices.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-08-14 14:42:25 -05:00
James Bottomley d872ebe454 [SCSI] add missing hold_mcs parameter to the spi transport class
This parameter is important only to people who take the time to tune the
margin control settings, otherwise it's completely irrelevant.  However,
just in case anyone should want to do this, it's appropriate to include
the parameter.

I don't do anything with it in DV by design, so the parameter will come
up as off by default, so if anyone actually wants to play with the
margin control settings they'll have to enable it under the
spi_transport class first.

I also updated the transfer settings display to report all of the PPR
settings instead of only DT, IU and QAS

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-08-03 15:54:55 -05:00
James Bottomley 62a8612972 [SCSI] implement parameter limits in the SPI transport class
There's a basic need not to have parameters go under or over certain
values when doing domain validation.  The basic ones are

max_offset, max_width and min_period

This patch makes the transport class take and enforce these three
limits.  Currently they can be set by the user, although they could
obviously be read from the HBA's on-board NVRAM area during
slave_configure (if it has one).

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-05-20 15:54:32 -05:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00