* Regression: usb serial gadget on sama5d3 broken
From: Alexandre Belloni @ 2016-10-17 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <621565bc-2fa0-bbd1-80cd-6c9b2a494faa@axentia.se>
On 17/10/2016 at 19:50:48 +0200, Peter Rosin wrote :
> On 2016-10-17 16:54, Nicolas Ferre wrote:
> > Le 17/10/2016 ? 14:53, Peter Rosin a ?crit :
> >> Hi!
> >>
> >> I'm suffering from a regression while using the usb gadget port on the
> >> sama5d3 to get terminal access to the device in question (CONFIG_USB_G_SERIAL).
> >>
> >> I get this message when I try to connect:
> >> udc: ep: Invalid setup request: 02.01 v0000 i0081 l0, halting endpoint...
> >>
> >> A bisect blames commit v4.7-rc1-21-gc32b5bcfa3c4 "ARM: dts: at91: Fix
> >> USB endpoint nodes".
> >>
> >> And indeed, reverting that commit on top of v4.9-rc1 fixes things,
> >> although that doesn't look like the best of fixes...
> >>
> >> BTW, the bisect was extremely painful since v4.7-rc1 seemed broken
> >> somewhere in the overlayfs area. I hope I will never ever need to bisect
> >> in the v4.6..v4.7 area again. This was the second time, the first time
> >> I was chasing a gpio interrupt bug, but I never found out what was wrong
> >> and stopped looking when v4.9-rc1 turned out to be ok even though v4.8
> >> was bad, it was just too painful to look for things that already seemed
> >> fixed.
> >
> > I guess that you are referring to the regression listed here:
> > https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1239220.html
> >
> > The patch is available and will hopefully land in an official kernel
> > soon (4.8.1) as said by Felipe and Greg.
> >
> > Sorry for the inconvenience. Best regards,
>
> Ok, I tried "usb: gadget: udc: atmel: fix endpoint name" and it fixes
> things for me too. But shouldn't the memory for the now dynamic name be
> allocated with devm_kasprintf instead of that plain kasprint? If you
> are pedantic...
>
That wouldn't be a bad idea.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Robert Richter @ 2016-10-17 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006161114.GH22012@rric.localdomain>
Mark, Will, any opinion here?
Thanks,
-Robert
On 06.10.16 18:11:14, Robert Richter wrote:
> Ard,
>
> thank you for your answer and you explanation.
>
> On 06.10.16 11:00:33, Ard Biesheuvel wrote:
> > On 6 October 2016 at 10:52, Robert Richter <rrichter@cavium.com> wrote:
> > > There is a memory setup problem on ThunderX systems with certain
> > > memory configurations. The symptom is
> > >
> > > kernel BUG at mm/page_alloc.c:1848!
> > >
> > > This happens for some configs with 64k page size enabled. The bug
> > > triggers for page zones with some pages in the zone not assigned to
> > > this particular zone. In my case some pages that are marked as nomap
> > > were not reassigned to the new zone of node 1, so those are still
> > > assigned to node 0.
> > >
> > > The reason for the mis-configuration is a change in pfn_valid() which
> > > reports pages marked nomap as invalid:
> > >
> > > 68709f45385a arm64: only consider memblocks with NOMAP cleared for linear mapping
> > >
> >
> > These pages are owned by the firmware, which may map it with
> > attributes that conflict with the attributes we use for the linear
> > mapping. This means they should not be covered by the linear mapping.
> >
> > > This causes pages marked as nomap being no long reassigned to the new
> > > zone in memmap_init_zone() by calling __init_single_pfn().
> > >
> >
> > This sounds like the root cause of your issue. Could we not fix that instead?
>
> Yes, this is proposal b) from my last mail that would work too: I
> implemented an arm64 private early_pfn_valid() function that uses
> memblock_is_memory() to setup all pages of a zone. Though, I think
> this is the wrong way and thus I prefer this patch instead. I see
> serveral reasons for this:
>
> Inconsistent use of struct *page, it is initialized but never used
> again.
>
> Other archs only do a basic range check in pfn_valid(), the default
> implementation just returns if the whole section is valid. As I
> understand the code, if the mem range is not aligned to the section,
> then there will be pfn's in the section that don't have physical mem
> attached. The page is then just initialized, it's not marked reserved
> nor the refcount is non-zero. It is then simply not used. This is how
> no-map pages should be handled too.
>
> I think pfn_valid() is just a quick check if the pfn's struct *page
> can be used. There is a good description for this in include/linux/
> mmzone.h. So there can be memory holes that have a valid pfn.
>
> If the no-map memory needs special handling, then additional checks
> need to be added to the particular code (as in ioremap.c). It's imo
> wrong to (mis-)use pfn_valid for that.
>
> Variant b) involves generic mm code to fix it for arm64, this patch is
> an arm64 change only. This makes it harder to get a fix for it.
> (Though maybe only a problem of patch logistics.)
>
> >
> > > Fixing this by restoring the old behavior of pfn_valid() to use
> > > memblock_is_memory().
> >
> > This is incorrect imo. In general, pfn_valid() means ordinary memory
> > covered by the linear mapping and the struct page array. Returning
> > reserved ranges that the kernel should not even touch only to please
> > the NUMA code seems like an inappropriate way to deal with this issue.
>
> As said above, it is not marked as reserved, it is treated like
> non-existing memory.
>
> This has been observed for non-numa kernels too and can happen for
> each zone that is only partly initialized.
>
> I think the patch addresses your concerns. I can't see there the
> kernel uses memory marked as nomap in a wrong way.
>
> Thanks,
>
> -Robert
>
> >
> > > Also changing users of pfn_valid() in arm64 code
> > > to use memblock_is_map_memory() where necessary. This only affects
> > > code in ioremap.c. The code in mmu.c still can use the new version of
> > > pfn_valid().
> > >
> > > Should be marked stable v4.5..
> > >
> > > Signed-off-by: Robert Richter <rrichter@cavium.com>
> > > ---
> > > arch/arm64/mm/init.c | 2 +-
> > > arch/arm64/mm/ioremap.c | 5 +++--
> > > 2 files changed, 4 insertions(+), 3 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" 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] clk: qoriq: Don't allow CPU clocks higher than starting value
From: Scott Wood @ 2016-10-17 18:42 UTC (permalink / raw)
To: linux-arm-kernel
The boot-time frequency of a CPU is considered its rated maximum, as we
have no other source of such information. However, this was previously
only used for chips with 80% restrictions on secondary PLLs. This
usually wasn't a problem because most chips/configs boot with a divider
of /1, with other dividers being used only for dynamic frequency
reduction. However, at least one config (LS1021A at less than 1 GHz)
uses a different divider for top speed. This was causing cpufreq to set
a frequency beyond the chip's rated speed.
This is fixed by applying a 100%-of-initial-speed limit to all CPU PLLs,
similar to the existing 80% limit that only applied to some.
Signed-off-by: Scott Wood <oss@buserror.net>
Cc: stable at vger.kernel.org
---
drivers/clk/clk-qoriq.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 20b1055..80ae2a5 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -700,6 +700,7 @@ static struct clk * __init create_mux_common(struct clockgen *cg,
struct mux_hwclock *hwc,
const struct clk_ops *ops,
unsigned long min_rate,
+ unsigned long max_rate,
unsigned long pct80_rate,
const char *fmt, int idx)
{
@@ -728,6 +729,8 @@ static struct clk * __init create_mux_common(struct clockgen *cg,
continue;
if (rate < min_rate)
continue;
+ if (rate > max_rate)
+ continue;
parent_names[j] = div->name;
hwc->parent_to_clksel[j] = i;
@@ -759,7 +762,7 @@ static struct clk * __init create_one_cmux(struct clockgen *cg, int idx)
struct mux_hwclock *hwc;
const struct clockgen_pll_div *div;
unsigned long plat_rate, min_rate;
- u64 pct80_rate;
+ u64 max_rate, pct80_rate;
u32 clksel;
hwc = kzalloc(sizeof(*hwc), GFP_KERNEL);
@@ -787,8 +790,8 @@ static struct clk * __init create_one_cmux(struct clockgen *cg, int idx)
return NULL;
}
- pct80_rate = clk_get_rate(div->clk);
- pct80_rate *= 8;
+ max_rate = clk_get_rate(div->clk);
+ pct80_rate = max_rate * 8;
do_div(pct80_rate, 10);
plat_rate = clk_get_rate(cg->pll[PLATFORM_PLL].div[PLL_DIV1].clk);
@@ -798,7 +801,7 @@ static struct clk * __init create_one_cmux(struct clockgen *cg, int idx)
else
min_rate = plat_rate / 2;
- return create_mux_common(cg, hwc, &cmux_ops, min_rate,
+ return create_mux_common(cg, hwc, &cmux_ops, min_rate, max_rate,
pct80_rate, "cg-cmux%d", idx);
}
@@ -813,7 +816,7 @@ static struct clk * __init create_one_hwaccel(struct clockgen *cg, int idx)
hwc->reg = cg->regs + 0x20 * idx + 0x10;
hwc->info = cg->info.hwaccel[idx];
- return create_mux_common(cg, hwc, &hwaccel_ops, 0, 0,
+ return create_mux_common(cg, hwc, &hwaccel_ops, 0, ULONG_MAX, 0,
"cg-hwaccel%d", idx);
}
--
2.7.4
^ permalink raw reply related
* Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness
From: Will Deacon @ 2016-10-17 18:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I'm seeing an arm64 build failure with -rc1 and GCC trunk, although I
believe that the new compiler behaviour at the heart of the problem
has the potential to affect other architectures and other pieces of
kernel code relying on dead-code elimination to remove deliberately
undefined functions.
The failure looks like:
| drivers/built-in.o: In function `armada_3700_add_composite_clk':
|
| linux/drivers/clk/mvebu/armada-37xx-periph.c:351:
| undefined reference to `____ilog2_NaN'
|
| linux/drivers/clk/mvebu/armada-37xx-periph.c:351:(.text+0xc72e0):
| relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
| `____ilog2_NaN'
|
| make: *** [vmlinux] Error 1
and if we look at the source for armada_3700_add_composite_clk, we see
that this is caused by:
int table_size = 0;
rate->reg = reg + (u64)rate->reg;
for (clkt = rate->table; clkt->div; clkt++)
table_size++;
rate->width = order_base_2(table_size);
order_base_2 calls ilog2, which has the ____ilog2_NaN call:
#define ilog2(n) \
( \
__builtin_constant_p(n) ? ( \
(n) < 1 ? ____ilog2_NaN() : \
This is because we're in a curious case where GCC has emitted a
special-cased version of armada_3700_add_composite_clk, with table_size
effectively constant-folded as 0. Whilst we shouldn't see this in a
non-buggy kernel (hence the deliberate call to the undefined function
____ilog2_NaN), it means that the final link fails because we have a
____ilog2_NaN in the code, with a runtime check on table_size.
In other words, __builtin_constant_p appears to be weaker than we've
been assuming. Talking to the compiler guys here, this is due to the
"jump-threading" optimisation pass, so the patch below disables that.
A simpler example is:
int foo();
int bar();
int count(int *argc)
{
int table_size = 0;
for (; *argc; argc++)
table_size++;
if (__builtin_constant_p(table_size))
return table_size == 0 ? foo() : bar();
return bar();
}
which compiles to:
count:
ldr w0, [x0]
cbz w0, .L4
b bar
.p2align 3
.L4:
b foo
and, with the "optimisation" disabled:
count:
b bar
Thoughts? It feels awfully fragile disabling passes like this, but with
GCC transforming the code like this, I can't immediately think of a way
to preserve the intended behaviour of the code.
Will
--->8
diff --git a/Makefile b/Makefile
index 512e47a53e9a..750873d6d11e 100644
--- a/Makefile
+++ b/Makefile
@@ -641,6 +641,11 @@ endif
# Tell gcc to never replace conditional load with a non-conditional one
KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
+# Stop gcc from converting switches into a form that defeats dead code
+# elimination and can subsequently lead to calls to intentionally
+# undefined functions appearing in the final link.
+KBUILD_CFLAGS += $(call cc-option,--param=max-fsm-thread-path-insns=1)
+
include scripts/Makefile.gcc-plugins
ifdef CONFIG_READABLE_ASM
^ permalink raw reply related
* [PATCH] arm64: sysreg: Fix use of XZR in write_sysreg_s
From: Mark Rutland @ 2016-10-17 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476724859-18818-1-git-send-email-will.deacon@arm.com>
On Mon, Oct 17, 2016 at 06:20:59PM +0100, Will Deacon wrote:
> Commit 8a71f0c656e0 ("arm64: sysreg: replace open-coded mrs_s/msr_s with
> {read,write}_sysreg_s") introduced a write_sysreg_s macro for writing
> to system registers that are not supported by binutils.
>
> Unfortunately, this was implemented with the wrong template (%0 vs %x0),
> so in the case that we are writing a constant 0, we will generate
> invalid instruction syntax and bail with a cryptic assembler error:
>
> | Error: constant expression required
>
> This patch fixes the template.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Whoops; I should've spotted that in review. FWIW:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> arch/arm64/include/asm/sysreg.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index e8d46e8e6079..6c80b3699cb8 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -286,7 +286,7 @@ asm(
>
> #define write_sysreg_s(v, r) do { \
> u64 __val = (u64)v; \
> - asm volatile("msr_s " __stringify(r) ", %0" : : "rZ" (__val)); \
> + asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val)); \
> } while (0)
>
> static inline void config_sctlr_el1(u32 clear, u32 set)
> --
> 2.1.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* 4.7.6->4.8.1 Possible regression
From: Russell King - ARM Linux @ 2016-10-17 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476722858.483756177@f140.i.mail.ru>
On Mon, Oct 17, 2016 at 07:47:38PM +0300, Alexander Shiyan wrote:
> Hello.
>
> After a kernel update from 4.7.6 to 4.8.1, the bug appear once kernel run "init".
Please try this patch, thanks:
diff --git a/arch/arm/mm/abort-lv4t.S b/arch/arm/mm/abort-lv4t.S
index 6d8e8e3365d1..e81d09f1887d 100644
--- a/arch/arm/mm/abort-lv4t.S
+++ b/arch/arm/mm/abort-lv4t.S
@@ -48,7 +48,10 @@ ENTRY(v4t_late_abort)
/* c */ b do_DataAbort @ ldc rd, [rn], #m @ Same as ldr rd, [rn], #m
/* d */ b do_DataAbort @ ldc rd, [rn, #m]
/* e */ b .data_unknown
-/* f */
+/* f */ b .data_unknown
+
+.data_unknown_r9:
+ ldr r9, [sp], #4
.data_unknown: @ Part of jumptable
mov r0, r4
mov r1, r8
@@ -57,6 +60,7 @@ ENTRY(v4t_late_abort)
.data_arm_ldmstm:
tst r8, #1 << 21 @ check writeback bit
beq do_DataAbort @ no writeback -> no fixup
+ str r9, [sp, #-4]!
mov r7, #0x11
orr r7, r7, #0x1100
and r6, r8, r7
@@ -75,12 +79,14 @@ ENTRY(v4t_late_abort)
subne r7, r7, r6, lsl #2 @ Undo increment
addeq r7, r7, r6, lsl #2 @ Undo decrement
str r7, [r2, r9, lsr #14] @ Put register 'Rn'
+ ldr r9, [sp], #4
b do_DataAbort
.data_arm_lateldrhpre:
tst r8, #1 << 21 @ Check writeback bit
beq do_DataAbort @ No writeback -> no fixup
.data_arm_lateldrhpost:
+ str r9, [sp, #-4]!
and r9, r8, #0x00f @ get Rm / low nibble of immediate value
tst r8, #1 << 22 @ if (immediate offset)
andne r6, r8, #0xf00 @ { immediate high nibble
@@ -93,6 +99,7 @@ ENTRY(v4t_late_abort)
subne r7, r7, r6 @ Undo incrmenet
addeq r7, r7, r6 @ Undo decrement
str r7, [r2, r9, lsr #14] @ Put register 'Rn'
+ ldr r9, [sp], #4
b do_DataAbort
.data_arm_lateldrpreconst:
@@ -101,12 +108,14 @@ ENTRY(v4t_late_abort)
.data_arm_lateldrpostconst:
movs r6, r8, lsl #20 @ Get offset
beq do_DataAbort @ zero -> no fixup
+ str r9, [sp, #-4]!
and r9, r8, #15 << 16 @ Extract 'n' from instruction
ldr r7, [r2, r9, lsr #14] @ Get register 'Rn'
tst r8, #1 << 23 @ Check U bit
subne r7, r7, r6, lsr #20 @ Undo increment
addeq r7, r7, r6, lsr #20 @ Undo decrement
str r7, [r2, r9, lsr #14] @ Put register 'Rn'
+ ldr r9, [sp], #4
b do_DataAbort
.data_arm_lateldrprereg:
@@ -115,6 +124,7 @@ ENTRY(v4t_late_abort)
.data_arm_lateldrpostreg:
and r7, r8, #15 @ Extract 'm' from instruction
ldr r6, [r2, r7, lsl #2] @ Get register 'Rm'
+ str r9, [sp, #-4]!
mov r9, r8, lsr #7 @ get shift count
ands r9, r9, #31
and r7, r8, #0x70 @ get shift type
@@ -126,33 +136,33 @@ ENTRY(v4t_late_abort)
b .data_arm_apply_r6_and_rn
b .data_arm_apply_r6_and_rn @ 1: LSL #0
nop
- b .data_unknown @ 2: MUL?
+ b .data_unknown_r9 @ 2: MUL?
nop
- b .data_unknown @ 3: MUL?
+ b .data_unknown_r9 @ 3: MUL?
nop
mov r6, r6, lsr r9 @ 4: LSR #!0
b .data_arm_apply_r6_and_rn
mov r6, r6, lsr #32 @ 5: LSR #32
b .data_arm_apply_r6_and_rn
- b .data_unknown @ 6: MUL?
+ b .data_unknown_r9 @ 6: MUL?
nop
- b .data_unknown @ 7: MUL?
+ b .data_unknown_r9 @ 7: MUL?
nop
mov r6, r6, asr r9 @ 8: ASR #!0
b .data_arm_apply_r6_and_rn
mov r6, r6, asr #32 @ 9: ASR #32
b .data_arm_apply_r6_and_rn
- b .data_unknown @ A: MUL?
+ b .data_unknown_r9 @ A: MUL?
nop
- b .data_unknown @ B: MUL?
+ b .data_unknown_r9 @ B: MUL?
nop
mov r6, r6, ror r9 @ C: ROR #!0
b .data_arm_apply_r6_and_rn
mov r6, r6, rrx @ D: RRX
b .data_arm_apply_r6_and_rn
- b .data_unknown @ E: MUL?
+ b .data_unknown_r9 @ E: MUL?
nop
- b .data_unknown @ F: MUL?
+ b .data_unknown_r9 @ F: MUL?
.data_thumb_abort:
ldrh r8, [r4] @ read instruction
@@ -190,6 +200,7 @@ ENTRY(v4t_late_abort)
.data_thumb_pushpop:
tst r8, #1 << 10
beq .data_unknown
+ str r9, [sp, #-4]!
and r6, r8, #0x55 @ hweight8(r8) + R bit
and r9, r8, #0xaa
add r6, r6, r9, lsr #1
@@ -204,9 +215,11 @@ ENTRY(v4t_late_abort)
addeq r7, r7, r6, lsl #2 @ increment SP if PUSH
subne r7, r7, r6, lsl #2 @ decrement SP if POP
str r7, [r2, #13 << 2]
+ ldr r9, [sp], #4
b do_DataAbort
.data_thumb_ldmstm:
+ str r9, [sp, #-4]!
and r6, r8, #0x55 @ hweight8(r8)
and r9, r8, #0xaa
add r6, r6, r9, lsr #1
@@ -219,4 +232,5 @@ ENTRY(v4t_late_abort)
and r6, r6, #15 @ number of regs to transfer
sub r7, r7, r6, lsl #2 @ always decrement
str r7, [r2, r9, lsr #6]
+ ldr r9, [sp], #4
b do_DataAbort
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently@9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply related
* [PATCH] ARM: dts: sunxi: Add cpu-supply for Olimex A20 EVB
From: Maxime Ripard @ 2016-10-17 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161015152340.43315-1-manu@bidouilliste.com>
Hi,
On Sat, Oct 15, 2016 at 05:23:40PM +0200, Emmanuel Vadot wrote:
> sun7i-a20-olimex-som-evb.dts doesn't contain cpu-supply needed for
> voltage-scaling with cpufreq-dt so define it.
> The default voltages are defined in sun7i-a20.dtsi.
>
> Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161017/3aebd1db/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Lorenzo Pieralisi @ 2016-10-17 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f9dfa5a4-f42a-265f-ab84-7599f2de37ed@arm.com>
On Mon, Oct 17, 2016 at 03:19:46PM +0100, Robin Murphy wrote:
> Hi Lorenzo,
>
> On 17/10/16 14:21, Lorenzo Pieralisi wrote:
> > On Mon, Oct 17, 2016 at 12:06:20PM +0100, Robin Murphy wrote:
> >> We now delay installing our per-bus iommu_ops until we know an SMMU has
> >> successfully probed, as they don't serve much purpose beforehand, and
> >> doing so also avoids fights between multiple IOMMU drivers in a single
> >> kernel. However, the upshot of passing the return value of bus_set_iommu()
> >> back from our probe function is that if there happens to be more than
> >> one SMMUv3 device in a system, the second and subsequent probes will
> >> wind up returning -EBUSY to the driver core and getting torn down again.
> >>
> >> There are essentially 3 cases in which bus_set_iommu() returns nonzero:
> >> 1. The bus already has iommu_ops installed
> >> 2. One of the add_device callbacks from the initial notifier failed
> >> 3. Allocating or installing the notifier itself failed
> >>
> >> The first two are down to devices other than the SMMU in question, so
> >> shouldn't abort an otherwise-successful SMMU probe, whilst the third is
> >> indicative of the kind of catastrophic system failure which isn't going
> >> to get much further anyway. Consequently, there is little harm in
> >> ignoring the return value either way.
> >>
> >> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >> ---
> >> drivers/iommu/arm-smmu-v3.c | 11 ++++-------
> >> 1 file changed, 4 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> >> index 15c01c3cd540..74fbef384deb 100644
> >> --- a/drivers/iommu/arm-smmu-v3.c
> >> +++ b/drivers/iommu/arm-smmu-v3.c
> >> @@ -2637,16 +2637,13 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> >> of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> >> #ifdef CONFIG_PCI
> >> pci_request_acs();
> >> - ret = bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> >> - if (ret)
> >> - return ret;
> >> + bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> >> #endif
> >> #ifdef CONFIG_ARM_AMBA
> >> - ret = bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> >> - if (ret)
> >> - return ret;
> >> + bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> >> #endif
> >> - return bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
> >> + bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
> >> + return 0;
> >
> > Nit: I do not see why you would not take the same approach as
> > the ARM SMMUv1/v2, namely checking if ops are already set and
> > skip the call if that's the case.
>
> Well, I'd say it really goes the other way around - since the very first
> thing bus_set_iommu() does is check if ops are present, and return if
> so, and the v2 driver already doesn't care about that return value,
> there's not really any need for it to duplicate the check either. I
> didn't change it at the time to avoid cluttering the gigantic rework any
> further, but I could spin a cleanup patch if you like.
No worries, it was to understand if there was a reason to keep
the code different and after another look I agree with what
you are saying (by checking if ops are present you could eg
avoid calling pci_request_acs() every probe but that's a detail).
Thanks for fixing it !
Lorenzo
> > Anyway:
> >
> > Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>
> Thanks!
>
> Robin.
>
^ permalink raw reply
* [PATCH v8 1/2] ARM: dts: Add TOPEET itop core board SCP package version
From: ayaka @ 2016-10-17 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017162759.GA25818@kozik-lap>
On 10/18/2016 12:27 AM, Krzysztof Kozlowski wrote:
> On Mon, Sep 19, 2016 at 11:48:22PM +0800, Randy Li wrote:
>> The TOPEET itop is a samsung exnynos 4412 core board, which have
>> two package versions. This patch add the support for SCP version.
>>
>> Currently supported are USB3503A HSIC, USB OTG, eMMC, rtc and
>> PMIC. The future features are in the based board. Also MFC and
>> watchdog have been enabled.
>>
>> Signed-off-by: Randy Li <ayaka@soulik.info>
>> ---
>> arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 501 ++++++++++++++++++++++++
>> 1 file changed, 501 insertions(+)
>> create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
> I wanted to apply it... but then I saw a bunch of checkpatch trivial issues.
> Really, after v8? The code must compile (v6 did not compile...), there
> should be no warnings from smatch, sparse and checkpatch (only the last
> one is applicable for DTS). Unless of course checkpatch would be
> wrong... but in this case it is correct. You did not follow coding
> style:
>
> WARNING: please, no spaces at the start of a line
> #134: FILE: arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi:109:
> + devfreq = <&bus_leftbus>;$
>
> ERROR: code indent should use tabs where possible
> #135: FILE: arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi:110:
> + status = "okay";$
Oh, it is a copy mistake, the copy operation makes the original tab
becomes spaces.
Should I send a new version to correct them?
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Regression: usb serial gadget on sama5d3 broken
From: Peter Rosin @ 2016-10-17 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <38ca0db7-9bc6-7258-b102-ea9fdeb9b03c@atmel.com>
On 2016-10-17 16:54, Nicolas Ferre wrote:
> Le 17/10/2016 ? 14:53, Peter Rosin a ?crit :
>> Hi!
>>
>> I'm suffering from a regression while using the usb gadget port on the
>> sama5d3 to get terminal access to the device in question (CONFIG_USB_G_SERIAL).
>>
>> I get this message when I try to connect:
>> udc: ep: Invalid setup request: 02.01 v0000 i0081 l0, halting endpoint...
>>
>> A bisect blames commit v4.7-rc1-21-gc32b5bcfa3c4 "ARM: dts: at91: Fix
>> USB endpoint nodes".
>>
>> And indeed, reverting that commit on top of v4.9-rc1 fixes things,
>> although that doesn't look like the best of fixes...
>>
>> BTW, the bisect was extremely painful since v4.7-rc1 seemed broken
>> somewhere in the overlayfs area. I hope I will never ever need to bisect
>> in the v4.6..v4.7 area again. This was the second time, the first time
>> I was chasing a gpio interrupt bug, but I never found out what was wrong
>> and stopped looking when v4.9-rc1 turned out to be ok even though v4.8
>> was bad, it was just too painful to look for things that already seemed
>> fixed.
>
> I guess that you are referring to the regression listed here:
> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1239220.html
>
> The patch is available and will hopefully land in an official kernel
> soon (4.8.1) as said by Felipe and Greg.
>
> Sorry for the inconvenience. Best regards,
Ok, I tried "usb: gadget: udc: atmel: fix endpoint name" and it fixes
things for me too. But shouldn't the memory for the now dynamic name be
allocated with devm_kasprintf instead of that plain kasprint? If you
are pedantic...
Cheers,
Peter
^ permalink raw reply
* [PATCH 1/2] i2c: bcm-iproc: constify i2c_adapter_quirks structures
From: Ray Jui @ 2016-10-17 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476552722-12352-2-git-send-email-Julia.Lawall@lip6.fr>
Hi Julia,
On 10/15/2016 10:32 AM, Julia Lawall wrote:
> Check for i2c_adapter_quirks structures that are only stored in the
> quirks field of an i2c_adapter structure. This field is declared
> const, so i2c_adapter_quirks structures that have this property can be
> declared as const also.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct i2c_adapter_quirks i at p = { ... };
>
> @ok@
> identifier r.i;
> struct i2c_adapter e;
> position p;
> @@
> e.quirks = &i at p;
>
> @bad@
> position p != {r.p,ok.p};
> identifier r.i;
> struct i2c_adapter_quirks e;
> @@
> e at i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
> struct i2c_adapter_quirks i = { ... };
> // </smpl>
>
> The effect on the layout of the .o file is shown by the following
> output of the size command, first before then after the
> transformation:
>
> text data bss dec hex filename
> 3458 744 8 4210 1072 drivers/i2c/busses/i2c-bcm-iproc.o
> 3490 720 8 4218 107a drivers/i2c/busses/i2c-bcm-iproc.o
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> drivers/i2c/busses/i2c-bcm-iproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
> index 326b3db..318df55 100644
> --- a/drivers/i2c/busses/i2c-bcm-iproc.c
> +++ b/drivers/i2c/busses/i2c-bcm-iproc.c
> @@ -395,7 +395,7 @@ static uint32_t bcm_iproc_i2c_functionality(struct i2c_adapter *adap)
> .functionality = bcm_iproc_i2c_functionality,
> };
>
> -static struct i2c_adapter_quirks bcm_iproc_i2c_quirks = {
> +static const struct i2c_adapter_quirks bcm_iproc_i2c_quirks = {
> /* need to reserve one byte in the FIFO for the slave address */
> .max_read_len = M_TX_RX_FIFO_SIZE - 1,
> };
>
Change looks good. Thanks.
Acked-by: Ray Jui <ray.jui@broadcom.com>
^ permalink raw reply
* [PATCH 1/2] ARM: vexpress: refine MCPM smp operations override criteria
From: Sudeep Holla @ 2016-10-17 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923140303.GA26672@red-moon>
On 23/09/16 15:03, Lorenzo Pieralisi wrote:
> On Fri, Sep 23, 2016 at 02:09:06PM +0100, Lorenzo Pieralisi wrote:
>> Current vexpress smp init code detects whether to override the
>> default smp ops with MCPM smp ops by matching the "cci-400"
>> compatible string, in that MCPM requires control over CCI ports
>> to manage low-power states entry/exit.
>>
>> The "cci-400" compatible string check is a necessary but not
>> sufficient condition for MCPM to work, because the cci-400
>> can be made visible to the kernel, but firmware can nonetheless
>> disable non-secure CCI ports control, while still allowing PMU
>> access; if booted in non-secure world, the kernel would still
>> blindly override smp operations with MCPM operations, resulting
>> in kernel faults when the CCI ports programming interface is
>> accessed from non-secure world.
>>
>> This means that the "cci-400" compatible string check would
>> result in a false positive in systems that eg boot in HYP mode,
>> where CCI ports non-secure access is explicitly not allowed,
>> and it is reported in the respective device tree nodes with
>> CCI ports marked as disabled.
>>
>> Refactor the smp operations initialization to make sure that
>> the kernel is actually allowed to take control over CCI ports
>> (by enabling MCPM smp operations) before overriding default
>> vexpress smp operations.
>>
>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Cc: Liviu Dudau <liviu.dudau@arm.com>
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> arch/arm/mach-vexpress/platsmp.c | 31 ++++++++++++++++++++++++-------
>> 1 file changed, 24 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
>> index 8b8d072..6cfd782 100644
>> --- a/arch/arm/mach-vexpress/platsmp.c
>> +++ b/arch/arm/mach-vexpress/platsmp.c
>> @@ -26,17 +26,34 @@
>> bool __init vexpress_smp_init_ops(void)
>> {
>> #ifdef CONFIG_MCPM
>> + int cpu;
>> + struct device_node *cpu_node, *cci_node;
>> +
>> /*
>> - * The best way to detect a multi-cluster configuration at the moment
>> - * is to look for the presence of a CCI in the system.
>> + * The best way to detect a multi-cluster configuration
>> + * is to detect if the kernel can take over CCI ports
>> + * control. Loop over possible CPUs and check if CCI
>> + * port control is available.
>> * Override the default vexpress_smp_ops if so.
>> */
>> - struct device_node *node;
>> - node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
>> - if (node && of_device_is_available(node)) {
>> - mcpm_smp_set_ops();
>> - return true;
>> + for_each_possible_cpu(cpu) {
>> + bool available;
>> +
>> + cpu_node = of_get_cpu_node(cpu, NULL);
>> + if (WARN(!cpu_node, "Missing cpu device node!"))
>> + return false;
>> +
>> + cci_node = of_parse_phandle(cpu_node, "cci-control-port", 0);
>> + available = cci_node && of_device_is_available(cci_node);
>> + of_node_put(cci_node);
>> + of_node_put(cpu_node);
>> +
>> + if (!available)
>> + return false;
>> }
>> +
>> + mcpm_smp_set_ops();
>> + return true;
>> #endif
>> return false;
>
> For the records, while moving the code around I missed I was ending
> up with this idiotic double return, I have already reworked the patch
> and will squash changes in the final version if we agree on the bulk of
> the code.
>
I applied both patches to [1] with the fix for the above issue. Let me
know if that's fine. I have tested both hyp mode boot and SVC mode +
MCPM boot with latest u-boot by just fliping a bit in the firmware
(board.txt) without recompiling the kernel.
--
Regards,
Sudeep
[1] git.kernel.org/sudeep.holla/linux/h/vexpress/for-next
^ permalink raw reply
* [PATCH V3 RFT 3/5] ARM64: dts: bcm283x: Use dtsi for USB host mode
From: Eric Anholt @ 2016-10-17 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1471792204-21908-4-git-send-email-stefan.wahren@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> In case dr_mode isn't passed via DT, the dwc2 driver defaults
> to OTG mode. But the Raspberry Pi 3 is designed only for host mode.
> So fix this issue by linking to the dtsi file which set the dr_mode
> to host.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Applied Gerd's Tested-by and merged to bcm2835-dt-64-next.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161017/1eb7a5d5/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: sysreg: Fix use of XZR in write_sysreg_s
From: Will Deacon @ 2016-10-17 17:20 UTC (permalink / raw)
To: linux-arm-kernel
Commit 8a71f0c656e0 ("arm64: sysreg: replace open-coded mrs_s/msr_s with
{read,write}_sysreg_s") introduced a write_sysreg_s macro for writing
to system registers that are not supported by binutils.
Unfortunately, this was implemented with the wrong template (%0 vs %x0),
so in the case that we are writing a constant 0, we will generate
invalid instruction syntax and bail with a cryptic assembler error:
| Error: constant expression required
This patch fixes the template.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/sysreg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index e8d46e8e6079..6c80b3699cb8 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -286,7 +286,7 @@ asm(
#define write_sysreg_s(v, r) do { \
u64 __val = (u64)v; \
- asm volatile("msr_s " __stringify(r) ", %0" : : "rZ" (__val)); \
+ asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val)); \
} while (0)
static inline void config_sctlr_el1(u32 clear, u32 set)
--
2.1.4
^ permalink raw reply related
* [PATCH v4 2/7] ARM: dts: bcm283x: Define standard pinctrl groups in the gpio node.
From: Eric Anholt @ 2016-10-17 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474274603-24215-3-git-send-email-kraxel@redhat.com>
Gerd Hoffmann <kraxel@redhat.com> writes:
> From: Eric Anholt <eric@anholt.net>
>
> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
> function selects do for the pins, and there are a bunch of obvious
> groupings to be made. With these created, we'll be able to replace
> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
> references to specific groups we want enabled.
>
> Also add pinctrl groups for emmc and sdhost.
>
> Based on patches by Eric Anholt <eric@anholt.net>
I amended this line to "Based on patches by Eric Anholt, with fixups by
Gerd Hoffmann." to explain why it had me as author but you in signoff.
I had to resolve some conflicts on the way in because apparently you had
built this against a tree with 14 and 15 already dropped from alt0. I
think those resolutions were sufficiently mechanical that it didn't
merit a respin.
Merged the series to bcm2835-dt-next. Thanks for getting this done!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161017/8fe3d040/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver
From: Kevin Hilman @ 2016-10-17 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476721850-454-3-git-send-email-bgolaszewski@baylibre.com>
Bartosz Golaszewski <bgolaszewski@baylibre.com> writes:
> Create the driver for the da8xx System Configuration and implement
> support for writing to the three Master Priority registers.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
[...]
> +#define DA8XX_IO_PHYS 0x01c00000ul
> +#define DA8XX_SYSCFG0_BASE (DA8XX_IO_PHYS + 0x14000)
The base addr should come from DT.
Kevin
^ permalink raw reply
* [PATCH 1/3] ARM: memory: da8xx-ddrctl: new driver
From: Kevin Hilman @ 2016-10-17 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476721850-454-2-git-send-email-bgolaszewski@baylibre.com>
Bartosz Golaszewski <bgolaszewski@baylibre.com> writes:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
[...]
> diff --git a/drivers/memory/da8xx-ddrctl.c b/drivers/memory/da8xx-ddrctl.c
> new file mode 100644
> index 0000000..dcd0a61
> --- /dev/null
> +++ b/drivers/memory/da8xx-ddrctl.c
> @@ -0,0 +1,77 @@
> +/*
> + * TI da8xx DDR2/mDDR controller driver
> + *
> + * Copyright (C) 2016 BayLibre SAS
> + *
> + * Author:
> + * Bartosz Golaszewski <bgolaszewski@baylibre.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +
> +#define DA8XX_DDR_CTL_BASE 0xB0000000
This base addr should be the reg property of the node.
> +#define DA8XX_PBBPR_OFFSET 0x00000020
> +#define DA8XX_PBBPR_REG(p) ((p) + DA8XX_PBBPR_OFFSET)
Kevin
^ permalink raw reply
* [PATCH] ARM: dts: mps2: remove skeleton.dtsi include and fix unit address warnings
From: Sudeep Holla @ 2016-10-17 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476704849-24039-1-git-send-email-vladimir.murzin@arm.com>
On 17/10/16 12:47, Vladimir Murzin wrote:
> Removale of skeleton.dtsi allows us also to fix the following
> warning from the dts compiler:
> Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
>
> by adding proper unit addresses to the memory nodes.
>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
It's always better to cc device-tree list, anyways applied this to [1].
--
Regards,
Sudeep
[1] git.kernel.org/sudeep.holla/linux/h/vexpress-dt/for-next
^ permalink raw reply
* master build: 2 failures 4 warnings (v4.8-11811-g35ff96d)
From: Thomas Gleixner @ 2016-10-17 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161014103344.GB3304@dell>
On Fri, 14 Oct 2016, Lee Jones wrote:
> On Tue, 11 Oct 2016, Mark Brown wrote:
>
> > On Tue, Oct 11, 2016 at 07:30:35AM +0100, Build bot for Mark Brown wrote:
> >
> > Linus' tree is currently failing to build arm and arm64 allmodconfigs
> > with:
> >
> > > arm64-allmodconfig
> > > ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
> >
> > > arm-allmodconfig
> > > ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
> >
> > due to 6556bdacf646fc (mfd: tps65217: Add support for IRQs) since
> > irq_set_parent() isn't exported. This has been present in -next
> > for getting on for a month, a patch was proposed adding the relevant
> > export but that isn't present in -next yet.
> >
> > The function is being used in order to enable lazy IRQ disabling for
> > threaded interrupts:
> >
> > https://www.spinics.net/lists/arm-kernel/msg532864.html
> >
> > What's the plan for getting this fixed in Linus' tree?
>
> Here's the conversation:
>
> https://www.spinics.net/lists/arm-kernel/msg531850.html
>
> I'm waiting on a firm answer from Arnd and Thomas before applying
> anything.
As I said, we can export it, if it's needed to make the driver modular. But
we definitely don't want to export it just to make the build happy.
Grigoryi has an excellent answer here:
https://www.spinics.net/lists/arm-kernel/msg532864.html
Only the driver authors/maintainers can decide whether this is the case or
not.
Thanks,
tglx
^ permalink raw reply
* 4.7.6->4.8.1 Possible regression
From: Alexander Shiyan @ 2016-10-17 16:47 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
After a kernel update from 4.7.6 to 4.8.1, the bug appear once kernel run "init".
...
VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
devtmpfs: mounted
Freeing unused kernel memory: 144K (c04da000 - c04fe000)
This architecture does not have kernel memory protection.
Please press Enter to activate this console.
starting pid 448, tty '': '-/bin/ash'
Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c3b58000
[00000008] *pgd=800000000, *pte=00000000, *ppte=feff4140
Internal error: Oops: 63c11817 [#1] PREEMPT ARM
CPU: 0 PID: 448 Comm: ash Not tainted 4.8.1+ #1
Hardware name: Cirrus Logic CLPS711X (Device Tree Support)
task: c39e03a0 ti: c3b4e000 task.ti: c3b4e000
PC is at __dabt_svc+0x4c/0x60
LR is at do_page_fault+0x144/0x2ac
pc : [<c000d3ac>] lr : [<c000fcec>] psr: 60000093
sp : c3b4fe6c ip : 00000001 fp : b6f1bf88
r10: c387a5a0 r9 : 00000000 r8 : e4e0e001
r7 : bee3ef83 r6 : 00100000 r5 : 80000013 r4 : c022fcf8
r3 : 00000000 r2 : 00000008 r1 : bf000000 r0 : 00000000
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0000217f Table: c3b58055 DAC: 00000055
Process ash (pid: 448, stack limit = 0xc3b4e190)
Stack: (0xc3b4fe6c to 0xc3b50000)
fe60: bee3ef83 c05168d1 ffffffff 00000000 c3adfe80
fe80: c3a03300 00000000 c3b4fed0 c3a03400 bee3ef83 c387a5a0 b6f1bf88 00000001
fea0: c3b4febc 00000076 c022fcf8 80000013 ffffffff 0000003f bf000000 bee3ef83
fec0: 00000004 00000000 c3adfe80 c00e432c 00000812 00000005 00000001 00000006
fee0: b6f1b000 00000000 00010000 0003c944 0004d000 0004d439 00010000 b6f1b000
ff00: 00000005 00000000 00015ecc c3b4fed0 0000000a 00000000 00000000 c00a1dc0
ff20: befff000 c3a03300 c3b4e000 c0507cd8 c0508024 fffffff8 c3a03300 00000000
ff40: c0516a58 c00a35bc c39e03a0 000001c0 bea84ce8 0004e008 c3b3a000 c00a3ac0
ff60: c3b40374 c3b3a000 bea84d11 00000000 c0500188 bea84d11 bea84ce8 00000001
ff80: 0000000b c000a304 c3b4e000 00000000 bea84ce4 c00a3cd0 00000000 bea84d11
ffa0: bea84ce8 c000a160 bea84d11 bea84ce8 bea84d11 bea84ce8 0004e008 0004d450
ffc0: bea84d11 bea84ce8 00000001 0000000b b6f45ee4 00000000 b6f5ff70 bea84ce4
ffe0: b6f2f130 bea84cb0 b6f2f194 b6ef29f4 a0000010 bea84d11 02c7cffa 02c7cffd
[<c000d3ac>] (__dabt_svc) from [<c022fcf8>] (__copy_to_user_std+0xf8/0x330)
[<c022fcf8>] (__copy_to_user_std) from [<c00e432c>] (load_elf_binary+0x920/0x107c)
[<c00e432c>] (load_elf_binary) from [<c00a35bc>] (search_binary_handler+0x80/0x16c)
[<c00a35bc>] (search_binary_handler) from [<c00a3ac0>] (do_execveat_common+0x418/0x600)
[<c00a3ac0>] (do_execveat_common) from [<c00a3cd0>] (do_execve+0x28/0x30)
[<c00a3cd0>] (do_execve) from [<c000a160>] (ret_fast_syscall+0x0/0x30)
Code: e1a0200d eb00136b e321f093 e59d104c (e5891008)
---[ end trace 4b4f8086ebef98c5 ]---
process '-/bin/ash' (pid 448) exited. Scheduling for restart.
Git-bisect found a bad commit: "ARM: save and reset the address limit when entering an exception"
Reverting this commit on top of 4.8.1 solve this problem.
Can anyone have similar problems? Any ideas?
Thanks.
---
^ permalink raw reply
* [PATCH 1/3] arm64/dts: Add SMMUs to Juno
From: Sudeep Holla @ 2016-10-17 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <acf4f770eab43fec8c5b6e9cddb6dd0defc52138.1476706244.git.robin.murphy@arm.com>
On 17/10/16 13:13, Robin Murphy wrote:
> Juno has seperate MMU-401 instances in front of the DMA-330, both HDLCD
> controllers, the USB host controller, the PCIe root complex, and the
> CoreSight ETR. Since there is still work to do to make all the relevant
> subsystems interact nicely with the presence of an IOMMU, add the nodes
> to aid develompent and testing but leave them disabled by default to
> avoid nasty surprises.
>
> CC: Liviu Dudau <liviu.dudau@arm.com>
> CC: Sudeep Holla <sudeep.holla@arm.com>
Applied to [1] with $subject reformatted and typos fixed
--
Regards,
Sudeep
[1] git.kernel.org/sudeep.holla/linux/h/juno-dt/for-next
^ permalink raw reply
* [PATCH v7 REPOST 0/9] CPUs capacity information for heterogeneous systems
From: Juri Lelli @ 2016-10-17 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <66c7bbfd-ec3f-ff43-9a06-ae644d9ee9d9@arm.com>
Hi Sudeep,
On 17/10/16 17:39, Sudeep Holla wrote:
>
>
> On 17/10/16 16:46, Juri Lelli wrote:
> >Hi all,
> >
> >this is a repost of version 7 of "CPUs capacity information for heterogeneous
> >systems" patchset [1] (please refer to previous postings to get some context).
> >I only added Juno r1 dts, as discussed off-line with Sudeep meanwhile (no code
> >changes at all, so that's why I'm saying this is a repost).
> >
> >I'm reposting as I didn't receive any comment (despite pinging people) on the
> >original v7 posting (apart from Vincent acking patches 2 and 4, thanks!). I
> >then waited until merge window for 4.9 was closed.
> >
> >I'm thus now assuming that everybody is OK with the patches and that they can
> >be queued for 4.10 (we certainly need this plumbing at this point). Please
> >speak if my assumption is wrong (and provide feedback! :).
> >Otherwise I'm going to:
> >
> > - use Russell's patching system for patches 2 and 8
> > - ask Sudeep to pull patches 3,5,6 and 7
>
> I have applied 3 to [1] and 5,6,7 to [2]. Let me know if things change
> and you want me to drop them with some cosmetic subject change and
> updated changelog.
>
Thanks!
Best,
- Juri
> --
> Regards,
> Sudeep
>
> [1] git.kernel.org/sudeep.holla/linux/h/vexpress-dt/for-next
> [2] git.kernel.org/sudeep.holla/linux/h/juno-dt/for-next
>
^ permalink raw reply
* [PATCH 2/2] ARM: multi_v7_defconfig: Enable exynos-gsc driver as module
From: Krzysztof Kozlowski @ 2016-10-17 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475677469-1524-2-git-send-email-javier@osg.samsung.com>
On Wed, Oct 05, 2016 at 11:24:29AM -0300, Javier Martinez Canillas wrote:
> Exynos5 SoCs have a General SCALER (GSCALER) IP block that can be used
> to do video streams scaling and color space conversions by hardware.
> Enable support for its driver as a module so the GSCALER can be tested.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> ---
>
> arch/arm/configs/multi_v7_defconfig | 1 +
> 1 file changed, 1 insertion(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/2] ARM: exynos_defconfig: Enable exynos-gsc driver as module
From: Krzysztof Kozlowski @ 2016-10-17 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475677469-1524-1-git-send-email-javier@osg.samsung.com>
On Wed, Oct 05, 2016 at 11:24:28AM -0300, Javier Martinez Canillas wrote:
> Exynos5 SoCs have a General SCALER (GSCALER) IP block that can be used
> to do video streams scaling and color space conversions by hardware.
> Enable support for its driver as a module so the GSCALER can be tested.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> arch/arm/configs/exynos_defconfig | 1 +
> 1 file changed, 1 insertion(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 3/5] [media] rc: meson-ir: Fix module autoload
From: Kevin Hilman @ 2016-10-17 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476719053-17600-4-git-send-email-javier@osg.samsung.com>
On Mon, Oct 17, 2016 at 8:44 AM, Javier Martinez Canillas
<javier@osg.samsung.com> wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ modinfo drivers/media/rc/meson-ir.ko | grep alias
> $
>
> After this patch:
>
> $ modinfo drivers/media/rc/meson-ir.ko | grep alias
> alias: of:N*T*Camlogic,meson-gxbb-irC*
> alias: of:N*T*Camlogic,meson-gxbb-ir
> alias: of:N*T*Camlogic,meson8b-irC*
> alias: of:N*T*Camlogic,meson8b-ir
> alias: of:N*T*Camlogic,meson6-irC*
> alias: of:N*T*Camlogic,meson6-ir
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
^ 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