* [PATCH 08/11] signal/arm: Document conflicts with SI_USER and SIGFPE
From: Eric W. Biederman @ 2018-01-12 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87373b6ghs.fsf@xmission.com>
Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER. Posix and common sense requires
that SI_USER not be a signal specific si_code. As such this use of 0
for the si_code is a pretty horribly broken ABI.
Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design. Making this a very
flakey implementation.
Utilizing FPE_FIXME, siginfo_layout will now return SIL_FAULT and the
appropriate fields will be reliably copied.
Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Russell King <rmk@flint.arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Ref: 451436b7bbb2 ("[ARM] Add support code for ARM hardware vector floating point")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
arch/arm/include/uapi/asm/siginfo.h | 13 +++++++++++++
arch/arm/vfp/vfpmodule.c | 2 +-
2 files changed, 14 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/uapi/asm/siginfo.h
diff --git a/arch/arm/include/uapi/asm/siginfo.h b/arch/arm/include/uapi/asm/siginfo.h
new file mode 100644
index 000000000000..d0513880be21
--- /dev/null
+++ b/arch/arm/include/uapi/asm/siginfo.h
@@ -0,0 +1,13 @@
+#ifndef __ASM_SIGINFO_H
+#define __ASM_SIGINFO_H
+
+#include <asm-generic/siginfo.h>
+
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+#endif
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index a71a48e71fff..03c6a3c72f9c 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -257,7 +257,7 @@ static void vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr, struct pt_
if (exceptions == VFP_EXCEPTION_ERROR) {
vfp_panic("unhandled bounce", inst);
- vfp_raise_sigfpe(0, regs);
+ vfp_raise_sigfpe(FPE_FIXME, regs);
return;
}
--
2.14.1
^ permalink raw reply related
* [GIT PULL] Allwinner fixes for 4.15, round 2
From: Olof Johansson @ 2018-01-12 1:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108084243.GA3261@wens.csie.org>
On Mon, Jan 08, 2018 at 04:42:43PM +0800, Chen-Yu Tsai wrote:
> Hi Arnd, Olof,
>
> Here's another fix for 4.15. The error was introduced in 4.15-rc1,
> so we'd really like to see it fixed for this release.
>
> Thanks
> ChenYu
>
> The following changes since commit eac6a3639decefcc8eb0941dd3cebe79993670ad:
>
> ARM: dts: sun8i: a711: Reinstate the PMIC compatible (2017-12-19 09:56:57 +0100)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-fixes-for-4.15-2
>
> for you to fetch changes up to bdae44705c0d5b751fbd79bc4a169905b25ed335:
>
> ARM: dts: sun[47]i: Fix display backend 1 output to TCON0 remote endpoint (2018-01-06 11:21:28 +0800)
>
> ----------------------------------------------------------------
> Allwinner fixes for 4.15, round 2
>
> One fix that fixes the display pipeline description in the device tree
> for the A10 and A20 SoCs. This description was introduced in 4.15-rc1
> with a mismatch in the graph remote endpoints, which would likely
> result in the driver misinterpreting how the individual components fit
> together.
>
> ----------------------------------------------------------------
> Chen-Yu Tsai (1):
> ARM: dts: sun[47]i: Fix display backend 1 output to TCON0 remote endpoint
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCH] soc: brcmstb: Only register SoC device on STB platforms
From: Olof Johansson @ 2018-01-12 1:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109145409.11612-1-thierry.reding@gmail.com>
On Tue, Jan 09, 2018 at 03:54:09PM +0100, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> After moving the SoC device initialization to an early initcall in
> commit f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall"),
> the Broadcom STB SoC device is registered on all platforms if support
> for the device is enabled in the kernel configuration.
>
> This causes an additional SoC device to appear on platforms that already
> register a native one. In case of Tegra the STB SoC device is registered
> as soc0 (with totally meaningless content in the sysfs attributes) and
> causes various scripts and programs to fail because they don't know how
> to parse that data.
>
> To fix this, duplicate the check from brcmstb_soc_device_early_init()
> that already prevents the code from doing anything nonsensical on non-
> STB platforms.
>
> Fixes: f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall")
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
Thanks, applied.
-Olof
^ permalink raw reply
* [PATCH] soc: brcmstb: Only register SoC device on STB platforms
From: Florian Fainelli @ 2018-01-12 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112010130.3tz7hnmzs74trwhw@localhost>
On 01/11/2018 05:01 PM, Olof Johansson wrote:
> On Tue, Jan 09, 2018 at 03:54:09PM +0100, Thierry Reding wrote:
>> From: Thierry Reding <treding@nvidia.com>
>>
>> After moving the SoC device initialization to an early initcall in
>> commit f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall"),
>> the Broadcom STB SoC device is registered on all platforms if support
>> for the device is enabled in the kernel configuration.
>>
>> This causes an additional SoC device to appear on platforms that already
>> register a native one. In case of Tegra the STB SoC device is registered
>> as soc0 (with totally meaningless content in the sysfs attributes) and
>> causes various scripts and programs to fail because they don't know how
>> to parse that data.
>>
>> To fix this, duplicate the check from brcmstb_soc_device_early_init()
>> that already prevents the code from doing anything nonsensical on non-
>> STB platforms.
>>
>> Fixes: f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall")
>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>> ---
>
>
> Thanks, applied.
Thanks for picking that up, I was just going to submit it.
--
Florian
^ permalink raw reply
* [PATCH 03/19] drm/exynos: Use the alpha format helper
From: Inki Dae @ 2018-01-12 1:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <345b8966460f13af7e29d2700876572d34f06cf4.1515494838.git-series.maxime.ripard@free-electrons.com>
2018? 01? 09? 19:56? Maxime Ripard ?(?) ? ?:
> Now that the core has a drm format helper to tell if a format embeds an
> alpha component in it, let's use it.
>
> Cc: Inki Dae <inki.dae@samsung.com>
> Cc: Joonyoung Shim <jy0922.shim@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Thanks,
Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 14 +-------------
> 1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c
> index dc5d79465f9b..d7339a6d072c 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -179,18 +179,6 @@ static const u8 filter_cr_horiz_tap4[] = {
> 70, 59, 48, 37, 27, 19, 11, 5,
> };
>
> -static inline bool is_alpha_format(unsigned int pixel_format)
> -{
> - switch (pixel_format) {
> - case DRM_FORMAT_ARGB8888:
> - case DRM_FORMAT_ARGB1555:
> - case DRM_FORMAT_ARGB4444:
> - return true;
> - default:
> - return false;
> - }
> -}
> -
> static inline u32 vp_reg_read(struct mixer_context *ctx, u32 reg_id)
> {
> return readl(ctx->vp_regs + reg_id);
> @@ -625,7 +613,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
> mixer_reg_write(ctx, MXR_GRAPHIC_BASE(win), dma_addr);
>
> mixer_cfg_layer(ctx, win, priority, true);
> - mixer_cfg_gfx_blend(ctx, win, is_alpha_format(fb->format->format));
> + mixer_cfg_gfx_blend(ctx, win, drm_format_has_alpha(fb->format->format));
>
> /* layer update mandatory for mixer 16.0.33.0 */
> if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
>
^ permalink raw reply
* PM regression in next
From: Tony Lindgren @ 2018-01-12 1:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111164537.79165ac8918e6d38e1837062@linux-foundation.org>
* Andrew Morton <akpm@linux-foundation.org> [180112 00:45]:
> On Thu, 11 Jan 2018 16:23:22 -0800 Tony Lindgren <tony@atomide.com> wrote:
>
> > * Andrew Morton <akpm@linux-foundation.org> [180112 00:18]:
> > > On Thu, 11 Jan 2018 16:01:13 -0800 Tony Lindgren <tony@atomide.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > I'm seeing a considerable idle power consumption regression in
> > > > Linux next, with power consumption for my idle test system going
> > > > to 17.5mW compared to the usual 8mW on my test device.
> > > >
> > > > Git bisect points to merge commit e130bc1d00a4 ("Merge branch
> > > > 'akpm-current/current'") being the first bad commit.
> > > >
> > > > I have also verified that commit 70286688e5ad ("ipc/mqueue.c:
> > > > have RT tasks queue in by priority in wq_add()") is good, and
> > > > commit e2d7fe89e8ae ("Merge remote-tracking branch
> > > > 'init_task/init_task'") is good.
> > >
> > > Do you mean that everything up to and including 70286688e5ad
> > > ("ipc/mqueue.c: have RT tasks queue in by priority in wq_add()") is
> > > good?
> >
> > Yes I'm not seeing the regression in your branch at commit
> > 70286688e5ad. I'm seeing it only with the merge commit
> > e130bc1d00a4.
> >
>
> That's weird. All I'm seeing between 70286688e5ad and end-of-mm is:
>
> tools-objtool-makefile-dont-assume-sync-checksh-is-executable.patch
> ipc-mqueue-add-missing-error-code-in-init_mqueue_fs.patch
>
> vfs-remove-might_sleep-from-clear_inode.patch
>
> mm-remove-duplicate-includes.patch
>
> mm-remove-unneeded-kallsyms-include.patch
> hrtimer-remove-unneeded-kallsyms-include.patch
> genirq-remove-unneeded-kallsyms-include.patch
>
> mm-memblock-memblock_is_map-region_memory-can-be-boolean.patch
> lib-lockref-__lockref_is_dead-can-be-boolean.patch
> kernel-cpuset-current_cpuset_is_being_rebound-can-be-boolean.patch
> kernel-resource-iomem_is_exclusive-can-be-boolean.patch
> kernel-module-module_is_live-can-be-boolean.patch
> kernel-mutex-mutex_is_locked-can-be-boolean.patch
> crash_dump-is_kdump_kernel-can-be-boolean.patch
>
> fix-const-confusion-in-certs-blacklist.patch
> fix-read-buffer-overflow-in-delta-ipc.patch
>
> kasan-rework-kconfig-settings.patch
>
> sparc64-ng4-memset-32-bits-overflow.patch
>
> lib-crc-ccitt-add-ccitt-false-crc16-variant.patch
Well there are some changes in merge commit e130bc1d00a4..
> And I don't see how any of those can cause this. Did anything else
> change, like context switch rates, interrupt rates, etc?
Well I tried to measure suspend power consumption and noticed
that system suspend fails too hand hangs the network device:
# echo mem > /sys/power/state
[ 32.577850] PM: suspend entry (deep)
[ 32.582031] PM: Syncing filesystems ... done.
[ 32.598083] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 32.608398] OOM killer disabled.
[ 32.611846] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
[ 32.622192] Suspending console(s) (use no_console_suspend to debug)
[ 32.651123] dpm_run_callback(): mdio_bus_suspend+0x0/0x24 returns 4352
[ 32.651428] PM: Device 2c000000.ethernet-ffffffff:01 failed to suspend: error 4352
[ 32.653289] PM: Some devices failed to suspend, or early wake event detected
[ 32.685455] OOM killer enabled.
[ 32.688629] Restarting tasks ... done.
[ 32.695983] PM: suspend exit
ash: write error: Bad address
That too works just fine at commit 70286688e5ad.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/9] iommu/of: Drop early initialisation hooks
From: JeffyChen @ 2018-01-12 1:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <faeccc75-79e9-ddb6-446d-88ab63fe4e1f@arm.com>
Hi Robin,
Thnaks for your reply.
On 01/11/2018 08:24 PM, Robin Murphy wrote:
> Hi Jeffy,
>
> On 11/01/18 11:14, JeffyChen wrote:
>> Hi Marek,
>>
>> Thanks for your reply.
>>
>> On 01/11/2018 05:40 PM, Marek Szyprowski wrote:
>>> Hi Jeffy,
>>>
>>> On 2018-01-11 09:22, Jeffy Chen wrote:
>>>> With the probe-deferral mechanism, early initialisation hooks are no
>>>> longer needed.
>>>>
>>>> Suggested-by: Robin Murphy <robin.murphy@arm.com>
>
> In fact, shortly after I said that I had a "how hard can it be?" moment
> and took a crack at it myself - sorry, I should probably have cc'd you
> on that series[1].
hmmm, i'll drop this patch in the next version.
and maybe rebase my patch[9] (iommu/rockchip: Use OF_IOMMU to attach
devices automatically) on that series
>
>>>> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
>>>> ---
>>>>
>>>> drivers/iommu/arm-smmu-v3.c | 2 +-
>>>> drivers/iommu/arm-smmu.c | 12 ++++++------
>>>> drivers/iommu/exynos-iommu.c | 2 +-
>>>
>>> For Exynos IOMMU:
>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>
>>> IPMMU and MSM IOMMU are no longer multi-platform safe after this patch.
>>> It breaks them in the same way as my commit 928055a01b3f ("iommu/exynos:
>>> Remove custom platform device registration code") broke Exynos IOMMU.
>>>
>>> You need a similar fix for them:
>>> https://www.spinics.net/lists/arm-kernel/msg627648.html
>>
>> hmmm, right, i did saw this fix in the rockchip iommu driver too.
>>
>> and there're also some other iommu drivers put bus_set_iommu in their
>> probe() to avoid that.
>>
>> maybe we can do it in the iommu framework?
>>
>> for example:
>> 1/ add a bus type member to struct iommu_device
>> 2/ and a iommu_device_set_bus()
>> 3/ do the bus_set_iommu stuff in iommu_device_register()
>> 4/ undo bus_set_iommu in iommu_device_unregister()
>
> Ultimately we'd like to get rid of the bus relationship altogether, so I
> don't think it's really worth adding more infrastructure around it.
> Having of-iommu-based drivers set bus ops at probe time, and others
> conditionally from an initcall, is pretty clean and simple, so I'd
> rather stick with that approach for now.
ok, make sense:)
>
> Robin.
>
> [1]
> https://lists.linuxfoundation.org/pipermail/iommu/2018-January/025395.html
>
>
>
^ permalink raw reply
* [PATCH v4 1/8] ARM: l2c: move cache-aurora-l2.h to asm/hardware
From: Chris Packham @ 2018-01-12 1:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112012755.20495-1-chris.packham@alliedtelesis.co.nz>
From: Jan Luebbe <jlu@pengutronix.de>
This include file will be used by the AURORA EDAC code.
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/{mm => include/asm/hardware}/cache-aurora-l2.h | 0
arch/arm/mm/cache-l2x0.c | 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename arch/arm/{mm => include/asm/hardware}/cache-aurora-l2.h (100%)
diff --git a/arch/arm/mm/cache-aurora-l2.h b/arch/arm/include/asm/hardware/cache-aurora-l2.h
similarity index 100%
rename from arch/arm/mm/cache-aurora-l2.h
rename to arch/arm/include/asm/hardware/cache-aurora-l2.h
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 808efbb89b88..a00d6f7fd34c 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -30,8 +30,8 @@
#include <asm/cp15.h>
#include <asm/cputype.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/hardware/cache-aurora-l2.h>
#include "cache-tauros3.h"
-#include "cache-aurora-l2.h"
struct l2c_init_data {
const char *type;
--
2.15.1
^ permalink raw reply related
* [PATCH v4 2/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
From: Chris Packham @ 2018-01-12 1:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112012755.20495-1-chris.packham@alliedtelesis.co.nz>
From: Jan Luebbe <jlu@pengutronix.de>
The macro name is too generic, so add a AURORA_ prefix.
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-
arch/arm/mm/cache-l2x0.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h b/arch/arm/include/asm/hardware/cache-aurora-l2.h
index c86124769831..dc5c479ec4c3 100644
--- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
+++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
@@ -41,7 +41,7 @@
#define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
(2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
-#define MAX_RANGE_SIZE 1024
+#define AURORA_MAX_RANGE_SIZE 1024
#define AURORA_WAY_SIZE_SHIFT 2
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index a00d6f7fd34c..7d2d2a3c67d0 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1364,8 +1364,8 @@ static unsigned long aurora_range_end(unsigned long start, unsigned long end)
* since cache range operations stall the CPU pipeline
* until completion.
*/
- if (end > start + MAX_RANGE_SIZE)
- end = start + MAX_RANGE_SIZE;
+ if (end > start + AURORA_MAX_RANGE_SIZE)
+ end = start + AURORA_MAX_RANGE_SIZE;
/*
* Cache range operations can't straddle a page boundary.
--
2.15.1
^ permalink raw reply related
* [PATCH v4 3/8] ARM: aurora-l2: add defines for parity and ECC registers
From: Chris Packham @ 2018-01-12 1:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112012755.20495-1-chris.packham@alliedtelesis.co.nz>
From: Jan Luebbe <jlu@pengutronix.de>
These defines will be used by subsequent patches to add support for the
parity check and error correction functionality in the Aurora L2 cache
controller.
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
[cp: use shorter names for some #defines]
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
arch/arm/include/asm/hardware/cache-aurora-l2.h | 48 +++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h b/arch/arm/include/asm/hardware/cache-aurora-l2.h
index dc5c479ec4c3..39769ffa0051 100644
--- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
+++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
@@ -31,6 +31,9 @@
#define AURORA_ACR_REPLACEMENT_TYPE_SEMIPLRU \
(3 << AURORA_ACR_REPLACEMENT_OFFSET)
+#define AURORA_ACR_PARITY_EN (1 << 21)
+#define AURORA_ACR_ECC_EN (1 << 20)
+
#define AURORA_ACR_FORCE_WRITE_POLICY_OFFSET 0
#define AURORA_ACR_FORCE_WRITE_POLICY_MASK \
(0x3 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
@@ -41,6 +44,51 @@
#define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
(2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
+#define AURORA_ERR_CNT_REG 0x600
+#define AURORA_ERR_ATTR_CAP_REG 0x608
+#define AURORA_ERR_ADDR_CAP_REG 0x60c
+#define AURORA_ERR_WAY_CAP_REG 0x610
+#define AURORA_ERR_INJECT_CTL_REG 0x614
+#define AURORA_ERR_INJECT_MASK_REG 0x618
+
+#define AURORA_ERR_CNT_CLR_OFFSET 31
+#define AURORA_ERR_CNT_CLR \
+ (0x1 << AURORA_ERR_CNT_CLR_OFFSET)
+#define AURORA_ERR_CNT_UE_OFFSET 16
+#define AURORA_ERR_CNT_UE_MASK \
+ (0x7fff << AURORA_ERR_CNT_UE_OFFSET)
+#define AURORA_ERR_CNT_CE_OFFSET 0
+#define AURORA_ERR_CNT_CE_MASK \
+ (0xffff << AURORA_ERR_CNT_CE_OFFSET)
+
+#define AURORA_ERR_ATTR_SRC_OFF 16
+#define AURORA_ERR_ATTR_SRC_MSK \
+ (0x7 << AURORA_ERR_ATTR_SRC_OFF)
+#define AURORA_ERR_ATTR_TXN_OFF 12
+#define AURORA_ERR_ATTR_TXN_MSK \
+ (0xf << AURORA_ERR_ATTR_TXN_OFF)
+#define AURORA_ERR_ATTR_ERR_OFF 8
+#define AURORA_ERR_ATTR_ERR_MSK \
+ (0x3 << AURORA_ERR_ATTR_ERR_OFF)
+#define AURORA_ERR_ATTR_CAP_VALID_OFF 0
+#define AURORA_ERR_ATTR_CAP_VALID \
+ (0x1 << AURORA_ERR_ATTR_CAP_VALID_OFF)
+
+#define AURORA_ERR_ADDR_CAP_ADDR_MASK 0xffffffe0
+
+#define AURORA_ERR_WAY_IDX_OFF 8
+#define AURORA_ERR_WAY_IDX_MSK \
+ (0xfff << AURORA_ERR_WAY_IDX_OFF)
+#define AURORA_ERR_WAY_CAP_WAY_OFFSET 1
+#define AURORA_ERR_WAY_CAP_WAY_MASK \
+ (0xf << AURORA_ERR_WAY_CAP_WAY_OFFSET)
+
+#define AURORA_ERR_INJECT_CTL_ADDR_MASK 0xfffffff0
+#define AURORA_ERR_ATTR_TXN_OFF 12
+#define AURORA_ERR_INJECT_CTL_EN_MASK 0x3
+#define AURORA_ERR_INJECT_CTL_EN_PARITY 0x2
+#define AURORA_ERR_INJECT_CTL_EN_ECC 0x1
+
#define AURORA_MAX_RANGE_SIZE 1024
#define AURORA_WAY_SIZE_SHIFT 2
--
2.15.1
^ permalink raw reply related
* [PATCH v4 4/8] ARM: l2x0: support parity-enable/disable on aurora
From: Chris Packham @ 2018-01-12 1:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112012755.20495-1-chris.packham@alliedtelesis.co.nz>
The aurora cache on the Marvell Armada-XP SoC supports the same tag
parity features as the other l2x0 cache implementations.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
[jlu at pengutronix.de: use aurora specific define AURORA_ACR_PARITY_EN]
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
---
arch/arm/mm/cache-l2x0.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 7d2d2a3c67d0..b70bee74750d 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1505,6 +1505,13 @@ static void __init aurora_of_parse(const struct device_node *np,
mask |= AURORA_ACR_FORCE_WRITE_POLICY_MASK;
}
+ if (of_property_read_bool(np, "arm,parity-enable")) {
+ mask |= AURORA_ACR_PARITY_EN;
+ val |= AURORA_ACR_PARITY_EN;
+ } else if (of_property_read_bool(np, "arm,parity-disable")) {
+ mask |= AURORA_ACR_PARITY_EN;
+ }
+
*aux_val &= ~mask;
*aux_val |= val;
*aux_mask &= ~mask;
--
2.15.1
^ permalink raw reply related
* [PATCH v4 5/8] ARM: l2x0: add marvell,ecc-enable property for aurora
From: Chris Packham @ 2018-01-12 1:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112012755.20495-1-chris.packham@alliedtelesis.co.nz>
The aurora cache on the Marvell Armada-XP SoC supports ECC protection
for the L2 data arrays. Add a "marvell,ecc-enable" device tree property
which can be used to enable this.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
[jlu at pengutronix.de: use aurora specific define AURORA_ACR_ECC_EN]
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
---
Documentation/devicetree/bindings/arm/l2c2x0.txt | 2 ++
arch/arm/mm/cache-l2x0.c | 7 +++++++
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/l2c2x0.txt b/Documentation/devicetree/bindings/arm/l2c2x0.txt
index fbe6cb21f4cf..15a84f0ba9f1 100644
--- a/Documentation/devicetree/bindings/arm/l2c2x0.txt
+++ b/Documentation/devicetree/bindings/arm/l2c2x0.txt
@@ -76,6 +76,8 @@ Optional properties:
specified to indicate that such transforms are precluded.
- arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
- arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
+- marvell,ecc-enable : enable ECC protection on the L2 cache
+- marvell,ecc-disable : disable ECC protection on the L2 cache
- arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
will randomly hang unless outer sync operations are disabled.
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index b70bee74750d..644f786e4fa9 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1505,6 +1505,13 @@ static void __init aurora_of_parse(const struct device_node *np,
mask |= AURORA_ACR_FORCE_WRITE_POLICY_MASK;
}
+ if (of_property_read_bool(np, "marvell,ecc-enable")) {
+ mask |= AURORA_ACR_ECC_EN;
+ val |= AURORA_ACR_ECC_EN;
+ } else if (of_property_read_bool(np, "marvell,ecc-disable")) {
+ mask |= AURORA_ACR_ECC_EN;
+ }
+
if (of_property_read_bool(np, "arm,parity-enable")) {
mask |= AURORA_ACR_PARITY_EN;
val |= AURORA_ACR_PARITY_EN;
--
2.15.1
^ permalink raw reply related
* [GIT PULL] ARM64: Xilinx ZynqMP SoC patches for v4.16
From: Olof Johansson @ 2018-01-12 1:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <84cfd3d5-f0e7-23dc-0e33-430a1f2dbdb0@monstr.eu>
On Mon, Jan 08, 2018 at 02:02:18PM +0100, Michal Simek wrote:
> Hi guys,
>
> please consider to pull these 3 patches to your tree. I have discussed
> it with Arnd that this could be probably fine even it is a little bit late.
>
> Thanks,
> Michal
>
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> https://github.com/Xilinx/linux-xlnx.git tags/zynqmp-soc-for-4.16
>
> for you to fetch changes up to cee8113a295acfc4cd25728d7c3d44e6bc3bbff9:
>
> soc: xilinx: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver
> (2018-01-08 13:42:47 +0100)
>
> ----------------------------------------------------------------
> arm: Xilinx ZynqMP SoC patches for v4.16
>
> - Create drivers/soc/xilinx folder structure
> - Add ZynqMP vcu init driver
>
> ----------------------------------------------------------------
> Dhaval Shah (2):
> dt-bindings: soc: xilinx: Add DT bindings to xlnx_vcu driver
> soc: xilinx: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver
>
> Michal Simek (1):
> soc: xilinx: Create folder structure for soc specific drivers
>
Merged, but you should probably add a platform config option for Xilinx
and use that instead of obj-y to descend into the directory?
-Olof
^ permalink raw reply
* PM regression in next
From: Tony Lindgren @ 2018-01-12 1:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112012019.GA4059@atomide.com>
* Tony Lindgren <tony@atomide.com> [180111 17:20]:
> Well I tried to measure suspend power consumption and noticed
> that system suspend fails too hand hangs the network device:
>
> # echo mem > /sys/power/state
> [ 32.577850] PM: suspend entry (deep)
> [ 32.582031] PM: Syncing filesystems ... done.
> [ 32.598083] Freezing user space processes ... (elapsed 0.002 seconds) done.
> [ 32.608398] OOM killer disabled.
> [ 32.611846] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
> [ 32.622192] Suspending console(s) (use no_console_suspend to debug)
> [ 32.651123] dpm_run_callback(): mdio_bus_suspend+0x0/0x24 returns 4352
> [ 32.651428] PM: Device 2c000000.ethernet-ffffffff:01 failed to suspend: error 4352
> [ 32.653289] PM: Some devices failed to suspend, or early wake event detected
> [ 32.685455] OOM killer enabled.
> [ 32.688629] Restarting tasks ... done.
> [ 32.695983] PM: suspend exit
> ash: write error: Bad address
>
> That too works just fine at commit 70286688e5ad.
Suspend fails at commit e2d7fe89e8ae though, so looks like we
have two separate issues. I'll try to bisect that separately.
Regards,
Tony
^ permalink raw reply
* [GIT PULL] TI DaVinci SoC updates for v4.16 (part 2)
From: Olof Johansson @ 2018-01-12 1:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110112505.13633-1-nsekhar@ti.com>
On Wed, Jan 10, 2018 at 04:55:05PM +0530, Sekhar Nori wrote:
> The following changes since commit 23bbeaef90ab7607d03428bbb708efe44f43c761:
>
> ARM: davinci: constify gpio_led (2018-01-05 19:28:41 +0530)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.16/soc-p2
>
> for you to fetch changes up to 0808d3260456aaba061fe06ead31d578c8bdc936:
>
> ARM: davinci: remove watchdog reset (2018-01-10 14:38:07 +0530)
>
> ----------------------------------------------------------------
> A patch to shift to using watchdog timer for DaVinci restart functionality.
> The driver support is present in linux-next as 71d1f058844d "watchdog:
> davinci_wdt: add restart function"
Hi,
So if this is merged before the driver is merged, what happens? Might
be better to hold off a release to avoid regressions?
-Olof
^ permalink raw reply
* [GIT PULL 3/4] soc: samsung: Stuff for v4.16
From: Olof Johansson @ 2018-01-12 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180107113625.15488-2-krzk@kernel.org>
On Sun, Jan 07, 2018 at 12:36:22PM +0100, Krzysztof Kozlowski wrote:
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-4.16-2
>
> for you to fetch changes up to 06512c539ff1d6d008d5e8ab9d6f5f6405972f53:
>
> soc: samsung: Add SPDX license identifiers (2018-01-03 18:45:15 +0100)
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCH -next] IIO: ADC: fix return value check in stm32_dfsdm_adc_probe()
From: weiyongjun (A) @ 2018-01-12 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111212837.minmnjkvhudstafs@mwanda>
>
> On Thu, Jan 11, 2018 at 11:12:41AM +0000, Wei Yongjun wrote:
> > In case of error, the function devm_iio_device_alloc() returns NULL
> > pointer not ERR_PTR(). The IS_ERR() test in the return value check
> > should be replaced with NULL test.
> >
> > Fixes: e2e6771c6462 ("IIO: ADC: add STM32 DFSDM sigma delta ADC
> support")
> > Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> > ---
> > drivers/iio/adc/stm32-dfsdm-adc.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-
> dfsdm-adc.c
> > index e628d04..5e87140 100644
> > --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> > +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> > @@ -1100,9 +1100,9 @@ static int stm32_dfsdm_adc_probe(struct
> platform_device *pdev)
> > dev_data = (const struct stm32_dfsdm_dev_data *)of_id->data;
> >
> > iio = devm_iio_device_alloc(dev, sizeof(*adc));
> > - if (IS_ERR(iio)) {
> > + if (!iio) {
> > dev_err(dev, "%s: Failed to allocate IIO\n", __func__);
> > - return PTR_ERR(iio);
> > + return -ENOMEM;
> > }
> >
> > adc = iio_priv(iio);
> ^^^^^^^^^^^^^^^^^^
> This one doesn't return an error pointer either. The check causes a
> static check warning for me. (It can't actually fail, though so maybe
> it will return an error pointer in the future?)
It seems that we can simply remove the check since 'adc' can never
be an invalid address here.
Regards,
Yongjun Wei
^ permalink raw reply
* [GIT PULL 1/4] ARM: dts: exynos: Stuff for v4.16, 2nd round
From: Olof Johansson @ 2018-01-12 1:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180107113625.15488-3-krzk@kernel.org>
On Sun, Jan 07, 2018 at 12:36:23PM +0100, Krzysztof Kozlowski wrote:
> Hi,
>
> On top of previous pull request.
>
> Best regards,
> Krzysztof
>
>
> The following changes since commit 3be1ecf291df8191f5ea395d363acc8fa029b5fd:
>
> ARM: dts: exynos: Use lower case hex addresses in node unit addresses (2017-12-18 18:15:51 +0100)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.16-2
>
> for you to fetch changes up to 5628a8ca14149ba4226e3bdce3a04c3b688435ad:
>
> ARM: dts: exynos: fix RTC interrupt for exynos5410 (2018-01-07 11:15:59 +0100)
>
> ----------------------------------------------------------------
> Samsung DTS ARM changes for 4.16, part 2
>
> 1. Add SPDX license identifiers.
> 2. Properly fix DTC warning for PMU/RTC interrupts on Exynos5410.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 2/4] arm64: dts: exynos: Stuff for v4.16, 2nd round
From: Olof Johansson @ 2018-01-12 1:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180107113625.15488-4-krzk@kernel.org>
On Sun, Jan 07, 2018 at 12:36:24PM +0100, Krzysztof Kozlowski wrote:
> Hi,
>
> On top of previous pull request.
>
> Best regards,
> Krzysztof
>
>
> The following changes since commit 3808354701090723b53c73afaccfcafdeb8a5bfe:
>
> arm64: dts: exynos: Increase bus frequency for MHL chip (2017-12-04 17:51:10 +0100)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.16-2
>
> for you to fetch changes up to 45fef752126603d591754befa63d0a800492eb6c:
>
> arm64: dts: exynos: Add SPDX license identifiers (2018-01-03 18:16:35 +0100)
>
> ----------------------------------------------------------------
> Samsung DTS ARM64 changes for v4.16, part 2
>
> 1. Fix DTC warnings around unit addresses.
> 2. Add SPDX license identifiers.
>
> ----------------------------------------------------------------
> Krzysztof Kozlowski (3):
> arm64: dts: exynos: Use lower case hex addresses in node unit addresses
> arm64: dts: exynos: Fix typo in MSCL clock controller unit address of Exynos5433
> arm64: dts: exynos: Add SPDX license identifiers
Merged, thanks.
-Olof
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v5 2/2] media: V3s: Add support for Allwinner CSI.
From: Yong @ 2018-01-12 1:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111132844.mok7upqjycpx3bqm@flea.lan>
Hi Maxime,
On Thu, 11 Jan 2018 14:28:44 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> Hi Yong,
>
> On Thu, Jan 11, 2018 at 11:06:06AM +0800, Yong Deng wrote:
> > Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
> > interface and CSI1 is used for parallel interface. This is not
> > documented in datasheet but by test and guess.
> >
> > This patch implement a v4l2 framework driver for it.
> >
> > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > ISP's support are not included in this patch.
> >
> > Signed-off-by: Yong Deng <yong.deng@magewell.com>
>
> I've needed this patch in order to fix a NULL pointer dereference:
> http://code.bulix.org/oz6gmb-257359?raw
>
> This is needed because while it's ok to have a NULL pointer to
> v4l2_subdev_pad_config when you call the subdev set_fmt with
> V4L2_SUBDEV_FORMAT_ACTIVE, it's not with V4L2_SUBDEV_FORMAT_TRY, and
> sensors will assume taht it's a valid pointer.
>
> Otherwise,
> Tested-by: Maxime Ripard <maxime.ripard@free-electrons.com>
I revisit some code of subdevs and you are right.
Squash your patch into my driver patch and add your Tested-by in
commit. Is it right?
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Thanks,
Yong
^ permalink raw reply
* [GIT PULL 4/4] ARM: exynos/samsung: Stuff for v4.16
From: Olof Johansson @ 2018-01-12 1:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180107113625.15488-5-krzk@kernel.org>
On Sun, Jan 07, 2018 at 12:36:25PM +0100, Krzysztof Kozlowski wrote:
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-4.16-2
>
> for you to fetch changes up to 4490e3c688d9e409a98189a6ea08bc2823d452e2:
>
> ARM: SAMSUNG: Add SPDX license identifiers (2018-01-03 18:43:13 +0100)
>
> ----------------------------------------------------------------
> Samsung mach/soc changes for v4.16
>
> Add SPDX license identifiers.
>
> ----------------------------------------------------------------
> Krzysztof Kozlowski (5):
> ARM: EXYNOS: Add SPDX license identifiers
> ARM: S3C24XX: Add SPDX license identifiers
> ARM: S3C64XX: Add SPDX license identifiers
> ARM: S5PV210: Add SPDX license identifiers
> ARM: SAMSUNG: Add SPDX license identifiers
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCH] arm64: dts: socfpga: add missing interrupt-parent
From: Olof Johansson @ 2018-01-12 1:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e3a44268-88f2-3dbd-a992-f9484a82d826@kernel.org>
On Thu, Jan 11, 2018 at 08:35:58AM -0600, Dinh Nguyen wrote:
>
>
> On 01/10/2018 03:04 PM, Arnd Bergmann wrote:
> > The PMU node has no working interrupt, as shown by this dtc warning:
> >
> > arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu
> >
> > This adds an interrupt-parent property so we can correct parse
> > that interrupt number.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > If this looks ok, I'd apply it directly to the fixes branch
> > for 4.15, as the warning is one that was introduced in this
> > release.
>
> Acked-by: Dinh Nguyen <dinguyen@kernel.org>
>
> Yes, please feel free to apply it. And thanks alot!
Applied.
-Olof
^ permalink raw reply
* [PATCH] arm64: dts: add #cooling-cells to CPU nodes
From: Olof Johansson @ 2018-01-12 2:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515631110.19513.5.camel@mhfsdcap03>
On Thu, Jan 11, 2018 at 08:38:30AM +0800, Chunfeng Yun wrote:
> On Wed, 2018-01-10 at 22:06 +0100, Arnd Bergmann wrote:
> > dtc complains about the lack of #coolin-cells properties for the
> > CPU nodes that are referred to as "cooling-device":
> >
> > arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning (cooling_device_property): Missing property '#cooling-cells' in node /cpus/cpu at 0 or bad phandle (referred from /thermal-zones/cpu_thermal/cooling-maps/map at 0:cooling-device[0])
> > arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning (cooling_device_property): Missing property '#cooling-cells' in node /cpus/cpu at 100 or bad phandle (referred from /thermal-zones/cpu_thermal/cooling-maps/map at 1:cooling-device[0])
> >
> > Apparently this property must be '<2>' to match the binding.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > If this looks ok, I'd apply it directly to the fixes branch
> > for 4.15, as the warning is one that was introduced in this
> > release.
Actually, it's in next/dt (or at least this patch doesn't apply as it is to
fixes), so I've added it there.
-Olof
^ permalink raw reply
* [GIT PULL] updates to soc/fsl drivers for v4.16
From: Olof Johansson @ 2018-01-12 2:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515628596-4715-1-git-send-email-leoyang.li@nxp.com>
On Wed, Jan 10, 2018 at 05:56:36PM -0600, Li Yang wrote:
> Hi arm-soc maintainer,
>
> Please merge the following tag to get updates to the soc/fsl/guts driver
> for support of additional SoCs and more error path handling.
>
> Thanks,
> Leo
>
>
> The following changes since commit b2cd1df66037e7c4697c7e40496bf7e4a5e16a2d:
>
> Linux 4.15-rc7 (2018-01-07 14:22:41 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git tags/soc-fsl-for-4.16
>
> for you to fetch changes up to 00ce0a2304014c73c2b7915215c7b3c73e2a25aa:
>
> soc: fsl: guts: Add a NULL check for devm_kasprintf() (2018-01-10 16:54:26 -0600)
1) This is based on much too new a release
2) the fact that it's based on this new a release makes me suspect it hasn't
been sitting in linux-next either, at least not since before -rc7.
Conclusion: Please resend post merge window and we'll queue it up for the
next release. If the bugfix should go in sooner than that, I can cherry-pick
that into our fixes. Let me know.
-Olof
^ permalink raw reply
* [GIT PULL] tee dynamic shm fixes for v4.16
From: Olof Johansson @ 2018-01-12 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111124456.2fziqy4sdxq5wdlz@jax>
On Thu, Jan 11, 2018 at 01:44:56PM +0100, Jens Wiklander wrote:
> Hello arm-soc maintainers,
>
> Please pull these fixes for the previous tee-drv-dynamic-shm-for-v4.16
> pull request that is currently kept in the drivers/tee-2 branch in the
> arm-soc git.
>
> This pull request addresses the question about registering memory that
> isn't regular memory. I posted those patches some time ago with no feedback
> so far.
>
> There's also three small fixes to the dynamic shm patches that I've
> picked up from the mailing lists.
>
> Thanks,
> Jens
>
>
> The following changes since commit ef8e08d24ca84846ce639b835ebd2f15a943f42b:
>
> tee: shm: inline tee_shm_get_id() (2017-12-15 13:36:21 +0100)
>
> are available in the git repository at:
>
> https://git.linaro.org/people/jens.wiklander/linux-tee.git tee-drv-dynamic-shm+fixes-for-v4.16
>
> for you to fetch changes up to 2490cdf6435b1d3cac0dbf710cd752487c67c296:
>
> tee: shm: Potential NULL dereference calling tee_shm_register() (2018-01-09 14:34:00 +0100)
>
> ----------------------------------------------------------------
> This pull request updates the previous tee-drv-dynamic-shm-for-v4.16 pull
> request with five new patches fixing review comments and errors.
>
> Apart from three small fixes there's two larger patches that in the end
> checks that memory to be registered really is normal cached memory.
Merged into next/drivers. I noticed git.linaro.org is really slow though,
maybe you should look into getting a kernel.org account instead? It took about
a minute for the pull request to complete.
-Olof
^ permalink raw reply
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