linux-kernel - Re: [PATCH v1] clk: Add enable-state column to clk summary

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

Message-ID: <519526ca-fd50-f8c5-6ea9-dba6d356f0e9@gmail.com>
Date:   Fri, 13 Nov 2020 12:04:29 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Stephen Boyd <sboyd@...nel.org>,
        Michael Turquette <mturquette@...libre.com>
Cc:     linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] clk: Add enable-state column to clk summary

13.11.2020 11:18, Stephen Boyd пишет:
> Quoting Dmitry Osipenko (2020-11-04 08:56:31)
>> Add "enable state" column to the clk summary. It's handy to know actual
>> hardware state of all clocks for debugging purposes. In conjunction with
>> clk_ignore_unused, this tells us what unused clocks are left on after
>> bootloader without disabling the clocks.
> 
> Should it be called "boot state" then? That idea sounds OK to me.
> 
>> It's also s useful debugging
> 
> Stray 's' here.
> 
>> information for cases where firmware touches clocks.
> 
> Care to explain more? Presumably you mean when firmware is modifying clk
> state without notifying the kernel?

This is exactly what I meant.

> In which case it should be called
> "hardware enable" or something like that and be a "Y/N/?" value
> depending on if the value can be read or not and if it is enabled or not?

Indeed, I like the "hardware enable", thank you for the suggestion. The
"Y/N/?" suggestion is also good.

I'll prepare v2, thank you for the review!