Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARM: dts: Add support for Olimex AM3352-SOM #52

Closed
wants to merge 1 commit into from

Conversation

vinifr
Copy link

@vinifr vinifr commented Dec 6, 2015

Add a dts file for Olimex AM3352-SOM board. The board does not use the PMIC
tps65217 and does not have many peripherals present in beaglebone. Thus, a
specific dtsi file (am335x-som-common.dtsi) is needed.

Signed-off-by: Dimitar Gamishev hehopmajieh@debian.bg
Signed-off-by: Vinicius Maciel viniciusfre@gmail.com

Add a dts file for Olimex AM3352-SOM board. The board does not use the PMIC
tps65217 and does not have many peripherals present in beaglebone. Thus, a
specific dtsi file (am335x-som-common.dtsi) is needed.

Signed-off-by: Dimitar Gamishev <hehopmajieh@debian.bg>
Signed-off-by: Vinicius Maciel <viniciusfre@gmail.com>
@vinifr vinifr closed this Dec 6, 2015
@RobertCNelson
Copy link
Member

Something wrong? I was going to gueue this up on Monday? Let me know..

@vinifr
Copy link
Author

vinifr commented Dec 6, 2015

Something is wrong. The two Ethernet interfaces are not detected. Just working with https://github.com/OLIMEX/linux-3.12.10-ti2013.12.01-am3352_som/blob/master/drivers/net/ethernet/ti/cpsw.c

My change seems it's not ok to your cpsw.c:

&mac {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&cpsw_default>;
pinctrl-1 = <&cpsw_sleep>;
slaves = <2>;
dual_emac = <1>;

cpsw_emac0 {
    dual_emac_res_vlan = <1>;
};

cpsw_emac1 {
    dual_emac_res_vlan = <2>;
};

};

&cpsw_emac0 {
phy_id = <&davinci_mdio>, <0>;
phy-mode = "mii";
};

&cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
phy-mode = "mii";
};

@RobertCNelson
Copy link
Member

I think your tripping on linux/commit/e6c31b3467ac383ba57ae41146d31f0ef29da3c3

Drop the am335-bone compat..

@RobertCNelson
Copy link
Member

e6c31b3

@vinifr
Copy link
Author

vinifr commented Dec 7, 2015

If I understood you correctly, removing "ti,am335x-bone" from am335x-olimex-som.dts still does not work. It's very strange, there is not even a mention to davinci_mdio.c functions or cpsw.c: http://pastebin.com/aDPBYXC7 ... I setup kernel log level to 7. Dimitar' kernel: http://pastebin.com/LdJvw7c3

@vinifr
Copy link
Author

vinifr commented Dec 9, 2015

Hi RobertCNelson,
Finally the ethernet interfaces worked! A simple status = "okay" solved the problem.

davinci_mdio: dt: updated phy_id[0] from phy_mask[fffffffc]
davinci_mdio: dt: updated phy_id[1] from phy_mask[fffffffc]

@RobertCNelson
Copy link
Member

That's great it worked, but i see the phy_mask bug so only one probally works, i'll edit out the "ti,am335x-bone" in the patch..

@vinifr
Copy link
Author

vinifr commented Dec 9, 2015

OK. Anyway, I tested both interfaces and both pick up IP.

ifconfig
eth2 Link encap:Ethernet HWaddr 1c:ba:8c:9c:92:49
inet addr:192.168.25.173 Bcast:192.168.25.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6953 errors:0 dropped:0 overruns:0 frame:0
TX packets:3953 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9849789 (9.3 MiB) TX bytes:276379 (269.9 KiB)
Interrupt:171

eth3 Link encap:Ethernet HWaddr 1c:ba:8c:9c:92:4b
inet addr:192.168.25.172 Bcast:192.168.25.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:44 errors:0 dropped:0 overruns:0 frame:0
TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8655 (8.4 KiB) TX bytes:3283 (3.2 KiB)

Kernel log: http://pastebin.com/LKnzXEDd

@RobertCNelson
Copy link
Member

That's crazy!

With the patch we get the first phy_mask:

https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.1.y/patches/beaglebone/phy/0001-cpsw-search-for-phy.patch#L45

