linux-kernel - Re: [PATCH v1] dt-bindings: opp: Allow multi-worded node names

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]

Date:   Sat, 23 Oct 2021 16:46:01 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Viresh Kumar <viresh.kumar@...aro.org>,
        Rob Herring <robh@...nel.org>
Cc:     Viresh Kumar <vireshk@...nel.org>, Stephen Boyd <sboyd@...nel.org>,
        Nishanth Menon <nm@...com>, David Heidelberg <david@...t.cz>,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v1] dt-bindings: opp: Allow multi-worded node names

23.10.2021 16:00, Dmitry Osipenko пишет:
> 22.10.2021 10:45, Viresh Kumar пишет:
>> On 22-10-21, 10:39, Dmitry Osipenko wrote:
>>> What we currently have for Tegra is a tegra-opps.dtsi and tegra.dtsi
>>> which includes the OPP's dtsi.
>>>
>>> the tegra-opps.dtsi has this structure:
>>>
>>> table: devname-opp-table {
>>> 	opp: ...
>>> };
>>>
>>> and tegra.dtsi:
>>>
>>> #include "tegra-opps.dtsi"
>>>
>>> device@...0 {
>>> 	operating-points-v2 = <&table>;
>>> };
>>>
>>> It just occurred to me that there is no need to move all tables to
>>> tegra.dtsi, but change structure of tegra-opps.dtsi to:
>>>
>>> device@...0 {
>>> 	operating-points-v2 = <&table>;
>>>
>>> 	table: opp-table {
>>> 		opp: ...
>>> 	};
>>> };
>>
>> I thought you would have already thought about that and I was surprised when you
>> saw the tables are big enough to be moved. I was wondering what does it really
>> mean :)
>>
>>> Then there no need to change current naming scheme. Let me try to
>>> implement it and see how it goes.
>>
>> That's good then.
>>
> 
> I implemented that approach and it works, but there are two problems:
> 
> 1. I had to factor out OPP tables from SPI device-tree nodes because DTC doesn't allow to have them within SPI nodes [1] and dtb fails to compile.
> 
> [1] https://elixir.bootlin.com/linux/v5.15-rc6/source/scripts/dtc/checks.c#L1141
> 
> 2. dtbs_check now warns about every opp-table sub-node, like this:
> 
> /home/runner/work/linux/linux/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-E1565.dt.yaml: memory-controller@...0f400: 'opp-table' does not match any of the regexes: '^emc-timings-[0-9]+$', 'pinctrl-[0-9]+'
> 	From schema: /home/runner/work/linux/linux/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
> 

Thinking more about this, it's not a good idea to add new sub-node to
nodes which already have sub-nodes because existing driver code that
parses sub-nodes may not be ready to face the new opp-table sub-node.

I'll revert back to the previous variant with distinct opp-table nodes.