<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/include/scsi/fc, branch v2.6.29.4</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>[SCSI] fcoe: ETH_P_8021Q is already in if_ether and fcoe is not using it anyway</title>
<updated>2009-03-10T14:07:09+00:00</updated>
<author>
<name>Yi Zou</name>
<email>yi.zou@intel.com</email>
</author>
<published>2009-02-27T18:56:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=74846bf85e42b4ba851d3f0dd67aa1df245895f9'/>
<id>74846bf85e42b4ba851d3f0dd67aa1df245895f9</id>
<content type='text'>
Signed-off-by: Yi Zou &lt;yi.zou@intel.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Yi Zou &lt;yi.zou@intel.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] libfc: rport retry on LS_RJT from certain ELS</title>
<updated>2009-03-06T21:39:34+00:00</updated>
<author>
<name>Chris Leech</name>
<email>christopher.leech@intel.com</email>
</author>
<published>2009-02-27T18:55:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6755db1cd4587084be85f860b7aa7c0cc9d776dc'/>
<id>6755db1cd4587084be85f860b7aa7c0cc9d776dc</id>
<content type='text'>
This allows any rport ELS to retry on LS_RJT.

The rport error handling would only retry on resource allocation failures
and exchange timeouts.  I have a target that will occasionally reject PLOGI
when we do a quick LOGO/PLOGI.  When a critical ELS was rejected, libfc would
fail silently leaving the rport in a dead state.

The retry count and delay are managed by fc_rport_error_retry.  If the retry
count is exceeded fc_rport_error will be called.  When retrying is not the
correct course of action, fc_rport_error can be called directly.

Signed-off-by: Chris Leech &lt;christopher.leech@intel.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This allows any rport ELS to retry on LS_RJT.

The rport error handling would only retry on resource allocation failures
and exchange timeouts.  I have a target that will occasionally reject PLOGI
when we do a quick LOGO/PLOGI.  When a critical ELS was rejected, libfc would
fail silently leaving the rport in a dead state.

The retry count and delay are managed by fc_rport_error_retry.  If the retry
count is exceeded fc_rport_error will be called.  When retrying is not the
correct course of action, fc_rport_error can be called directly.

Signed-off-by: Chris Leech &lt;christopher.leech@intel.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] FC protocol definition header files</title>
<updated>2008-12-29T17:24:32+00:00</updated>
<author>
<name>Robert Love</name>
<email>robert.w.love@intel.com</email>
</author>
<published>2008-12-09T23:10:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f032c2f7cdaae0e8907cd3b26426fc651dc5c275'/>
<id>f032c2f7cdaae0e8907cd3b26426fc651dc5c275</id>
<content type='text'>
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
