linux-kernel - Re: [PATCH v3 21/22] cpufreq: add support for CPU DVFS based on SCMI message protocol

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: <d7aa31d7-f68a-b81a-05fe-75d42cf88ed0@arm.com>
Date:   Thu, 5 Oct 2017 12:26:14 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        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 <alexey.klimov@....com>,
        Ryan Harkin <Ryan.Harkin@....com>,
        Jassi Brar <jassisinghbrar@...il.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        linux-pm@...r.kernel.org
Subject: Re: [PATCH v3 21/22] cpufreq: add support for CPU DVFS based on SCMI
 message protocol



On 05/10/17 12:20, Arnd Bergmann wrote:
> On Wed, Oct 4, 2017 at 5:01 PM, Sudeep Holla <sudeep.holla@....com> wrote:
>>>> +
>>>> +static struct platform_driver scmi_cpufreq_platdrv = {
>>>> +       .driver = {
>>>> +               .name   = "scmi-cpufreq",
>>>> +       },
>>>> +       .probe          = scmi_cpufreq_probe,
>>>> +       .remove         = scmi_cpufreq_remove,
>>>> +};
>>>
>>> You appear to have split this driver into the 'cpufreq' side and
>>> the 'protocol' handler in a different file. I already commented that
>>> the way the main scmi driver knows about all the protocols looks
>>> bad, here we can see another aspect of the same problem.
>>>
>>> Rather than manually register a platform_device for the purpose
>>> of connecting it to the cpufreq driver, there should be a way
>>> to dynamically register the protocol from the cpufreq driver
>>> and then have both in the same file.
>>>
>>
>> I agree that should be possible. I took this approach for 2 reasons:
>>
>> 1. to avoid all sorts of probe ordering issues
>> 2. we may have system with multiple instances of SCMI. E.g. a system
>>    may have multiple remote processors, each controlling dvfs/power mgmt
>>    of a subset of CPUs/devices controller in OS.
>>
>> I have to admit that I haven't thought too much in details yet. That's
>> the main idea behind scmi_handle and restricting access to that only to
>> sub-nodes in it. I am open to suggestions.
> 
> How about introducing a separate bus_type for protocols?
> The platform_device you use here isn't really the best abstraction,
> and with a new bus_type, you can handle multiple instances of
> scmi as well as decoupling them from the protocol drivers.
> 

Yes based on some discussion on this thread yesterday, I started
exploring and seem to have come to same conclusions. I will try to hack
and see how that evolves. Thanks for the suggestion.

-- 
Regards,
Sudeep