* PM regression in next
From: Andrew Morton @ 2018-01-12 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112000037.GA3875@atomide.com>
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?
^ permalink raw reply
* PM regression in next
From: Tony Lindgren @ 2018-01-12 0:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111161837.f1c1d891a1b80d97e30a9b1b@linux-foundation.org>
* 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.
Regards,
Tony
^ permalink raw reply
* [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Jae Hyun Yoo @ 2018-01-12 0:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111235346.GA13443@lunn.ch>
On 1/11/2018 3:53 PM, Andrew Lunn wrote:
> On Thu, Jan 11, 2018 at 03:14:37PM -0800, Jae Hyun Yoo wrote:
>> On 1/11/2018 2:18 PM, Andrew Lunn wrote:
>>>>>>> +static const struct of_device_id peci_of_table[] = {
>>>>>>> + { .compatible = "peci-hwmon", },
>>>>>>
>>>>>> This does not look like a reference to some piece of hardware.
>>>>>>
>>>>>
>>>>> This driver provides generic PECI hwmon function to which controller has
>>>>> PECI HW such as Aspeed or Nuvoton BMC chip so it's not dependant on a
>>>>> specific hardware. Should I remove this or any suggestion?
>>>
>>> PECI seems to be an Intel thing. So at least it should be
>>>
>>> { .compatible = "intel,peci-hwmon", }
>>>
>>> assuming it is actually compatible with the Intel specification.
>>>
>>> Andrew
>>>
>>
>> Yes, PECI is an Intel thing but this driver is running on an ARM kernel on
>> Aspeed or Nuvoton chipsets for now. This driver will be monitoring a host
>> server's Intel CPU and DIMM which is running on a separated OS.
>
> Hi Jae
>
> You need to be careful with the name then. You should not claim the
> name 'peci' in case somebody actually implements a PECI driver which
> is compatible with Intel PECI.
>
> However, looking at other comments, it seems like this part is going
> away, if you turn your code into a bus driver.
>
> Andrew
>
Hi Andrew,
I see. I'll keep that in mind and will keep finding if there is any
better way. Thanks for sharing your thought.
Jae
^ permalink raw reply
* [PATCH 2/9] iommu/rockchip: Fix error handling in attach
From: JeffyChen @ 2018-01-12 0:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <427ecf29-2024-b746-c567-903c1ce02e75@arm.com>
Hi Robin,
thanks for your reply.
On 01/11/2018 11:47 PM, Robin Murphy wrote:
>>
>> + for (i = 0; i < iommu->num_irq; i++) {
>> + ret = devm_request_irq(iommu->dev, iommu->irq[i], rk_iommu_irq,
>> + IRQF_SHARED, dev_name(dev), iommu);
>
> Why aren't we simply requesting the IRQ once in rk_iommu_probe()? Given
> that the hardware doesn't handle multiple translation contexts, there
> doesn't seem to be much point in being this dynamic about it.
>
it make sense, will do it in next version:)
> Robin.
^ permalink raw reply
* PM regression in next
From: Andrew Morton @ 2018-01-12 0:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112002322.GB3875@atomide.com>
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
And I don't see how any of those can cause this. Did anything else
change, like context switch rates, interrupt rates, etc?
^ permalink raw reply
* [GIT PULL v2 5/5] i.MX defconfig updates for 4.16
From: Olof Johansson @ 2018-01-12 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515209554-21082-1-git-send-email-shawnguo@kernel.org>
On Sat, Jan 06, 2018 at 11:32:34AM +0800, Shawn Guo wrote:
> Changes for v2:
> Drop savedefconfig changes from patch 'ARM: imx_v6_v7_defconfig: enable
> CONFIG_CPU_FREQ_STAT'.
>
> The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36:
>
> Linux 4.15-rc3 (2017-12-10 17:56:26 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-defconfig-4.16
>
> for you to fetch changes up to 495a68d74dfe25f8d441e3493ba447fb1ed209f1:
>
> ARM: imx_v6_v7_defconfig: enable CONFIG_CPU_FREQ_STAT (2018-01-06 10:45:51 +0800)
>
> ----------------------------------------------------------------
> i.MX defconfig updates for 4.16:
> - Enable CPU_FREQ_STAT for cpufreq transtion statistics support.
> - Enable SRTC driver RTC_DRV_MXC_V2 for i.MX53.
> - Turn on a few drivers useful for DART-MX6 SoM support, SERDEV
> bluetooth, SERIAL_DEV_BUS, WL18XX, and DEFAULT_ON LED Trigger.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT changes for v4.16, round 3
From: Olof Johansson @ 2018-01-12 0:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hh8rz25of.fsf@baylibre.com>
On Fri, Jan 05, 2018 at 04:26:40PM -0800, Kevin Hilman wrote:
> Arnd, Olof,
>
> A final round of 64-bit DT changes for Amlogic SoCs.
>
> These were just waiting for the clock dependencies to land in the clock
> tree which they now have. I've merged the same tag into this branch to
> avoid any dependency issues.
>
> Thanks,
Thanks, merged.
-Olof
^ permalink raw reply
* [GIT PULL] Allwinner DT changes for 4.16, step 2
From: Olof Johansson @ 2018-01-12 0:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a09eNwCZbjxxDad8hANmm8m_a_eeGK2bB+1N_Q9152Z1w@mail.gmail.com>
On Fri, Jan 05, 2018 at 05:51:35PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 5, 2018 at 11:22 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi Arnd, Olof,
> >
> > Happy new year :)
> >
> > Here is the second bunch of changes we talked about in our first PR.
> >
> > There's one fix for 4.16, and the other patches have been around for
> > quite a while that I'm feeling confident that we should merge them.
>
> Pulled into next/dt
Looks like this went into fixes instead of next/dt, so I've moved it over.
> > On a side note, my GPG key changed recently. The new fingerprint is
> > 2BA0E943D27E3D2094B10B24D824ECA89C346DCE, and you'll find that it has
> > been signed by a bunch of kernel developpers already. The old one is
> > superseeded, but has not been compromised.
>
> Ok.
Thanks for the heads up!
-Olof
^ permalink raw reply
* [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS
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, BUS_FIXME, TRAP_FIXME siginfo_layout will now return
SIL_FAULT and the appropriate fields will be reliably copied.
But folks this is a new and unique kind of bad. This is massively
untested code bad. This is inventing new and unique was to get
siginfo wrong bad. This is don't even think about Posix or what
siginfo means bad. This is lots of eyeballs all missing the fact
that the code does the wrong thing bad. This is getting stuck
and keep making the same mistake bad.
I really hope we can find a non userspace breaking fix for this on a
port as new as arm64.
Possible ABI fixes include:
- 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: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Tyler Baicar <tbaicar@codeaurora.org>
Cc: James Morse <james.morse@arm.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Nicolas Pitre <nico@linaro.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel at lists.infradead.org
Ref: 53631b54c870 ("arm64: Floating point and SIMD")
Ref: 32015c235603 ("arm64: exception: handle Synchronous External Abort")
Ref: 1d18c47c735e ("arm64: MMU fault handling and page table management")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
arch/arm64/include/uapi/asm/siginfo.h | 21 +++++++
arch/arm64/kernel/fpsimd.c | 2 +-
arch/arm64/mm/fault.c | 114 +++++++++++++++++-----------------
kernel/signal.c | 4 ++
4 files changed, 83 insertions(+), 58 deletions(-)
diff --git a/arch/arm64/include/uapi/asm/siginfo.h b/arch/arm64/include/uapi/asm/siginfo.h
index 574d12f86039..9b4d91277742 100644
--- a/arch/arm64/include/uapi/asm/siginfo.h
+++ b/arch/arm64/include/uapi/asm/siginfo.h
@@ -21,4 +21,25 @@
#include <asm-generic/siginfo.h>
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGBUS si_codes
+ */
+#ifdef __KERNEL__
+#define BUS_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGTRAP si_codes
+ */
+#ifdef __KERNEL__
+#define TRAP_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
#endif
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index fae81f7964b4..ad0edf31e247 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -867,7 +867,7 @@ asmlinkage void do_fpsimd_acc(unsigned int esr, struct pt_regs *regs)
asmlinkage void do_fpsimd_exc(unsigned int esr, struct pt_regs *regs)
{
siginfo_t info;
- unsigned int si_code = 0;
+ unsigned int si_code = FPE_FIXME;
if (esr & FPEXC_IOF)
si_code = FPE_FLTINV;
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 9b7f89df49db..abe200587334 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -596,7 +596,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
info.si_signo = SIGBUS;
info.si_errno = 0;
- info.si_code = 0;
+ info.si_code = BUS_FIXME;
if (esr & ESR_ELx_FnV)
info.si_addr = NULL;
else
@@ -607,70 +607,70 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
}
static const struct fault_info fault_info[] = {
- { do_bad, SIGBUS, 0, "ttbr address size fault" },
- { do_bad, SIGBUS, 0, "level 1 address size fault" },
- { do_bad, SIGBUS, 0, "level 2 address size fault" },
- { do_bad, SIGBUS, 0, "level 3 address size fault" },
+ { do_bad, SIGBUS, BUS_FIXME, "ttbr address size fault" },
+ { do_bad, SIGBUS, BUS_FIXME, "level 1 address size fault" },
+ { do_bad, SIGBUS, BUS_FIXME, "level 2 address size fault" },
+ { do_bad, SIGBUS, BUS_FIXME, "level 3 address size fault" },
{ do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 0 translation fault" },
{ do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 1 translation fault" },
{ do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 2 translation fault" },
{ do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 3 translation fault" },
- { do_bad, SIGBUS, 0, "unknown 8" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 8" },
{ do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 access flag fault" },
{ do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 access flag fault" },
{ do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 access flag fault" },
- { do_bad, SIGBUS, 0, "unknown 12" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 12" },
{ do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 permission fault" },
{ do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 permission fault" },
{ do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 permission fault" },
- { do_sea, SIGBUS, 0, "synchronous external abort" },
- { do_bad, SIGBUS, 0, "unknown 17" },
- { do_bad, SIGBUS, 0, "unknown 18" },
- { do_bad, SIGBUS, 0, "unknown 19" },
- { do_sea, SIGBUS, 0, "level 0 (translation table walk)" },
- { do_sea, SIGBUS, 0, "level 1 (translation table walk)" },
- { do_sea, SIGBUS, 0, "level 2 (translation table walk)" },
- { do_sea, SIGBUS, 0, "level 3 (translation table walk)" },
- { do_sea, SIGBUS, 0, "synchronous parity or ECC error" }, // Reserved when RAS is implemented
- { do_bad, SIGBUS, 0, "unknown 25" },
- { do_bad, SIGBUS, 0, "unknown 26" },
- { do_bad, SIGBUS, 0, "unknown 27" },
- { do_sea, SIGBUS, 0, "level 0 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
- { do_sea, SIGBUS, 0, "level 1 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
- { do_sea, SIGBUS, 0, "level 2 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
- { do_sea, SIGBUS, 0, "level 3 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
- { do_bad, SIGBUS, 0, "unknown 32" },
+ { do_sea, SIGBUS, BUS_FIXME, "synchronous external abort" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 17" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 18" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 19" },
+ { do_sea, SIGBUS, BUS_FIXME, "level 0 (translation table walk)" },
+ { do_sea, SIGBUS, BUS_FIXME, "level 1 (translation table walk)" },
+ { do_sea, SIGBUS, BUS_FIXME, "level 2 (translation table walk)" },
+ { do_sea, SIGBUS, BUS_FIXME, "level 3 (translation table walk)" },
+ { do_sea, SIGBUS, BUS_FIXME, "synchronous parity or ECC error" }, // Reserved when RAS is implemented
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 25" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 26" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 27" },
+ { do_sea, SIGBUS, BUS_FIXME, "level 0 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
+ { do_sea, SIGBUS, BUS_FIXME, "level 1 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
+ { do_sea, SIGBUS, BUS_FIXME, "level 2 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
+ { do_sea, SIGBUS, BUS_FIXME, "level 3 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 32" },
{ do_alignment_fault, SIGBUS, BUS_ADRALN, "alignment fault" },
- { do_bad, SIGBUS, 0, "unknown 34" },
- { do_bad, SIGBUS, 0, "unknown 35" },
- { do_bad, SIGBUS, 0, "unknown 36" },
- { do_bad, SIGBUS, 0, "unknown 37" },
- { do_bad, SIGBUS, 0, "unknown 38" },
- { do_bad, SIGBUS, 0, "unknown 39" },
- { do_bad, SIGBUS, 0, "unknown 40" },
- { do_bad, SIGBUS, 0, "unknown 41" },
- { do_bad, SIGBUS, 0, "unknown 42" },
- { do_bad, SIGBUS, 0, "unknown 43" },
- { do_bad, SIGBUS, 0, "unknown 44" },
- { do_bad, SIGBUS, 0, "unknown 45" },
- { do_bad, SIGBUS, 0, "unknown 46" },
- { do_bad, SIGBUS, 0, "unknown 47" },
- { do_bad, SIGBUS, 0, "TLB conflict abort" },
- { do_bad, SIGBUS, 0, "Unsupported atomic hardware update fault" },
- { do_bad, SIGBUS, 0, "unknown 50" },
- { do_bad, SIGBUS, 0, "unknown 51" },
- { do_bad, SIGBUS, 0, "implementation fault (lockdown abort)" },
- { do_bad, SIGBUS, 0, "implementation fault (unsupported exclusive)" },
- { do_bad, SIGBUS, 0, "unknown 54" },
- { do_bad, SIGBUS, 0, "unknown 55" },
- { do_bad, SIGBUS, 0, "unknown 56" },
- { do_bad, SIGBUS, 0, "unknown 57" },
- { do_bad, SIGBUS, 0, "unknown 58" },
- { do_bad, SIGBUS, 0, "unknown 59" },
- { do_bad, SIGBUS, 0, "unknown 60" },
- { do_bad, SIGBUS, 0, "section domain fault" },
- { do_bad, SIGBUS, 0, "page domain fault" },
- { do_bad, SIGBUS, 0, "unknown 63" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 34" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 35" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 36" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 37" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 38" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 39" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 40" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 41" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 42" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 43" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 44" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 45" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 46" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 47" },
+ { do_bad, SIGBUS, BUS_FIXME, "TLB conflict abort" },
+ { do_bad, SIGBUS, BUS_FIXME, "Unsupported atomic hardware update fault" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 50" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 51" },
+ { do_bad, SIGBUS, BUS_FIXME, "implementation fault (lockdown abort)" },
+ { do_bad, SIGBUS, BUS_FIXME, "implementation fault (unsupported exclusive)" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 54" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 55" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 56" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 57" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 58" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 59" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 60" },
+ { do_bad, SIGBUS, BUS_FIXME, "section domain fault" },
+ { do_bad, SIGBUS, BUS_FIXME, "page domain fault" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 63" },
};
int handle_guest_sea(phys_addr_t addr, unsigned int esr)
@@ -739,11 +739,11 @@ static struct fault_info __refdata debug_fault_info[] = {
{ do_bad, SIGTRAP, TRAP_HWBKPT, "hardware breakpoint" },
{ do_bad, SIGTRAP, TRAP_HWBKPT, "hardware single-step" },
{ do_bad, SIGTRAP, TRAP_HWBKPT, "hardware watchpoint" },
- { do_bad, SIGBUS, 0, "unknown 3" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 3" },
{ do_bad, SIGTRAP, TRAP_BRKPT, "aarch32 BKPT" },
- { do_bad, SIGTRAP, 0, "aarch32 vector catch" },
+ { do_bad, SIGTRAP, TRAP_FIXME, "aarch32 vector catch" },
{ early_brk64, SIGTRAP, TRAP_BRKPT, "aarch64 BRK" },
- { do_bad, SIGBUS, 0, "unknown 7" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 7" },
};
void __init hook_debug_fault_code(int nr,
diff --git a/kernel/signal.c b/kernel/signal.c
index c894162ec96c..fd182a845490 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2711,6 +2711,10 @@ enum siginfo_layout siginfo_layout(int sig, int si_code)
#ifdef FPE_FIXME
if ((sig == SIGFPE) && (si_code == FPE_FIXME))
layout = SIL_FAULT;
+#endif
+#ifdef BUS_FIXME
+ if ((sig == SIGBUS) && (si_code == BUS_FIXME))
+ layout = SIL_FAULT;
#endif
}
return layout;
--
2.14.1
^ permalink raw reply related
* [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
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