linux-kernel - Re: [PATCH v5 11/20] firmware: arm_scmi: add support for polling based SCMI transfers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a31CMsLUSm0rsHLdvM4sbjZ6fwocKmA1JiuCtF97vj3PQ@mail.gmail.com>
Date:   Mon, 19 Feb 2018 12:32:39 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     ALKML <linux-arm-kernel@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Roy Franz <roy.franz@...ium.com>,
        Harb Abdulhamid <harba@...eaurora.org>,
        Nishanth Menon <nm@...com>, Loc Ho <lho@....com>,
        Alexey Klimov <klimov.linux@...il.com>,
        Ryan Harkin <Ryan.Harkin@....com>,
        Jassi Brar <jassisinghbrar@...il.com>
Subject: Re: [PATCH v5 11/20] firmware: arm_scmi: add support for polling
 based SCMI transfers

On Tue, Jan 2, 2018 at 3:42 PM, Sudeep Holla <sudeep.holla@....com> wrote:

> +#define SCMI_MAX_POLLING_TIMEOUT_NS    (100 * NSEC_PER_USEC)
>  /**
>   * scmi_do_xfer() - Do one transfer
>   *
> @@ -389,14 +406,30 @@ int scmi_do_xfer(const struct scmi_handle *handle, struct scmi_xfer *xfer)

> +       if (xfer->hdr.poll_completion) {
> +               ktime_t stop, cur;
> +
> +               stop = ktime_add_ns(ktime_get(), SCMI_MAX_POLLING_TIMEOUT_NS);
> +               do {
> +                       udelay(5);
> +                       cur = ktime_get();
> +               } while (!scmi_xfer_poll_done(info, xfer) &&
> +                        ktime_before(cur, stop));

The 5 microsecond back-off isn't that much smaller than the 100 microsecond
timeout, given that udelay() often waits much longer than the specified time.

How did you come up with those two numbers? Are you sure this is better
than just using a cpu_relax() instead of the udelay()?

      Arnd