[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a89bd80c-bdfc-77ed-1de9-9cad38da7cf5@codeaurora.org>
Date: Mon, 20 Aug 2018 18:15:12 +0530
From: Sricharan R <sricharan@...eaurora.org>
To: Rob Herring <robh@...nel.org>
Cc: mark.rutland@....com, sudeep.holla@....com, linux@....linux.org.uk,
ctatlor97@...il.com, rjw@...ysocki.net, viresh.kumar@...aro.org,
mturquette@...libre.com, linux-pm@...r.kernel.org,
sboyd@...eaurora.org, linux@...linux.org.uk,
thierry.escande@...aro.org, linux-kernel@...r.kernel.org,
david.brown@...aro.org, devicetree@...r.kernel.org,
linux-arm-msm@...r.kernel.org, andy.gross@...aro.org,
linux-soc@...r.kernel.org, linux-clk@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, niklas.cassel@...aro.org
Subject: Re: [PATCH v12 13/14] cpufreq: qcom: Re-organise kryo cpufreq to use
it for other nvmem based qcom socs
Hi Rob,
On 8/17/2018 8:39 PM, Rob Herring wrote:
> Hi, this email is from Rob's (experimental) review bot. I found a couple
> of common problems with your patch. Please see below.
>
> On Tue, 14 Aug 2018 17:42:32 +0530, Sricharan R wrote:
>> The kryo cpufreq driver reads the nvmem cell and uses that data to
>> populate the opps. There are other qcom cpufreq socs like krait which
>> does similar thing. Except for the interpretation of the read data,
>> rest of the driver is same for both the cases. So pull the common things
>> out for reuse.
>>
>> Signed-off-by: Sricharan R <sricharan@...eaurora.org>
>
> The preferred subject prefix is "dt-bindings: <binding dir>: ...".
>
ok, will change and keep the bindings update part out for this and the next
patch.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Powered by blists - more mailing lists