> >
> > mpi3mr_fw.c - Keep common code which interact with underlying
> fw/hw.
> > mpi3mr_os.c - Keep common code which interact with scsi midlayer.
> > mpi3mr_app.c - Keep common code which interact with
> application/ioctl.
> > This is currently work in progress.
> >
>
> Meaning what? That it's not finished by the time of submission?
Hannes-
Current patch series has around 15K lines so we wanted to avoid something
which can be delayed for better review.
Application part is ready but it is many time going through API changes, so
having something close to freeze is better for upstream submission.
Once this set is committed , application support is possible in next series.
> > +
> > +/**
> > + * struct scmd_priv - SCSI command private data
> > + *
> > + * @host_tag: Host tag specific to operational queue
> > + * @in_lld_scope: Command in LLD scope or not
> > + * @scmd: SCSI Command pointer
> > + * @req_q_idx: Operational request queue index
> > + * @chain_idx: Chain frame index
> > + * @mpi3mr_scsiio_req: MPI SCSI IO request
> > + */
> > +struct scmd_priv {
> > + u16 host_tag;
> > + u8 in_lld_scope;
> > + struct scsi_cmnd *scmd;
> > + u16 req_q_idx;
> > + int chain_idx;
> > + u8 mpi3mr_scsiio_req[MPI3MR_ADMIN_REQ_FRAME_SZ];
> > +};
> > +
>
> Why is this not of type MPI3_SCSI_IO_REQUEST, but rather a binary blob?
>
Type MPI3_SCSI_IO_REQUEST is not static struct. MPI spec designed to have
dynamic size of " MPI3_SCSI_IO_REQUEST" but current code cannot work to
handle dynamic size.
In case of old MPT product (mpt3sas) most of the time we have always used
128 byte size from FW for MPI3_SCSI_IO_REQUEST and that may continue for
this product as well.
I have to discuss within a Broadcom and do changes in this area based on
product support. For now, I have to consider your comment as TBD. Hope you
are ok with it.
Kashyap
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
