linux-kernel - Re: [PATCH v5 2/2] thermal: add brcmstb AVS TMON 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]

Date:   Tue, 26 Sep 2017 15:14:25 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Scott Branden <scott.branden@...adcom.com>,
        Markus Mayer <code@...yer.net>
Cc:     Zhang Rui <rui.zhang@...el.com>,
        Eduardo Valentin <edubezval@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Doug Berger <opendmb@...il.com>,
        Brian Norris <computersforpeace@...il.com>,
        Gregory Fong <gregory.0xf0@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Rafał Miłecki <rafal@...ecki.pl>,
        Broadcom Kernel List <bcm-kernel-feedback-list@...adcom.com>,
        Power Management List <linux-pm@...r.kernel.org>,
        Device Tree List <devicetree@...r.kernel.org>,
        ARM Kernel List <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Markus Mayer <mmayer@...adcom.com>
Subject: Re: [PATCH v5 2/2] thermal: add brcmstb AVS TMON driver

On 09/26/2017 03:08 PM, Scott Branden wrote:
> 
> 
> On 17-09-26 02:38 PM, Markus Mayer wrote:
>> On 26 September 2017 at 14:32, Scott Branden
>> <scott.branden@...adcom.com> wrote:
>>> Hi Markus,
>>>
>>>
>>> On 17-09-26 02:27 PM, Markus Mayer wrote:
>>>> From: Brian Norris <computersforpeace@...il.com>
>>>>
>>>> The AVS TMON core provides temperature readings, a pair of configurable
>>>> high- and low-temperature threshold interrupts, and an emergency
>>>> over-temperature chip reset. The driver utilizes the first two to
>>>> provide temperature readings and high-temperature notifications to
>>>> applications. The over-temperature reset is not exposed to
>>>> applications; this reset threshold is critical to the system and should
>>>> be set with care within the bootloader.
>>>>
>>>> Applications may choose to utilize the notification mechanism, the
>>>> temperature reading mechanism (e.g., through polling), or both.
>>>>
>>>> Signed-off-by: Brian Norris <computersforpeace@...il.com>
>>>> Signed-off-by: Doug Berger <opendmb@...il.com>
>>>> Signed-off-by: Markus Mayer <mmayer@...adcom.com>
>>>> ---
>>>>    drivers/thermal/Kconfig                    |   2 +-
>>>>    drivers/thermal/broadcom/Kconfig           |   7 +
>>>>    drivers/thermal/broadcom/Makefile          |   1 +
>>>>    drivers/thermal/broadcom/brcmstb_thermal.c | 387
>>>> +++++++++++++++++++++++++++++
>>>>    4 files changed, 396 insertions(+), 1 deletion(-)
>>>>    create mode 100644 drivers/thermal/broadcom/brcmstb_thermal.c
>>>>
>>>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>>>> index 07002df..96774a7 100644
>>>> --- a/drivers/thermal/Kconfig
>>>> +++ b/drivers/thermal/Kconfig
>>>> @@ -408,7 +408,7 @@ config MTK_THERMAL
>>>>            controller present in Mediatek SoCs
>>>>      menu "Broadcom thermal drivers"
>>>> -depends on ARCH_BCM || COMPILE_TEST
>>>> +depends on ARCH_BCM || ARCH_BRCMSTB || COMPILE_TEST
>>> No need for this additional depends.  ARCH_BCM is always defined before
>>> ARCH_BRCMSTB can be selected.
>> ARCH_BCM does not exist in arch/arm64/configs/defconfig. ARCH_BRCMSTB
>> does. So, we do need both or the driver won't be built on ARM64.
>> (After internal discussions we went with that approach rather than
>> defining ARCH_BCM on ARM64.)
> Got it.  Looking at our internal iproc tree I see we've done exactly the
> same with ARCH_BCM_IPROC needing to be added.  We haven't upstreamed
> the thermal driver needing it yet.
> 
> Perhaps we should add ARCH_BCM to ARM64....

If it is just added to satisfy dependencies, I don't see much value in
doing that. It does make sense in the ARM v7 multiplatform context, but
outside of that, not so sur.
-- 
Florian