and then we update the both ethernet slaves with the exact same phy_mask. ;)

I'm just really surprised you got two ip's, i was kinda expecting them to clone..

RobertCNelson added a commit to RobertCNelson/ti-linux-kernel-dev that referenced this pull request Dec 9, 2015
fixes: beagleboard/linux#53

fixes: beagleboard/linux#52
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
RobertCNelson added a commit to RobertCNelson/ti-linux-kernel-dev that referenced this pull request Dec 9, 2015
fixes: beagleboard/linux#53

fixes: beagleboard/linux#52
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
@RobertCNelson
Copy link
Member

Okay, pushed to "4.1.x-ti" and "4.1.x-rt-ti" it'll be part of r36, pushed out on Thursday, noon central.

Thanks!!!

RobertCNelson added a commit to RobertCNelson/dtb-rebuilder that referenced this pull request Dec 9, 2015
fixes: beagleboard/linux#53

fixes: beagleboard/linux#52
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
@vinifr
Copy link
Author

vinifr commented Dec 9, 2015

Great! Thanks.

thess pushed a commit to thess/ti-linux-kernel-dev that referenced this pull request Dec 10, 2015
fixes: beagleboard/linux#53

fixes: beagleboard/linux#52
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
RobertCNelson pushed a commit that referenced this pull request Nov 10, 2016
commit a7a7aee upstream.

When interrupting an application which was allocating DMAable
memory, it was possible, that the DMA memory was deallocated
twice, leading to the error symptoms below.

Thanks to Gerald, who analyzed the problem and provided this
patch.

I agree with his analysis of the problem: ddcb_cmd_fixups() ->
genwqe_alloc_sync_sgl() (fails in f/lpage, but sgl->sgl != NULL
and f/lpage maybe also != NULL) -> ddcb_cmd_cleanup() ->
genwqe_free_sync_sgl() (double free, because sgl->sgl != NULL and
f/lpage maybe also != NULL)

In this scenario we would have exactly the kind of double free that
would explain the WARNING / Bad page state, and as expected it is
caused by broken error handling (cleanup).

Using the Ubuntu git source, tag Ubuntu-4.4.0-33.52, he was able to reproduce
the "Bad page state" issue, and with the patch on top he could not reproduce
it any more.

------------[ cut here ]------------
WARNING: at /build/linux-o03cxz/linux-4.4.0/arch/s390/include/asm/pci_dma.h:141
Modules linked in: qeth_l2 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common genwqe_card qeth crc_itu_t qdio ccwgroup vmur dm_multipath dasd_eckd_mod dasd_mod
CPU: 2 PID: 3293 Comm: genwqe_gunzip Not tainted 4.4.0-33-generic #52-Ubuntu
task: 0000000032c7e270 ti: 00000000324e4000 task.ti: 00000000324e4000
Krnl PSW : 0404c00180000000 0000000000156346 (dma_update_cpu_trans+0x9e/0xa8)
           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 00000000324e7bcd 0000000000c3c34a 0000000027628298 000000003215b400
           0000000000000400 0000000000001fff 0000000000000400 0000000116853000
           07000000324e7b1e 0000000000000001 0000000000000001 0000000000000001
           0000000000001000 0000000116854000 0000000000156402 00000000324e7a38
Krnl Code: 000000000015633a: 95001000           cli     0(%r1),0
           000000000015633e: a774ffc3           brc     7,1562c4
          #0000000000156342: a7f40001           brc     15,156344
          >0000000000156346: 92011000           mvi     0(%r1),1
           000000000015634a: a7f4ffbd           brc     15,1562c4
           000000000015634e: 0707               bcr     0,%r7
           0000000000156350: c00400000000       brcl    0,156350
           0000000000156356: eb7ff0500024       stmg    %r7,%r15,80(%r15)
