linux-kernel - Re: [PATCH] cpufreq: rockchip: add driver

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: <1677635.LBekym086Y@diego>
Date:	Mon, 21 Mar 2016 16:52:23 +0100
From:	Heiko Stübner <heiko@...ech.de>
To:	Feng Xiao <xf@...k-chips.com>
Cc:	Viresh Kumar <viresh.kumar@...aro.org>, linux@....linux.org.uk,
	rjw@...ysocki.net, linux-arm-kernel@...ts.infradead.org,
	linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org, wxt@...k-chips.com, zyw@...k-chips.com,
	jay.xu@...k-chips.com, tim.chen@...k-chips.com, xxx@...k-chips.com,
	huangtao@...k-chips.com, Stephen Boyd <sboyd@...eaurora.org>,
	Michael Turquette <mturquette@...libre.com>
Subject: Re: [PATCH] cpufreq: rockchip: add driver

Am Montag, 21. März 2016, 16:13:40 schrieb Heiko Stübner:
> Hi,
> 
> Am Montag, 21. März 2016, 21:24:32 schrieb Feng Xiao:
> > 在 2016/3/21 17:58, Viresh Kumar 写道:
> > > On 21-03-16, 10:54, Heiko Stübner wrote:
> > >> I hadn't seen that yet ... nice that cpufreq-dt now also supports
> > >> clusters :-)
> > >> 
> > >> The other part still stands though, as we probably should register the
> > >> platform-device somewhere else and not in some new special module.
> > >> 
> > >> When everything is using cpufreq-dt now, I guess we could just add it
> > >> to
> > >> the core rockchip clk-code. Or was there some agreement where this
> > >> should be done (obviously not the devicetree itself)?
> > 
> > Of_clk_init is called early, and platform_device_register_simple should
> > be called after devices_init, it will be failed to do it from clk-code.
> > So we need add a new file or add module_init to each clock controller
> > driver(like clk-rk3368.c, clk-rk3399.c) ?
> 
> as Viresh said, it should be ok to do it like your approach creating a
> module in drivers/cpufreq. But the compatible check is necessary.
> 
> Doing it this way also makes it easier to have

Seem like I forgot the complete my sentence here. This should've been

Doing it this way also makes it easier to have everything go into cpufreq-dt 
once that whitelist appears that Viresh wrote about. So this might be better 
than to distribute this stuff around other subsystems, as I originally 
suggested.

> 
> > > Yeah, there was a discussion around creating a white or black list of
> > > platforms that want to create a platform device for cpufreq-dt. That can
> > > be done in cpufreq-dt.c or a new file, but I haven't worked out on that
> > > yet.
> > > 
> > > You can do it from clk-code or from the driver that was added in this
> > > thread. Just that you need to match your platform's compatible string
> > > before doing that.
> > 
> > Rockchip-cpufreq.c depends on ARM_ROCKCHIP_CPUFREQ, it will not be
> > compiled on non-Rockchip platforms.
> > The driver can support all Rockchip SoCs up to now, add
> > of_machine_is_compatible may be redundant ?
> 
> Please always keep multiplatform in mind. These days the kernel can be
> compiled for multiple architectures at the same time, so you can have
> support for Rockchip, Exynos, Qualcom and whatever in the same kernel
> image.
> 
> Therefore a compile-time check is not enough and you need to check the
> actually running machine as well.
> 
> 
> Heiko