Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2 |
|
#
6bb1504d |
| 16-Feb-2023 |
Rob Herring <robh@kernel.org> |
bus: mvebu-mbus: Remove open coded "ranges" parsing
"ranges" is a standard property, and we have common helper functions for parsing it, so let's use them.
Cc: Andrew Lunn <andrew@lunn.ch> Cc: Seba
bus: mvebu-mbus: Remove open coded "ranges" parsing
"ranges" is a standard property, and we have common helper functions for parsing it, so let's use them.
Cc: Andrew Lunn <andrew@lunn.ch> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Gregory Clement <gregory.clement@bootlin.com> Link: https://lore.kernel.org/r/20230216181204.2895676-1-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
show more ...
|
Revision tags: v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69 |
|
#
a5ccec12 |
| 16-Sep-2022 |
Liu Shixin <liushixin2@huawei.com> |
bus: mvebu-mbus: use DEFINE_SHOW_ATTRIBUTE to simplify mvebu_{sdram/devs}_debug
Use DEFINE_SHOW_ATTRIBUTE helper macro to simplify the code.
Signed-off-by: Liu Shixin <liushixin2@huawei.com> Link:
bus: mvebu-mbus: use DEFINE_SHOW_ATTRIBUTE to simplify mvebu_{sdram/devs}_debug
Use DEFINE_SHOW_ATTRIBUTE helper macro to simplify the code.
Signed-off-by: Liu Shixin <liushixin2@huawei.com> Link: https://lore.kernel.org/r/20220916141244.2174005-1-liushixin2@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51 |
|
#
85df4646 |
| 29-Jun-2022 |
Zhang Jiaming <jiaming@nfschina.com> |
bus: mvebu-mbus: Fix spelling mistake
Change 'informations' to 'information'. Change 'accross' to 'across'.
Signed-off-by: Zhang Jiaming <jiaming@nfschina.com> Link: https://lore.kernel.org/r/20220
bus: mvebu-mbus: Fix spelling mistake
Change 'informations' to 'information'. Change 'accross' to 'across'.
Signed-off-by: Zhang Jiaming <jiaming@nfschina.com> Link: https://lore.kernel.org/r/20220629060716.22310-1-jiaming@nfschina.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46 |
|
#
3bb16560 |
| 07-Jun-2022 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_56.RULE (part 2)
Based on the normalized pattern:
this file is licensed under the terms of the gnu general public license v
treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_56.RULE (part 2)
Based on the normalized pattern:
this file is licensed under the terms of the gnu general public license version 2 this program is licensed as is without any warranty of any kind whether express or implied
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6 |
|
#
859186e2 |
| 26-Nov-2021 |
Pali Rohár <pali@kernel.org> |
bus: mvebu-mbus: Export symbols for public API window functions
This would allow to compile pci-mvebu.c driver as module.
Link: https://lore.kernel.org/r/20211126144307.7568-2-pali@kernel.org Signe
bus: mvebu-mbus: Export symbols for public API window functions
This would allow to compile pci-mvebu.c driver as module.
Link: https://lore.kernel.org/r/20211126144307.7568-2-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
show more ...
|
Revision tags: v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26 |
|
#
a2fa9e57 |
| 23-Mar-2021 |
Arnd Bergmann <arnd@arndb.de> |
ARM: mvebu: avoid clang -Wtautological-constant warning
Clang warns about the comparison when using a 32-bit phys_addr_t:
drivers/bus/mvebu-mbus.c:621:17: error: result of comparison of constant 42
ARM: mvebu: avoid clang -Wtautological-constant warning
Clang warns about the comparison when using a 32-bit phys_addr_t:
drivers/bus/mvebu-mbus.c:621:17: error: result of comparison of constant 4294967296 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (reg_start >= 0x100000000ULL)
Add a cast to shut up the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20210323131952.2835509-1-arnd@kernel.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
Revision tags: v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
2241ed92 |
| 11-Nov-2020 |
Chris Packham <chris.packham@alliedtelesis.co.nz> |
bus: mvebu-mbus: make iounmap() symmetric with ioremap()
make coccicheck complains:
./drivers/bus/mvebu-mbus.c:1113:2-8: ERROR: missing iounmap; ioremap on line 1106 and execution via conditional
bus: mvebu-mbus: make iounmap() symmetric with ioremap()
make coccicheck complains:
./drivers/bus/mvebu-mbus.c:1113:2-8: ERROR: missing iounmap; ioremap on line 1106 and execution via conditional on line 1111
It took some staring but I don't think there is a problem because the file global `mbus_state` is passed mvebu_mbus_common_init() as the `mbus` parameter so `mbus_state.mbuswins_base` and `mbus->mbuswins_base` are the same thing. But this is confusing for anyone reading the code and one less complaint from coccicheck would be nice so lets fix it.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15 |
|
#
b10d6bca |
| 13-Oct-2020 |
Mike Rapoport <rppt@linux.ibm.com> |
arch, drivers: replace for_each_membock() with for_each_mem_range()
There are several occurrences of the following pattern:
for_each_memblock(memory, reg) { start = __pfn_to_phys(memblock_region
arch, drivers: replace for_each_membock() with for_each_mem_range()
There are several occurrences of the following pattern:
for_each_memblock(memory, reg) { start = __pfn_to_phys(memblock_region_memory_base_pfn(reg); end = __pfn_to_phys(memblock_region_memory_end_pfn(reg));
/* do something with start and end */ }
Using for_each_mem_range() iterator is more appropriate in such cases and allows simpler and cleaner code.
[akpm@linux-foundation.org: fix arch/arm/mm/pmsa-v7.c build] [rppt@linux.ibm.com: mips: fix cavium-octeon build caused by memblock refactoring] Link: http://lkml.kernel.org/r/20200827124549.GD167163@linux.ibm.com
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Baoquan He <bhe@redhat.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Daniel Axtens <dja@axtens.net> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Emil Renner Berthing <kernel@esmil.dk> Cc: Hari Bathini <hbathini@linux.ibm.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Simek <monstr@monstr.eu> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Stafford Horne <shorne@gmail.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will@kernel.org> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Link: https://lkml.kernel.org/r/20200818151634.14343-13-rppt@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6 |
|
#
c655f7ea |
| 27-Aug-2018 |
Rob Herring <robh@kernel.org> |
bus: mvebu-mbus: Convert to using %pOFn instead of device_node.name
In preparation to remove the node name pointer from struct device_node, convert printf users to use the %pOFn format specifier.
S
bus: mvebu-mbus: Convert to using %pOFn instead of device_node.name
In preparation to remove the node name pointer from struct device_node, convert printf users to use the %pOFn format specifier.
Signed-off-by: Rob Herring <robh@kernel.org>
show more ...
|
Revision tags: v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14, v4.13.5, v4.13 |
|
#
2bbbd963 |
| 28-Aug-2017 |
Jan Luebbe <jlu@pengutronix.de> |
bus: mbus: fix window size calculation for 4GB windows
At least the Armada XP SoC supports 4GB on a single DRAM window. Because the size register values contain the actual size - 1, the MSB is set i
bus: mbus: fix window size calculation for 4GB windows
At least the Armada XP SoC supports 4GB on a single DRAM window. Because the size register values contain the actual size - 1, the MSB is set in that case. For example, the SDRAM window's control register's value is 0xffffffe1 for 4GB (bits 31 to 24 contain the size).
The MBUS driver reads back each window's size from registers and calculates the actual size as (control_reg | ~DDR_SIZE_MASK) + 1, which overflows for 32 bit values, resulting in other miscalculations further on (a bad RAM window for the CESA crypto engine calculated by mvebu_mbus_setup_cpu_target_nooverlap() in my case).
This patch changes the type in 'struct mbus_dram_window' from u32 to u64, which allows us to keep using the same register calculation code in most MBUS-using drivers (which calculate ->size - 1 again).
Fixes: fddddb52a6c4 ("bus: introduce an Marvell EBU MBus driver") CC: stable@vger.kernel.org Signed-off-by: Jan Luebbe <jlu@pengutronix.de> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
show more ...
|
Revision tags: v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14 |
|
#
ac29abf3 |
| 21-Jun-2016 |
Ben Dooks <ben.dooks@codethink.co.uk> |
bus: mvebu-mbus: make mvebu_mbus_syscore_ops static
Make mvebu_mbus_syscore_ops static as it does not get used or declared outside mvebu-mbus.c to fix the following sparse warning:
linux/drivers/bu
bus: mvebu-mbus: make mvebu_mbus_syscore_ops static
Make mvebu_mbus_syscore_ops static as it does not get used or declared outside mvebu-mbus.c to fix the following sparse warning:
linux/drivers/bus/mvebu-mbus.c:1092:20: warning: symbol 'mvebu_mbus_syscore_ops' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
show more ...
|
#
fce7b5ae |
| 21-Jun-2016 |
Ben Dooks <ben.dooks@codethink.co.uk> |
bus: mvebu-mbus: fix __iomem on register pointers
The save_cpu_target functions should take "u32 __iomem *", not a plain "u32 *" as it is passed to register access functions. Fix the following warni
bus: mvebu-mbus: fix __iomem on register pointers
The save_cpu_target functions should take "u32 __iomem *", not a plain "u32 *" as it is passed to register access functions. Fix the following warnings by adding the annotation:
drivers/bus/mvebu-mbus.c:739:17: warning: incorrect type in argument 2 (different address spaces) drivers/bus/mvebu-mbus.c:739:17: expected void volatile [noderef] <asn:2>*addr drivers/bus/mvebu-mbus.c:739:17: got unsigned int [usertype] * drivers/bus/mvebu-mbus.c:741:17: warning: incorrect type in argument 2 (different address spaces) drivers/bus/mvebu-mbus.c:741:17: expected void volatile [noderef] <asn:2>*addr drivers/bus/mvebu-mbus.c:741:17: got unsigned int [usertype] * drivers/bus/mvebu-mbus.c:742:17: warning: incorrect type in argument 2 (different address spaces) drivers/bus/mvebu-mbus.c:742:17: expected void volatile [noderef] <asn:2>*addr drivers/bus/mvebu-mbus.c:742:17: got unsigned int [usertype] * drivers/bus/mvebu-mbus.c:744:17: warning: incorrect type in argument 2 (different address spaces) drivers/bus/mvebu-mbus.c:744:17: expected void volatile [noderef] <asn:2>*addr drivers/bus/mvebu-mbus.c:744:17: got unsigned int [usertype] * drivers/bus/mvebu-mbus.c:790:17: warning: incorrect type in argument 2 (different address spaces) drivers/bus/mvebu-mbus.c:790:17: expected void volatile [noderef] <asn:2>*addr drivers/bus/mvebu-mbus.c:790:17: got unsigned int [usertype] * drivers/bus/mvebu-mbus.c:792:17: warning: incorrect type in argument 2 (different address spaces) drivers/bus/mvebu-mbus.c:792:17: expected void volatile [noderef] <asn:2>*addr drivers/bus/mvebu-mbus.c:792:17: got unsigned int [usertype] *
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
show more ...
|
Revision tags: v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6 |
|
#
77644ad8 |
| 15-Mar-2016 |
Arnd Bergmann <arnd@arndb.de> |
bus: mvebu-mbus: use %pa to print phys_addr_t
A recent change to the mbus driver added a warning printk that prints a phys_addr_t using the %x format string, which fails in case we build with 64-bit
bus: mvebu-mbus: use %pa to print phys_addr_t
A recent change to the mbus driver added a warning printk that prints a phys_addr_t using the %x format string, which fails in case we build with 64-bit phys_addr_t:
drivers/bus/mvebu-mbus.c: In function 'mvebu_mbus_get_dram_win_info': drivers/bus/mvebu-mbus.c:975:9: error: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'phys_addr_t {aka long long unsigned int}' [-Werror=format=]
This uses the special %pa format string instead, so we always print the correct type.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: f2900acea801 ("bus: mvebu-mbus: provide api for obtaining IO and DRAM window information") Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
show more ...
|
#
f2900ace |
| 14-Mar-2016 |
Marcin Wojtas <mw@semihalf.com> |
bus: mvebu-mbus: provide api for obtaining IO and DRAM window information
This commit enables finding appropriate mbus window and obtaining its target id and attribute for given physical address in
bus: mvebu-mbus: provide api for obtaining IO and DRAM window information
This commit enables finding appropriate mbus window and obtaining its target id and attribute for given physical address in two separate routines, both for IO and DRAM windows. This functionality is needed for Armada XP/38x Network Controller's Buffer Manager and PnC configuration.
[gregory.clement@free-electrons.com: Fix size test for mvebu_mbus_get_dram_win_info]
Signed-off-by: Marcin Wojtas <mw@semihalf.com> [DRAM window information reference in LKv3.10] Signed-off-by: Evan Wang <xswang@marvell.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1, openbmc-20151123-1, openbmc-20151118-1, openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6 |
|
#
bfa1ce5f |
| 28-May-2015 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
bus: mvebu-mbus: add mv_mbus_dram_info_nooverlap()
This commit introduces a variant of the mv_mbus_dram_info() function called mv_mbus_dram_info_nooverlap(). Both functions are used by Marvell drive
bus: mvebu-mbus: add mv_mbus_dram_info_nooverlap()
This commit introduces a variant of the mv_mbus_dram_info() function called mv_mbus_dram_info_nooverlap(). Both functions are used by Marvell drivers supporting devices doing DMA, and provide them a description the DRAM ranges that they need to configure their DRAM windows.
The ranges provided by the mv_mbus_dram_info() function may overlap with the I/O windows if there is a lot (>= 4 GB) of RAM installed. This is not a problem for most of the DMA masters, except for the upcoming new CESA crypto driver because it does DMA to the SRAM, which is mapped through an I/O window. For this unit, we need to have DRAM ranges that do not overlap with the I/O windows.
A first implementation done in commit 1737cac69369 ("bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window"), changed the information returned by mv_mbus_dram_info() to match this requirement. However, it broke the requirement of the other DMA masters than the DRAM ranges should have power of two sizes.
To solve this situation, this commit introduces a new mv_mbus_dram_info_nooverlap() function, which returns the same information as mv_mbus_dram_info(), but guaranteed to not overlap with the I/O windows.
In the end, it gives us two variants of the mv_mbus_dram_info*() functions:
- The normal one, mv_mbus_dram_info(), which has been around for many years. This function returns the raw DRAM ranges, which are guaranteed to use power of two sizes, but will overlap with I/O windows. This function will therefore be used by all DMA masters (SATA, XOR, Ethernet, etc.) except the CESA crypto driver.
- The new 'nooverlap' variant, mv_mbus_dram_info_nooverlap(). This function returns DRAM ranges after they have been "tweaked" to make sure they don't overlap with I/O windows. By doing this tweaking, we remove the power of two size guarantee. This variant will be used by the new CESA crypto driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
show more ...
|
#
885dbd15 |
| 28-May-2015 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
Revert "bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window"
This reverts commit 1737cac69369 ("bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge
Revert "bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window"
This reverts commit 1737cac69369 ("bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window"), because it breaks DMA on platforms having more than 2 GB of RAM.
This commit changed the information reported to DMA masters device drivers through the mv_mbus_dram_info() function so that the returned DRAM ranges do not overlap with I/O windows.
This was necessary as a preparation to support the new CESA Crypto Engine driver, which will use DMA for cryptographic operations. But since it does DMA with the SRAM which is mapped as an I/O window, having DRAM ranges overlapping with I/O windows was problematic.
To solve this, the above mentioned commit changed the mvebu-mbus to adjust the DRAM ranges so that they don't overlap with the I/O windows. However, by doing this, we re-adjust the DRAM ranges in a way that makes them have a size that is no longer a power of two. While this is perfectly fine for the Crypto Engine, which supports DRAM ranges with a granularity of 64 KB, it breaks basically all other DMA masters, which expect power of two sizes for the DRAM ranges.
Due to this, if the installed system memory is 4 GB, in two chip-selects of 2 GB, the second DRAM range will be reduced from 2 GB to a little bit less than 2 GB to not overlap with the I/O windows, in a way that results in a DRAM range that doesn't have a power of two size. This means that whenever you do a DMA transfer with an address located in the [ 2 GB ; 4 GB ] area, it will freeze the system. Any serious DMA activity like simply running:
for i in $(seq 1 64) ; do dd if=/dev/urandom of=file$i bs=1M count=16 ; done
in an ext3 partition mounted over a SATA drive will freeze the system.
Since the new CESA crypto driver that uses DMA has not been merged yet, the easiest fix is to simply revert this commit. A follow-up commit will introduce a different solution for the CESA crypto driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Fixes: 1737cac69369 ("bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window") Cc: <stable@vger.kernel.org> # v4.0+ Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
show more ...
|
#
8c9e06e6 |
| 28-May-2015 |
Nicolas Schichan <nschichan@freebox.fr> |
bus: mvebu-mbus: do not set WIN_CTRL_SYNCBARRIER on non io-coherent platforms.
Commit a0b5cd4ac2d6 ("bus: mvebu-mbus: use automatic I/O synchronization barriers") enabled the usage of automatic I/O
bus: mvebu-mbus: do not set WIN_CTRL_SYNCBARRIER on non io-coherent platforms.
Commit a0b5cd4ac2d6 ("bus: mvebu-mbus: use automatic I/O synchronization barriers") enabled the usage of automatic I/O synchronization barriers by enabling bit WIN_CTRL_SYNCBARRIER in the control registers of MBus windows, but on non io-coherent platforms (orion5x, kirkwood and dove) the WIN_CTRL_SYNCBARRIER bit in the window control register is either reserved (all windows except 6 and 7) or enables read-only protection (windows 6 and 7).
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: <stable@vger.kernel.org> # v4.0+ Fixes: a0b5cd4ac2d6 ("bus: mvebu-mbus: use automatic I/O synchronization barriers") Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
show more ...
|
Revision tags: v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4 |
|
#
1737cac6 |
| 09-Jan-2015 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window
The mvebu-mbus driver reads the SDRAM window registers, and make the information about the DRAM CS configuration avai
bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window
The mvebu-mbus driver reads the SDRAM window registers, and make the information about the DRAM CS configuration available to device drivers using the mv_mbus_dram_info() API. This information is used by the DMA-capable device drivers to program their address decoding windows.
Until now, we were basically providing the SDRAM window register details as is. However, it turns out that the DMA capability of the CESA cryptographic engine consists in doing DMA being the DRAM and the crypto SRAM mapped as a MBus window. For this case, it is very important that the SDRAM CS information does not overlap with the MBus bridge window.
Therefore, this commit improves the mvebu-mbus driver to make sure we adjust the SDRAM CS information so that it doesn't overlap with the MBus bridge window. This problem was reported by Boris Brezillon, while working on the mv_cesa driver for Armada 37x/38x/XP. We use the memblock memory information to know where the usable RAM is located, as this information is guaranteed to be correct on all SoC variants.
We could have used the MBus bridge window registers on Armada 370/XP, but they are not really used on Armada 375/38x (Cortex-A9 based), since the PL310 L2 filtering is used instead to discriminate between RAM accesses and I/O accesses. Therefore, using the memblock information is more generic and works accross the different platforms.
Reported-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [Andrew Lunn <andrew@lunn.ch>: Fixed merge conflict] Signed-off-by: Andrew Lunn <andrew@lunn.ch>
show more ...
|
Revision tags: v3.19-rc3 |
|
#
7fdf3d8a |
| 30-Dec-2014 |
Michal Mazur <arg@semihalf.com> |
bus: mvebu-mbus: fix support of MBus window 13 on Armada XP/375/38x
On Armada XP, 375 and 38x the MBus window 13 has the remap capability, like windows 0 to 7. However, the mvebu-mbus driver isn't c
bus: mvebu-mbus: fix support of MBus window 13 on Armada XP/375/38x
On Armada XP, 375 and 38x the MBus window 13 has the remap capability, like windows 0 to 7. However, the mvebu-mbus driver isn't currently taking into account this special case, which means that when window 13 is actually used, the remap registers are left to 0, making the device using this MBus window unavailable.
To make things even more fun, the hardware designers have chosen to put the window 13 remap registers in a completely custom location, using a logic that differs from the one used for all other remappable windows.
To solve this problem, this commit:
* Adds a SoC specific function to calculate offset of remap registers to the mvebu_mbus_soc_data structure. This function, ->win_remap_offset(), returns the offset of the remap registers, or MVEBU_MBUS_NO_REMAP if the window does not have the remap capability. This new function replaces the previous integer field num_remappable_wins, which was insufficient to encode the special case of window 13.
* Adds an implementation of the ->win_remap_offset() function for the various SoC families. Some have 2 first windows that are remapable, some the 4 first, some the 8 first, and then the Armada XP/375/38x case where the 8 first are remapable plus the special window 13. This is implemented in functions generic_mbus_win_remap_2_offset(), generic_mbus_win_remap_4_offset(), generic_mbus_win_remap_8_offset() and armada_xp_mbus_win_remap_offset() respectively.
* Change the code to use the ->win_remap_offset() function when accessing the remap registers, and also to use a newly introduced mvebu_mbus_window_is_remappable() helper function that tells whether a given window is remapable or not.
* Separate Armada 370 from XP/375/38X because the window 13 of Armada 370 does not support the remap capability.
[Thomas: adapted for the mainline kernel, minor clarifications in the code, reword the commit log.]
Signed-off-by: Michal Mazur <arg@semihalf.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [Andrew Lunn <andrew@lunn.ch>: Undo the simple fix for stable] Signed-off-by: Andrew Lunn <andrew@lunn.ch>
show more ...
|
#
a0b5cd4a |
| 16-Jan-2015 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
bus: mvebu-mbus: use automatic I/O synchronization barriers
Instead of using explicit I/O synchronization barriers shoehorned inside the streaming DMA mappings API (in arch/arm/mach-mvebu/coherency.
bus: mvebu-mbus: use automatic I/O synchronization barriers
Instead of using explicit I/O synchronization barriers shoehorned inside the streaming DMA mappings API (in arch/arm/mach-mvebu/coherency.c), we are switching to use automatic I/O synchronization barrier.
The primary motivation for this change is that explicit I/O synchronization barriers are not only needed for streaming DMA mappings (which can easily be done by overriding the dma_map_ops), but also for coherent DMA mappings (which is a lot less easy to do, since the kernel assumes such mappings are coherent and don't require any sort of cache maintenance operation to ensure the consistency of the buffers).
Switching to automatic I/O synchronization barriers will also allow us to use the existing arm_coherent_dma_ops instead of our custom arm_dma_ops.
In order to use automatic I/O synchronization barriers, this commit changes mvebu-mbus in two ways:
- It enables automatic I/O synchronization barriers in the 0x84 register of the MBus bridge, by enabling such barriers for all MBus units. This enables automatic barriers for the on-SoC peripherals that are doing DMA.
- It enables the SyncEnable bit in the MBus windows, so that PCIe devices also use automatic I/O synchronization barrier.
This automatic synchronization barrier relies on the assumption that at least one register of a given hardware unit is read before the driver accesses the DMA mappings modified by this unit. This assumption is guaranteed for PCI devices by vertue of the PCI standard, and we can reasonably verify that this assumption is also true for the limited number of platform drivers doing DMA used on Marvell EBU platforms.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
show more ...
|
#
38bdf45f |
| 18-Jan-2015 |
Andrew Lunn <andrew@lunn.ch> |
bus: mvebu-mbus: fix support of MBus window 13
On Armada XP, 375 and 38x the MBus window 13 has the remap capability, like windows 0 to 7. However, the mvebu-mbus driver isn't currently taking into
bus: mvebu-mbus: fix support of MBus window 13
On Armada XP, 375 and 38x the MBus window 13 has the remap capability, like windows 0 to 7. However, the mvebu-mbus driver isn't currently taking into account this special case, which means that when window 13 is actually used, the remap registers are left to 0, making the device using this MBus window unavailable.
As a minimal fix for stable, don't use window 13. A full fix will follow later.
Fixes: fddddb52a6c ("bus: introduce an Marvell EBU MBus driver") Cc: <stable@vger.kernel.org> # v3.10+ Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
show more ...
|
Revision tags: v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6 |
|
#
4749c02b |
| 21-Nov-2014 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
bus: mvebu-mbus: provide a mechanism to save SDRAM window configuration
On Marvell EBU platforms, when doing suspend/resume, the SDRAM window configuration must be saved on suspend, and restored on
bus: mvebu-mbus: provide a mechanism to save SDRAM window configuration
On Marvell EBU platforms, when doing suspend/resume, the SDRAM window configuration must be saved on suspend, and restored on resume. However, it needs to be restored on resume *before* re-entering the kernel, because the SDRAM window configuration defines the layout of the memory. For this reason, it cannot simply be done in the ->suspend() and ->resume() hooks of the mvebu-mbus driver.
Instead, it needs to be restored by the bootloader "boot info" mechanism used when resuming. This mechanism allows the kernel to define a list of (address, value) pairs when suspending, that the bootloader will restore on resume before jumping back into the kernel.
This commit therefore adds a new function to the mvebu-mbus driver, called mvebu_mbus_save_cpu_target(), which will be called by the platform code to make the mvebu-mbus driver save the SDRAM window configuration in a way that can be understood by the bootloader "boot info" mechanism.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1416585613-2113-8-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
show more ...
|
#
a0e89c02 |
| 21-Nov-2014 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
bus: mvebu-mbus: suspend/resume support
This commit extends the mvebu-mbus driver to provide suspend/resume support. Since mvebu-mbus is not a platform_driver, the syscore_ops mechanism is used to g
bus: mvebu-mbus: suspend/resume support
This commit extends the mvebu-mbus driver to provide suspend/resume support. Since mvebu-mbus is not a platform_driver, the syscore_ops mechanism is used to get ->suspend() and ->resume() hooks called into the driver.
In those hooks, we save and restore the MBus windows state, to make sure after resume all Mbus windows are properly restored. Note that while the state of some windows could be gathered by looking again at the Device Tree (for statically described windows), it is not the case of dynamically described windows such as the PCIe memory and I/O windows. Therefore, we take the simple approach of saving and restoring the registers for all MBus windows.
In addition, the commit extends the Device Tree binding of the MBus controller, to control the MBus bridge registers (which define which parts of the physical address space is routed to MBus windows vs. normal RAM memory). Those registers must be saved and restored during suspend/resume. The Device Tree binding extension is made is a backward compatible fashion, but of course, suspend/resume will not work without the Device Tree update.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1416585613-2113-7-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
show more ...
|
Revision tags: v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2 |
|
#
5686a1e5 |
| 14-Apr-2014 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
bus: mvebu: pass the coherency availability information at init time
Until now, the mvebu-mbus was guessing by itself whether hardware I/O coherency was available or not by poking into the Device Tr
bus: mvebu: pass the coherency availability information at init time
Until now, the mvebu-mbus was guessing by itself whether hardware I/O coherency was available or not by poking into the Device Tree to see if the coherency fabric Device Tree node was present or not.
However, on some upcoming SoCs, the presence or absence of the coherency fabric DT node isn't sufficient: in CONFIG_SMP, the coherency can be enabled, but not in !CONFIG_SMP.
In order to clean this up, the mvebu_mbus_dt_init() function is extended to get a boolean argument telling whether coherency is enabled or not. Therefore, the logic to decide whether coherency is available or not now belongs to the core SoC code instead of the mvebu-mbus driver itself, which is much better.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397483228-25625-4-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
show more ...
|
#
b566e782 |
| 18-Apr-2014 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
bus: mvebu-mbus: allow several windows with the same target/attribute
Having multiple windows with the same target and attribute is actually legal, and can be useful for PCIe windows, when PCIe BARs
bus: mvebu-mbus: allow several windows with the same target/attribute
Having multiple windows with the same target and attribute is actually legal, and can be useful for PCIe windows, when PCIe BARs have a size that isn't a power of two, and we therefore need to create several MBus windows to cover the PCIe BAR for a given PCIe interface.
Fixes: fddddb52a6c4 ('bus: introduce an Marvell EBU MBus driver') Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397823593-1932-7-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex <neil@fatboyfat.co.uk> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
show more ...
|