Call Trace:
([<00000000001563e0>] dma_update_trans+0x90/0x228)
 [<00000000001565dc>] s390_dma_unmap_pages+0x64/0x160
 [<00000000001567c2>] s390_dma_free+0x62/0x98
 [<000003ff801310ce>] __genwqe_free_consistent+0x56/0x70 [genwqe_card]
 [<000003ff801316d0>] genwqe_free_sync_sgl+0xf8/0x160 [genwqe_card]
 [<000003ff8012bd6e>] ddcb_cmd_cleanup+0x86/0xa8 [genwqe_card]
 [<000003ff8012c1c0>] do_execute_ddcb+0x110/0x348 [genwqe_card]
 [<000003ff8012c914>] genwqe_ioctl+0x51c/0xc20 [genwqe_card]
 [<000000000032513a>] do_vfs_ioctl+0x3b2/0x518
 [<0000000000325344>] SyS_ioctl+0xa4/0xb8
 [<00000000007b86c6>] system_call+0xd6/0x264
 [<000003ff9e8e520a>] 0x3ff9e8e520a
Last Breaking-Event-Address:
 [<0000000000156342>] dma_update_cpu_trans+0x9a/0xa8
---[ end trace 35996336235145c8 ]---
BUG: Bad page state in process jbd2/dasdb1-8  pfn:3215b
page:000003d100c856c0 count:-1 mapcount:0 mapping:          (null) index:0x0
flags: 0x3fffc0000000000()
page dumped because: nonzero _count

Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Frank Haverkamp <haver@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
nmenon pushed a commit to nmenon/nm-beagle-linux that referenced this pull request May 22, 2023
[ Upstream commit 031af50 ]

The inline assembly for arm64's cmpxchg_double*() implementations use a
+Q constraint to hazard against other accesses to the memory location
being exchanged. However, the pointer passed to the constraint is a
pointer to unsigned long, and thus the hazard only applies to the first
8 bytes of the location.

GCC can take advantage of this, assuming that other portions of the
location are unchanged, leading to a number of potential problems.

This is similar to what we fixed back in commit:

  fee960b ("arm64: xchg: hazard against entire exchange variable")

... but we forgot to adjust cmpxchg_double*() similarly at the same
time.

The same problem applies, as demonstrated with the following test:

| struct big {
|         u64 lo, hi;
| } __aligned(128);
|
| unsigned long foo(struct big *b)
| {
|         u64 hi_old, hi_new;
|
|         hi_old = b->hi;
|         cmpxchg_double_local(&b->lo, &b->hi, 0x12, 0x34, 0x56, 0x78);
|         hi_new = b->hi;
|
|         return hi_old ^ hi_new;
| }

... which GCC 12.1.0 compiles as:

| 0000000000000000 <foo>:
|    0:   d503233f        paciasp
|    4:   aa0003e4        mov     x4, x0
|    8:   1400000e        b       40 <foo+0x40>
|    c:   d2800240        mov     x0, #0x12                       // beagleboard#18
|   10:   d2800681        mov     x1, #0x34                       // beagleboard#52
|   14:   aa0003e5        mov     x5, x0
|   18:   aa0103e6        mov     x6, x1
|   1c:   d2800ac2        mov     x2, #0x56                       // beagleboard#86
|   20:   d2800f03        mov     x3, #0x78                       // beagleboard#120
|   24:   48207c82        casp    x0, x1, x2, x3, [x4]
|   28:   ca050000        eor     x0, x0, x5
|   2c:   ca060021        eor     x1, x1, x6
|   30:   aa010000        orr     x0, x0, x1
|   34:   d2800000        mov     x0, #0x0                        // #0    <--- BANG
|   38:   d50323bf        autiasp
|   3c:   d65f03c0        ret
|   40:   d2800240        mov     x0, #0x12                       // beagleboard#18
|   44:   d2800681        mov     x1, #0x34                       // beagleboard#52
|   48:   d2800ac2        mov     x2, #0x56                       // beagleboard#86
|   4c:   d2800f03        mov     x3, #0x78                       // beagleboard#120
|   50:   f9800091        prfm    pstl1strm, [x4]
|   54:   c87f1885        ldxp    x5, x6, [x4]
|   58:   ca0000a5        eor     x5, x5, x0
|   5c:   ca0100c6        eor     x6, x6, x1
|   60:   aa0600a6        orr     x6, x5, x6
|   64:   b5000066        cbnz    x6, 70 <foo+0x70>
|   68:   c8250c82        stxp    w5, x2, x3, [x4]
|   6c:   35ffff45        cbnz    w5, 54 <foo+0x54>
|   70:   d2800000        mov     x0, #0x0                        // #0     <--- BANG
|   74:   d50323bf        autiasp
|   78:   d65f03c0        ret

