Re: [RFC] IBM Power RAID driver (ipr)

[Brian King <brking@us.ibm.com>]

Christoph Hellwig wrote
>>Ok, but I will still need that interface to send commands directed to 
>>the adapter.
> 
> 
> commands as in scsi commands or as in internal commands?

Internal commands. As you look through the driver, they will look very 
similar, as the interface to the adapter maps to scsi pretty close. I 
could use the mid-layer for these commands, but I would need some way to 
send them when the adapter is self blocked and would probably need to 
call scsi_add_host before the adapter is functional so I could send the 
adapter initialization sequence.


>>>>Build a command in DMA'able host memory (struct ipr_ioarcb), write the 
>>>>PCI address to a register on the adapter, the adapter DMAs down the 
>>>>control block, executes the command, writes the 
>>>>ipr_ioarcb.host_response_handle in the command control block to the host 
>>>>request/response queue in host memory, and signals an interrupt.
>>>>
>>>>Does that help at all?
>>>
>>>What's the relation of all these command lists to that?
>>
>>Sorry, I guess I'm missing something here. Are you saying a LLD 
>>shouldn't need to maintain of queue of its command blocks (like my 
>>pending_q and free_q)?
> 
> 
> Unless you allocate the blocks in ->queuecommand (like most modern drivers
> do) you'll need some form of freelist of course.  What you shouldn't need iß
> the pendig_q as the midlayer already keeps track of pending commands.
> This of course only works if you actually do send all commands via the
> midlayer (which you should).

The reason I have a pending_q is so that when I reset the adapter 
without the mid-layer knowing about it, I need to fail back any 
outstanding ops so they get retried as appropriate. I suppose a way 
around this would be a mid-layer interface that an LLD could call which 
would cause a host reset. Then the midlayer could drive the reset and 
take care of doing the right thing with any outstanding ops.


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html