linux-kernel - Re: [PATCH v2] platform/chrome: cros_ec: Send host event for prepare/complete

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>] [day] [month] [year] [list]

Date:   Thu, 14 Jul 2022 02:22:54 +0000
From:   Tzung-Bi Shih <tzungbi@...nel.org>
To:     Tim Van Patten <timvp@...gle.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, rrangel@...omium.org,
        robbarnes@...gle.com, Benson Leung <bleung@...omium.org>,
        Guenter Roeck <groeck@...omium.org>,
        chrome-platform@...ts.linux.dev
Subject: Re: [PATCH v2] platform/chrome: cros_ec: Send host event for
 prepare/complete

On Wed, Jul 13, 2022 at 12:05:14PM -0600, Tim Van Patten wrote:
> This patch changes *when* the EC outputs the host command that indicates
> the AP is starting suspend and finishing resume, due to the change (in this
> patch) when the AP sends that host command.   This makes the EC's logs more
> accurate when correlating them with the AP's logs in regards to when
> suspend is started and resume is completed.   Previously, those events were
> sent when suspend/resume were already in progress.

I see.

> We'd also like to keep the new logs emitted by the AP to make it clearer
> when the AP is starting suspend and completing resume, so we can correlate
> it with the EC logs more easily.   This should aid debugging and timing
> analysis.   Since it only occurs during suspend/resume, it shouldn't flood
> the logs and follows the logging of other driver PM functions.
> 
> I didn't see concerns in [1] have been addressed.
> 
> 
> I replied to the first email stating why we want to keep the log message
> (and reiterated it above).   What's the correct process to indicate we
> don't want to make the change requested in [1]?

I didn't see the message in the v1 thread[2].  What did you mean by
"first email"?  Checked my mbox but got nothing.

Also, I found the message didn't show in [3].  I'm not sure what happened
but perhaps you should use plain text next time (see [4])?

[2]: https://patchwork.kernel.org/project/chrome-platform/patch/20220701095421.1.I78ded92e416b55de31975686d34b2058d4761c07@changeid/
[3]: https://patchwork.kernel.org/project/chrome-platform/patch/20220706205136.v2.1.Ic7a7c81f880ab31533652e0928aa6e687bb268b5@changeid/
[4]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#no-mime-no-links-no-compression-no-attachments-just-plain-text