Notice that at the lines with "BANG" comments, GCC has assumed that the
higher 8 bytes are unchanged by the cmpxchg_double() call, and that
`hi_old ^ hi_new` can be reduced to a constant zero, for both LSE and
LL/SC versions of cmpxchg_double().

This patch fixes the issue by passing a pointer to __uint128_t into the
+Q constraint, ensuring that the compiler hazards against the entire 16
bytes being modified.

With this change, GCC 12.1.0 compiles the above test as:

| 0000000000000000 <foo>:
|    0:   f9400407        ldr     x7, [x0, beagleboard#8]
|    4:   d503233f        paciasp
|    8:   aa0003e4        mov     x4, x0
|    c:   1400000f        b       48 <foo+0x48>
|   10:   d2800240        mov     x0, #0x12                       // beagleboard#18
|   14:   d2800681        mov     x1, #0x34                       // beagleboard#52
|   18:   aa0003e5        mov     x5, x0
|   1c:   aa0103e6        mov     x6, x1
|   20:   d2800ac2        mov     x2, #0x56                       // beagleboard#86
|   24:   d2800f03        mov     x3, #0x78                       // beagleboard#120
|   28:   48207c82        casp    x0, x1, x2, x3, [x4]
|   2c:   ca050000        eor     x0, x0, x5
|   30:   ca060021        eor     x1, x1, x6
|   34:   aa010000        orr     x0, x0, x1
|   38:   f9400480        ldr     x0, [x4, beagleboard#8]
|   3c:   d50323bf        autiasp
|   40:   ca0000e0        eor     x0, x7, x0
|   44:   d65f03c0        ret
|   48:   d2800240        mov     x0, #0x12                       // beagleboard#18
|   4c:   d2800681        mov     x1, #0x34                       // beagleboard#52
|   50:   d2800ac2        mov     x2, #0x56                       // beagleboard#86
|   54:   d2800f03        mov     x3, #0x78                       // beagleboard#120
|   58:   f9800091        prfm    pstl1strm, [x4]
|   5c:   c87f1885        ldxp    x5, x6, [x4]
|   60:   ca0000a5        eor     x5, x5, x0
|   64:   ca0100c6        eor     x6, x6, x1
|   68:   aa0600a6        orr     x6, x5, x6
|   6c:   b5000066        cbnz    x6, 78 <foo+0x78>
|   70:   c8250c82        stxp    w5, x2, x3, [x4]
|   74:   35ffff45        cbnz    w5, 5c <foo+0x5c>
|   78:   f9400480        ldr     x0, [x4, beagleboard#8]
|   7c:   d50323bf        autiasp
|   80:   ca0000e0        eor     x0, x7, x0
|   84:   d65f03c0        ret

... sampling the high 8 bytes before and after the cmpxchg, and
performing an EOR, as we'd expect.

For backporting, I've tested this atop linux-4.9.y with GCC 5.5.0. Note
that linux-4.9.y is oldest currently supported stable release, and
mandates GCC 5.1+. Unfortunately I couldn't get a GCC 5.1 binary to run
on my machines due to library incompatibilities.

I've also used a standalone test to check that we can use a __uint128_t
pointer in a +Q constraint at least as far back as GCC 4.8.5 and LLVM
3.9.1.

Fixes: 5284e1b ("arm64: xchg: Implement cmpxchg_double")
Fixes: e9a4b79 ("arm64: cmpxchg_dbl: patch in lse instructions when supported by the CPU")
Reported-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/lkml/Y6DEfQXymYVgL3oJ@boqun-archlinux/
Reported-by: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/lkml/Y6GXoO4qmH9OIZ5Q@hirez.programming.kicks-ass.net/
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: stable@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20230104151626.3262137-1-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants