[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c22589614fa279421b77163aeddeea99fa23be05.camel@hpe.com>
Date: Wed, 20 Feb 2019 00:06:40 +0000
From: "Kani, Toshi" <toshi.kani@....com>
To: "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"krzysztof.rusocki@...el.com" <krzysztof.rusocki@...el.com>,
"erwin.tsaur@...cle.com" <erwin.tsaur@...cle.com>,
"vishal.l.verma@...el.com" <vishal.l.verma@...el.com>
Subject: Re: [PATCH v2 0/6] nfit/ars: Improve polling and short-ARS execution
On Fri, 2019-02-15 at 11:43 -0800, Dan Williams wrote:
> Changes since v1: [1]
> * Fix the root poll interval support to avoid a infinite loop condition
> when the polling is faster than the ARS completion.
> * Move the introduction of scrub_flags earlier in the series and
> introduce ARS_POLL to fix the above issue.
>
> [1]: https://lists.01.org/pipermail/linux-nvdimm/2019-February/019964.html
>
> ---
>
> Here is a small pile of updates to better coordinate the Linux ARS state
> machine with platform-BIOS implementations. Specifically, take advantage
> of opportunities to run short-ARS whenever the ARS interface is found to
> be idle at init, always run short-ARS even if no_init_ars is specified,
> allow root to reset the exponential backoff polling interval for ARS
> completion, and protect the kernel against the consumption of stale ARS
> results.
>
> ---
>
> Dan Williams (6):
> nfit/ars: Attempt a short-ARS whenever the ARS state is idle at boot
> nfit/ars: Attempt short-ARS even in the no_init_ars case
> nfit/ars: Remove ars_start_flags
> nfit/ars: Introduce scrub_flags
> nfit/ars: Allow root to busy-poll the ARS state machine
> nfit/ars: Avoid stale ARS results
>
>
> drivers/acpi/nfit/core.c | 70 ++++++++++++++++++++++++++++++++--------------
> drivers/acpi/nfit/nfit.h | 11 +++++--
> 2 files changed, 57 insertions(+), 24 deletions(-)
The changes look good to me. For the series:
Reviewed-by: Toshi Kani <toshi.kani@....com>
Thanks,
-Toshi
Powered by blists - more mailing lists