* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Nick Desaulniers @ 2018-05-23 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAeHK+wk0hSH6iQcsLzrpjvsGocev-UZ6=z95ysecdFnAcHVSQ@mail.gmail.com>
On Wed, May 23, 2018 at 4:54 AM Andrey Konovalov <andreyknvl@google.com>
wrote:
> On Tue, May 22, 2018 at 8:28 PM, Nick Desaulniers
> <ndesaulniers@google.com> wrote:
> > On Fri, May 18, 2018 at 11:13 AM Marc Zyngier <marc.zyngier@arm.com>
wrote:
> >> > - you have checked that with a released version of the compiler, you
> >
> > On Tue, May 22, 2018 at 10:58 AM Andrey Konovalov <andreyknvl@google.com
> > wrote:
> >> Tested-by: Andrey Konovalov <andreyknvl@google.com>
> >
> > Hi Andrey,
> > Thank you very much for this report. Can you confirm as well the
version
> > of Clang that you were using?
> I'm on 86852a40 ("[InstCombine] Calloc-ed strings optimizations").
> > If it's not a binary release (built from
> > source), would you be able to re-confirm with a released version?
> Sure. Which release should I try and how do I get it?
Maybe clang-6.0 as the latest release (though I suspect you may run into
the recently-fixed-in-clang-7.0 "S" constraint bug that you reported).
I've had luck on debian based distributions installing from:
http://apt.llvm.org/
(These can be added to your /etc/apt/sources.list, then a `sudo apt update`
and `sudo apt install clang-6.0`)
If you're not able to add remote repositories (some employers block this ;)
), then you can find releases for download for a few different platforms:
https://releases.llvm.org/
For example, a quick:
$ mkdir llvm-6.0
$ cd !$
$ wget
https://releases.llvm.org/6.0.0/clang+llvm-6.0.0-x86_64-linux-gnu-debian8.tar.xz
$ tar xvf clang+llvm-6.0.0-x86_64-linux-gnu-debian8.tar.xz
$ ./clang+llvm-6.0.0-x86_64-linux-gnu-debian8/bin/clang-6.0 -v
clang version 6.0.0 (tags/RELEASE_600/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: .../llvm-6.0/./clang+llvm-6.0.0-x86_64-linux-gnu-debian8/bin
Found candidate GCC installation: ...
Candidate multilib: .;@m64
Selected multilib: .;@m64
Seems to work.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [PATCH v7 2/2] drivers: soc: Add LLCC driver
From: rishabhb at codeaurora.org @ 2018-05-23 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75Vd8HZU+BT38-OfXHiihv1yZG6YBeMWyfweBA+kAwk6HUw@mail.gmail.com>
On 2018-05-22 12:38, Andy Shevchenko wrote:
> On Tue, May 22, 2018 at 9:33 PM, <rishabhb@codeaurora.org> wrote:
>> On 2018-05-18 14:01, Andy Shevchenko wrote:
>>> On Wed, May 16, 2018 at 8:43 PM, Rishabh Bhatnagar
>>> <rishabhb@codeaurora.org> wrote:
>
>>>> +#define ACTIVATE 0x1
>>>> +#define DEACTIVATE 0x2
>>>> +#define ACT_CTRL_OPCODE_ACTIVATE 0x1
>>>> +#define ACT_CTRL_OPCODE_DEACTIVATE 0x2
>>>> +#define ACT_CTRL_ACT_TRIG 0x1
>>>
>>>
>>> Are these bits? Perhaps BIT() ?
>>>
>> isn't it just better to use fixed size as u suggest in the next
>> comment?
>
> If the are bits, use BIT() macro.
>
>>>> +struct llcc_slice_desc *llcc_slice_getd(u32 uid)
>>>> +{
>>>> + const struct llcc_slice_config *cfg;
>>>> + struct llcc_slice_desc *desc;
>>>> + u32 sz, count = 0;
>>>> +
>>>> + cfg = drv_data->cfg;
>>>> + sz = drv_data->cfg_size;
>>>> +
>>>
>>>
>>>> + while (cfg && count < sz) {
>>>> + if (cfg->usecase_id == uid)
>>>> + break;
>>>> + cfg++;
>>>> + count++;
>>>> + }
>>>> + if (cfg == NULL || count == sz)
>>>> + return ERR_PTR(-ENODEV);
>>>
>>>
>>> if (!cfg)
>>> return ERR_PTR(-ENODEV);
>>>
>>> while (cfg->... != uid) {
>>> cfg++;
>>> count++;
>>> }
>>>
>>> if (count == sz)
>>> return ...
>>>
>>> Though I would rather put it to for () loop.
>>>
>> In each while loop iteration the cfg pointer needs to be checked for
>> NULL. What if the usecase id never matches the uid passed by client
>> and we keep iterating. At some point it will crash.
>
> do {
> if (!cfg || count == sz)
> return ...(-ENODEV);
> ...
> } while (...);
>
> Though, as I said for-loop will look slightly better I think.
>
>>>> + ret = llcc_update_act_ctrl(desc->slice_id, act_ctrl_val,
>>>> + DEACTIVATE);
>>>
>>>
>>> Perhaps one line (~83 characters here is OK) ?
>>
>> The checkpatch script complains about such lines.
>
> So what if it just 3 characters out?
>
Many upstream reviewers have objection to lines crossing over 80
characters
I have gotten reviews to reduce the line length even if its like 81~82
characters. Can we keep this as it is? I have addressed all other
comments and will send out the next patch by today.
>>>> + ret = llcc_update_act_ctrl(desc->slice_id, act_ctrl_val,
>>>> + ACTIVATE);
>
>>> Ditto.
>
>>>> + attr1_cfg = bcast_off +
>>>> +
>>>> LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id);
>>>> + attr0_cfg = bcast_off +
>>>> +
>>>> LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id);
>
>>> Ditto.
>
>>>> + attr1_val |= llcc_table[i].probe_target_ways <<
>>>> + ATTR1_PROBE_TARGET_WAYS_SHIFT;
>>>> + attr1_val |= llcc_table[i].fixed_size <<
>>>> + ATTR1_FIXED_SIZE_SHIFT;
>>>> + attr1_val |= llcc_table[i].priority <<
>>>> ATTR1_PRIORITY_SHIFT;
>
>>> foo |=
>>> bar << SHIFT;
>>>
>>> would look slightly better.
>
> Did you consider this option ?
^ permalink raw reply
* [PATCH 3/5] watchdog: sp805: set WDOG_HW_RUNNING when appropriate
From: Guenter Roeck @ 2018-05-23 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <76d47e02-7a5f-3fc2-3905-cd4aa03ac69c@arm.com>
On Wed, May 23, 2018 at 12:48:10PM +0100, Robin Murphy wrote:
> On 23/05/18 08:52, Scott Branden wrote:
> >
> >
> >On 18-05-22 04:24 PM, Ray Jui wrote:
> >>Hi Guenter,
> >>
> >>On 5/22/2018 1:54 PM, Guenter Roeck wrote:
> >>>On Tue, May 22, 2018 at 11:47:18AM -0700, Ray Jui wrote:
> >>>>If the watchdog hardware is already enabled during the boot process,
> >>>>when the Linux watchdog driver loads, it should reset the watchdog and
> >>>>tell the watchdog framework. As a result, ping can be generated from
> >>>>the watchdog framework, until the userspace watchdog daemon takes over
> >>>>control
> >>>>
> >>>>Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> >>>>Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
> >>>>Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> >>>>---
> >>>>? drivers/watchdog/sp805_wdt.c | 22 ++++++++++++++++++++++
> >>>>? 1 file changed, 22 insertions(+)
> >>>>
> >>>>diff --git a/drivers/watchdog/sp805_wdt.c
> >>>>b/drivers/watchdog/sp805_wdt.c
> >>>>index 1484609..408ffbe 100644
> >>>>--- a/drivers/watchdog/sp805_wdt.c
> >>>>+++ b/drivers/watchdog/sp805_wdt.c
> >>>>@@ -42,6 +42,7 @@
> >>>>????? /* control register masks */
> >>>>????? #define??? INT_ENABLE??? (1 << 0)
> >>>>????? #define??? RESET_ENABLE??? (1 << 1)
> >>>>+??? #define??? ENABLE_MASK??? (INT_ENABLE | RESET_ENABLE)
> >>>>? #define WDTINTCLR??????? 0x00C
> >>>>? #define WDTRIS??????????? 0x010
> >>>>? #define WDTMIS??????????? 0x014
> >>>>@@ -74,6 +75,18 @@ module_param(nowayout, bool, 0);
> >>>>? MODULE_PARM_DESC(nowayout,
> >>>>????????? "Set to 1 to keep watchdog running after device release");
> >>>>? +/* returns true if wdt is running; otherwise returns false */
> >>>>+static bool wdt_is_running(struct watchdog_device *wdd)
> >>>>+{
> >>>>+??? struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
> >>>>+
> >>>>+??? if ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
> >>>>+??????? ENABLE_MASK)
> >>>>+??????? return true;
> >>>>+??? else
> >>>>+??????? return false;
> >>>
> >>>????return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
> >>>
> >>
> >>Note ENABLE_MASK contains two bits (INT_ENABLE and RESET_ENABLE);
> >>therefore, a simple !!(expression) would not work? That is, the masked
> >>result needs to be compared against the mask again to ensure both bits
> >>are set, right?
> >Ray - your original code looks correct to me.? Easier to read and less
> >prone to errors as shown in the attempted translation to a single
> >statement.
>
> if (<boolean condition>)
> return true;
> else
> return false;
>
> still looks really dumb, though, and IMO is actually harder to read than
> just "return <boolean condition>;" because it forces you to stop and
> double-check that the logic is, in fact, only doing the obvious thing.
>
Yes, and I won't accept it, sorry.
Guenter
> Robin.
>
>
>
> p.s. No thanks for making me remember the mind-boggling horror of briefly
> maintaining part of this legacy codebase... :P
>
> $ grep -r '? true : false' --include=*.cpp . | wc -l
> 951
^ permalink raw reply
* [PATCH 3/5] watchdog: sp805: set WDOG_HW_RUNNING when appropriate
From: Guenter Roeck @ 2018-05-23 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ef3539fd-c95c-f364-93c7-680aabd1eea3@arm.com>
On Wed, May 23, 2018 at 06:15:14PM +0100, Robin Murphy wrote:
> On 23/05/18 17:29, Ray Jui wrote:
> >Hi Robin,
> >
> >On 5/23/2018 4:48 AM, Robin Murphy wrote:
> >>On 23/05/18 08:52, Scott Branden wrote:
> >>>
> >>>
> >>>On 18-05-22 04:24 PM, Ray Jui wrote:
> >>>>Hi Guenter,
> >>>>
> >>>>On 5/22/2018 1:54 PM, Guenter Roeck wrote:
> >>>>>On Tue, May 22, 2018 at 11:47:18AM -0700, Ray Jui wrote:
> >>>>>>If the watchdog hardware is already enabled during the boot process,
> >>>>>>when the Linux watchdog driver loads, it should reset the
> >>>>>>watchdog and
> >>>>>>tell the watchdog framework. As a result, ping can be generated from
> >>>>>>the watchdog framework, until the userspace watchdog daemon
> >>>>>>takes over
> >>>>>>control
> >>>>>>
> >>>>>>Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> >>>>>>Reviewed-by: Vladimir Olovyannikov
> >>>>>><vladimir.olovyannikov@broadcom.com>
> >>>>>>Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> >>>>>>---
> >>>>>>? drivers/watchdog/sp805_wdt.c | 22 ++++++++++++++++++++++
> >>>>>>? 1 file changed, 22 insertions(+)
> >>>>>>
> >>>>>>diff --git a/drivers/watchdog/sp805_wdt.c
> >>>>>>b/drivers/watchdog/sp805_wdt.c
> >>>>>>index 1484609..408ffbe 100644
> >>>>>>--- a/drivers/watchdog/sp805_wdt.c
> >>>>>>+++ b/drivers/watchdog/sp805_wdt.c
> >>>>>>@@ -42,6 +42,7 @@
> >>>>>>????? /* control register masks */
> >>>>>>????? #define??? INT_ENABLE??? (1 << 0)
> >>>>>>????? #define??? RESET_ENABLE??? (1 << 1)
> >>>>>>+??? #define??? ENABLE_MASK??? (INT_ENABLE | RESET_ENABLE)
> >>>>>>? #define WDTINTCLR??????? 0x00C
> >>>>>>? #define WDTRIS??????????? 0x010
> >>>>>>? #define WDTMIS??????????? 0x014
> >>>>>>@@ -74,6 +75,18 @@ module_param(nowayout, bool, 0);
> >>>>>>? MODULE_PARM_DESC(nowayout,
> >>>>>>????????? "Set to 1 to keep watchdog running after device release");
> >>>>>>? +/* returns true if wdt is running; otherwise returns false */
> >>>>>>+static bool wdt_is_running(struct watchdog_device *wdd)
> >>>>>>+{
> >>>>>>+??? struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
> >>>>>>+
> >>>>>>+??? if ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
> >>>>>>+??????? ENABLE_MASK)
> >>>>>>+??????? return true;
> >>>>>>+??? else
> >>>>>>+??????? return false;
> >>>>>
> >>>>>????return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
> >>>>>
> >>>>
> >>>>Note ENABLE_MASK contains two bits (INT_ENABLE and RESET_ENABLE);
> >>>>therefore, a simple !!(expression) would not work? That is, the
> >>>>masked result needs to be compared against the mask again to ensure
> >>>>both bits are set, right?
> >>>Ray - your original code looks correct to me.? Easier to read and less
> >>>prone to errors as shown in the attempted translation to a single
> >>>statement.
> >>
> >>?????if (<boolean condition>)
> >>???????? return true;
> >>?????else
> >>???????? return false;
> >>
> >>still looks really dumb, though, and IMO is actually harder to read than
> >>just "return <boolean condition>;" because it forces you to stop and
> >>double-check that the logic is, in fact, only doing the obvious thing.
> >
> >If you can propose a way to modify my original code above to make it more
> >readable, I'm fine to make the change.
>
> Well,
>
> return readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK == ENABLE_MASK;
>
> would probably be reasonable to anyone other than the 80-column zealots, but
> removing the silly boolean-to-boolean translation idiom really only
> emphasises the fact that it's fundamentally a big complex statement; for
> maximum clarity I'd be inclined to separate the two logical operations (read
> and comparison), e.g.:
>
> u32 wdtcontrol = readl_relaxed(wdt->base + WDTCONTROL);
>
> return wdtcontrol & ENABLE_MASK == ENABLE_MASK;
== has higher precendence than bitwise &, so this will need ( ),
but otherwise I agree.
>
> which is still -3 lines vs. the original.
>
> >As I mentioned, I don't think the following change proposed by Guenter
> >will work due to the reason I pointed out:
> >
> >return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
>
> FWIW, getting the desired result should only need one logical not swapping
> for a bitwise one there:
>
> return !(~readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK);
>
> but that's well into "too clever for its own good" territory ;)
Yes, that would be confusing.
>
> Robin.
^ permalink raw reply
* [PATCH 1/5] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Guenter Roeck @ 2018-05-23 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <af81ea74-fb80-11e2-7bdc-d3607bdbd46b@arm.com>
On Wed, May 23, 2018 at 11:57:25AM +0100, Robin Murphy wrote:
> On 22/05/18 19:47, Ray Jui wrote:
> >Update the SP805 binding document to add optional 'timeout-sec'
> >devicetree property
> >
> >Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> >Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> >---
> > Documentation/devicetree/bindings/watchdog/sp805-wdt.txt | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> >diff --git a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> >index edc4f0e..f898a86 100644
> >--- a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> >+++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> >@@ -19,6 +19,8 @@ Required properties:
> > Optional properties:
> > - interrupts : Should specify WDT interrupt number.
> >+- timeout-sec : Should specify default WDT timeout in seconds. If unset, the
> >+ default timeout is 30 seconds
>
> According to the SP805 TRM, the default interval is dependent on the rate of
> WDOGCLK, but would typically be a lot longer than that :/
>
Depends on the definition of "default". In the context of watchdog drivers,
it is (or should be) a driver default, not a chip default.
Guenter
> On a related note, anyone have any idea why we seem to have two subtly
> different SP805 bindings defined?
>
> Robin.
>
> > Examples:
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH RFC V2 2/6] hwmon: Add support for RPi voltage sensor
From: Guenter Roeck @ 2018-05-23 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cbbdab47-cde3-7a7c-c797-c00d546e00d5@arm.com>
On Wed, May 23, 2018 at 01:12:10PM +0100, Robin Murphy wrote:
> On 22/05/18 20:31, Stefan Wahren wrote:
> [...]
> >>>>>+static int rpi_hwmon_probe(struct platform_device *pdev)
> >>>>>+{
> >>>>>+ struct device *dev = &pdev->dev;
> >>>>>+ struct rpi_hwmon_data *data;
> >>>>>+ int ret;
> >>>>>+
> >>>>>+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> >>>>>+ if (!data)
> >>>>>+ return -ENOMEM;
> >>>>>+
> >>>>>+ data->fw = platform_get_drvdata(to_platform_device(dev->parent));
> >>>>>+ if (!data->fw)
> >>>>>+ return -EPROBE_DEFER;
> >>>>>+
> >>>>
> >>>>I am a bit at loss here (and sorry I didn't bring this up before).
> >>>>How would this ever be possible, given that the driver is registered
> >>>>from the firmware driver ?
> >>>
> >>>Do you refer to the (wrong) return code, the assumption that the parent must be a platform driver or a possible race?
> >>>
> >>
> >>The return code is one thing. My question was how the driver would ever be instantiated
> >>with platform_get_drvdata(to_platform_device(dev->parent)) == NULL (but dev->parent != NULL),
> >>so I referred to the race. But, sure, a second question would be how that would indicate
> >>that the parent is not instantiated yet (which by itself seems like an odd question).
> >
> >This shouldn't happen and worth a log error. In patch #3 the registration is called after the complete private data of the firmware driver is initialized. Did i missed something?
> >
> >But i must confess that i didn't test all builtin/module combinations.
>
> The point is that, by construction, a "raspberrypi-hwmon" device will only
> ever be created for this driver to bind to if the firmware device is both
> fully initialised and known to support the GET_THROTTLED call already. Thus
> trying to check those again from the hwmon driver is at best pointless, and
> at worst misleading. If somebody *does* manage to bind this driver to some
> random inappropriate device, you've still got no guarantee that dev->parent
> is valid or that dev_get_drvdata(dev->parent)) won't return something
> non-NULL that isn't a struct rpi_firmware pointer, at which point you're
> liable to pass the paranoid check yet still crash anyway.
>
> IOW, you can't reasonably defend against incorrect operation, and under
> correct operation there's nothing to defend against, so either way it's
> pretty futile to waste effort trying.
>
Well said.
Guenter
^ permalink raw reply
* [GIT PULL] Amlogic 32-bit DT updates for v4.18, round 2
From: Kevin Hilman @ 2018-05-23 18:17 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 35ee52bea66c74a7c33cebda8692d61b1ed7c6e9:
ARM: dts: meson8m2: add support for the Tronsmart MXIII Plus (2018-05-10 17:03:28 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt-2
for you to fetch changes up to ae0257da5701b6e44eba9dc4ebab867b56d6ea29:
ARM: meson: merge Kconfig symbol MACH_MESON8B into MACH_MESON8 (2018-05-23 10:08:13 -0700)
----------------------------------------------------------------
Amlogic 32-bit DT changes for v4.18, round 2
- remove MACH_MESON8B, only used for building DTs
----------------------------------------------------------------
Martin Blumenstingl (2):
ARM: dts: meson: build the Meson8b .dtbs with MACH_MESON8
ARM: meson: merge Kconfig symbol MACH_MESON8B into MACH_MESON8
arch/arm/boot/dts/Makefile | 5 ++---
arch/arm/mach-meson/Kconfig | 9 +--------
2 files changed, 3 insertions(+), 11 deletions(-)
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT updates for v4.18, round 2
From: Kevin Hilman @ 2018-05-23 18:17 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit c51fb2d458a6d62215c1ff6bbca8e5c876370e71:
dt-bindings: arm: amlogic: add support for the Tronsmart MXIII Plus (2018-05-09 15:25:20 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-2
for you to fetch changes up to ffe2f2a415a5c36c0629c0ac8ea3dda80fbfd4b6:
ARM64: dts: meson-axg: enable i2c AO on the S400 board (2018-05-23 10:05:41 -0700)
----------------------------------------------------------------
Amlogic 64-bit DT updates for v4.18, round 2
- AXG I2C fixups/cleanups
----------------------------------------------------------------
Jerome Brunet (4):
ARM64: dts: meson-axg: clean-up i2c nodes
ARM64: dts: meson-axg: correct i2c AO clock
ARM64: dts: meson-axg: add i2c AO pins
ARM64: dts: meson-axg: enable i2c AO on the S400 board
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 6 ++++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------------
2 files changed, 62 insertions(+), 23 deletions(-)
^ permalink raw reply
* [PATCH 06/11] dts: bindings: Restrict coresight tmc-etr scatter-gather mode
From: Rob Herring @ 2018-05-23 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526661567-4578-7-git-send-email-suzuki.poulose@arm.com>
On Fri, May 18, 2018 at 05:39:22PM +0100, Suzuki K Poulose wrote:
> We are about to add the support for ETR builtin scatter-gather mode
> for dealing with large amount of trace buffers. However, on some of
> the platforms, using the ETR SG mode can lock up the system due to
> the way the ETR is connected to the memory subsystem.
>
> In SG mode, the ETR performs READ from the scatter-gather table to
> fetch the next page and regular WRITE of trace data. If the READ
> operation doesn't complete(due to the memory subsystem issues,
> which we have seen on a couple of platforms) the trace WRITE
> cannot proceed leading to issues. So, we by default do not
> use the SG mode, unless it is known to be safe on the platform.
> We define a DT property for the TMC node to specify whether we
> have a proper SG mode.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Mike Leach <mike.leach@linaro.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: John Horley <john.horley@arm.com>
> Cc: Robert Walker <robert.walker@arm.com>
> Cc: devicetree at vger.kernel.org
> Cc: frowand.list at gmail.com
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> Documentation/devicetree/bindings/arm/coresight.txt | 2 ++
> drivers/hwtracing/coresight/coresight-tmc.c | 9 ++++++++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 03/15] clk: sunxi-ng: r40: Export video PLLs
From: Rob Herring @ 2018-05-23 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180519183127.2718-4-jernej.skrabec@siol.net>
On Sat, May 19, 2018 at 08:31:15PM +0200, Jernej Skrabec wrote:
> Video PLLs need to be referenced in R40 DT as possible HDMI PHY parent.
>
> Export them.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/clk/sunxi-ng/ccu-sun8i-r40.h | 8 ++++++--
> include/dt-bindings/clock/sun8i-r40-ccu.h | 4 ++++
> 2 files changed, 10 insertions(+), 2 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 05/15] drm/sun4i: Add TCON TOP driver
From: Rob Herring @ 2018-05-23 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180519183127.2718-6-jernej.skrabec@siol.net>
On Sat, May 19, 2018 at 08:31:17PM +0200, Jernej Skrabec wrote:
> As already described in DT binding, TCON TOP is responsible for
> configuring display pipeline. In this initial driver focus is on HDMI
> pipeline, so TVE and LCD configuration is not implemented.
>
> Implemented features:
> - HDMI source selection
> - clock driver (TCON and DSI gating)
> - connecting mixers and TCONS
>
> Something similar also existed in previous SoCs, except that it was part
> of first TCON.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/sun4i/Makefile | 3 +-
> drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 256 +++++++++++++++++++++
> drivers/gpu/drm/sun4i/sun8i_tcon_top.h | 20 ++
> include/dt-bindings/clock/sun8i-tcon-top.h | 11 +
This belongs with the binding doc patch.
> 4 files changed, 289 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.h
> create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
^ permalink raw reply
* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
From: Tony Lindgren @ 2018-05-23 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <243730d3-e7f3-584d-b5dd-491c2700cf11@ti.com>
* Tero Kristo <t-kristo@ti.com> [180523 05:58]:
> On 22/05/18 23:01, Rob Herring wrote:
> > On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
> > > Ok trying to resurrect this thread a bit. Is there any kind of consensus how
> > > things like this should be handled? Should we add the DT overlay files to
> > > kernel tree or not?
> >
> > IMO, yes.
I too agree the overlay files should be in the kernel rather than
people having to try to figure out where to find them.
No idea how we'll verify they'll build though :) Maybe we
just need randconfig support for DT overlay files too?
Regards,
Tony
^ permalink raw reply
* [PATCH v2] OMAP: CLK: CLKSRC: Add suspend resume hooks
From: Tony Lindgren @ 2018-05-23 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527013340-8036-1-git-send-email-j-keerthy@ti.com>
* Keerthy <j-keerthy@ti.com> [180522 11:24]:
> Add the save and restore for clksrc as part of suspend and resume
> so that it saves the counter value and restores. This is needed in
> modes like rtc+ddr in self-refresh not doing this stalls the time.
Can't we now do this all in drivers/clocksource/timer-ti-*.c?
> @@ -490,6 +513,15 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
> res = omap_dm_timer_init_one(&clksrc, fck_source, property,
> &clocksource_gpt.name,
> OMAP_TIMER_NONPOSTED);
> +
> + if (soc_is_am43xx()) {
> + clocksource_gpt.suspend = omap2_gptimer_clksrc_suspend;
> + clocksource_gpt.resume = omap2_gptimer_clksrc_resume;
> +
> + clocksource_gpt_hwmod =
> + omap_hwmod_lookup(clocksource_gpt.name);
> + }
> +
Then you can do this based on a quirk flag set by compatible.
Regards,
Tony
^ permalink raw reply
* [PATCHv2] arm64: Make sure permission updates happen for pmd/pud
From: Laura Abbott @ 2018-05-23 18:43 UTC (permalink / raw)
To: linux-arm-kernel
Commit 15122ee2c515 ("arm64: Enforce BBM for huge IO/VMAP mappings")
disallowed block mappings for ioremap since that code does not honor
break-before-make. The same APIs are also used for permission updating
though and the extra checks prevent the permission updates from happening,
even though this should be permitted. This results in read-only permissions
not being fully applied. Visibly, this can occasionaly be seen as a failure
on the built in rodata test when the test data ends up in a section or
as an odd RW gap on the page table dump. Fix this by using
pgattr_change_is_safe instead of p*d_present for determining if the
change is permitted.
Reported-by: Peter Robinson <pbrobinson@gmail.com>
Fixes: 15122ee2c515 ("arm64: Enforce BBM for huge IO/VMAP mappings")
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v2: Switch to using pgattr_change_is_safe per suggestion of Will
---
arch/arm64/mm/mmu.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9f1ec1..493ff75670ff 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -933,13 +933,15 @@ int pud_set_huge(pud_t *pudp, phys_addr_t phys, pgprot_t prot)
{
pgprot_t sect_prot = __pgprot(PUD_TYPE_SECT |
pgprot_val(mk_sect_prot(prot)));
+ pud_t new_pud = pfn_pud(__phys_to_pfn(phys), sect_prot);
- /* ioremap_page_range doesn't honour BBM */
- if (pud_present(READ_ONCE(*pudp)))
+ /* Only allow permission changes for now */
+ if (!pgattr_change_is_safe(READ_ONCE(pud_val(*pudp)),
+ pud_val(new_pud)))
return 0;
BUG_ON(phys & ~PUD_MASK);
- set_pud(pudp, pfn_pud(__phys_to_pfn(phys), sect_prot));
+ set_pud(pudp, new_pud);
return 1;
}
@@ -947,13 +949,15 @@ int pmd_set_huge(pmd_t *pmdp, phys_addr_t phys, pgprot_t prot)
{
pgprot_t sect_prot = __pgprot(PMD_TYPE_SECT |
pgprot_val(mk_sect_prot(prot)));
+ pmd_t new_pmd = pfn_pmd(__phys_to_pfn(phys), sect_prot);
- /* ioremap_page_range doesn't honour BBM */
- if (pmd_present(READ_ONCE(*pmdp)))
+ /* Only allow permission changes for now */
+ if (!pgattr_change_is_safe(READ_ONCE(pmd_val(*pmdp)),
+ pmd_val(new_pmd)))
return 0;
BUG_ON(phys & ~PMD_MASK);
- set_pmd(pmdp, pfn_pmd(__phys_to_pfn(phys), sect_prot));
+ set_pmd(pmdp, new_pmd);
return 1;
}
--
2.17.0
^ permalink raw reply related
* [GIT PULL] Amlogic 64-bit DT updates for v4.18, round 3
From: Kevin Hilman @ 2018-05-23 18:50 UTC (permalink / raw)
To: linux-arm-kernel
Olof, ARnd,
Here's final round of 64-bit DT updates for v4.18 for Amlogic.
I separated this one from round 2 because I've merged a tag from the
clock tree where the headers were added that are used by the new clock
driver nodes.
That clock dependency branch is already queued by the clock maintainers,
but included here so the arm-soc DT branch will continue to build
standalone.
Kevin
The following changes since commit ffe2f2a415a5c36c0629c0ac8ea3dda80fbfd4b6:
ARM64: dts: meson-axg: enable i2c AO on the S400 board (2018-05-23 10:05:41 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-3
for you to fetch changes up to 9adda3534faad306c3d5351c5b87d26fea9767be:
ARM64: dts: meson: fix clock source of the pclk for UART_AO (2018-05-23 11:31:54 -0700)
----------------------------------------------------------------
Amlogic 64-bit DT updates, round3
- AXG: add new clock driver
----------------------------------------------------------------
Kevin Hilman (1):
Merge tag 'for-kevin-meson-clk-bindings-v4.18-1' of https://github.com/BayLibre/clk-meson into v4.18/dt64
Martin Blumenstingl (1):
dt-bindings: clock: meson8b: export the NAND clock
Maxime Jourdan (1):
clk: meson: gxbb: expose VDEC_1 and VDEC_HEVC clocks
Qiufang Dai (1):
ARM64: dts: meson-axg: add AO clock driver
Yixun Lan (3):
dt-bindings: clock: axg-aoclkc: New binding for Meson-AXG SoC
dt-bindings: clock: reset: Add AXG AO Clock and Reset Bindings
ARM64: dts: meson: fix clock source of the pclk for UART_AO
Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt | 1 +
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 16 ++++++++++++++--
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++--
include/dt-bindings/clock/axg-aoclkc.h | 26 ++++++++++++++++++++++++++
include/dt-bindings/clock/gxbb-clkc.h | 2 ++
include/dt-bindings/clock/meson8b-clkc.h | 1 +
include/dt-bindings/reset/axg-aoclkc.h | 20 ++++++++++++++++++++
8 files changed, 68 insertions(+), 6 deletions(-)
create mode 100644 include/dt-bindings/clock/axg-aoclkc.h
create mode 100644 include/dt-bindings/reset/axg-aoclkc.h
^ permalink raw reply
* [PATCH 3/6] ASoC: ams_delta: use GPIO lookup table
From: Tony Lindgren @ 2018-05-23 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180521100503.GA24638@sirena.org.uk>
* Mark Brown <broonie@kernel.org> [180521 10:07]:
> On Fri, May 18, 2018 at 11:09:51PM +0200, Janusz Krzysztofik wrote:
> > Now as the Amstrad Delta board provides GPIO lookup tables, switch from
> > GPIO numbers to GPIO descriptors and use the table to locate required
> > GPIO pins.
>
> Acked-by: Mark Brown <broonie@kernel.org>
Thanks applying patches 1 and 3 of this series into omap-for-v4.18/soc.
It's kind of getting late for v4.18, but let's see if we can still make
it.
Seems the others can be applied to the driver trees after no more
comments, then once all that is done we can apply the last patch
in this series.
Regards,
Tony
^ permalink raw reply
* [PATCH v2] ARM: AM43XX: Add functions to save/restore am43xx control registers
From: Tony Lindgren @ 2018-05-23 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527013299-7982-1-git-send-email-j-keerthy@ti.com>
* Keerthy <j-keerthy@ti.com> [180522 11:24]:
> From: Tero Kristo <t-kristo@ti.com>
>
> These registers are part of the wkup domain and are lost during RTC only
> suspend and also hibernation, so storing/restoring their state is
> necessary.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> ---
>
> Changes in v2:
>
> * Introduced cpu_pm notifier instead of direct calls from pm33xx code.
> * Tested on am437x-gp-evm
>
> Probably too late for 4.18!
Applying into omap-for-v4.18/soc thanks, let's see if we can still
make it. If not, then for v4.19.
Regards,
Tony
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Andrey Konovalov @ 2018-05-23 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKwvOd=fqk2bQSiPBsUmVSQLGUEGYSUev3iWvico6HOpYs5YJA@mail.gmail.com>
On Wed, May 23, 2018 at 7:47 PM, Nick Desaulniers
<ndesaulniers@google.com> wrote:
> On Wed, May 23, 2018 at 4:54 AM Andrey Konovalov <andreyknvl@google.com>
> wrote:
>> On Tue, May 22, 2018 at 8:28 PM, Nick Desaulniers
>> <ndesaulniers@google.com> wrote:
>> > On Fri, May 18, 2018 at 11:13 AM Marc Zyngier <marc.zyngier@arm.com>
> wrote:
>> >> > - you have checked that with a released version of the compiler, you
>> >
>> > On Tue, May 22, 2018 at 10:58 AM Andrey Konovalov <andreyknvl@google.com
>
>> > wrote:
>> >> Tested-by: Andrey Konovalov <andreyknvl@google.com>
>> >
>> > Hi Andrey,
>> > Thank you very much for this report. Can you confirm as well the
> version
>> > of Clang that you were using?
>
>> I'm on 86852a40 ("[InstCombine] Calloc-ed strings optimizations").
>
>> > If it's not a binary release (built from
>> > source), would you be able to re-confirm with a released version?
>
>> Sure. Which release should I try and how do I get it?
>
> Maybe clang-6.0 as the latest release (though I suspect you may run into
> the recently-fixed-in-clang-7.0 "S" constraint bug that you reported).
Yes, and also into the "support for "r" prefixed variables in ARM
inline assembly" issue.
Tested on upstream commit ded4c39e (before both issues were
introduced) with -fno-jump-tables patch applied using clang 6.0.
Same result, the patch helps.
>
> I've had luck on debian based distributions installing from:
> http://apt.llvm.org/
>
> (These can be added to your /etc/apt/sources.list, then a `sudo apt update`
> and `sudo apt install clang-6.0`)
>
> If you're not able to add remote repositories (some employers block this ;)
> ), then you can find releases for download for a few different platforms:
> https://releases.llvm.org/
>
> For example, a quick:
> $ mkdir llvm-6.0
> $ cd !$
> $ wget
> https://releases.llvm.org/6.0.0/clang+llvm-6.0.0-x86_64-linux-gnu-debian8.tar.xz
> $ tar xvf clang+llvm-6.0.0-x86_64-linux-gnu-debian8.tar.xz
> $ ./clang+llvm-6.0.0-x86_64-linux-gnu-debian8/bin/clang-6.0 -v
> clang version 6.0.0 (tags/RELEASE_600/final)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: .../llvm-6.0/./clang+llvm-6.0.0-x86_64-linux-gnu-debian8/bin
> Found candidate GCC installation: ...
> Candidate multilib: .;@m64
> Selected multilib: .;@m64
>
> Seems to work.
> --
> Thanks,
> ~Nick Desaulniers
^ permalink raw reply
* [PATCH 1/5] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Rob Herring @ 2018-05-23 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c542388f-e417-f624-ade1-95f9a2fc8a3b@broadcom.com>
On Wed, May 23, 2018 at 09:25:49AM -0700, Ray Jui wrote:
>
>
> On 5/23/2018 3:57 AM, Robin Murphy wrote:
> > On 22/05/18 19:47, Ray Jui wrote:
> > > Update the SP805 binding document to add optional 'timeout-sec'
> > > devicetree property
> > >
> > > Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> > > Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> > > ---
> > > ? Documentation/devicetree/bindings/watchdog/sp805-wdt.txt | 2 ++
> > > ? 1 file changed, 2 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> > > b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> > > index edc4f0e..f898a86 100644
> > > --- a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> > > +++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> > > @@ -19,6 +19,8 @@ Required properties:
> > > ? Optional properties:
> > > ? - interrupts : Should specify WDT interrupt number.
> > > +- timeout-sec : Should specify default WDT timeout in seconds. If
> > > unset, the
> > > +??????????????? default timeout is 30 seconds
> >
> > According to the SP805 TRM, the default interval is dependent on the
> > rate of WDOGCLK, but would typically be a lot longer than that :/
> >
> > On a related note, anyone have any idea why we seem to have two subtly
> > different SP805 bindings defined?
Sigh.
> Interesting, I did not even know that until you pointed this out (and it's
> funny that I found that I actually reviewed arm,sp805.txt internally in
> Broadcom code review).
>
> It looks like one was done by Bhupesh Sharma (sp805-wdt.txt) and the other
> was done by Anup Patel (arm,sp805.txt). Both were merged at the same time
> around March 20, 2016: 915c56bc01d6. I'd assume both were sent out at around
> the same time.
>
> It sounds like we should definitely remove one of them. Given that
> sp805-wdt.txt appears to have more detailed descriptions on the use of the
> clocks, should we remove arm,sp805.txt?
Take whichever text you like, but I prefer filenames using the
compatible string and the correct string is 'arm,sp805' because '-wdt'
is redundant. You can probably safely just update all the dts files with
'arm,sp805' and just remove 'arm,sp805-wdt' because it is not actually
used (as the ID registers are).
Rob
^ permalink raw reply
* [PATCH] ARM: DTS: dra7: fix DCAN node addresses
From: Tony Lindgren @ 2018-05-23 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cf431fca-0372-bd50-88e7-d478e4aa52da@ti.com>
* Roger Quadros <rogerq@ti.com> [180521 20:25]:
> On 21/05/18 15:08, Kevin Hilman wrote:
> > Fix the DT node addresses to match the reg property addresses,
> > which were verified to match the TRM:
> > http://www.ti.com/lit/pdf/sprui30
> >
> > Cc: Roger Quadros <rogerq@ti.com>
> > Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>
> Thanks Kevin.
>
> Acked-by: Roger Quadros <rogerq@ti.com>
Applying into omap-for-v4.18/dt-fixes thanks.
Tony
^ permalink raw reply
* [PATCH V4 8/8] dt-bindings: stm32: add compatible for syscon
From: Rob Herring @ 2018-05-23 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527090479-5263-9-git-send-email-christophe.roullier@st.com>
On Wed, May 23, 2018 at 05:47:59PM +0200, Christophe Roullier wrote:
> This patch describes syscon DT bindings.
>
> Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
> ---
> Documentation/devicetree/bindings/arm/stm32.txt | 10 ----------
> .../devicetree/bindings/arm/stm32/stm32-syscon.txt | 14 ++++++++++++++
> Documentation/devicetree/bindings/arm/stm32/stm32.txt | 10 ++++++++++
> 3 files changed, 24 insertions(+), 10 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/stm32.txt
> create mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt
> create mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32.txt
In the future, use the -M option so file moves don't show any diff.
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 0/5] add missing of_node_put
From: Julia Lawall @ 2018-05-23 19:07 UTC (permalink / raw)
To: linux-arm-kernel
The device node iterators perform an of_node_get on each iteration, so a
jump out of the loop requires an of_node_put.
---
drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
drivers/pci/hotplug/pnv_php.c | 8 ++++++--
drivers/phy/hisilicon/phy-hisi-inno-usb2.c | 9 +++++++--
drivers/pinctrl/pinctrl-at91-pio4.c | 4 +++-
drivers/soc/ti/knav_dma.c | 1 +
5 files changed, 20 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH 1/5] pinctrl: at91-pio4: add missing of_node_put
From: Julia Lawall @ 2018-05-23 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527102436-13447-1-git-send-email-Julia.Lawall@lip6.fr>
The device node iterators perform an of_node_get on each iteration, so a
jump out of the loop requires an of_node_put.
The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):
// <smpl>
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
+ of_node_put(child);
? break;
...
}
... when != child
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/pinctrl/pinctrl-at91-pio4.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c b/drivers/pinctrl/pinctrl-at91-pio4.c
index 4b57a13..bafb3d4 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -576,8 +576,10 @@ static int atmel_pctl_dt_node_to_map(struct pinctrl_dev *pctldev,
for_each_child_of_node(np_config, np) {
ret = atmel_pctl_dt_subnode_to_map(pctldev, np, map,
&reserved_maps, num_maps);
- if (ret < 0)
+ if (ret < 0) {
+ of_node_put(np);
break;
+ }
}
}
^ permalink raw reply related
* [PATCH 3/5] soc: ti: knav_dma: add missing of_node_put
From: Julia Lawall @ 2018-05-23 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527102436-13447-1-git-send-email-Julia.Lawall@lip6.fr>
The device node iterators perform an of_node_get on each iteration, so a
jump out of the loop requires an of_node_put.
The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):
// <smpl>
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
+ of_node_put(child);
? break;
...
}
... when != child
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/soc/ti/knav_dma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
index 224d7dd..bda3173 100644
--- a/drivers/soc/ti/knav_dma.c
+++ b/drivers/soc/ti/knav_dma.c
@@ -768,6 +768,7 @@ static int knav_dma_probe(struct platform_device *pdev)
ret = dma_init(node, child);
if (ret) {
dev_err(&pdev->dev, "init failed with %d\n", ret);
+ of_node_put(child);
break;
}
}
^ permalink raw reply related
* [PATCH 5/5] drm/rockchip: lvds: add missing of_node_put
From: Julia Lawall @ 2018-05-23 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527102436-13447-1-git-send-email-Julia.Lawall@lip6.fr>
The device node iterators perform an of_node_get on each iteration, so a
jump out of the loop requires an of_node_put.
The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):
// <smpl>
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
+ of_node_put(child);
? break;
...
}
... when != child
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index e67f4ea..051b8be 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -363,8 +363,10 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
of_property_read_u32(endpoint, "reg", &endpoint_id);
ret = drm_of_find_panel_or_bridge(dev->of_node, 1, endpoint_id,
&lvds->panel, &lvds->bridge);
- if (!ret)
+ if (!ret) {
+ of_node_put(endpoint);
break;
+ }
}
if (!child_count) {
DRM_DEV_ERROR(dev, "lvds port does not have any children\n");
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox