On Wed, 2007-11-28 at 14:06 -0600, Mike Christie wrote:
> Anil Veerabhadrappa wrote:
> >
> Which ones were they exactly? I think JamesB wanted only common
> transport values in the transport class. If it is driver specific then
> it should go on the host or target or device with t
Anil Veerabhadrappa wrote:
Which ones were they exactly? I think JamesB wanted only common
transport values in the transport class. If it is driver specific then
it should go on the host or target or device with the scsi_host_template
attrs.
It's a chicken & egg issue to put "port mapper"
> >> Which ones were they exactly? I think JamesB wanted only common
> >> transport values in the transport class. If it is driver specific then
> >> it should go on the host or target or device with the scsi_host_template
> >> attrs.
> >>
> >
> > It's a chicken & egg issue to put "port mapper
Anil Veerabhadrappa wrote:
The sysfs bits related to the hba should be use one of the scsi sysfs
facilities or if they are related to iscsi bits and are generic then
through the iscsi hba
bnx2i needs 2 sysfs entries -
1. QP size info - this is used to size per connection shared data
structures
Anil Veerabhadrappa wrote:
It's a chicken & egg issue to put "port mapper" sysfs entry in scsi host
attributes. Application won't see sysfs unless initiator creates an
iSCSI session and driver can't create an iSCSI session without a tcp
port. I was wondering if there is a better way than using I
> >> The sysfs bits related to the hba should be use one of the scsi sysfs
> >> facilities or if they are related to iscsi bits and are generic then
> >> through the iscsi hba
> >
> > bnx2i needs 2 sysfs entries -
> > 1. QP size info - this is used to size per connection shared data
> > structu
CC'ed Jens, James, and linux-scsi again.
On Thu, 27 Sep 2007 04:22:15 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2007-09-27 at 03:49 -0400, Jeff Garzik wrote:
> >> Benjamin Herrenschmidt wrote:
> >>> On Thu, 2007-09-27 at 03:31 -0400, Jeff Garzik wrot
FUJITA Tomonori wrote:
CC'ed Jens, James, and linux-scsi.
On Thu, 27 Sep 2007 03:31:55 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
FUJITA Tomonori wrote:
Yeah, we could nicely handle lld's restrictions (especially with
stacking devices). But iommu code needs only max_segment_size and
seg_bou
Benjamin Herrenschmidt wrote:
On Thu, 2007-09-27 at 03:49 -0400, Jeff Garzik wrote:
Benjamin Herrenschmidt wrote:
On Thu, 2007-09-27 at 03:31 -0400, Jeff Garzik wrote:
A key problem I was hoping would be solved with your work here was
the
elimination of that post dma_map_sg() split.
If I un
On Thu, 2007-09-27 at 03:49 -0400, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2007-09-27 at 03:31 -0400, Jeff Garzik wrote:
> >> A key problem I was hoping would be solved with your work here was
> >> the
> >> elimination of that post dma_map_sg() split.
> >>
> >> If I underst
CC'ed Jens, James, and linux-scsi.
On Thu, 27 Sep 2007 03:31:55 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> FUJITA Tomonori wrote:
> > Yeah, we could nicely handle lld's restrictions (especially with
> > stacking devices). But iommu code needs only max_segment_size and
> > seg_boundary_mask, r
Benjamin Herrenschmidt wrote:
On Thu, 2007-09-27 at 03:31 -0400, Jeff Garzik wrote:
A key problem I was hoping would be solved with your work here was
the
elimination of that post dma_map_sg() split.
If I understood James and Ben correctly, one of the key problems was
always in communicating
On Thu, 2007-09-27 at 03:31 -0400, Jeff Garzik wrote:
> A key problem I was hoping would be solved with your work here was
> the
> elimination of that post dma_map_sg() split.
>
> If I understood James and Ben correctly, one of the key problems was
> always in communicating libata's segment bou
FUJITA Tomonori wrote:
Yeah, we could nicely handle lld's restrictions (especially with
stacking devices). But iommu code needs only max_segment_size and
seg_boundary_mask, right? If so, the first simple approach to add two
values to device structure is not so bad, I think.
(replying to slightl
On Tue, 25 Sep 2007 10:39:17 +0200
Hannes Reinecke <[EMAIL PROTECTED]> wrote:
> Hi Tomo,
>
> FUJITA Tomonori wrote:
> > On Sat, 8 Sep 2007 13:00:36 +0100
> > Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> >
> >> On Sat, Sep 08, 2007 at 07:32:27AM -0400, Jeff Garzik wrote:
> >>> FUJITA Tomonori w
Hi Tomo,
FUJITA Tomonori wrote:
> On Sat, 8 Sep 2007 13:00:36 +0100
> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
>> On Sat, Sep 08, 2007 at 07:32:27AM -0400, Jeff Garzik wrote:
>>> FUJITA Tomonori wrote:
Yeah, iommu code ignores the lld limitations (the problem is that the
lld limit
On Sat, 8 Sep 2007 13:00:36 +0100
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 08, 2007 at 07:32:27AM -0400, Jeff Garzik wrote:
> > FUJITA Tomonori wrote:
> > >Yeah, iommu code ignores the lld limitations (the problem is that the
> > >lld limitations are in request_queue and iommu co
On Sat, 2007-09-08 at 07:49 -0700, Michael Chan wrote:
> Christoph Hellwig wrote:
>
> > Most of it should just go away, and the other bits shouldn't
> > change over
> > the lifetime of the driver except for additions. So there
> > really isn't
> > any point in auto-generating it.
> >
>
> Yes,
Christoph Hellwig wrote:
> Most of it should just go away, and the other bits shouldn't
> change over
> the lifetime of the driver except for additions. So there
> really isn't
> any point in auto-generating it.
>
Yes, I agree with Mike Christie on this. These values in
question are defined
On Sat, Sep 08, 2007 at 07:32:27AM -0400, Jeff Garzik wrote:
> FUJITA Tomonori wrote:
> >Yeah, iommu code ignores the lld limitations (the problem is that the
> >lld limitations are in request_queue and iommu code can't access to
> >request_queue). There is no way to tell iommu code about the lld
>
On Wed, Sep 05, 2007 at 02:27:02PM -0700, Anil Veerabhadrappa wrote:
> This is a very tricky proposal as this header file is automatically
> generated by a well defined process and is shared between various driver
> supporting multiple platform/OS and the firmware. If it is not of a big
> issue I w
FUJITA Tomonori wrote:
Yeah, iommu code ignores the lld limitations (the problem is that the
lld limitations are in request_queue and iommu code can't access to
request_queue). There is no way to tell iommu code about the lld
limitations.
This fact very much wants fixing.
Jeff
-
To
On Fri, 07 Sep 2007 17:36:47 -0500
Mike Christie <[EMAIL PROTECTED]> wrote:
> > +/*
> > + * map SG list
> > + */
> > +static int bnx2i_map_sg(struct bnx2i_hba *hba, struct bnx2i_cmd *cmd)
> > +{
> > + struct scsi_cmnd *sc = cmd->scsi_cmd;
> > + struct iscsi_bd *bd = cmd->bd_tbl->bd_tbl;
> > +
Some quick comments that got cut out of the original mail.
+
+/*
+ * map single buffer
+ */
+static int bnx2i_map_single_buf(struct bnx2i_hba *hba,
+ struct bnx2i_cmd *cmd)
+{
+ struct scsi_cmnd *sc = cmd->scsi_cmd;
+ struct iscsi_bd *bd = cmd->b
Anil Veerabhadrappa wrote:
+
+/* iSCSI stages */
+#define ISCSI_STAGE_SECURITY_NEGOTIATION (0)
+#define ISCSI_STAGE_LOGIN_OPERATIONAL_NEGOTIATION (1)
+#define ISCSI_STAGE_FULL_FEATURE_PHASE (3)
+/* Logout response codes */
+#define ISCSI_LOGOUT_RESPONSE_CONNECTION_CLOSED (0)
+#define ISCSI_LOGO
On Wed, 2007-09-05 at 13:34 -0500, Mike Christie wrote:
> Michael Chan wrote:
> > +* This file defines HSI constants for the iSCSI flows
> > +*/
> > +
> > +/* iSCSI request op codes */
> > +#define ISCSI_OPCODE_NOP_OUT (0 | 0x40)
> > +#define ISCSI_OPCODE_SCSI_CMD
Michael Chan wrote:
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 6f2c71e..adcfbbc 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1800,6 +1800,8 @@ config ZFCP
called zfcp. If you want to compile it as a module, say M here
and read .
+sou
27 matches
Mail list logo
