On Tue, 2017-05-02 at 09:25 -0600, Jens Axboe wrote:
> On 05/02/2017 09:16 AM, Christoph Hellwig wrote:
> > Any reason for the move from ->end_io_data to ->special? I thought
> > that ->special was something we'd get rid of sooner or later now
> > that we can have additional per-cmd data even for
This looks reasonable to me, although of course I don't have a way
to test it.
Any reason for the move from ->end_io_data to ->special? I thought
that ->special was something we'd get rid of sooner or later now
that we can have additional per-cmd data even for !mq.
On 05/02/2017 07:53 AM, Jens Axboe wrote:
> On 05/02/2017 01:28 AM, Christoph Hellwig wrote:
>> Looks fine for now:
>>
>> Reviewed-by: Christoph Hellwig
>>
>> But rather sooner than later we need to make this path at least go
>> through the normal end_request processing. Without
On 05/02/2017 01:28 AM, Christoph Hellwig wrote:
> Looks fine for now:
>
> Reviewed-by: Christoph Hellwig
>
> But rather sooner than later we need to make this path at least go
> through the normal end_request processing. Without that we're just
> bound to run into problems like
Looks fine for now:
Reviewed-by: Christoph Hellwig
But rather sooner than later we need to make this path at least go
through the normal end_request processing. Without that we're just
bound to run into problems like we had with the tag changes again
when the driver is using the
The driver special cases certain things for command issue, depending
on whether it's an internal command or not. Make the internal commands
use the regular infrastructure for issuing IO.
Since this is an 8-group souped up AHCI variant, we have to deal
with NCQ vs non-queueable commands. Do this