linux-kernel - Re: [TEGRA194_CPUFREQ Patch 1/3] firmware: tegra: adding function to get BPMP data

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: <20200506165831.GD2723987@ulmo>
Date:   Wed, 6 May 2020 18:58:31 +0200
From:   Thierry Reding <thierry.reding@...il.com>
To:     Rob Herring <robh+dt@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:     Mikko Perttunen <cyndis@...si.fi>, Sumit Gupta <sumitg@...dia.com>,
        catalin.marinas@....com, will@...nel.org, jonathanh@...dia.com,
        talho@...dia.com, linux-pm@...r.kernel.org,
        linux-tegra@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, bbasu@...dia.com,
        mperttunen@...dia.com, devicetree@...r.kernel.org
Subject: Re: [TEGRA194_CPUFREQ Patch 1/3] firmware: tegra: adding function to
 get BPMP data

On Mon, Apr 27, 2020 at 09:18:00AM +0200, Thierry Reding wrote:
> On Tue, Apr 07, 2020 at 12:05:20PM +0200, Thierry Reding wrote:
> > On Wed, Dec 04, 2019 at 03:21:38PM +0530, Viresh Kumar wrote:
> > > On 04-12-19, 10:33, Thierry Reding wrote:
> > > > Yeah, the code that registers this device is in drivers/base/cpu.c in
> > > > register_cpu(). It even retrieves the device tree node for the CPU from
> > > > device tree and stores it in cpu->dev.of_node, so we should be able to
> > > > just pass &cpu->dev to tegra_bpmp_get() in order to retrieve a reference
> > > > to the BPMP.
> > > > 
> > > > That said, I'm wondering if perhaps we could just add a compatible
> > > > string to the /cpus node for cases like this where we don't have an
> > > > actual device representing the CPU complex. There are a number of CPU
> > > > frequency drivers that register dummy devices just so that they have
> > > > something to bind a driver to.
> > > > 
> > > > If we allow the /cpus node to represent the CPU complex (if no other
> > > > "device" does that yet), we can add a compatible string and have the
> > > > cpufreq driver match on that.
> > > > 
> > > > Of course this would be slightly difficult to retrofit into existing
> > > > drivers because they'd need to remain backwards compatible with existing
> > > > device trees. But it would allow future drivers to do this a little more
> > > > elegantly. For some SoCs this may not matter, but especially once you
> > > > start depending on additional resources this would come in handy.
> > > > 
> > > > Adding Rob and the device tree mailing list for feedback on this idea.
> > > 
> > > Took some time to find this thread, but something around this was
> > > suggested by Rafael earlier.
> > > 
> > > https://lore.kernel.org/lkml/8139001.Q4eV8YG1Il@vostro.rjw.lan/
> > 
> > I gave this a try and came up with the following:
> > 
> > --- >8 ---
> > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > index f4ede86e32b4..e4462f95f0b3 100644
> > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > @@ -1764,6 +1764,9 @@ bpmp_thermal: thermal {
> >  	};
> >  
> >  	cpus {
> > +		compatible = "nvidia,tegra194-ccplex";
> > +		nvidia,bpmp = <&bpmp>;
> > +
> >  		#address-cells = <1>;
> >  		#size-cells = <0>;
> >  
> > --- >8 ---
> > 
> > Now I can do something rougly like this, although I have a more complete
> > patch locally that also gets rid of all the global variables because we
> > now actually have a struct platform_device that we can anchor everything
> > at:
> > 
> > --- >8 ---
> > static const struct of_device_id tegra194_cpufreq_of_match[] = {
> > 	{ .compatible = "nvidia,tegra194-ccplex", },
> > 	{ /* sentinel */ }
> > };
> > MODULE_DEVICE_TABLE(of, tegra194_cpufreq_of_match);
> > 
> > static struct platform_driver tegra194_ccplex_driver = {
> > 	.driver = {
> > 		.name = "tegra194-cpufreq",
> > 		.of_match_table = tegra194_cpufreq_of_match,
> > 	},
> > 	.probe = tegra194_cpufreq_probe,
> > 	.remove = tegra194_cpufreq_remove,
> > };
> > module_platform_driver(tegra194_ccplex_driver);
> > --- >8 ---
> > 
> > I don't think that's exactly what Rafael (Cc'ed) had in mind, since the
> > above thread seems to have mostly talked about binding a driver to each
> > individual CPU.
> > 
> > But this seems a lot better than having to instantiate a device from
> > scratch just so that a driver can bind to it and it allows additional
> > properties to be associated with the CCPLEX device.
> > 
> > Rob, any thoughts on this from a device tree point of view? The /cpus
> > bindings don't mention the compatible property, but there doesn't seem
> > to be anything in the bindings that would prohibit its use.
> > 
> > If we can agree on that, I can forward my local changes to Sumit for
> > inclusion or reference.
> 
> Rob, do you see any reason why we shouldn't be able to use a compatible
> string in the /cpus node for devices such as Tegra194 where there is no
> dedicated hardware block for the CCPLEX?

Rob, can you take a brief look and provide some feedback on this? I'd
like to get this merged for v5.8 and where to instantiate this is the
only thing holding this up at this point.

Thanks,
Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)