On 4/27/21 5:47 PM, Kashyap Desai wrote:
>>>
>>> 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.
>
Oh, that's okay. If the commands really are of different sizes then sure
you'd have to use a raw blob to avoid padding.
So:
Reviewed-by: Hannes Reinecke <hare@xxxxxxx>
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions Germany GmbH, 90409 Nürnberg
GF: F. Imendörffer, HRB 36809 (AG Nürnberg)
