[PATCH v2 2/2] nvme: Enable autonomous power state transitions
Andy Lutomirski
luto at amacapital.net
Fri Jan 20 10:07:42 PST 2017
On Fri, Jan 20, 2017 at 2:30 AM, Christoph Hellwig <hch at lst.de> wrote:
>
>> +static void nvme_set_latency_tolerance(struct device *dev, s32 val)
>> +{
>> + struct nvme_ctrl *ctrl = dev_get_drvdata(dev);
>> +
>> + u64 latency;
>> +
>> + if (val == PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT ||
>> + val == PM_QOS_LATENCY_ANY)
>> + latency = U64_MAX;
>> + else
>> + latency = val;
>
> In addition to the latency vs val mixup pointed out earlier -
> can you use a switch statement here to make the code a little
> more obvious?
Sure.
>
>> + if (ctrl->ps_max_latency_us != val) {
>> + ctrl->ps_max_latency_us = val;
>> + nvme_configure_apst(ctrl);
>> + }
>> +}
>> +
>
>> ctrl->identified = true;
>
> The ->identified field seems to never be checked anywhere.
>
See the previous patch:
+ if (!ctrl->identified) {
>
>> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
>> index 7103bce4ba4f..1c3e170da6de 100644
>> --- a/drivers/nvme/host/pci.c
>> +++ b/drivers/nvme/host/pci.c
>> @@ -1791,6 +1791,8 @@ static void nvme_reset_work(struct work_struct *work)
>> if (result)
>> goto out;
>>
>> + nvme_configure_apst(&dev->ctrl);
>> +
>> /*
>> * A controller that can not execute IO typically requires user
>> * intervention to correct. For such degraded controllers, the driver
>> diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
>> index 557f29b1f1bb..a64b5db96fd8 100644
>> --- a/drivers/nvme/host/rdma.c
>> +++ b/drivers/nvme/host/rdma.c
>> @@ -1629,6 +1629,8 @@ static int nvme_rdma_configure_admin_queue(struct nvme_rdma_ctrl *ctrl)
>>
>> nvme_start_keep_alive(&ctrl->ctrl);
>>
>> + nvme_configure_apst(&ctrl->ctrl);
>> +
>
> Is there a specific reason for the exact placement of these calls here
> and not at inside nvme_init_identify? Having all the code called
> from an existing core function would make things a lot easier in the
> future. And if that's not possible we'll probably need comments
> on why it's placed like it is.
In the original version I had this in nvme_init_identify(). I moved
it later just in case there was a buggy device that didn't like having
APST flipped on before the queue setup was done. I could easily move
it back to nvme_init_identify() or add a new nvme_finish_setup() or
similar. Any preference?
--Andy
More information about the Linux-nvme
mailing list