Re: [PATCH 1/2] memory: brcmstb_dpfe: Simplify with dev_err_probe()

On Fri, 28 Aug 2020 at 08:37, Krzysztof Kozlowski wrote: > > Common pattern of handling deferred probe can be simplified with > dev_err_probe(). Less code and the error value gets printed. > > Signed-off-by: Krzysztof Kozlowski Acked-by: Markus Mayer > --- > drivers/

[PATCH v3] memory: brcmstb_dpfe: fix array index out of bounds

y directly. The function includes a bounds check that prevents the array from being overrun. This patch was prepared in response to https://lkml.org/lkml/2020/8/18/505. Signed-off-by: Markus Mayer Acked-by: Florian Fainelli Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE"

Re: [PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds

On Sat, 22 Aug 2020 at 13:46, Krzysztof Kozlowski wrote: > > On Sat, Aug 22, 2020 at 01:21:47PM -0700, Florian Fainelli wrote: > > > > > > On 8/22/2020 1:14 PM, Markus Mayer wrote: > > > On Sat, 22 Aug 2020 at 09:46, Krzysztof Kozlowski wrote: > > > &g

Re: [PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds

On Sat, 22 Aug 2020 at 13:21, Florian Fainelli wrote: > > On 8/22/2020 1:14 PM, Markus Mayer wrote: > > On Sat, 22 Aug 2020 at 09:46, Krzysztof Kozlowski wrote: > >> > >> On Sat, Aug 22, 2020 at 09:40:59AM -0700, Markus Mayer wrote: > >>> On Sat, 22 Aug

Re: [PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds

On Sat, 22 Aug 2020 at 09:46, Krzysztof Kozlowski wrote: > > On Sat, Aug 22, 2020 at 09:40:59AM -0700, Markus Mayer wrote: > > On Sat, 22 Aug 2020 at 04:56, Krzysztof Kozlowski wrote: > > > > > > On Fri, Aug 21, 2020 at 09:52:21AM -0700, Markus Mayer w

Re: [PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds

On Sat, 22 Aug 2020 at 04:56, Krzysztof Kozlowski wrote: > > On Fri, Aug 21, 2020 at 09:52:21AM -0700, Markus Mayer wrote: > > We would overrun the error_text array if we hit a TIMEOUT condition, > > because we were using the error code "ETIMEDOUT" (which is 110) as an

[PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds

y directly. The function includes a bounds check that prevents the array from being overrun. This patch was prepared in response to https://lkml.org/lkml/2020/8/18/505. Signed-off-by: Markus Mayer Acked-by: Florian Fainelli --- Changes since v1: - Added link of the coverity report to

Re: [PATCH] memory: brcmstb_dpfe: fix array index out of bounds

On Thu, 20 Aug 2020 at 22:40, Krzysztof Kozlowski wrote: > > On Thu, Aug 20, 2020 at 06:03:33PM -0700, Markus Mayer wrote: > > We would overrun the error_text array if we hit a TIMEOUT condition, > > because we were using the error code "ETIMEDOUT" (which is 110) as an

Re: out of bounds access on array error_text[] because of -ETIMEDOUT return from __send_command()

On Thu, 20 Aug 2020 at 10:23, Markus Mayer wrote: > > On Wed, 19 Aug 2020 at 11:34, Florian Fainelli wrote: > > > > On 8/18/20 5:21 AM, Colin Ian King wrote: > > > Hi, > > > > > > static analysis with coverity has found a buffer overflow issue with th

[PATCH] memory: brcmstb_dpfe: fix array index out of bounds

y directly. The function includes a bounds check that prevents the array from being overrun. Signed-off-by: Markus Mayer --- This patch was prepared in response to https://lkml.org/lkml/2020/8/18/505. drivers/memory/brcmstb_dpfe.c | 23 --- 1 file changed, 16 insertions(+), 7

Re: [PATCH v2] memory: brcmstb_dpfe: Fix memory leak

On Thu, 20 Aug 2020 at 10:21, Alex Dewar wrote: > > In brcmstb_dpfe_download_firmware(), memory is allocated to variable fw by > firmware_request_nowarn(), but never released. Fix up to release fw on > all return paths. Thanks for the fix! Acked-by: Markus Mayer > Signed-off

Re: out of bounds access on array error_text[] because of -ETIMEDOUT return from __send_command()

ing > > commit: > > > > commit a7c25759d8d84b64c437a78f05df7314b02934e5 > > Author: Markus Mayer > > Date: Tue Apr 2 16:01:00 2019 -0700 > > > > memory: brcmstb: dpfe: wait for DCPU to be ready > > > > The static analysis is as follows

Build error caused by "arm64: dts: agilex: add nand clocks"

Hi, I don't know if anybody else is seeing this, but for me the commit "arm64: dts: agilex: add nand clocks"[1] is causing a build error while generating DTS files for ARM64. The error goes away when I drop the commit. $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make defconfig dtbs HOSTCC

Re: [PATCH 16/23] memory: brcmstb_dpfe: Constify the contents of string

On Thu, 23 Jul 2020 at 10:11, Florian Fainelli wrote: > > On 7/23/20 12:37 AM, Krzysztof Kozlowski wrote: > > The string itself can be made const for safety. > > > > Signed-off-by: Krzysztof Kozlowski > > Acked-by: Florian Fainelli Acked-by: Markus Mayer

Re: [PATCH 17/23] memory: brcmstb_dpfe: Remove unneeded braces

; > > Signed-off-by: Krzysztof Kozlowski > > Acked-by: Florian Fainelli Acked-by: Markus Mayer

[PATCH] tools/thermal: tmon: include pthread and time headers in tmon.h

^~ make[3]: *** [: tui.o] Error 1 make[2]: *** [Makefile:83: tmon] Error 2 Signed-off-by: Markus Mayer --- The issue was discovered cross-compiling tmon for aarch64 with musl-libc. The build succeeds with glibc, because the required headers are included implicitly. This is not the case wit

[PATCH 3/3] cpufreq: brcmstb-avs-cpufreq: send S2_ENTER / S2_EXIT commands to AVS

On suspend we send AVS_CMD_S2_ENTER and on resume AVS_CMD_S2_EXIT. These are best effort calls, so we don't check the return code or take any action if either of the calls fails. Signed-off-by: Markus Mayer --- drivers/cpufreq/brcmstb-avs-cpufreq.c | 12 +++- 1 file changed, 11

[PATCH 2/3] cpufreq: brcmstb-avs-cpufreq: Support polling AVS firmware

From: Florian Fainelli In case the interrupt towards the host is never raised, yet the AVS firmware responds correctly within the alloted time, allow supporting a polling mode. Signed-off-by: Florian Fainelli Signed-off-by: Markus Mayer --- drivers/cpufreq/brcmstb-avs-cpufreq.c | 47

[PATCH 1/3] cpufreq: brcmstb-avs-cpufreq: more flexible interface for __issue_avs_command()

We are changing how parameters are passed to __issue_avs_command(), so we can pass input *and* output arguments with the same command, rather than just one or the other. Signed-off-by: Markus Mayer --- drivers/cpufreq/brcmstb-avs-cpufreq.c | 30 +-- 1 file changed, 14

[PATCH 0/3] brcmstb-avs-cpufreq updates

-cpufreq: Support polling AVS firmware Markus Mayer (2): cpufreq: brcmstb-avs-cpufreq: more flexible interface for __issue_avs_command() cpufreq: brcmstb-avs-cpufreq: send S2_ENTER / S2_EXIT commands to AVS drivers/cpufreq/brcmstb-avs-cpufreq.c | 89 ++- 1 file

[PATCH 4/8] memory: brcmstb: dpfe: move init_data into brcmstb_dpfe_download_firmware()

Rather than declaring our init_data in several places and passing it as parameter into brcmstb_dpfe_download_firmware(), we declare it inside brcmstb_dpfe_download_firmware() instead. Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 21 + 1 file changed, 9

[PATCH 5/8] memory: brcmstb: dpfe: pass *priv as argument to brcmstb_dpfe_download_firmware()

Rather than passing a (struct platform_device *) to brcmstb_dpfe_download_firmware(), we pass a (struct private_data *). This is the more sensible thing to do. Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff

[PATCH 7/8] memory: brcmstb: dpfe: Compute checksum at __send_command() time

necessary and is removed. Signed-off-by: Florian Fainelli Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c index cf320302d2c0

[PATCH 8/8] memory: brcmstb: dpfe: Fixup API version/commands for 7211

-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 44 --- 1 file changed, 36 insertions(+), 8 deletions(-) diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c index 7c6e85ad25a7..82b415be18d1 100644 --- a/drivers/memory/brcmstb_dpfe.c +++ b/drivers

[PATCH 6/8] memory: brcmstb: dpfe: support for deferred firmware download

We add support for deferred downloading of the DPFE firmware. It may be necessary to do this if the root file system containing the firmware image is not yet available at the time the driver's probe function is being called. Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 12

[PATCH 3/8] memory: brcmstb: dpfe: add locking around DCPU enable/disable

To ensure consistency, we add locking primitives inside the DCPU enable and disable routines. Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 31 +-- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/drivers/memory/brcmstb_dpfe.c b

[PATCH 1/8] memory: brcmstb: dpfe: rename struct private_data

To avoid potential (future) conflicts with other data structures we rename "struct private_data" to "struct brcmstb_dpfe_priv". Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 28 ++-- 1 file changed, 14 insertions(+), 14 dele

[PATCH 2/8] memory: brcmstb: dpfe: initialize priv->dev

Add missing initialization of priv->dev. It is only used in an emergency error message that is very unlikely to ever occur, which is how this has remained unnoticed. Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/driv

[PATCH 0/8] memory: brcmstb: dpfe: introduce DPFE API v2.5

v2 (now called "old v2") and v3 Florian Fainelli (2): memory: brcmstb: dpfe: Compute checksum at __send_command() time memory: brcmstb: dpfe: Fixup API version/commands for 7211 Markus Mayer (6): memory: brcmstb: dpfe: rename struct private_data memory: brcmstb: dpfe: initializ

Re: [PATCH 0/2] cpufreq: brcmstb-avs-cpufreq: Couple fixes

for the brcmstb-avs-cpufreq > >> driver. > >> > >> Florian Fainelli (2): > >> cpufreq: brcmstb-avs-cpufreq: Fix initial command check > >> cpufreq: brcmstb-avs-cpufreq: Fix types for voltage/frequency To both of these Acked-by: Markus M

[PATCH 4/6] memory: brcmstb: dpfe: prepare support for multiple API versions

From: Markus Mayer Extend the driver, so it can handle different API versions for interacting with the DCPU. This is in preparation for the upcoming API v3. Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 87 --- 1 file changed, 59 insertions

[PATCH 5/6] memory: brcmstb: dpfe: prepare for API-dependent sysfs attributes

From: Markus Mayer Prepare the driver so that sysfs attributes can differ based on the API version. Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 47 +-- 1 file changed, 34 insertions(+), 13 deletions(-) diff --git a/drivers/memory

[PATCH 1/6] memory: brcmstb: dpfe: remove unused code and fix formatting

From: Markus Mayer Remove an unused struct and fix source code formatting in a few areas. Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 13 ++--- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory

[PATCH 0/6] memory: brcmstb: dpfe: introduce DPFE API v3

From: Markus Mayer This series introduces a new API for communicating with the DCPU. It will be used as the default going forward. Before adding the new API, there is also some code cleanup and hardening. This series is based on drivers/next of https://github.com/Broadcom/stblinux.git, since

[PATCH 6/6] memory: brcmstb: dpfe: introduce DPFE API v3

From: Markus Mayer Introduce code to handle DPFE API v3. We also change the driver to default to v3 by default and use API v2 only for select chips. Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 114 +++--- 1 file changed, 105 insertions(+), 9

[PATCH 3/6] memory: brcmstb: dpfe: wait for DCPU to be ready

From: Markus Mayer We wait for the DCPU to be ready before sending a command. Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c index c67774a4fe8b

[PATCH 2/6] memory: brcmstb: dpfe: report firmware loading error

From: Markus Mayer Print an error message if the DCPU firmware couldn't be downloaded. Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c index

[PATCH 1/3] soc: brcmstb: dpfe: use msleep() over udelay()

From: Markus Mayer To be more "scheduler friendly", we use msleep() rather than udelay() while we wait for the DCPU to respond. Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/memory/brcmst

[PATCH 0/3] Some minor updates and fixes for the BRCMSTB DPFE driver

From: Markus Mayer This series contains three unrelated improvements or fixes for the BRCMSTB DPFE driver: * use msleep() over udelay() to be more scheduler friendly * optimize generic_show() * work around a firmware issue by reading byte 3 instead of byte 0 Markus Mayer (3): soc: brcmstb

[PATCH 3/3] soc: brcmstb: dpfe: use byte 3 of registers MR4-MR8

From: Markus Mayer For dual-rank LPDDR4, result data for any command is placed in byte 0 and byte 3 of the corresponding MR register by the firmware. Single-rank RAM was supposed to work the same way. However, due to a firmware bug, result values are only placed in byte 3 of the corresponding MR

[PATCH 2/3] soc: brcmstb: dpfe: optimize generic_show()

From: Markus Mayer We can pass a (struct priv_data *) to generic_show() rather than a (struct device *). For two of the three callers of this function, the change means one less call to dev_get_drvdata(). For the third caller, it makes no difference. Signed-off-by: Markus Mayer --- drivers

[PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order

From: Markus Mayer <mma...@broadcom.com> Most CPUfreq drivers (at least on ARM) seem to be sorting the available frequencies from lowest to highest. To match this behaviour, we reverse the sorting order in brcmstb-avs-cpufreq, so it is now also lowest to highest. Signed-off-by: Markus Maye

[PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order

From: Markus Mayer Most CPUfreq drivers (at least on ARM) seem to be sorting the available frequencies from lowest to highest. To match this behaviour, we reverse the sorting order in brcmstb-avs-cpufreq, so it is now also lowest to highest. Signed-off-by: Markus Mayer --- drivers/cpufreq

Re: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported

On 18 April 2018 at 09:37, Florian Fainelli <f.faine...@gmail.com> wrote: > On 04/18/2018 08:56 AM, Markus Mayer wrote: >> From: Jim Quinlan <jim2101...@gmail.com> >> >> If the SCMI cpufreq driver is supported, we bail, so that the new >> approach can be

Re: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported

On 18 April 2018 at 09:37, Florian Fainelli wrote: > On 04/18/2018 08:56 AM, Markus Mayer wrote: >> From: Jim Quinlan >> >> If the SCMI cpufreq driver is supported, we bail, so that the new >> approach can be used. >> >> Signed-off-by: Jim

[PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported

From: Jim Quinlan <jim2101...@gmail.com> If the SCMI cpufreq driver is supported, we bail, so that the new approach can be used. Signed-off-by: Jim Quinlan <jim2101...@gmail.com> Signed-off-by: Markus Mayer <mma...@broadcom.com> --- drivers/cpufreq/brcmstb-avs-cpufreq.c | 16 +

[PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported

From: Jim Quinlan If the SCMI cpufreq driver is supported, we bail, so that the new approach can be used. Signed-off-by: Jim Quinlan Signed-off-by: Markus Mayer --- drivers/cpufreq/brcmstb-avs-cpufreq.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/cpufreq

[PATCH 1/2] cpufreq: brcmstb-avs-cpufreq: remove development debug support

From: Markus Mayer <mma...@broadcom.com> This debug code was helpful while developing the driver, but it isn't being used for anything anymore. Signed-off-by: Markus Mayer <mma...@broadcom.com> --- drivers/cpufreq/Kconfig.arm | 10 -- drivers/cpufreq/brcmstb-avs-cpu

[PATCH 0/2] brcmstb-avs-cpufreq changes

From: Markus Mayer <mma...@broadcom.com> These changes are based on v4.17-rc1. The two patches are unrelated. Patch 1/2 removes unused code that was only useful during driver development and that has been disabled by default for a long time. Patch 2/2 allows the driver to detect if the

[PATCH 1/2] cpufreq: brcmstb-avs-cpufreq: remove development debug support

From: Markus Mayer This debug code was helpful while developing the driver, but it isn't being used for anything anymore. Signed-off-by: Markus Mayer --- drivers/cpufreq/Kconfig.arm | 10 -- drivers/cpufreq/brcmstb-avs-cpufreq.c | 323 +- 2 files

[PATCH 0/2] brcmstb-avs-cpufreq changes

From: Markus Mayer These changes are based on v4.17-rc1. The two patches are unrelated. Patch 1/2 removes unused code that was only useful during driver development and that has been disabled by default for a long time. Patch 2/2 allows the driver to detect if the system supports SCMI cpufreq

Re: [PATCH] memory: brcmstb: dpfe: Remove need for dpfe_dev

re > guaranteed to have an unique path in the sysfs hiearchy. > > Signed-off-by: Florian Fainelli <f.faine...@gmail.com> Looks good. Thanks. Acked-by: Markus Mayer <mma...@broadcom.com> > --- > drivers/memory/brcmstb_dpfe.c | 42 ++--

Re: [PATCH] memory: brcmstb: dpfe: Remove need for dpfe_dev

unique path in the sysfs hiearchy. > > Signed-off-by: Florian Fainelli Looks good. Thanks. Acked-by: Markus Mayer > --- > drivers/memory/brcmstb_dpfe.c | 42 ++ > 1 file changed, 10 insertions(+), 32 deletions(-) > > diff --git

[PATCH 3/3] memory: brcmstb: dpfe: support new way of passing data from the DCPU

. Signed-off-by: Markus Mayer <mma...@broadcom.com> --- drivers/memory/brcmstb_dpfe.c | 65 --- 1 file changed, 55 insertions(+), 10 deletions(-) diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c index 2013a91217a9..e9c148

[PATCH 3/3] memory: brcmstb: dpfe: support new way of passing data from the DCPU

. Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 65 --- 1 file changed, 55 insertions(+), 10 deletions(-) diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c index 2013a91217a9..e9c1485c32b9 100644 --- a/drivers

[PATCH 2/3] memory: brcmstb: dpfe: fix type declaration of variable "ret"

In some functions, variable "ret" should be ssize_t, so we fix it. Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE") Signed-off-by: Markus Mayer <mma...@broadcom.com> --- drivers/memory/brcmstb_dpfe.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletion

[PATCH 2/3] memory: brcmstb: dpfe: fix type declaration of variable "ret"

In some functions, variable "ret" should be ssize_t, so we fix it. Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE") Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mem

[PATCH 0/3] Update for the Broadcom STB DPFE driver

which method to use upon receiving a reply. The series also contains two fixes to the driver that have no direct relation with the new communication feature. Markus Mayer (3): memory: brcmstb: dpfe: properly mask vendor error bits memory: brcmstb: dpfe: fix type declaration of variable &quo

[PATCH 0/3] Update for the Broadcom STB DPFE driver

which method to use upon receiving a reply. The series also contains two fixes to the driver that have no direct relation with the new communication feature. Markus Mayer (3): memory: brcmstb: dpfe: properly mask vendor error bits memory: brcmstb: dpfe: fix type declaration of variable &quo

[PATCH 1/3] memory: brcmstb: dpfe: properly mask vendor error bits

We were printing the entire 32 bit register rather than just the lower 8 bits. Anything above bit 7 is reserved and may be any random value. Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE") Signed-off-by: Markus Mayer <mma...@broadcom.com> --- drivers/memory/brcmstb_d

[PATCH 1/3] memory: brcmstb: dpfe: properly mask vendor error bits

We were printing the entire 32 bit register rather than just the lower 8 bits. Anything above bit 7 is reserved and may be any random value. Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE") Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 3 ++- 1 file

Re: 4.14.0-rc7: cpufreq interface in sysfs removed ?

On 1 November 2017 at 10:06, Jörg Otte wrote: > In 4.14.0-rc7-9-g287683d cpufreq directory under > /sys/devices/system/cpu/cpufreq > is empty. Also link /sys/devices/system/cpu/cpu0/cpufreq is missing. It is looking fine on my system. # dmesg | grep cpufreq <6>[

Re: 4.14.0-rc7: cpufreq interface in sysfs removed ?

On 1 November 2017 at 10:06, Jörg Otte wrote: > In 4.14.0-rc7-9-g287683d cpufreq directory under > /sys/devices/system/cpu/cpufreq > is empty. Also link /sys/devices/system/cpu/cpu0/cpufreq is missing. It is looking fine on my system. # dmesg | grep cpufreq <6>[1.313374]

Re: [PATCH 0/3] tools/thermal: tmon: Makefile improvements

On 27 September 2017 at 16:02, Markus Mayer <c...@mmayer.net> wrote: > From: Markus Mayer <mma...@broadcom.com> > > This series introduces a number of improvements to tmon's Makefile. The > changes are meant to make it easier to cross-compile tmon on a greater > number

Re: [PATCH 0/3] tools/thermal: tmon: Makefile improvements

On 27 September 2017 at 16:02, Markus Mayer wrote: > From: Markus Mayer > > This series introduces a number of improvements to tmon's Makefile. The > changes are meant to make it easier to cross-compile tmon on a greater > number of platforms by giving more control to the pe

[PATCH 2/2] memory: brcmstb: dpfe: skip downloading firmware when possible

From: Markus Mayer <mma...@broadcom.com> We want to skip downloading the DPFE firmware from Linux if it was already downloaded by the boot loader. The driver now checks if the DCPU is already running and, if so, whether it can process commands. If the DCPU processes commands succes

[PATCH 2/2] memory: brcmstb: dpfe: skip downloading firmware when possible

From: Markus Mayer We want to skip downloading the DPFE firmware from Linux if it was already downloaded by the boot loader. The driver now checks if the DCPU is already running and, if so, whether it can process commands. If the DCPU processes commands successfully, the driver skips

[PATCH 1/2] memory: brcmstb: dpfe: introduce is_dcpu_enabled()

From: Markus Mayer <mma...@broadcom.com> In order to check whether or not the DCPU is running, we introduce a function called is_dcpu_enabled(). Signed-off-by: Markus Mayer <mma...@broadcom.com> --- drivers/memory/brcmstb_dpfe.c | 21 +++-- 1 file changed, 15 inse

[PATCH 1/2] memory: brcmstb: dpfe: introduce is_dcpu_enabled()

From: Markus Mayer In order to check whether or not the DCPU is running, we introduce a function called is_dcpu_enabled(). Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/memory

[PATCH 0/2] memory: brcmstb: dpfe: skip downloading firmware

From: Markus Mayer <mma...@broadcom.com> This series lets the DPFE driver skip the DPFE firmware download if the DCPU is already running. If it's running by the time Linux comes up, it means the boot loader already downloaded the DPFE firmware. Markus Mayer (2): memory: brcmstb

[PATCH 0/2] memory: brcmstb: dpfe: skip downloading firmware

From: Markus Mayer This series lets the DPFE driver skip the DPFE firmware download if the DCPU is already running. If it's running by the time Linux comes up, it means the boot loader already downloaded the DPFE firmware. Markus Mayer (2): memory: brcmstb: dpfe: introduce is_dcpu_enabled

[PATCH 3/3] tools/thermal: tmon: use $(PKG_CONFIG) instead of hard-coding pkg-config

From: Markus Mayer <mma...@broadcom.com> To ease cross-compiling, make use of the $(PKG_CONFIG) variable rather than hard-coding calls to pkg-config. Signed-off-by: Markus Mayer <mma...@broadcom.com> --- tools/thermal/tmon/Makefile | 9 + 1 file changed, 5 insertions(+),

[PATCH 3/3] tools/thermal: tmon: use $(PKG_CONFIG) instead of hard-coding pkg-config

From: Markus Mayer To ease cross-compiling, make use of the $(PKG_CONFIG) variable rather than hard-coding calls to pkg-config. Signed-off-by: Markus Mayer --- tools/thermal/tmon/Makefile | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/tools/thermal/tmon/Makefile

[PATCH 2/3] tools/thermal: tmon: allow $(CC) to be defined externally

From: Markus Mayer <mma...@broadcom.com> It can be helpful, especially when using a build system, to set the C compiler externally. Signed-off-by: Markus Mayer <mma...@broadcom.com> --- tools/thermal/tmon/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t

[PATCH 1/3] tools/thermal: tmon: use "-fstack-protector" only if supported

From: Markus Mayer <mma...@broadcom.com> Most, but not all, toolchains support the "-fstack-protector" flag. We check if the compiler supports the flag before using it. This allows tmon to be compiled for more environments. Signed-off-by: Markus Mayer <mma...@broadcom.com&

[PATCH 2/3] tools/thermal: tmon: allow $(CC) to be defined externally

From: Markus Mayer It can be helpful, especially when using a build system, to set the C compiler externally. Signed-off-by: Markus Mayer --- tools/thermal/tmon/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/thermal/tmon/Makefile b/tools/thermal/tmon

[PATCH 1/3] tools/thermal: tmon: use "-fstack-protector" only if supported

From: Markus Mayer Most, but not all, toolchains support the "-fstack-protector" flag. We check if the compiler supports the flag before using it. This allows tmon to be compiled for more environments. Signed-off-by: Markus Mayer --- tools/thermal/tmon/Makefile | 7 ++- 1 file

[PATCH 0/3] tools/thermal: tmon: Makefile improvements

From: Markus Mayer <mma...@broadcom.com> This series introduces a number of improvements to tmon's Makefile. The changes are meant to make it easier to cross-compile tmon on a greater number of platforms by giving more control to the person performing the build. At the same time, se

[PATCH 0/3] tools/thermal: tmon: Makefile improvements

From: Markus Mayer This series introduces a number of improvements to tmon's Makefile. The changes are meant to make it easier to cross-compile tmon on a greater number of platforms by giving more control to the person performing the build. At the same time, sensible defaults are retained so

Re: [PATCH v5 2/2] thermal: add brcmstb AVS TMON driver

On 26 September 2017 at 14:32, Scott Branden <scott.bran...@broadcom.com> wrote: > Hi Markus, > > > On 17-09-26 02:27 PM, Markus Mayer wrote: >> >> From: Brian Norris <computersforpe...@gmail.com> >> >> The AVS TMON core provides temperature r

Re: [PATCH v5 2/2] thermal: add brcmstb AVS TMON driver

On 26 September 2017 at 14:32, Scott Branden wrote: > Hi Markus, > > > On 17-09-26 02:27 PM, Markus Mayer wrote: >> >> From: Brian Norris >> >> The AVS TMON core provides temperature readings, a pair of configurable >> high- and low-temperature thre

Re: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver

l.com>; Rafal Milecki <ra...@milecki.pl> >> Cc: Markus Mayer <c...@mmayer.net>; Eduardo Valentin >> <edubez...@gmail.com>; Rob Herring <robh...@kernel.org>; Mark Rutland >> <mark.rutl...@arm.com>; Doug Berger <open...@gmail.com>; Brian >

Re: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver

On 25 September 2017 at 23:17, Zhang, Rui wrote: > Hi, Florian, > >> -Original Message- >> From: Florian Fainelli [mailto:f.faine...@gmail.com] >> Sent: Tuesday, September 26, 2017 12:14 PM >> To: Zhang, Rui ; Rafal Milecki >> Cc: Markus Mayer ; Edua

[PATCH v5 2/2] thermal: add brcmstb AVS TMON driver

m (e.g., through polling), or both. Signed-off-by: Brian Norris <computersforpe...@gmail.com> Signed-off-by: Doug Berger <open...@gmail.com> Signed-off-by: Markus Mayer <mma...@broadcom.com> --- drivers/thermal/Kconfig| 2 +- drivers/thermal/broadcom/Kconfig

[PATCH v5 2/2] thermal: add brcmstb AVS TMON driver

. Signed-off-by: Brian Norris Signed-off-by: Doug Berger Signed-off-by: Markus Mayer --- drivers/thermal/Kconfig| 2 +- drivers/thermal/broadcom/Kconfig | 7 + drivers/thermal/broadcom/Makefile | 1 + drivers/thermal/broadcom/brcmstb_thermal.c | 387

[PATCH v5 1/2] Documentation: devicetree: add binding for Broadcom STB AVS TMON

From: Brian Norris <computersforpe...@gmail.com> Add binding for Broadcom STB thermal. Signed-off-by: Brian Norris <computersforpe...@gmail.com> Acked-by: Rob Herring <r...@kernel.org> Signed-off-by: Markus Mayer <mma...@broadcom.com> --- .../devicetree/bindings/t

[PATCH v5 0/2] thermal: add brcmstb AVS TMON driver

From: Markus Mayer <mma...@broadcom.com> This series adds the brcmstb AVS TMON driver. The driver was originally written by Brian Norris. Changes since v4: - disable trip points properly when needed; there was code left-over from an older iteration of this driver that used long ints,

[PATCH v5 1/2] Documentation: devicetree: add binding for Broadcom STB AVS TMON

From: Brian Norris Add binding for Broadcom STB thermal. Signed-off-by: Brian Norris Acked-by: Rob Herring Signed-off-by: Markus Mayer --- .../devicetree/bindings/thermal/brcm,avs-tmon.txt| 20 MAINTAINERS | 8 2

[PATCH v5 0/2] thermal: add brcmstb AVS TMON driver

From: Markus Mayer This series adds the brcmstb AVS TMON driver. The driver was originally written by Brian Norris. Changes since v4: - disable trip points properly when needed; there was code left-over from an older iteration of this driver that used long ints, which resulted in code

Re: [PATCH] thermal: brcmstb: disable trip points properly when needed

On 14 September 2017 at 16:19, Markus Mayer <c...@mmayer.net> wrote: > From: Markus Mayer <mma...@broadcom.com> > > The code checking for low and high temperature points was still based > on an earlier implementation of the driver. It wasn't working properly > with the

Re: [PATCH] thermal: brcmstb: disable trip points properly when needed

On 14 September 2017 at 16:19, Markus Mayer wrote: > From: Markus Mayer > > The code checking for low and high temperature points was still based > on an earlier implementation of the driver. It wasn't working properly > with the data types currently being used. > > We

[PATCH] thermal: brcmstb: disable trip points properly when needed

From: Markus Mayer <mma...@broadcom.com> The code checking for low and high temperature points was still based on an earlier implementation of the driver. It wasn't working properly with the data types currently being used. We fix this by disabling the high trip point if our high tempe

[PATCH] thermal: brcmstb: disable trip points properly when needed

From: Markus Mayer The code checking for low and high temperature points was still based on an earlier implementation of the driver. It wasn't working properly with the data types currently being used. We fix this by disabling the high trip point if our high temperature is INT_MAX and disabling

[PATCH v3 2/2] memory: brcmstb: Add driver for DPFE

From: Markus Mayer <mma...@broadcom.com> This driver allows access to DRAM properties, such as the refresh rate, via the Broadcom STB DDR PHY Front End (DPFE). The refresh rate can be used as indirect indicator of the DRAM temperature. The driver also allows setting of the sampling in

[PATCH v3 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors

From: Markus Mayer <mma...@broadcom.com> Provide bindings for the Broadcom STB DDR PHY Front End (DPFE). Signed-off-by: Markus Mayer <mma...@broadcom.com> Acked-by: Rob Herring <r...@kernel.org> --- .../bindings/memory-controllers/brcm,dpfe-cpu.txt | 27

[PATCH v3 2/2] memory: brcmstb: Add driver for DPFE

From: Markus Mayer This driver allows access to DRAM properties, such as the refresh rate, via the Broadcom STB DDR PHY Front End (DPFE). The refresh rate can be used as indirect indicator of the DRAM temperature. The driver also allows setting of the sampling interval. Signed-off-by: Markus

[PATCH v3 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors

From: Markus Mayer Provide bindings for the Broadcom STB DDR PHY Front End (DPFE). Signed-off-by: Markus Mayer Acked-by: Rob Herring --- .../bindings/memory-controllers/brcm,dpfe-cpu.txt | 27 ++ 1 file changed, 27 insertions(+) create mode 100644 Documentation

[PATCH v3 0/2] SoC driver for Broadcom STB DPFE

From: Markus Mayer <mma...@broadcom.com> This series introduces a driver to interact with the Broadcom STB DDR PHY Front End (DPFE), specifically to communicate with the DCPU that is part of the DDR PHY and which is running its own firmware. The DCPU provides information such as DRAM r

[PATCH v3 0/2] SoC driver for Broadcom STB DPFE

From: Markus Mayer This series introduces a driver to interact with the Broadcom STB DDR PHY Front End (DPFE), specifically to communicate with the DCPU that is part of the DDR PHY and which is running its own firmware. The DCPU provides information such as DRAM refresh rate, which can be used

[PATCH v4 4/4] arm64: defconfig: add CONFIG_BRCMSTB_THERMAL

From: Markus Mayer <mma...@broadcom.com> Turn on CONFIG_BRCMSTB_THERMAL as module. Signed-off-by: Markus Mayer <mma...@broadcom.com> --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig i

  1   2   3   4   5   6   7   >