[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f2544b8e-59fe-8cbc-5598-bd2a2b325a39@broadcom.com>
Date: Mon, 29 May 2017 09:21:51 -0700
From: Scott Branden <scott.branden@...adcom.com>
To: Jon Mason <jon.mason@...adcom.com>
Cc: Florian Fainelli <florian.fainelli@...adcom.com>,
Zhang Rui <rui.zhang@...el.com>,
Eduardo Valentin <edubezval@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
open list <linux-kernel@...r.kernel.org>,
linux-pm@...r.kernel.org,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>
Subject: Re: [PATCH v3 2/3] thermal: broadcom: ns-thermal: default on iProc
SoCs
Hi Jon,
On 17-04-28 01:50 PM, Jon Mason wrote:
> On Fri, Apr 28, 2017 at 4:36 PM, Scott Branden
> <scott.branden@...adcom.com> wrote:
>>
>> On 17-04-28 01:11 PM, Jon Mason wrote:
>>> Tweak the Kconfig description to mention support for NSP and make the
>>> default on for iProc based platforms.
>>>
>>> Signed-off-by: Jon Mason <jon.mason@...adcom.com>
>>> ---
>>> drivers/thermal/broadcom/Kconfig | 9 +++++----
>>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/thermal/broadcom/Kconfig
>>> b/drivers/thermal/broadcom/Kconfig
>>> index f0dea8a..b6f4b85 100644
>>> --- a/drivers/thermal/broadcom/Kconfig
>>> +++ b/drivers/thermal/broadcom/Kconfig
>>> @@ -1,8 +1,9 @@
>>> config BCM_NS_THERMAL
>>> tristate "Northstar thermal driver"
>>> depends on ARCH_BCM_IPROC || COMPILE_TEST
>> If this driver is used on these SoCs then it:
>> depends on ARCH_BCM_NSP || ARCH_BCM_5301X || COMPILE_TEST
>> ?
> The code referenced is outside of this patch, as that code was already
> existing from when the driver was submitted.
>
> I did some checking and NS2 and Cygnus do not have the registers in
> use by this driver. So, you are correct in that this driver will
> never be used for them. So, this is slightly over-permissive in
> allowing a driver to be selected that could not ever be used on
> non-NS/NSP hardware. But barring an incorrect DT string, it would
> only result in an slightly larger kernel than necessary.
>
> I'll do a follow-on patch to correct this with your suggestion above,
> and push it separately (unless a v4 is needed on this series).
Please submit the follow on patch.
>
> Thanks,
> Jon
Thanks,
Scott
Powered by blists - more mailing lists